Re: [Xen-devel] [PATCH] x86/hvm: Fix use-after-free introduced by c/s 428607a

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

On 02/02/16 11:39, Corneliu ZUZU wrote:
> On 2/2/2016 12:52 PM, Jan Beulich wrote:
>>> NULLing the pointers would cause things like rtc_deinit() to always
>>> blow
>>> up when it followed the NULL pointer.
>>>
>>> IMO, we should unconditionally always NULL pointers when freeing a
>>> pointer which isn't in local scope.  It would make issues such as these
>>> completely obvious.
>> As would poisoning the pointers, yet poisoning has the advantage
>> of not allowing PV guests to control what the hypervisor might
>> access when erroneously de-referencing such a pointer.
>>
>> Jan
>
> Jan, that sounds interesting. I hope I'm not intruding, but when you
> have the time, could you please expand on this?
> Besides distinguishing a nuked pointer from zeroed-out memory, I did
> not know of any other advantage of 0xDEADBEEF pointer poisoning
> (generally or specifically).

Xen is 64bit only these days.  Bit 47 of a 64bit pointer must be signed
extended, or a #GP fault occurs because of the use of a non-canonical
address.

Therefore, a pointer such as 0xdeadc0de00000000ULL will unconditionally
cause a #GP fault if Xen accidentally used it.

> How could possibly setting a pointer to NULL allow a PV guest to
> control what the hypervisor might access, if the hypervisor *can't
> access* a NULL pointer?
> And can a PV guest write data @ *hypervisor's* 0 page  (virtual and/or
> physical)?

Xen and PV guests share the virtual address space, in exactly the same
way as a native kernel and its userspace.  PV guests can map pages at 0.

Therefore, if Xen were to accidentally follow a NULL pointer, it may not
result in a pagefault.  (Hardware mechanisms such as SMEP and SMAP are
added protection against this, but don't work on older hardware)

~Andrew

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