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 17:54, <andrew.cooper3@xxxxxxxxxx> wrote:
> On 24/04/15 16:07, Jan Beulich wrote:
>>>>> 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.
> 
> 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).

Userspace was never supposed to access this table, and hence
revoking access to the table cannot be a problem there.

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

The ordering doesn't matter. In relaxed mode, the first time a
table gets used for kernel purposes the entry will be inserted
(and hence potentially become visible to user mode).

But anyway I'm confused that you're starting this discussion
now, when the patch had already gone in and only needed to
be reverted because of breaking migration.

Jan


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