Hi! I made the xen kernel buildable on OpenBSD. The first patch touches the buildsystem. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On Wednesday 18 October 2006 17:24, Keir Fraser wrote:> On 17/10/06 15:30, "Christoph Egger" <Christoph.Egger@amd.com> wrote: > > I made the xen kernel buildable on OpenBSD. > > The first patch touches the buildsystem. > > Why is elf_{i386,x86_64}_obsd needed? Is OpenBSD so very special it needs > its own linkage target architecture?ld on OpenBSD complains that elf_i386 and elf_x86_64 are not supported. It expects elf_i386_obsd or elf_x86_64_obsd respectively. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On Wednesday 18 October 2006 18:27, Keir Fraser wrote:> On 18/10/06 17:17, "Anil Madhavapeddy" <anil@xensource.com> wrote: > >> I applied your second patch, but not the third (SSP/ProPolice) one > >> as I > >> don''t understand why it''s needed. If there''s some extra magic in > >> OpenBSD''s > >> gcc, I hope there is a flag we can specify to turn it off for the > >> hypervisor > >> itself. > > > > It''s enabled by default in OpenBSD''s modified gcc-3.3.5, turn it off > > with CFLAGS+= -fno-stack-protector > > We have that already in arch/x86/Rules.mk. If that was working, I doubt > Christoph would have gone to the trouble of hacking up the SSP goop.I did this work in August. There wasn''t anything SSP-related there. So without SSP support, I got into linking errors. Now that the work is done, why shouldn''t it go in? _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On Thursday 19 October 2006 09:41, Keir Fraser wrote:> On 18/10/06 8:25 am, "Christoph Egger" <Christoph.Egger@amd.com> wrote: > >> We have that already in arch/x86/Rules.mk. If that was working, I doubt > >> Christoph would have gone to the trouble of hacking up the SSP goop. > > > > I did this work in August. There wasn''t anything SSP-related there. So > > without SSP support, I got into linking errors. > > Now that the work is done, why shouldn''t it go in? > > Uncertainty about new compiler-assisted stuff that I don''t believe will > catch any bugs in Xen. Linux guys have clearly reached the same conclusion. > Given we even turn off frame pointers in non-debug builds, is it likely > we''ll take this? :-)Linux guys also came to the conclusion, kernel debuggers are useless to catch any bugs. On the other side, how many use the kgdb patch? So, even if my SSP patch won''t go in, how many will use it? Hmm... now I feel, this ends up in a debate on principles. :-) _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On 17/10/06 15:30, "Christoph Egger" <Christoph.Egger@amd.com> wrote:> I made the xen kernel buildable on OpenBSD. > The first patch touches the buildsystem.Why is elf_{i386,x86_64}_obsd needed? Is OpenBSD so very special it needs its own linkage target architecture? -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Anil Madhavapeddy
2006-Oct-18 16:01 UTC
Re: [Xen-devel] [PATCH 1/3] Add support for OpenBSD
On 18 Oct 2006, at 16:24, Keir Fraser wrote:> > On 17/10/06 15:30, "Christoph Egger" <Christoph.Egger@amd.com> wrote: > >> I made the xen kernel buildable on OpenBSD. >> The first patch touches the buildsystem. > > Why is elf_{i386,x86_64}_obsd needed? Is OpenBSD so very special it > needs > its own linkage target architecture?If I remember, these emulations are for W^X support on OpenBSD when we switched to elf from a.out a couple of years ago; it links sections in different address areas so that segment registers (on i386 32-bit anyway) can be used to ensure that no pages are simultaneously writable and executable. - http://www.openbsd.org/papers/ven05-deraadt/index.html -anil _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On 17/10/06 17:02, "Christoph Egger" <Christoph.Egger@amd.com> wrote:>>> I made the xen kernel buildable on OpenBSD. >>> The first patch touches the buildsystem. >> >> Why is elf_{i386,x86_64}_obsd needed? Is OpenBSD so very special it needs >> its own linkage target architecture? > > ld on OpenBSD complains that elf_i386 and elf_x86_64 are not supported. > It expects elf_i386_obsd or elf_x86_64_obsd respectively.Okay. I applied a modified form of your patch which puts common definitions in config/StdGNU.mk. I applied your second patch, but not the third (SSP/ProPolice) one as I don''t understand why it''s needed. If there''s some extra magic in OpenBSD''s gcc, I hope there is a flag we can specify to turn it off for the hypervisor itself. -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Anil Madhavapeddy
2006-Oct-18 16:17 UTC
Re: [Xen-devel] [PATCH 1/3] Add support for OpenBSD
On 18 Oct 2006, at 17:11, Keir Fraser wrote:> On 17/10/06 17:02, "Christoph Egger" <Christoph.Egger@amd.com> wrote: > >>>> I made the xen kernel buildable on OpenBSD. >>>> The first patch touches the buildsystem. >>> >>> Why is elf_{i386,x86_64}_obsd needed? Is OpenBSD so very special >>> it needs >>> its own linkage target architecture? >> >> ld on OpenBSD complains that elf_i386 and elf_x86_64 are not >> supported. >> It expects elf_i386_obsd or elf_x86_64_obsd respectively. > > Okay. I applied a modified form of your patch which puts common > definitions > in config/StdGNU.mk. > > I applied your second patch, but not the third (SSP/ProPolice) one > as I > don''t understand why it''s needed. If there''s some extra magic in > OpenBSD''s > gcc, I hope there is a flag we can specify to turn it off for the > hypervisor > itself.It''s enabled by default in OpenBSD''s modified gcc-3.3.5, turn it off with CFLAGS+= -fno-stack-protector -anil _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On 18/10/06 17:17, "Anil Madhavapeddy" <anil@xensource.com> wrote:>> I applied your second patch, but not the third (SSP/ProPolice) one >> as I >> don''t understand why it''s needed. If there''s some extra magic in >> OpenBSD''s >> gcc, I hope there is a flag we can specify to turn it off for the >> hypervisor >> itself. > > It''s enabled by default in OpenBSD''s modified gcc-3.3.5, turn it off > with CFLAGS+= -fno-stack-protectorWe have that already in arch/x86/Rules.mk. If that was working, I doubt Christoph would have gone to the trouble of hacking up the SSP goop. -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Anil Madhavapeddy
2006-Oct-18 16:34 UTC
Re: [Xen-devel] [PATCH 1/3] Add support for OpenBSD
On 18 Oct 2006, at 17:27, Keir Fraser wrote:> On 18/10/06 17:17, "Anil Madhavapeddy" <anil@xensource.com> wrote: > >>> I applied your second patch, but not the third (SSP/ProPolice) one >>> as I >>> don''t understand why it''s needed. If there''s some extra magic in >>> OpenBSD''s >>> gcc, I hope there is a flag we can specify to turn it off for the >>> hypervisor >>> itself. >> >> It''s enabled by default in OpenBSD''s modified gcc-3.3.5, turn it off >> with CFLAGS+= -fno-stack-protector > > We have that already in arch/x86/Rules.mk. If that was working, I > doubt > Christoph would have gone to the trouble of hacking up the SSP goop. >That flag definitely works. I think Christoph wanted to get stack protection working, as all the other OpenBSD bits (kernel/userland) use it. There isn''t much to it beyond adding the stack smash handler, and the stack frame format changes a bit... -anil _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On 18/10/06 17:34, "Anil Madhavapeddy" <anil@xensource.com> wrote:>> We have that already in arch/x86/Rules.mk. If that was working, I >> doubt >> Christoph would have gone to the trouble of hacking up the SSP goop. >> > > That flag definitely works. > > I think Christoph wanted to get stack protection working, as all the > other OpenBSD bits (kernel/userland) use it. There isn''t much to it > beyond adding the stack smash handler, and the stack frame format > changes a bit...I don''t think stack-smashing attacks are a worrying vulnerability for Xen. We don''t do much variable-sized buffer manipulation, strcpy, and so on. I''d much rather see someone put some effort into something more likely to be useful (albeit undoubtedly more work!) like randomised attacks on the hypercall interfaces. -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On Wed, 2006-10-18 at 17:27 +0100, Keir Fraser wrote:> On 18/10/06 17:17, "Anil Madhavapeddy" <anil@xensource.com> wrote:> > > > It''s enabled by default in OpenBSD''s modified gcc-3.3.5, turn it off > > with CFLAGS+= -fno-stack-protector > > We have that already in arch/x86/Rules.mk. If that was working, I doubt > Christoph would have gone to the trouble of hacking up the SSP goop. > > -- KeirI can tell you for a fact that that check doesn''t work on Ubuntu edgy. ''test-gcc-flag'' greps the gcc --help output, which doesn''t do the right thing, at least on Ubuntu. I believe the linux kernel equivalent tries to actually use the option and checks the gcc return code. I was in the midst of tracking this down a few weeks ago when I discovered other HVM bugs that apparently only show up with gcc v4 (bad EFER values), so I moved back to compiling with gcc-3.4 and dropped it. I''ll see if I can finish it up and submit a patch unless someone beats me to it. john.c -- John Clemens Revive Systems, www.revivesystems.com _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On Wednesday, 18 October 2006 at 17:39, Keir Fraser wrote:> On 18/10/06 17:34, "Anil Madhavapeddy" <anil@xensource.com> wrote: > > >> We have that already in arch/x86/Rules.mk. If that was working, I > >> doubt > >> Christoph would have gone to the trouble of hacking up the SSP goop. > >> > > > > That flag definitely works. > > > > I think Christoph wanted to get stack protection working, as all the > > other OpenBSD bits (kernel/userland) use it. There isn''t much to it > > beyond adding the stack smash handler, and the stack frame format > > changes a bit... > > I don''t think stack-smashing attacks are a worrying vulnerability for Xen. > We don''t do much variable-sized buffer manipulation, strcpy, and so on. I''d > much rather see someone put some effort into something more likely to be > useful (albeit undoubtedly more work!) like randomised attacks on the > hypercall interfaces.I built something to do that for a course project a few months ago - basically a kernel module to pass along completely unchecked hypercalls, generated by a python script with a few hooks to filter out those that it knew Xen would catch anyway. It even managed to crash xen periodically, but I never quite finished the piece that was supposed to reproduce crashes after they happened. I guess I should clean it up and post it somewhere... _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
> > I don''t think stack-smashing attacks are a worrying vulnerabilityfor> Xen. > > We don''t do much variable-sized buffer manipulation, strcpy, and soon.> I''d > > much rather see someone put some effort into something more likelyto be> > useful (albeit undoubtedly more work!) like randomised attacks onthe> > hypercall interfaces. > > I built something to do that for a course project a few months ago - > basically a kernel module to pass along completely unchecked > hypercalls, generated by a python script with a few hooks to filter > out those that it knew Xen would catch anyway. It even managed to > crash xen periodically, but I never quite finished the piece that was > supposed to reproduce crashes after they happened. I guess I should > clean it up and post it somewhere...That would certainly be helpful -- thanks! I suspect you could get the most mileage with this by saving the domain, then having a loop that restores it and kicks off the test with a different seed. This should enable much faster cycling than having to boot the VM every time Xen decides to terminate it for misbehaving. Many of the more complex situations come about by having complex pagetable structures etc that are almost valid but have subtle bugs. Generating these scenarios by hand is going to be tough. I think that possibly fault injection is the best way of handling these, perhaps having a special guest kernel module that runs off the ticker and tries to do interesting corruptions to pagetables. We could also arrange to corrupt hypercall arguments one time in a thousand or something. It would be *great* if someone could work at this sort of testing. It may not sexy as some of the other security work that''s going on, but would be incredibly valuable to the project. Please could someone step forward! Thanks, Ian _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On 18/10/06 18:08, "John Clemens" <jclemens@revivesystems.com> wrote:> I can tell you for a fact that that check doesn''t work on Ubuntu edgy. > > ''test-gcc-flag'' greps the gcc --help output, which doesn''t do the right > thing, at least on Ubuntu. I believe the linux kernel equivalent tries > to actually use the option and checks the gcc return code. > > I was in the midst of tracking this down a few weeks ago when I > discovered other HVM bugs that apparently only show up with gcc v4 (bad > EFER values), so I moved back to compiling with gcc-3.4 and dropped it. > I''ll see if I can finish it up and submit a patch unless someone beats > me to it.Okay, I checked in something like the Linux cc-option function as xen-unstable changeset 11820:b2e71d574045. Actually I changed it because Linux allows through options which aren''t really recognised (and cause a warning to be printed) but which do not cause gcc to return an error code. Instead I look for any output on stdout/stderr. It should be more robust than grepping the output of gcc long help! By the way, the EFER bug was fixed weeks ago. -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On Wednesday, 18 October 2006 at 19:13, Ian Pratt wrote:> > > I don''t think stack-smashing attacks are a worrying vulnerability > for > > Xen. > > > We don''t do much variable-sized buffer manipulation, strcpy, and so > on. > > I''d > > > much rather see someone put some effort into something more likely > to be > > > useful (albeit undoubtedly more work!) like randomised attacks on > the > > > hypercall interfaces. > > > > I built something to do that for a course project a few months ago - > > basically a kernel module to pass along completely unchecked > > hypercalls, generated by a python script with a few hooks to filter > > out those that it knew Xen would catch anyway. It even managed to > > crash xen periodically, but I never quite finished the piece that was > > supposed to reproduce crashes after they happened. I guess I should > > clean it up and post it somewhere... > > That would certainly be helpful -- thanks! > I suspect you could get the most mileage with this by saving the domain, > then having a loop that restores it and kicks off the test with a > different seed. This should enable much faster cycling than having to > boot the VM every time Xen decides to terminate it for misbehaving.That''s exactly what it did.> Many of the more complex situations come about by having complex > pagetable structures etc that are almost valid but have subtle bugs. > Generating these scenarios by hand is going to be tough. I think that > possibly fault injection is the best way of handling these, perhaps > having a special guest kernel module that runs off the ticker and tries > to do interesting corruptions to pagetables. We could also arrange to > corrupt hypercall arguments one time in a thousand or something.Yes, ''almost correct'' is the hard part, and page table manipulation from userspace needs a bit more help than I ever put into my module. But I don''t think it would be that much work to export them, let userspace fiddle with them a bit, and reload them.> It would be *great* if someone could work at this sort of testing. It > may not sexy as some of the other security work that''s going on, but > would be incredibly valuable to the project. Please could someone step > forward!I don''t know if I''ve got the time for it in the near term, but if anyone''s interested, the code I wrote (such as it is) is available at http://hg.kublai.com/monkey _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On 18/10/06 8:25 am, "Christoph Egger" <Christoph.Egger@amd.com> wrote:>> We have that already in arch/x86/Rules.mk. If that was working, I doubt >> Christoph would have gone to the trouble of hacking up the SSP goop. > > I did this work in August. There wasn''t anything SSP-related there. So > without SSP support, I got into linking errors. > Now that the work is done, why shouldn''t it go in?Uncertainty about new compiler-assisted stuff that I don''t believe will catch any bugs in Xen. Linux guys have clearly reached the same conclusion. Given we even turn off frame pointers in non-debug builds, is it likely we''ll take this? :-) -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On 18/10/06 8:57 am, "Christoph Egger" <Christoph.Egger@amd.com> wrote:> On Thursday 19 October 2006 09:41, Keir Fraser wrote: >> On 18/10/06 8:25 am, "Christoph Egger" <Christoph.Egger@amd.com> wrote: >>>> We have that already in arch/x86/Rules.mk. If that was working, I doubt >>>> Christoph would have gone to the trouble of hacking up the SSP goop. >>> >>> I did this work in August. There wasn''t anything SSP-related there. So >>> without SSP support, I got into linking errors. >>> Now that the work is done, why shouldn''t it go in? >> >> Uncertainty about new compiler-assisted stuff that I don''t believe will >> catch any bugs in Xen. Linux guys have clearly reached the same conclusion. >> Given we even turn off frame pointers in non-debug builds, is it likely >> we''ll take this? :-) > > Linux guys also came to the conclusion, kernel debuggers are useless > to catch any bugs. On the other side, how many use the kgdb patch? > So, even if my SSP patch won''t go in, how many will use it? > Hmm... now I feel, this ends up in a debate on principles. :-)I''ll admit I don''t really have any time for kernel debuggers either. :-) We simply don''t have arrays on the stack all that often, and particularly not filled from untrusted sources with untrusted limits. -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Anil Madhavapeddy
2006-Oct-19 08:50 UTC
Re: [Xen-devel] [PATCH 1/3] Add support for OpenBSD
On 18 Oct 2006, at 08:57, Christoph Egger wrote:> On Thursday 19 October 2006 09:41, Keir Fraser wrote: >> On 18/10/06 8:25 am, "Christoph Egger" <Christoph.Egger@amd.com> >> wrote: >>>> We have that already in arch/x86/Rules.mk. If that was working, >>>> I doubt >>>> Christoph would have gone to the trouble of hacking up the SSP >>>> goop. >>> >>> I did this work in August. There wasn''t anything SSP-related >>> there. So >>> without SSP support, I got into linking errors. >>> Now that the work is done, why shouldn''t it go in? >> >> Uncertainty about new compiler-assisted stuff that I don''t believe >> will >> catch any bugs in Xen. Linux guys have clearly reached the same >> conclusion. >> Given we even turn off frame pointers in non-debug builds, is it >> likely >> we''ll take this? :-) > > Linux guys also came to the conclusion, kernel debuggers are useless > to catch any bugs. On the other side, how many use the kgdb patch? > So, even if my SSP patch won''t go in, how many will use it? > Hmm... now I feel, this ends up in a debate on principles. :-) >There is also the small matter of filling up the init_guard with random values, and not hard-coded ones ... in its current state it doesn''t actually add any security in Xen with regards to malicious activity (although it would catch some accidental stack overflows, but as Keir says the use of the stack in this way is fairly rare in Xen itself). -anil _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel