Re: [Xen-devel] [PATCH 1/3] x86: allow 64?bit PV guest kernels to suppress user mode exposure of M2P

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 19.03.15 at 13:35, <tim@xxxxxxx> wrote:
> At 15:54 +0000 on 17 Mar (1426607644), Jan Beulich wrote:
>> Xen L4 entries being uniformly installed into any L4 table and 64-bit
>> PV kernels running in ring 3 means that user mode was able to see the
>> read-only M2P presented by Xen to the guests. While apparently not
>> really representing an exploitable information leak, this still very
>> certainly was never meant to be that way.
>> 
>> Building on the fact that these guests already have separate kernel and
>> user mode page tables we can allow guest kernels to tell Xen that they
>> don't want user mode to see this table. We can't, however, do this by
>> default: There is no ABI requirement that kernel and user mode page
>> tables be separate. Therefore introduce a new VM-assist flag allowing
>> the guest to control respective hypervisor behavior:
>> - when not set, L4 tables get created with the respective slot blank,
>>   and whenever the L4 table gets used as a kernel one the missing
>>   mapping gets inserted,
>> - when set, L4 tables get created with the respective slot initialized
>>   as before, and whenever the L4 table gets used as a user one the
>>   mapping gets zapped.
> 
> Right, I think I understand your reasoning here.  Can you put all this
> into a header or API doc somewhere?  The comment you add to xen.h is
> not nearly enough for an OS dev to figure this out.

Sure.

> Two questions (to which I suspect your answer is yes, but just for clarity):
> 
> - Is the ABI change that an always-user-mode context never gets access
>   to the RO M2P acceptable, then?  I can't think of a reason why a
>   guest would have been relying on the old behaviour, but it is still
>   a change.

No, I wouldn't view that as an ABI change, because the ABI never
specified that this range would be exposed. In fact how I coded
this was to make sure there is no ABI change at all, i.e. the
reasoning above is about why a simpler approach (assuming fully
separate kernel and user L4 tables) can't be used, as that would
result in an ABI change.

> - Are you happy that this is important enough to add extra code to the
>   context switch paths?

I'm not really happy to add stuff to the context switch path, but I
also don't think such an accidental exposure of data should be left
in place. (If we thought that there was absolutely no way an
attacker could make use of this, including making the exploit of
some other bug more harmful, then we could as well specify that
this data is being exposed to user mode, and have e.g. libxc use
it instead of the mmap() it does currently.)

Jan


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