[PATCH] stubdom: fix errors in newlib

[PATCH] stubdom: fix errors in newlib

[Olaf Hering]

# HG changeset patch
# User Olaf Hering <olaf@aepfle.de>
# Date 1341839122 -7200
# Node ID 2dd50c201ca0d3542f3589942ae9e51d33ec7509
# Parent  42f76d536b116d2ebad1b6705ae51ecd171d2581
stubdom: fix errors in newlib

rpmlint found a few code bugs in newlib, and marks them as errors after
rpm build. Add another newlib patch and apply it during stubdom build.

I: A function uses a 'return;' statement, but has actually a value
   to return, like an integer ('return 42;') or similar.
W: xen voidreturn ../../../../newlib-1.16.0/libgloss/i386/cygmon-gmon.c:117, 125, 146, 157, 330

I: Program is using implicit definitions of special functions.
   these functions need to use their correct prototypes to allow
   the lightweight buffer overflow checking to work.
     - Implicit memory/string functions need #include <string.h>.
     - Implicit *printf functions need #include <stdio.h>.
     - Implicit *printf functions need #include <stdio.h>.
     - Implicit *read* functions need #include <unistd.h>.
     - Implicit *recv* functions need #include <sys/socket.h>.
E: xen implicit-fortify-decl ../../../../newlib-1.16.0/libgloss/i386/cygmon-gmon.c:119

I: Program returns random data in a function
E: xen no-return-in-nonvoid-function ../../../../newlib-1.16.0/libgloss/i386/cygmon-gmon.c:362


Signed-off-by: Olaf Hering <olaf@aepfle.de>

diff -r 42f76d536b11 -r 2dd50c201ca0 stubdom/Makefile
--- a/stubdom/Makefile
+++ b/stubdom/Makefile
@@ -102,6 +102,7 @@ newlib-$(NEWLIB_VERSION): newlib-$(NEWLI
 	patch -d $@ -p0 < newlib.patch
 	patch -d $@ -p0 < newlib-chk.patch
 	patch -d $@ -p1 < newlib-stdint-size_max-fix-from-1.17.0.patch
+	patch -d $@ -p1 < newlib-cygmon-gmon.patch
 	find $@ -type f | xargs perl -i.bak \
 		-pe 's/\b_(tzname|daylight|timezone)\b/$$1/g'
 	touch $@
diff -r 42f76d536b11 -r 2dd50c201ca0 stubdom/newlib-cygmon-gmon.patch
--- /dev/null
+++ b/stubdom/newlib-cygmon-gmon.patch
@@ -0,0 +1,51 @@
+
+I: A function uses a 'return;' statement, but has actually a value
+   to return, like an integer ('return 42;') or similar.
+W: xen voidreturn ../../../../newlib-1.16.0/libgloss/i386/cygmon-gmon.c:117, 125, 146, 157, 330
+
+I: Program is using implicit definitions of special functions.
+   these functions need to use their correct prototypes to allow
+   the lightweight buffer overflow checking to work.
+     - Implicit memory/string functions need #include <string.h>.
+     - Implicit *printf functions need #include <stdio.h>.
+     - Implicit *printf functions need #include <stdio.h>.
+     - Implicit *read* functions need #include <unistd.h>.
+     - Implicit *recv* functions need #include <sys/socket.h>.
+E: xen implicit-fortify-decl ../../../../newlib-1.16.0/libgloss/i386/cygmon-gmon.c:119
+
+I: Program returns random data in a function
+E: xen no-return-in-nonvoid-function ../../../../newlib-1.16.0/libgloss/i386/cygmon-gmon.c:362
+
+---
+ libgloss/i386/cygmon-gmon.c |    4 +++-
+ 1 file changed, 3 insertions(+), 1 deletion(-)
+
+Index: newlib-1.16.0/libgloss/i386/cygmon-gmon.c
+===================================================================
+--- newlib-1.16.0.orig/libgloss/i386/cygmon-gmon.c
++++ newlib-1.16.0/libgloss/i386/cygmon-gmon.c
+@@ -61,6 +61,7 @@
+ static char sccsid[] = "@(#)gmon.c	5.3 (Berkeley) 5/22/91";
+ #endif /* not lint */
+ 
++#include <string.h>
+ #define DEBUG
+ #ifdef DEBUG
+ #include <stdio.h>
+@@ -89,7 +90,7 @@ static int	s_scale;
+ 
+ extern int errno;
+ 
+-int
++void
+ monstartup(lowpc, highpc)
+      char	*lowpc;
+      char	*highpc;
+@@ -341,6 +342,7 @@ overflow:
+  *	profiling is what mcount checks to see if
+  *	all the data structures are ready.
+  */
++void
+ moncontrol(mode)
+     int mode;
+ {

Re: [PATCH] stubdom: fix errors in newlib

[Ian Campbell]

On Tue, 2012-07-10 at 12:12 -0400, Olaf Hering wrote:
> # HG changeset patch
> # User Olaf Hering <olaf@aepfle.de>
> # Date 1341839122 -7200
> # Node ID 2dd50c201ca0d3542f3589942ae9e51d33ec7509
> # Parent  42f76d536b116d2ebad1b6705ae51ecd171d2581
> stubdom: fix errors in newlib
> 
> rpmlint found a few code bugs in newlib, and marks them as errors after
> rpm build. Add another newlib patch and apply it during stubdom build.

Are any of these specific to Xen or should they really be being sent to
newlib upstream? (we could really do with resyncing on he latest newlib
and sending or our patches again it. In our CFT of course ;-))

Ian.

Re: [PATCH] stubdom: fix errors in newlib

[Olaf Hering]

On Tue, Jul 10, Ian Campbell wrote:

> On Tue, 2012-07-10 at 12:12 -0400, Olaf Hering wrote:
> > # HG changeset patch
> > # User Olaf Hering <olaf@aepfle.de>
> > # Date 1341839122 -7200
> > # Node ID 2dd50c201ca0d3542f3589942ae9e51d33ec7509
> > # Parent  42f76d536b116d2ebad1b6705ae51ecd171d2581
> > stubdom: fix errors in newlib
> > 
> > rpmlint found a few code bugs in newlib, and marks them as errors after
> > rpm build. Add another newlib patch and apply it during stubdom build.
> 
> Are any of these specific to Xen or should they really be being sent to
> newlib upstream? (we could really do with resyncing on he latest newlib
> and sending or our patches again it. In our CFT of course ;-))

I have not yet checked wether upstream has the same issue, just trying
to fix the build errors.

Olaf

Re: [PATCH] stubdom: fix errors in newlib

[Olaf Hering]

On Tue, Jul 10, Ian Campbell wrote:

> On Tue, 2012-07-10 at 12:12 -0400, Olaf Hering wrote:
> > # HG changeset patch
> > # User Olaf Hering <olaf@aepfle.de>
> > # Date 1341839122 -7200
> > # Node ID 2dd50c201ca0d3542f3589942ae9e51d33ec7509
> > # Parent  42f76d536b116d2ebad1b6705ae51ecd171d2581
> > stubdom: fix errors in newlib
> > 
> > rpmlint found a few code bugs in newlib, and marks them as errors after
> > rpm build. Add another newlib patch and apply it during stubdom build.
> 
> Are any of these specific to Xen or should they really be being sent to
> newlib upstream? (we could really do with resyncing on he latest newlib
> and sending or our patches again it. In our CFT of course ;-))

There are more issues in that file, I will send another version later.

Olaf

Re: [PATCH] stubdom: fix errors in newlib [and 1 more messages]

[Ian Jackson]

Olaf Hering writes ("[Xen-devel] [PATCH] stubdom: fix errors in newlib"):
> stubdom: fix errors in newlib

Well, I agree with Ian's reservations about this:

Ian Campbell writes ("Re: [Xen-devel] [PATCH] stubdom: fix errors in newlib"):
> On Tue, 2012-07-10 at 12:12 -0400, Olaf Hering wrote:
> > # HG changeset patch
> > # User Olaf Hering <olaf@aepfle.de>
> > # Date 1341839122 -7200
> > # Node ID 2dd50c201ca0d3542f3589942ae9e51d33ec7509
> > # Parent  42f76d536b116d2ebad1b6705ae51ecd171d2581
> > stubdom: fix errors in newlib
> > 
> > rpmlint found a few code bugs in newlib, and marks them as errors after
> > rpm build. Add another newlib patch and apply it during stubdom build.
> 
> Are any of these specific to Xen or should they really be being sent to
> newlib upstream? (we could really do with resyncing on he latest newlib
> and sending or our patches again it. In our CFT of course ;-))

I definitely don't think we should be trying to drain the swamp of
newlib's bad code in our own tree.

The right answer for your rpm checks is probably to disable them
somehow.  These are very likely to be real security problems in the
context of stubdomains.

Ian.

Re: [PATCH] stubdom: fix errors in newlib [and 1 more messages]

[Ian Campbell]

On Tue, 2012-07-24 at 15:47 +0100, Ian Jackson wrote:
> Olaf Hering writes ("[Xen-devel] [PATCH] stubdom: fix errors in newlib"):
> > stubdom: fix errors in newlib
> 
> Well, I agree with Ian's reservations about this:
> 
> Ian Campbell writes ("Re: [Xen-devel] [PATCH] stubdom: fix errors in newlib"):
> > On Tue, 2012-07-10 at 12:12 -0400, Olaf Hering wrote:
> > > # HG changeset patch
> > > # User Olaf Hering <olaf@aepfle.de>
> > > # Date 1341839122 -7200
> > > # Node ID 2dd50c201ca0d3542f3589942ae9e51d33ec7509
> > > # Parent  42f76d536b116d2ebad1b6705ae51ecd171d2581
> > > stubdom: fix errors in newlib
> > > 
> > > rpmlint found a few code bugs in newlib, and marks them as errors after
> > > rpm build. Add another newlib patch and apply it during stubdom build.
> > 
> > Are any of these specific to Xen or should they really be being sent to
> > newlib upstream? (we could really do with resyncing on he latest newlib
> > and sending or our patches again it. In our CFT of course ;-))
> 
> I definitely don't think we should be trying to drain the swamp of
> newlib's bad code in our own tree.
> 
> The right answer for your rpm checks is probably to disable them
> somehow.  These are very likely to be real security problems in the

                          ^un ?

> context of stubdomains.
> 
> Ian.

Re: [PATCH] stubdom: fix errors in newlib [and 1 more messages]

[Ian Jackson]

Ian Campbell writes ("Re: [Xen-devel] [PATCH] stubdom: fix errors in newlib [and 1 more messages]"):
> On Tue, 2012-07-24 at 15:47 +0100, Ian Jackson wrote:
> > The right answer for your rpm checks is probably to disable them
> > somehow.  These are very likely to be real security problems in the
> 
>                           ^un ?
> 
> > context of stubdomains.

Uh, yes.

I'll go and fetch more coffee.

Ian.

Re: [PATCH] stubdom: fix errors in newlib [and 1 more messages]

[Olaf Hering]

On Tue, Jul 24, Ian Jackson wrote:

> Olaf Hering writes ("[Xen-devel] [PATCH] stubdom: fix errors in newlib"):
> > stubdom: fix errors in newlib
> 
> Well, I agree with Ian's reservations about this:
> 
> Ian Campbell writes ("Re: [Xen-devel] [PATCH] stubdom: fix errors in newlib"):
> > On Tue, 2012-07-10 at 12:12 -0400, Olaf Hering wrote:
> > > # HG changeset patch
> > > # User Olaf Hering <olaf@aepfle.de>
> > > # Date 1341839122 -7200
> > > # Node ID 2dd50c201ca0d3542f3589942ae9e51d33ec7509
> > > # Parent  42f76d536b116d2ebad1b6705ae51ecd171d2581
> > > stubdom: fix errors in newlib
> > > 
> > > rpmlint found a few code bugs in newlib, and marks them as errors after
> > > rpm build. Add another newlib patch and apply it during stubdom build.
> > 
> > Are any of these specific to Xen or should they really be being sent to
> > newlib upstream? (we could really do with resyncing on he latest newlib
> > and sending or our patches again it. In our CFT of course ;-))
> 
> I definitely don't think we should be trying to drain the swamp of
> newlib's bad code in our own tree.
> 
> The right answer for your rpm checks is probably to disable them
> somehow.  These are very likely to be real security problems in the
> context of stubdomains.

I tried newlib 1.20, which seems to emit no such warnings. However
building stubdom with the newer version leads to link errors. I havent
spent time yet to find a fix for those failures.

Now that rc1 is out, its probably much too late to go for a more recent
newlib to get around the build failures in current code?

Olaf

Re: [PATCH] stubdom: fix errors in newlib [and 1 more messages]

[Ian Campbell]

On Mon, 2012-07-30 at 19:44 +0100, Olaf Hering wrote:
> On Tue, Jul 24, Ian Jackson wrote:
> 
> > Olaf Hering writes ("[Xen-devel] [PATCH] stubdom: fix errors in newlib"):
> > > stubdom: fix errors in newlib
> > 
> > Well, I agree with Ian's reservations about this:
> > 
> > Ian Campbell writes ("Re: [Xen-devel] [PATCH] stubdom: fix errors in newlib"):
> > > On Tue, 2012-07-10 at 12:12 -0400, Olaf Hering wrote:
> > > > # HG changeset patch
> > > > # User Olaf Hering <olaf@aepfle.de>
> > > > # Date 1341839122 -7200
> > > > # Node ID 2dd50c201ca0d3542f3589942ae9e51d33ec7509
> > > > # Parent  42f76d536b116d2ebad1b6705ae51ecd171d2581
> > > > stubdom: fix errors in newlib
> > > > 
> > > > rpmlint found a few code bugs in newlib, and marks them as errors after
> > > > rpm build. Add another newlib patch and apply it during stubdom build.
> > > 
> > > Are any of these specific to Xen or should they really be being sent to
> > > newlib upstream? (we could really do with resyncing on he latest newlib
> > > and sending or our patches again it. In our CFT of course ;-))
> > 
> > I definitely don't think we should be trying to drain the swamp of
> > newlib's bad code in our own tree.
> > 
> > The right answer for your rpm checks is probably to disable them
> > somehow.  These are very likely to be real security problems in the
> > context of stubdomains.
> 
> I tried newlib 1.20, which seems to emit no such warnings. However
> building stubdom with the newer version leads to link errors. I havent
> spent time yet to find a fix for those failures.

This would be good to have for 4.3.

> Now that rc1 is out, its probably much too late to go for a more recent
> newlib to get around the build failures in current code?

It was too late when we froze, never mind now!

Ian.

[PATCH] stubdom: fix errors in newlib

[Olaf Hering]

# HG changeset patch
# User Olaf Hering <olaf@aepfle.de>
# Date 1342079763 -7200
# Node ID 599f8f767c86d0445fd57d1525196b80056d9483
# Parent  02ec826cab1e4acb25b364a180a1597ace1149f9
stubdom: fix errors in newlib

rpm post-build-checks found a few code bugs in newlib, and marks them as
errors. Add another newlib patch and apply it during stubdom build.

I: A function uses a 'return;' statement, but has actually a value
   to return, like an integer ('return 42;') or similar.
W: xen voidreturn ../../../../newlib-1.16.0/libgloss/i386/cygmon-gmon.c:117, 125, 146, 157, 330

I: Program is using implicit definitions of special functions.
   these functions need to use their correct prototypes to allow
   the lightweight buffer overflow checking to work.
     - Implicit memory/string functions need #include <string.h>.
     - Implicit *printf functions need #include <stdio.h>.
     - Implicit *printf functions need #include <stdio.h>.
     - Implicit *read* functions need #include <unistd.h>.
     - Implicit *recv* functions need #include <sys/socket.h>.
E: xen implicit-fortify-decl ../../../../newlib-1.16.0/libgloss/i386/cygmon-gmon.c:119

I: Program returns random data in a function
E: xen no-return-in-nonvoid-function ../../../../newlib-1.16.0/libgloss/i386/cygmon-gmon.c:362

Signed-off-by: Olaf Hering <olaf@aepfle.de>

diff -r 02ec826cab1e -r 599f8f767c86 stubdom/Makefile
--- a/stubdom/Makefile
+++ b/stubdom/Makefile
@@ -102,6 +102,7 @@ newlib-$(NEWLIB_VERSION): newlib-$(NEWLI
 	patch -d $@ -p0 < newlib.patch
 	patch -d $@ -p0 < newlib-chk.patch
 	patch -d $@ -p1 < newlib-stdint-size_max-fix-from-1.17.0.patch
+	patch -d $@ -p1 < newlib-cygmon-gmon.patch
 	find $@ -type f | xargs perl -i.bak \
 		-pe 's/\b_(tzname|daylight|timezone)\b/$$1/g'
 	touch $@
diff -r 02ec826cab1e -r 599f8f767c86 stubdom/newlib-cygmon-gmon.patch
--- /dev/null
+++ b/stubdom/newlib-cygmon-gmon.patch
@@ -0,0 +1,60 @@
+
+I: A function uses a 'return;' statement, but has actually a value
+   to return, like an integer ('return 42;') or similar.
+W: xen voidreturn ../../../../newlib-1.16.0/libgloss/i386/cygmon-gmon.c:117, 125, 146, 157, 330
+
+I: Program is using implicit definitions of special functions.
+   these functions need to use their correct prototypes to allow
+   the lightweight buffer overflow checking to work.
+     - Implicit memory/string functions need #include <string.h>.
+     - Implicit *printf functions need #include <stdio.h>.
+     - Implicit *printf functions need #include <stdio.h>.
+     - Implicit *read* functions need #include <unistd.h>.
+     - Implicit *recv* functions need #include <sys/socket.h>.
+E: xen implicit-fortify-decl ../../../../newlib-1.16.0/libgloss/i386/cygmon-gmon.c:119
+
+I: Program returns random data in a function
+E: xen no-return-in-nonvoid-function ../../../../newlib-1.16.0/libgloss/i386/cygmon-gmon.c:362
+
+---
+ libgloss/i386/cygmon-gmon.c |    6 +++++-
+ 1 file changed, 5 insertions(+), 1 deletion(-)
+
+Index: newlib-1.16.0/libgloss/i386/cygmon-gmon.c
+===================================================================
+--- newlib-1.16.0.orig/libgloss/i386/cygmon-gmon.c
++++ newlib-1.16.0/libgloss/i386/cygmon-gmon.c
+@@ -61,6 +61,8 @@
+ static char sccsid[] = "@(#)gmon.c	5.3 (Berkeley) 5/22/91";
+ #endif /* not lint */
+ 
++#include <string.h>
++#include <unistd.h>
+ #define DEBUG
+ #ifdef DEBUG
+ #include <stdio.h>
+@@ -89,7 +91,7 @@ static int	s_scale;
+ 
+ extern int errno;
+ 
+-int
++void
+ monstartup(lowpc, highpc)
+      char	*lowpc;
+      char	*highpc;
+@@ -199,6 +201,7 @@ _mcleanup()
+ 
+ static char already_setup = 0;
+ 
++void
+ _mcount()
+ {
+   register char			*selfpc;
+@@ -341,6 +344,7 @@ overflow:
+  *	profiling is what mcount checks to see if
+  *	all the data structures are ready.
+  */
++void
+ moncontrol(mode)
+     int mode;
+ {