[PATCH 1/3] Add support for OpenBSD

[PATCH 1/3] Add support for OpenBSD

[Christoph Egger]

[-- Attachment #1: Type: text/plain, Size: 92 bytes --]


Hi!

I made the xen kernel buildable on OpenBSD.
The first patch touches the buildsystem.


[-- Attachment #2: openbsd_buildsystem.diff --]
[-- Type: text/x-diff, Size: 2436 bytes --]

diff -r bd207697f0c7 xen/arch/x86/Rules.mk
--- a/xen/arch/x86/Rules.mk	Wed Oct 18 13:43:35 2006 +0100
+++ b/xen/arch/x86/Rules.mk	Tue Oct 17 16:20:45 2006 +0200
@@ -34,7 +34,7 @@ endif
 endif
 
 ifeq ($(XEN_TARGET_ARCH),x86_32)
-LDFLAGS += -m elf_i386
+LDFLAGS += -m $(ELFFMT_X86_32) 
 x86_32 := y
 x86_64 := n
 endif
@@ -45,7 +45,7 @@ CFLAGS  += -fno-asynchronous-unwind-tabl
 # -fvisibility=hidden reduces -fpic cost, if it's available
 CFLAGS  += $(shell $(CC) -v --help 2>&1 | grep " -fvisibility=" | \
              grep -q hidden && echo "-DGCC_HAS_VISIBILITY_ATTRIBUTE")
-LDFLAGS += -m elf_x86_64
+LDFLAGS += -m $(ELFFMT_X86_64) 
 x86_32 := n
 x86_64 := y
 endif
diff -r bd207697f0c7 config/Linux.mk
--- a/config/Linux.mk	Wed Oct 18 13:43:35 2006 +0100
+++ b/config/Linux.mk	Tue Oct 17 16:20:45 2006 +0200
@@ -31,6 +31,9 @@ CFLAGS ?= -O1 -fno-omit-frame-pointer
 CFLAGS ?= -O1 -fno-omit-frame-pointer
 endif
 
+ELFFMT_X86_32 = elf_i386
+ELFFMT_X86_64 = elf_x86_64
+
 # You may use wildcards, e.g. KERNELS=*2.6*
 KERNELS ?= linux-2.6-xen
 
diff -r bd207697f0c7 config/SunOS.mk
--- a/config/SunOS.mk	Wed Oct 18 13:43:35 2006 +0100
+++ b/config/SunOS.mk	Tue Oct 17 16:20:45 2006 +0200
@@ -34,3 +34,6 @@ endif
 endif
 
 CFLAGS += -Wa,--divide
+
+ELFFMT_X86_32 = elf_i386
+ELFFMT_X86_64 = elf_x86_64
diff -r bd207697f0c7 config/OpenBSD.mk
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/config/OpenBSD.mk	Tue Oct 17 16:20:45 2006 +0200
@@ -0,0 +1,35 @@
+# -*- mode: Makefile; -*-
+
+AS         = $(CROSS_COMPILE)as
+LD         = $(CROSS_COMPILE)ld
+CC         = $(CROSS_COMPILE)gcc
+CPP        = $(CROSS_COMPILE)gcc -E
+AR         = $(CROSS_COMPILE)ar
+RANLIB     = $(CROSS_COMPILE)ranlib
+NM         = $(CROSS_COMPILE)nm
+STRIP      = $(CROSS_COMPILE)strip
+OBJCOPY    = $(CROSS_COMPILE)objcopy
+OBJDUMP    = $(CROSS_COMPILE)objdump
+
+INSTALL      = install
+INSTALL_DIR  = $(INSTALL) -d -m0755
+INSTALL_DATA = $(INSTALL) -m0644
+INSTALL_PROG = $(INSTALL) -m0755
+
+LIB64DIR = lib64
+
+SOCKET_LIBS =
+CURSES_LIBS = -lncurses
+SONAME_LDFLAG = -soname
+SHLIB_CFLAGS = -shared
+
+ifneq ($(debug),y)
+# Optimisation flags are overridable
+CFLAGS ?= -O2 -fomit-frame-pointer
+else
+# Less than -O1 produces bad code and large stack frames
+CFLAGS ?= -O1 -fno-omit-frame-pointer
+endif
+
+ELFFMT_X86_32 = elf_i386_obsd
+ELFFMT_X86_64 = elf_x86_64_obsd

[-- Attachment #3: Type: text/plain, Size: 138 bytes --]

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

Re: [PATCH 1/3] Add support for OpenBSD

[Christoph Egger]

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.

Re: [PATCH 1/3] Add support for OpenBSD

[Christoph Egger]

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?

Re: [PATCH 1/3] Add support for OpenBSD

[Christoph Egger]

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. :-)

Re: [PATCH 1/3] Add support for OpenBSD

[Keir Fraser]

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

Re: [PATCH 1/3] Add support for OpenBSD

[Anil Madhavapeddy]

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

Re: [PATCH 1/3] Add support for OpenBSD

[Keir Fraser]

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

Re: [PATCH 1/3] Add support for OpenBSD

[Anil Madhavapeddy]

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

Re: [PATCH 1/3] Add support for OpenBSD

[Keir Fraser]

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.

 -- Keir

Re: [PATCH 1/3] Add support for OpenBSD

[Anil Madhavapeddy]

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

Re: [PATCH 1/3] Add support for OpenBSD

[Keir Fraser]

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

Re: [PATCH 1/3] Add support for OpenBSD

[John Clemens]

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.
> 
>  -- Keir

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.

john.c 

-- 
John Clemens           Revive Systems, www.revivesystems.com

Re: [PATCH 1/3] Add support for OpenBSD

[Brendan Cully]

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...

RE: [PATCH 1/3] Add support for OpenBSD

[Ian Pratt]

> > 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. 

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

Re: [PATCH 1/3] Add support for OpenBSD

[Keir Fraser]

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

Re: [PATCH 1/3] Add support for OpenBSD

[Brendan Cully]

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

Re: [PATCH 1/3] Add support for OpenBSD

[Keir Fraser]

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

Re: [PATCH 1/3] Add support for OpenBSD

[Keir Fraser]

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

Re: [PATCH 1/3] Add support for OpenBSD

[Anil Madhavapeddy]

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