[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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |