thr3ads.net - Xen devel - [Xen-devel] stack protection in mini-os [Jul 2008]

If this information is useful, please help other people find it:
Share via:

Harald Roeck

2008-Jul-31 20:58 UTC

[Xen-devel] stack protection in mini-os

Hello,

we have a small OS based on mini-os running on a x86_64, and we would
like to implement a stack protection mechanism to catch stack
overflows. All threads are running in kernel mode and we tried to map
out the last stack page. If we overflow the stack and run into the
mapped out stack page xen crashes and the machine reboots. it looks
like xen is trying to push the arguments for the page fault trap onto
the mapped out page. If we mark the last stack page as read-only, only
the guest crashes and the hypervisor is still working. the guest
crashes with the following output on the console:

domain_crash_sync called from entry.S
Domain 2 (vcpu#0) crashed on cpu#1:
----[ Xen-3.1.4-xvm-debug  x86_64  debug=y  Not tainted ]----
CPU:    1
RIP:    e033:[<000000000001583f>]
RFLAGS: 0000000000010246   CONTEXT: guest
rax: 0000000000000000   rbx: 000000000000cb12   rcx: 000000000007b050
rdx: 000000000007b3d0   rsi: 000000000003309f   rdi: 0000000000032caa
rbp: 000000000007b120   rsp: 000000000007aff0   r8:  0000000000000010
r9:  00000000ffffffff   r10: 000000000003309f   r11: 0000000000032ca7
r12: 0000000000000000   r13: 0000000000000000   r14: 0000000000000000
r15: 0000000000000000   cr0: 000000008005003b   cr4: 00000000000006f0
cr3: 00000007ebeea000   cr2: 000000000007aff8
ds: 0000   es: 0000   fs: 0000   gs: 0000   ss: e02b   cs: e033
...

fyi: the read only page in this setup was 0x7a000.

so my question: is it possible to set an "alternate" trap stack? We
already tried to set a kernel stack with the stack_switch hypercall,
but this stack is only used when trapping from user context, but we
never enter user context. Or are we missing something? what about
double faults, or the failsafe_callback? we never see any of them.

any suggestions or comments on how we could handle stack overflows are welcome.

thanks,
Harald

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

Samuel Thibault

2008-Jul-31 21:10 UTC

head link

Re: [Xen-devel] stack protection in mini-os

Hello,

For stubdomains, what I did is to add a check for ESP relative to the
bottom of the stack in a frequently called function, (think about
something like errno_location())

Harald Roeck, le Thu 31 Jul 2008 13:58:36 -0700, a écrit
:> If we overflow the stack and run into the
> mapped out stack page xen crashes and the machine reboots.
Uh, that''s bad! Which version of Xen is this with? That is a bug of
Xen,
can you reproduce it with a RC of 3.3?
> it looks like xen is trying to push the arguments for the page fault
> trap onto the mapped out page.
Most probably yes, but it should catch the error.
> rbp: 000000000007b120   rsp: 000000000007aff0   r8:  0000000000000010
> ...
> 
> fyi: the read only page in this setup was 0x7a000.
So that''s coherent indeed, but I guess you''d like to have the
backtrace.
> so my question: is it possible to set an "alternate" trap stack?
I don''t think the hypervisor provides this for kernel level.
> or the failsafe_callback?
failsafe_callback is only called when you get a fault during the
execution of callback, not during normal flow.

Samuel

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

Harald Roeck

2008-Jul-31 21:40 UTC

head link

Re: [Xen-devel] stack protection in mini-os

Hi Samuel,

On Thu, Jul 31, 2008 at 2:10 PM, Samuel Thibault
<samuel.thibault@eu.citrix.com> wrote:> Hello,
>
> For stubdomains, what I did is to add a check for ESP relative to the
> bottom of the stack in a frequently called function, (think about
> something like errno_location())
thanks for the feedback. I could do this too. although I would prefer
to get a page fault and handle it there.
>
> Harald Roeck, le Thu 31 Jul 2008 13:58:36 -0700, a écrit :
>> If we overflow the stack and run into the
>> mapped out stack page xen crashes and the machine reboots.
>
> Uh, that''s bad! Which version of Xen is this with? That is a bug
of Xen,
> can you reproduce it with a RC of 3.3?
our machine runs on Xen 3.1.4 with solaris as dom0 (i.e. Sun xVM).
Sorry, but right now I cannot test it with another version 3.3.
>> it looks like xen is trying to push the arguments for the page fault
>> trap onto the mapped out page.
>
> Most probably yes, but it should catch the error.
>
>> rbp: 000000000007b120   rsp: 000000000007aff0   r8:  0000000000000010
>> ...
>>
>> fyi: the read only page in this setup was 0x7a000.
>
> So that''s coherent indeed, but I guess you''d like to have
the backtrace.
the backtrace shows the call stack of the crashing thread, which is
recursively calling a function and printing a value until it reaches
the read-only page and crashes. the complete console output is
attached.
>> so my question: is it possible to set an "alternate" trap
stack?
>
> I don''t think the hypervisor provides this for kernel level.
>
>> or the failsafe_callback?
>
> failsafe_callback is only called when you get a fault during the
> execution of callback, not during normal flow.
thanks, good to know. and what about double faults?

-Harald

(xVM) domain_crash_sync called from entry.S
(xVM) Domain 3 (vcpu#0) crashed on cpu#2:
(xVM) ----[ Xen-3.1.4-xvm-debug  x86_64  debug=y  Tainted:  M   ]----
(xVM) CPU:    2
(xVM) RIP:    e033:[<0000000000015867>]
(xVM) RFLAGS: 0000000000010246   CONTEXT: guest
(xVM) rax: 0000000000000000   rbx: 000000000000cb6e   rcx: 000000000007b050
(xVM) rdx: 000000000007b3d0   rsi: 000000000003309f   rdi: 0000000000032caa
(xVM) rbp: 000000000007b120   rsp: 000000000007aff0   r8:  0000000000000010
(xVM) r9:  00000000ffffffff   r10: 000000000003309f   r11: 0000000000032ca7
(xVM) r12: 0000000000000000   r13: 0000000000000000   r14: 0000000000000000
(xVM) r15: 0000000000000000   cr0: 000000008005003b   cr4: 00000000000006f0
(xVM) cr3: 00000007ebeea000   cr2: 000000000007aff8
(xVM) ds: 0000   es: 0000   fs: 0000   gs: 0000   ss: e02b   cs: e033
(xVM) Guest stack trace from rbp=000000000007b120:
(xVM)  0000000000016170 000000000001b607 000000000001b7bb 000000000000cb8f
(xVM)  000000000000cbf9 000000000000cbf9 000000000000cbf9 000000000000cbf9
(xVM)  000000000000cbf9 000000000000cbf9 000000000000cbf9 000000000000cbf9
(xVM)  000000000000cbf9 000000000000cbf9 000000000000cbf9 000000000000cbf9
(xVM)  000000000000cbf9 000000000000cbf9 000000000000cbf9 000000000000cbf9
(xVM)  000000000000cbf9 000000000000cbf9 000000000000cbf9 000000000000cbf9
(xVM)  000000000000cbf9 000000000000cbf9 000000000000cbf9 000000000000cbf9
(xVM)  000000000000cbf9 000000000000cbf9 000000000000cbf9 000000000000cbf9
(xVM)  000000000000cbf9 000000000000cbf9 000000000000cbf9 000000000000cbf9
(xVM)  000000000000cbf9 000000000000cbf9 000000000000cbf9 000000000000cbf9
(xVM)  000000000000cbf9 000000000000cbf9 000000000000cbf9 000000000000cbf9
(xVM)  000000000000cbf9 000000000000cbf9 000000000000cbf9 000000000000cbf9
(xVM)  000000000000cbf9 000000000000cbf9 000000000000cbf9 000000000000cbf9
(xVM)  000000000000cbf9 0000000000004547 0000000000011b64 000000000000454c
(xVM) Xen stack trace from rsp=000000000007aff0:
(xVM)    0000000000000000 0000000000000000 0000000000000000
(xVM)    0000000000000000 0000000000000000 0000000000000000
(xVM)    3736353433323130 4645444342413938 4e4d4c4b4a494847
(xVM)    565554535251504f 000000005a595857 0000000a00000000
(xVM)    3736353433323130 6665646362613938 6e6d6c6b6a696867
(xVM)    767574737271706f 4e4d4c007a797877 565554535251504f
(xVM)    000000005a595857 0000000a00000000 3736353433323130
(xVM)    6665646362613938 6e6d6c6b6a696867 767574737271706f
(xVM)    4e4d4c007a797877 565554535251504f 000000005a595857
(xVM)    000000000007b090 3736373130363536 6632383134373439
(xVM)    6e6d6c6b6a696867 ffffffff7271706f 0000001000000010
(xVM)    000000000007b3d0 000000000003309f 0000000000032caa
(xVM)    3838333535333238 000000000000cb6e 000000000007b230
(xVM)    0000000000016170 0000000a00000001 0001000000000000
(xVM)    000000000003309f 0000000000032cb6 3434313737363634
(xVM)    000000000000cb6e 000000000007b270 0000004b000165ba
(xVM)    0000000a00000002 0000800000000000 000000000003309f
(xVM)    000000000007b2c8 ffffffff00000010 0000000000000017
(xVM)    000000000001bb69 00000000deadbeef 00000000deadbeef
(xVM)    0000005000000000 000000000007b1e0 ffffffffffffffff
(xVM) Xen call trace:
(xVM)    [<0000000000015867>] ???
(xVM)    [<0000000000016170>] ???
(xVM)    [<000000000001b607>] ???
(xVM)    [<000000000001b7bb>] ???
(xVM)    [<000000000000cb8f>] ???
(xVM)    [<000000000000cbf9>] ???
(xVM)    [<000000000000cbf9>] ???
(xVM)    [<000000000000cbf9>] ???
(xVM)    [<000000000000cbf9>] ???
(xVM)    [<000000000000cbf9>] ???
(xVM)    [<000000000000cbf9>] ???
(xVM)    [<000000000000cbf9>] ???
(xVM)    [<000000000000cbf9>] ???
(xVM)    [<000000000000cbf9>] ???
(xVM)    [<000000000000cbf9>] ???
(xVM)    [<000000000000cbf9>] ???
(xVM)    [<000000000000cbf9>] ???
(xVM)    [<000000000000cbf9>] ???
(xVM)    [<000000000000cbf9>] ???
(xVM)    [<000000000000cbf9>] ???
(xVM)    [<000000000000cbf9>] ???
(xVM)    [<000000000000cbf9>] ???
(xVM)    [<000000000000cbf9>] ???
(xVM)    [<000000000000cbf9>] ???
(xVM)    [<000000000000cbf9>] ???
(xVM)    [<000000000000cbf9>] ???
(xVM)    [<000000000000cbf9>] ???
(xVM)    [<000000000000cbf9>] ???
(xVM)    [<000000000000cbf9>] ???
(xVM)    [<000000000000cbf9>] ???
(xVM)    [<000000000000cbf9>] ???
(xVM)    [<000000000000cbf9>] ???
(xVM)    [<000000000000cbf9>] ???
(xVM)    [<000000000000cbf9>] ???
(xVM)    [<000000000000cbf9>] ???
(xVM)    [<000000000000cbf9>] ???
(xVM)    [<000000000000cbf9>] ???
(xVM)    [<000000000000cbf9>] ???
(xVM)    [<000000000000cbf9>] ???
(xVM)    [<000000000000cbf9>] ???
(xVM)    [<000000000000cbf9>] ???
(xVM)    [<000000000000cbf9>] ???
(xVM)    [<000000000000cbf9>] ???
(xVM)    [<000000000000cbf9>] ???
(xVM)    [<000000000000cbf9>] ???
(xVM)    [<000000000000cbf9>] ???
(xVM)    [<000000000000cbf9>] ???
(xVM)    [<000000000000cbf9>] ???
(xVM)    [<000000000000cbf9>] ???
(xVM)    [<000000000000cbf9>] ???
(xVM)    [<000000000000cbf9>] ???
(xVM)    [<000000000000cbf9>] ???
(xVM)    [<000000000000cbf9>] ???
(xVM)    [<000000000000cbf9>] ???
(xVM)    [<0000000000004547>] ???
(xVM)    [<0000000000011b64>] ???
(xVM)    [<000000000000454c>] ???

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

Xen devel - Jul 2008 - stack protection in mini-os

[Xen-devel] stack protection in mini-os

Re: [Xen-devel] stack protection in mini-os

Re: [Xen-devel] stack protection in mini-os