Hi! The attached patch replaces sprintf with snprintf and strncpy with strlcpy. There are various cases where no NULL-terminated strings are guaranteed and eventual possible overflows. This patch fixes them. BTW: Since Xen kernel has its own string functions, can''t we just remove sprintf() and strncpy()? IMO, Xen should not inherit the historical C relicts. Christoph _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On 29/1/07 10:10, "Christoph Egger" <Christoph.Egger@amd.com> wrote:> The attached patch replaces sprintf with snprintf and strncpy with strlcpy. > > There are various cases where no NULL-terminated strings are guaranteed > and eventual possible overflows. This patch fixes them. > > BTW: Since Xen kernel has its own string functions, can''t we just remove > sprintf() and strncpy()? IMO, Xen should not inherit the historical C relicts.This makes plenty of sense. Strncpy() in particular is dangerous and strlcpy() is always preferable. So I''d be happy to see strncat/strncpy die. There are a few uses remaining (particularly in arch/ia64) that you''ll have to fix first. And please add ''signed-off-by'' attribution when you post patches! -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Christoph Egger
2007-Jan-29 11:10 UTC
Re: [Xen-devel] [PATCH] Use string bounded functions
On Monday 29 January 2007 11:52, Keir Fraser wrote:> On 29/1/07 10:10, "Christoph Egger" <Christoph.Egger@amd.com> wrote: > > The attached patch replaces sprintf with snprintf and strncpy with > > strlcpy. > > > > There are various cases where no NULL-terminated strings are guaranteed > > and eventual possible overflows. This patch fixes them. > > > > BTW: Since Xen kernel has its own string functions, can''t we just remove > > sprintf() and strncpy()? IMO, Xen should not inherit the historical C > > relicts. > > This makes plenty of sense. Strncpy() in particular is dangerous and > strlcpy() is always preferable. So I''d be happy to see strncat/strncpy die.sprintf() is also dangerous. snprintf() is better. sprintf() should also die.> There are a few uses remaining (particularly in arch/ia64) that you''ll have > to fix first.Yeah. But due to lack of hw, I can''t even build test for ia64 and ppc. So when I send the patches, intel and ibm have to verify first that they don''t break anything.> And please add ''signed-off-by'' attribution when you post patches!Will do. Christoph _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
I''m all for this. Are we going to mark all the "bad" ones as deprecated for some time? -JX On Jan 29, 2007, at 6:10 AM, Christoph Egger wrote:> On Monday 29 January 2007 11:52, Keir Fraser wrote: >> On 29/1/07 10:10, "Christoph Egger" <Christoph.Egger@amd.com> wrote: >>> The attached patch replaces sprintf with snprintf and strncpy with >>> strlcpy. >>> >>> There are various cases where no NULL-terminated strings are >>> guaranteed >>> and eventual possible overflows. This patch fixes them. >>> >>> BTW: Since Xen kernel has its own string functions, can''t we just >>> remove >>> sprintf() and strncpy()? IMO, Xen should not inherit the >>> historical C >>> relicts. >> >> This makes plenty of sense. Strncpy() in particular is dangerous and >> strlcpy() is always preferable. So I''d be happy to see strncat/ >> strncpy die. > > sprintf() is also dangerous. snprintf() is better. sprintf() should > also die. > >> There are a few uses remaining (particularly in arch/ia64) that >> you''ll have >> to fix first. > > Yeah. But due to lack of hw, I can''t even build test for ia64 and ppc. > So when I send the patches, intel and ibm have to verify first that > they don''t > break anything. > >> And please add ''signed-off-by'' attribution when you post patches! > > Will do. > > Christoph > > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
That''s overkill really. Once the uses are all gone from the repository we can just kill them off. Any out-of-tree patches can easily be fixed up. -- Keir On 29/1/07 13:41, "Jimi Xenidis" <jimix@watson.ibm.com> wrote:> I''m all for this. > Are we going to mark all the "bad" ones as deprecated for some time? > -JX > > On Jan 29, 2007, at 6:10 AM, Christoph Egger wrote: > >> On Monday 29 January 2007 11:52, Keir Fraser wrote: >>> On 29/1/07 10:10, "Christoph Egger" <Christoph.Egger@amd.com> wrote: >>>> The attached patch replaces sprintf with snprintf and strncpy with >>>> strlcpy. >>>> >>>> There are various cases where no NULL-terminated strings are >>>> guaranteed >>>> and eventual possible overflows. This patch fixes them. >>>> >>>> BTW: Since Xen kernel has its own string functions, can''t we just >>>> remove >>>> sprintf() and strncpy()? IMO, Xen should not inherit the >>>> historical C >>>> relicts. >>> >>> This makes plenty of sense. Strncpy() in particular is dangerous and >>> strlcpy() is always preferable. So I''d be happy to see strncat/ >>> strncpy die. >> >> sprintf() is also dangerous. snprintf() is better. sprintf() should >> also die. >> >>> There are a few uses remaining (particularly in arch/ia64) that >>> you''ll have >>> to fix first. >> >> Yeah. But due to lack of hw, I can''t even build test for ia64 and ppc. >> So when I send the patches, intel and ibm have to verify first that >> they don''t >> break anything. >> >>> And please add ''signed-off-by'' attribution when you post patches! >> >> Will do. >> >> Christoph >> >> >> >> _______________________________________________ >> Xen-devel mailing list >> Xen-devel@lists.xensource.com >> http://lists.xensource.com/xen-devel > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel