Xen devel - Jan 2007 - [PATCH 0/3] Use string bound functions (take #2)

Hi!

I killed safe_strcpy() and almost all users from strcpy() and strncpy().
The remaining users are acm and acpi.
When this is done, strcpy() and strncpy() can be removed.


patch 1/3:
Changes arch-independent code.
Warning: Since tools re-uses libelf, this breaks the tool-building of the 
Linux distris, whose glibc have NO strlcpy/strlcat. 
Solaris and *BSD are fine. They have these functions.
Keir, it''s up to you if you apply this or if you wait until a fix for
the
tools is available.

patch 2/3:
Changes for x86 platform.

patch 3/3:
Changes for ppc/ia64 platforms.
Warning: Due to lack of hw, these two patches are NOT even compile-tested.
IA64 and PPC maintainers, please verify.



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

On 29/1/07 14:22, "Christoph Egger" <Christoph.Egger@amd.com>
wrote:
> I killed safe_strcpy() and almost all users from strcpy() and strncpy().
> The remaining users are acm and acpi.
> When this is done, strcpy() and strncpy() can be removed.
Okay, there are no live users of strcpy/strncpy/strcat/strncat (I fixed the
acm uses and the acpi uses are dead macros that aren''t used). So
I''ve killed
off those functions, #defined them to informative undefined labels, and
implemented strlcat().

sprintf() can go once the ia64 uses are fixed up.

 -- Keir


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

xen-devel-bounces@lists.xensource.com wrote on 01/29/2007 11:07:18 AM:
> On 29/1/07 14:22, "Christoph Egger"
<Christoph.Egger@amd.com> wrote:
> 
> > I killed safe_strcpy() and almost all users from strcpy() and 
strncpy().
> > The remaining users are acm and acpi.
Thanks. This would have been it -- I am sure you did the same.

Signed-off-by: Stefan Berger <stefanb@us.ibm.com>


Index: root/xen-unstable.hg/xen/acm/acm_core.c
==================================================================---
root.orig/xen-unstable.hg/xen/acm/acm_core.c
+++ root/xen-unstable.hg/xen/acm/acm_core.c
@@ -89,7 +89,9 @@ acm_set_policy_reference(u8 * buf, u32 b
     if (!acm_bin_pol.policy_reference_name)
         return -ENOMEM;
 
-    strcpy(acm_bin_pol.policy_reference_name, (char *)(buf + 
sizeof(struct acm_policy_reference_buffer)));
+    strlcpy(acm_bin_pol.policy_reference_name,
+            (char *)(buf + sizeof(struct acm_policy_reference_buffer)),
+            ntohl(pr->len));
     printk("%s: Activating policy %s\n", __func__, 
acm_bin_pol.policy_reference_name);
     return 0;
 }
@@ -106,8 +108,9 @@ acm_dump_policy_reference(u8 *buf, u32 b
 
     memset(buf, 0, ret);
     pr_buf->len = htonl(strlen(acm_bin_pol.policy_reference_name) + 1); 
/* including stringend ''\0'' */
-    strcpy((char *)(buf + sizeof(struct acm_policy_reference_buffer)),
-           acm_bin_pol.policy_reference_name);
+    strlcpy((char *)(buf + sizeof(struct acm_policy_reference_buffer)),
+            acm_bin_pol.policy_reference_name,
+            buf_size - sizeof(struct acm_policy_reference_buffer));
     return ret;
 }
 



> > When this is done, strcpy() and strncpy() can be removed.
> 
> Okay, there are no live users of strcpy/strncpy/strcat/strncat (I fixed 
the
> acm uses and the acpi uses are dead macros that aren''t used). So
I''ve
killed
> off those functions, #defined them to informative undefined labels, and
> implemented strlcat().
> 
> sprintf() can go once the ia64 uses are fixed up.
> 
>  -- Keir
> 
> 
> _______________________________________________
> 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

On 29/1/07 16:22, "Stefan Berger" <stefanb@us.ibm.com> wrote:
>> > On 29/1/07 14:22, "Christoph Egger"
<Christoph.Egger@amd.com> wrote:
>> > 
>>> > > I killed safe_strcpy() and almost all users from strcpy()
and strncpy().
>>> > > The remaining users are acm and acpi.
> 
> Thanks. This would have been it -- I am sure you did the same.
> 
> Signed-off-by: Stefan Berger <stefanb@us.ibm.com>
Same for the first one. A bit different for the second one (but I¹m sure
it¹s okay either way: there¹s already a test against buf_size earlier in
that function). I¹d appreciate it if you glance an eye over it when it hits
the public tree later on.

 -- Keir



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

On Monday 29 January 2007 17:07, Keir Fraser wrote:
> On 29/1/07 14:22, "Christoph Egger"
<Christoph.Egger@amd.com> wrote:
> > I killed safe_strcpy() and almost all users from strcpy() and
strncpy().
> > The remaining users are acm and acpi.
> > When this is done, strcpy() and strncpy() can be removed.
>
> Okay, there are no live users of strcpy/strncpy/strcat/strncat (I fixed the
> acm uses and the acpi uses are dead macros that aren''t used). So
I''ve
> killed off those functions, #defined them to informative undefined labels,
> and implemented strlcat().
>
> sprintf() can go once the ia64 uses are fixed up.
Great! When do these changes appear in the public tree?

Christoph



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

On 30/1/07 08:23, "Christoph Egger" <Christoph.Egger@amd.com>
wrote:
>> Okay, there are no live users of strcpy/strncpy/strcat/strncat (I fixed
the
>> acm uses and the acpi uses are dead macros that aren''t used).
So I''ve
>> killed off those functions, #defined them to informative undefined
labels,
>> and implemented strlcat().
>> 
>> sprintf() can go once the ia64 uses are fixed up.
> 
> Great! When do these changes appear in the public tree?
Some are already in. The rest should push today; hopefully regression tests
will pass and the tree will get pushed automatically.

 -- Keir



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