Re: [Xen-devel] xc_evtchn_status fails with EFAULT on HVM, the same on PV works

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 14.01.17 at 03:52, <marmarek@xxxxxxxxxxxxxxxxxxxxxx> wrote:
> On Sat, Jan 14, 2017 at 01:47:49AM +0000, Andrew Cooper wrote:
>> In a native situation, SMAP raises #PF if hardware tries to follow a
>> user pointer outside of an area whitelisted by the kernel.  (The
>> copy_*_guest path suppresses #PF, opting instead to return -EFAULT.)
>> 
>> The choice of supervisor vs user in a pagewalk is a single bit, and Xen
>> (for better or worse, but realistically as a consequence of SMAP being
>> ~10 years younger than HVM guests) accesses pointers from hypercalls as
>> a supervisor entity when walking the pagetables.  The key point here is
>> that Xen must emulate the hardware pagewalker when trying to find the
>> data being pointed to.
>> 
>> If Xen has a bug causing spurious accesses to HVM guests, then all bets
>> are already off wrt memory corruption, because real hardware isn't used
>> to make the access.
>> 
>> As indicated before, we could deliberately break the Xen pagewalker to
>> ignore SMAP.  However, that would be identical to "pretend the guest
>> actually whitelisted this access". 
> 
> I think there is important difference between "whitelist all accesses
> to guest user memory for the hypercall time" vs "whitelist accesses done
> through copy_from_guest/copy_to_guest only". If I understand correctly
> above description, modifying privcmd_call would also suppress #PF when
> Xen would be tricked to access guest memory outside of copy_*_guest. Am
> I missing something?

There are two additional things to consider here:

1) For HVM guests, Xen can't access guest memory unintentionally,
as (other than in the PV case) virtual address spaces are distinct.

2) When the guest issues stac()/clac(), it indicates to Xen _its own_
intended view, without affecting Xen's. That is, as soon as hypervisor
context is being entered again, SMAP protection would be in effect
again (albeit as per point 1 guarding only against accessing PV guest
mappings).

So the driver adjustment suggested by Andrew has an effect on only
page walks done by Xen during copy_{to,from}_guest(), but not on
actual memory accesses.

> Anyway, if someone can access /dev/xen/privcmd and issue hypercalls,
> probably also can whitelist userspace access... So the practical
> difference is very small - apart from that I control Xen version, but
> not necessary the kernel. And I think this applies to many more Xen
> users (from which only I've tripped over this issue...). What is the
> point of SMAP if guest can disable it? Is it only about protecting
> hypervisor when attacker _does not_ control guest kernel?

As per above - each entity controls its own security here.

Jan


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