Xen devel - Oct 2010 - [PATCH] caml-stubdom: fix "red zone" bug

According to the AMD64 ABI, the 128-byte area below %rsp is reserved
for scratch space and should not be used by signal, interrupt, or
exception handlers. However, Mini-OS does not adhere to this
interface. As a result, the -mno-red-zone flag must be provided to gcc
in order to force code to be compiled without this assumption. In the
case of the c-stubdom or the ioemu stubdom, Makefile configuration and
flags are inherited from Xen, which includes this flag. However, in
the case of the ocaml stubdom, since an independent ocaml version is
pulled and compiled, with its own make system in place, this flag is
not present.

As a default optimisation (no optimisation flags specified), gcc
generates function header code that uses mov instead of push (to save
a few instructions). However, with the 128-byte scratch space
assumption in place, registers are moved onto the stack *before* %rsp
is updated. This results in cases where when a function is being
called, *after* the first mov <foo>, <offset>(%rsp) but *before* the
%rsp update, sub <bar>, %rsp, if an interrupt is fired, then the stack
will be clobbered (as Mini-OS uses the application stack for its
stack, pushing registers onto the stack on entry and popping them off
on exit).

This patch fixes this issue by passing the -mno-red-zone flag to the
ocaml configure script in the stubdom Makefile.


Signed-off-by: Patrick Colp <pjcolp@cs.ubc.ca>


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

Patrick Colp writes ("[Xen-devel] [PATCH] caml-stubdom: fix "red
zone" bug"):
> According to the AMD64 ABI, the 128-byte area below %rsp is reserved
> for scratch space and should not be used by signal, interrupt, or
> exception handlers. However, Mini-OS does not adhere to this
> interface. 
How unpleasant.
> This patch fixes this issue by passing the -mno-red-zone flag to the
> ocaml configure script in the stubdom Makefile.
Perhaps it would be better to make Mini-OS adhere to the specified
interface ?  But I guess your patch is good in the meantime.

Ian.

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

On Wed, 2010-10-27 at 17:16 +0100, Ian Jackson wrote:
> Patrick Colp writes ("[Xen-devel] [PATCH] caml-stubdom: fix "red
zone" bug"):
> > According to the AMD64 ABI, the 128-byte area below %rsp is reserved
> > for scratch space and should not be used by signal, interrupt, or
> > exception handlers. However, Mini-OS does not adhere to this
> > interface. 
> 
> How unpleasant.
> 
> > This patch fixes this issue by passing the -mno-red-zone flag to the
> > ocaml configure script in the stubdom Makefile.
> 
> Perhaps it would be better to make Mini-OS adhere to the specified
> interface ?  But I guess your patch is good in the meantime.
Red-zoning is really only intended to apply for userspace, and the
kernel must take pains to make it so, for example when injecting signals
etc.

A kernel (or anything which runs only in ring 0) generally cannot use
red-zoning on itself because there is no stack switch when taking an
exception/interrupt/etc from ring 0 and so the hardware has already
trashed the red-zone before the software would get to do any
fixup/obeying etc.

Xen compiles itself with -mno-red-zone for exactly this reason.

Ian.



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

At 17:16 +0100 on 27 Oct (1288199782), Ian Jackson
wrote:
> Patrick Colp writes ("[Xen-devel] [PATCH] caml-stubdom: fix "red
zone" bug"):
> > According to the AMD64 ABI, the 128-byte area below %rsp is reserved
> > for scratch space and should not be used by signal, interrupt, or
> > exception handlers. However, Mini-OS does not adhere to this
> > interface. 
> 
> How unpleasant.
> 
> > This patch fixes this issue by passing the -mno-red-zone flag to the
> > ocaml configure script in the stubdom Makefile.
> 
> Perhaps it would be better to make Mini-OS adhere to the specified
> interface?
Hmm.  We would need to have more heavyweight kernel/user separation to
make sure that interrupt delivery &c always happens on safe stacks.  At
the moment, all of Mini-OS runs in kernel mode, on one stack.  It might
be possible to use a different stack change for interrupts and
exceptions only without having a full user/kernel split though, as long
as all the interrupt handlers are compiled with -mno-red-zone...

It''s really just part of the confusion of running
"application" code in
what''s realy a kernel.  The Linux kernel and Xen are both compiled with
-mno-red-zone, to avoid this kind of issue.

Cheers,

Tim.

-- 
Tim Deegan <Tim.Deegan@citrix.com>
Principal Software Engineer, XenServer Engineering
Citrix Systems UK Ltd.  (Company #02937203, SL9 0BG)

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

Ian Campbell writes ("Re: [Xen-devel] [PATCH] caml-stubdom: fix "red
zone" bug"):
> A kernel (or anything which runs only in ring 0) generally cannot use
> red-zoning on itself because there is no stack switch when taking an
> exception/interrupt/etc from ring 0 and so the hardware has already
> trashed the red-zone before the software would get to do any
> fixup/obeying etc.
Thanks for the explanation.  It hadn''t occurred to me that
they''d
write something into the ABI which you can''t implement when running in
a kernel ...

I''ve applied Patrick''s patch.

Ian.

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

At 12:15 +0100 on 28 Oct (1288268144), Ian Jackson
wrote:
> Ian Campbell writes ("Re: [Xen-devel] [PATCH] caml-stubdom: fix
"red zone" bug"):
> Thanks for the explanation.  It hadn''t occurred to me that
they''d
> write something into the ABI which you can''t implement when
running in
> a kernel ...
It''s possible, just tedious/fiddly enough that people don''t.
:)
Looking at the Microsoft docs, they don''t seem to mention the red zone
even for usermode code.

Tim.

-- 
Tim Deegan <Tim.Deegan@citrix.com>
Principal Software Engineer, XenServer Engineering
Citrix Systems UK Ltd.  (Company #02937203, SL9 0BG)

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