[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH v2 2/2] x86: allow Meltdown band-aid to be disabled

On 16/01/18 08:12, Jan Beulich wrote:
>>>> On 15.01.18 at 19:26, <andrew.cooper3@xxxxxxxxxx> wrote:
>> On 15/01/18 11:07, Jan Beulich wrote:
>>> --- a/docs/misc/xen-command-line.markdown
>>> +++ b/docs/misc/xen-command-line.markdown
>>> @@ -1849,6 +1849,15 @@ In the case that x2apic is in use, this
>>>  clustered mode.  The default, given no hint from the **FADT**, is cluster
>>>  mode.
>>> +### xpti
>>> +> `= <boolean>`
>>> +
>>> +> Default: `false` on AMD hardware
>>> +> Default: `true` everywhere else
>> This is fine for now, but any further isolation is going to have to be
>> unconditional, or possibly compile-time choice, but maintaining that
>> going forwards is going to be truly horrible.
>>> +
>>> +Override default selection of whether to isolate 64-bit PV guest page
>>> +tables.
>> This wants a
>> ** WARNING: Not yet a complete isolation implementation, but better than
>> nothing. **
>> or similar, just to avoid giving the people the impression that it is
>> complete.  Perhaps also a similar warning in the patch 1 commit message?
> I've added the warning text here as suggested, and a respective
> remark to patch 1's description, albeit under the current guidelines
> of when we would consider an information leak a security issue, I
> think isolation is sufficiently complete: No parts of the direct map
> not pertaining to the current guest are being exposed, which
> implies that no parts of the Xen heap not pertaining to the current
> guest are. Leaking control page contents of other guests as well
> as leaking the bits and pieces of the Xen image is not an issue by
> itself.
> IOW I'm not convinced such a warning is - strictly from a "would
> this need an XSA on its own" pov - entirely appropriate.

The isolation is definitely not complete.  Amongst other things, remote
stacks are in view of an attacker, which is why my KAISER-prereq series
pushes for the fully isolated per-pcpu range.

We do not, under any circumstances, want to give the impression that
this patch makes them completely immune to leaks, but improvements on
this status quo shouldn't need an XSA.


Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.