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

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 24.04.15 at 16:57, <andrew.cooper3@xxxxxxxxxx> wrote:
> On 24/04/15 15:31, 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.
> 
> Is this complete?

Yes.

> For backwards compatibility, older kernels will not have m2p_strict set,
> and the m2p should unconditionally appear in all L4s.

No. L4s _only_ used for user mode have no need for this entry to
be non-zero. The difference between strict and relaxed mode is as
described - in strict mode, L4s default to have the entry populated
and tables used for user mode get it stripped, while in relaxed mode
L4s default to the empty and get the entry populated when used
for kernel mode. This guarantees that in non-strict mode all kernel
page tables have the entry filled, while in strict mode it guarantees
that all user page tables have it cleared.

Jan


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