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

[Andrew Cooper <andrew.cooper3@citrix.com>]

On 24/04/15 16:07, Jan Beulich wrote:
>>>> On 24.04.15 at 16:57, <andrew.cooper3@citrix.com> 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.

There is only ever a single L4 in a particular virtual address space. 
The M2P is part of the Xen ABI range.

Previously, the M2P was present in all L4s which is why they leaked into
user context.

If we don not wish to break backwards compatibility with this change,
then in relaxed mode the M2P must remain in all tables, or Userspace
which is actually making use of mappings will suddenly start faulting
because of a change in Xen, not a kernel change (and an unknowing kernel
might not be prepared to handle this case).

By your description, in the relaxed case a newly created L4 which is
first used as user table will have the mapping clear.

Or am I missing something?

~Andrew