Mailing List Archive: Re: [Xen-staging] [xen-unstable] ia64, ppc: Remove uses of sprintf().

On Tue, 2007-01-30 at 16:14 +0000, Xen staging patchbot-unstable wrote:
> diff -r 300c47bec138 -r bd69e83b65ea xen/arch/ia64/linux-xen/setup.c
> --- a/xen/arch/ia64/linux-xen/setup.c Tue Jan 30 16:09:16 2007 +0000
> +++ b/xen/arch/ia64/linux-xen/setup.c Tue Jan 30 16:14:16 2007 +0000
> @@ -550,7 +550,7 @@ show_cpuinfo (struct seq_file *m, void *
> switch (c->family) {
> case 0x07: memcpy(family, "Itanium", 8); break;
> case 0x1f: memcpy(family, "Itanium 2", 10); break;
> - default: sprintf(family, "%u", c->family); break;
> + default: snprintf(family, sizeof(family), "%u", c->family); break;
> }

What's the purpose of all this "cleanup"? This is just munging files
that we're leveraging from Linux, making updating them later on more
difficult. And these really should have been submitted via the
xen-ia64-devel list.

Alex

--
Alex Williamson HP Open Source & Linux Org.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On 30/1/07 5:03 pm, "Alex Williamson" <alex.williamson@hp.com> wrote:

> What's the purpose of all this "cleanup"? This is just munging files
> that we're leveraging from Linux, making updating them later on more
> difficult. And these really should have been submitted via the
> xen-ia64-devel list.

The aim is to get rid of the 'dangerous' sprintf/strcat/strcpy functions.
Obviously not all uses are unsafe but if we don't define them then dangerous
uses can't creep in. There were already a few uses throughout Xen where
overflow might have silently become a possibility in future (although none
would be obviously exploitable). On the x86 side at least it turned out that
only a few Linux-derived lines of code had to be modified which seems an
acceptable price to pay.

If you still need those functions (do you still grab and munge a whole Linux
tree to make Xen on ia64?) then you can define them just for ia64/linux-xen
to provide a Linux-y environment, in which case it would make sense to
revert any removal patches applied in that subtree.

-- Keir

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel