[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH] x86/emul: Poision the stubs with debug traps



>>> On 08.03.17 at 16:39, <andrew.cooper3@xxxxxxxxxx> wrote:
> ...rather than leaving fragments of old instructions in place.  This reduces
> the chances of something going further-wrong (as the debug trap will be cause
> and terminate the guest) in a cascade-failure where we end up executing the
> instruction fragments.

Where are you taking the "and terminate the guest" from? As far as
I can see, do_int3() does nothing at all for an INT3 from hypervisor
context (without CRASH_DEBUG), so we'd just take a row of INT3s
until we hit the end of stub space (running either past the page
boundary or into the next CPU's stub space, which is the syscall
entry code).

> Before:
>     (XEN) d2v0 exception 6 (ec=0000) in emulation stub (line 6239)
>     (XEN) d2v0 stub: c4 e1 44 77 c3 80 d0 82 ff ff ff d1 90 ec 90

Hmm, this is concerning: I don't think we have ways to generate
15-byte instructions into the stub, so where are all these non-zero
bytes coming from? After all alloc_stub_page() pre-fills the page
with all 0xCC.

> After:
>     (XEN) d3v0 exception 6 (ec=0000) in emulation stub (line 6239)
>     (XEN) d3v0 stub: c4 e1 44 77 c3 cc cc cc cc cc cc cc cc cc cc
> 
> Signed-off-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
> ---
> CC: Jan Beulich <JBeulich@xxxxxxxx>
> 
> Semi-RFC: I really don't like (ab)use of memset, but can't think of a cleaner
> way of doing this.

What abuse are you seeing here?

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.