Hi! This is the third and last patch. This patch makes the xen kernel buildable on OpenBSD by adding support for ProPolice. ProPolice has been added to standard GCC in version 4.1.x under the name Stack Smashing Protection (SSP). Cheers Christoph _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On Wednesday 18 October 2006 17:51, Keir Fraser wrote:> On 17/10/06 15:44, "Christoph Egger" <Christoph.Egger@amd.com> wrote: > > This is the third and last patch. > > > > This patch makes the xen kernel buildable on OpenBSD by adding support > > for ProPolice. ProPolice has been added to standard GCC in version 4.1.x > > under the name Stack Smashing Protection (SSP). > > Gcc 4.1.x works fine for me already (under Linux at least). We specifically > disable stack protection in xen/arch/x86/Rules.mk.The stack protection is not just to improve security. With a stack protection, it is more likely that you find off-by-one bugs like this: void foo(void) { char array[8]; int i; for (i = 0; i <= 8; i++) { array[i] = 0; } ..... } The propolice patch also contained a snippet, which necessary to make the Xen kernel build independ if SSP is disabled or not. I extracted this snippet into a separate patch to fix this build error: gcc -Wall -Werror -Wstrict-prototypes -O2 -fomit-frame-pointer -o boot/mkelf32 boot/mkelf32.c boot/mkelf32.c:93:1: "swap16" redefined In file included from /usr/include/machine/endian.h:68, from /usr/include/sys/types.h:45, from /usr/include/stdio.h:45, from boot/mkelf32.c:11: /usr/include/sys/endian.h:156:1: this is the location of the previous definition boot/mkelf32.c:94:1: "swap32" redefined /usr/include/sys/endian.h:157:1: this is the location of the previous definition boot/mkelf32.c:95:1: "swap64" redefined /usr/include/sys/endian.h:158:1: this is the location of the previous definition gmake[2]: *** [boot/mkelf32] Error 1 This mail has two patches attached: openbsd_buildfix.diff - the absolute necessary patch to make the kernel build on OpenBSD openbsd_propolice.diff - it adds support for SSP _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On Thursday 19 October 2006 09:51, Keir Fraser wrote:> On 18/10/06 8:08 am, "Christoph Egger" <Christoph.Egger@amd.com> wrote: > > /usr/include/sys/endian.h:156:1: this is the location of the previous > > definition > > boot/mkelf32.c:94:1: "swap32" redefined > > /usr/include/sys/endian.h:157:1: this is the location of the previous > > definition > > boot/mkelf32.c:95:1: "swap64" redefined > > /usr/include/sys/endian.h:158:1: this is the location of the previous > > definition > > Is there a standard definition for these functions (i.e., can we be *sure* > the original definitions have the same semantics as our own)? If not, which > I think is the case, we''re better off #undef''ing the old definitions.This is the snippet of /usr/include/endian.h: ----------------------------------------------------------------------------------- #ifdef __GNUC__ #define __swap16gen(x) __statement({ \ __uint16_t __swap16gen_x = (x); \ \ (__uint16_t)((__swap16gen_x & 0xff) << 8 | \ (__swap16gen_x & 0xff00) >> 8); \ }) #define __swap32gen(x) __statement({ \ __uint32_t __swap32gen_x = (x); \ \ (__uint32_t)((__swap32gen_x & 0xff) << 24 | \ (__swap32gen_x & 0xff00) << 8 | \ (__swap32gen_x & 0xff0000) >> 8 | \ (__swap32gen_x & 0xff000000) >> 24); \ }) #define __swap64gen(x) __statement({ \ __uint64_t __swap64gen_x = (x); \ \ (__uint64_t)((__swap64gen_x & 0xff) << 56 | \ (__swap64gen_x & 0xff00ULL) << 40 | \ (__swap64gen_x & 0xff0000ULL) << 24 | \ (__swap64gen_x & 0xff000000ULL) << 8 | \ (__swap64gen_x & 0xff00000000ULL) >> 8 | \ (__swap64gen_x & 0xff0000000000ULL) >> 24 | \ (__swap64gen_x & 0xff000000000000ULL) >> 40 | \ (__swap64gen_x & 0xff00000000000000ULL) >> 56); \ }) #else /* __GNUC__ */ /* Note that these macros evaluate their arguments several times. */ #define __swap16gen(x) \ (__uint16_t)(((__uint16_t)(x) & 0xffU) << 8 | ((__uint16_t)(x) & 0xff00U)>> 8)#define __swap32gen(x) \ (__uint32_t)(((__uint32_t)(x) & 0xff) << 24 | \ ((__uint32_t)(x) & 0xff00) << 8 | ((__uint32_t)(x) & 0xff0000) >> 8 |\ ((__uint32_t)(x) & 0xff000000) >> 24) #define __swap64gen(x) \ (__uint64_t)((((__uint64_t)(x) & 0xff) << 56) | \ ((__uint64_t)(x) & 0xff00ULL) << 40 | \ ((__uint64_t)(x) & 0xff0000ULL) << 24 | \ ((__uint64_t)(x) & 0xff000000ULL) << 8 | \ ((__uint64_t)(x) & 0xff00000000ULL) >> 8 | \ ((__uint64_t)(x) & 0xff0000000000ULL) >> 24 | \ ((__uint64_t)(x) & 0xff000000000000ULL) >> 40 | \ ((__uint64_t)(x) & 0xff00000000000000ULL) >> 56) #endif /* __GNUC__ */ ----------------------------------------------------------------------------------- _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On 17/10/06 15:44, "Christoph Egger" <Christoph.Egger@amd.com> wrote:> This is the third and last patch. > > This patch makes the xen kernel buildable on OpenBSD by adding support for > ProPolice. ProPolice has been added to standard GCC in version 4.1.x under > the name Stack Smashing Protection (SSP).Gcc 4.1.x works fine for me already (under Linux at least). We specifically disable stack protection in xen/arch/x86/Rules.mk. -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On 18/10/06 8:08 am, "Christoph Egger" <Christoph.Egger@amd.com> wrote:> /usr/include/sys/endian.h:156:1: this is the location of the previous > definition > boot/mkelf32.c:94:1: "swap32" redefined > /usr/include/sys/endian.h:157:1: this is the location of the previous > definition > boot/mkelf32.c:95:1: "swap64" redefined > /usr/include/sys/endian.h:158:1: this is the location of the previous > definitionIs there a standard definition for these functions (i.e., can we be *sure* the original definitions have the same semantics as our own)? If not, which I think is the case, we''re better off #undef''ing the old definitions. -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On 18/10/06 09:55, "Christoph Egger" <Christoph.Egger@amd.com> wrote:>> Is there a standard definition for these functions (i.e., can we be *sure* >> the original definitions have the same semantics as our own)? If not, which >> I think is the case, we''re better off #undef''ing the old definitions. > > This is the snippet of /usr/include/endian.h:Well, that doesn''t indicate whether the semantics of swap<16,32,etc> is standardised or not. I''ll fix in mkelf32 by undef''ing. -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On Thursday 19 October 2006 13:23, Keir Fraser wrote:> On 18/10/06 09:55, "Christoph Egger" <Christoph.Egger@amd.com> wrote: > >> Is there a standard definition for these functions (i.e., can we be > >> *sure* the original definitions have the same semantics as our own)? If > >> not, which I think is the case, we''re better off #undef''ing the old > >> definitions. > > > > This is the snippet of /usr/include/endian.h: > > Well, that doesn''t indicate whether the semantics of swap<16,32,etc> is > standardised or not. I''ll fix in mkelf32 by undef''ing.Thanks. I''m awaiting your commit. :-) _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel