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

Re: [Xen-devel] Xen Project Spectre/Meltdown FAQ

On 01/07/2018 05:11 PM, Andrew Cooper wrote:
> On 07/01/2018 15:00, Marek Marczykowski-Górecki wrote:
>> On Fri, Jan 05, 2018 at 07:05:56PM +0000, Andrew Cooper wrote:
>>> On 05/01/18 18:16, Rich Persaud wrote:
>>>>> On Jan 5, 2018, at 06:35, Lars Kurth <lars.kurth.xen@xxxxxxxxx
>>>>> <mailto:lars.kurth.xen@xxxxxxxxx>> wrote:
>>>>> Linux’s KPTI series is designed to address SP3 only.  For Xen guests,
>>>>> only 64-bit PV guests are affected by SP3. A KPTI-like approach was
>>>>> explored initially, but required significant ABI changes.  
>> Is some partial KPTI-like approach feasible? Like unmapping memory owned
>> by other guests, but keeping Xen areas mapped? This will still allow
>> leaking Xen memory, but there are very few secrets there (vCPUs state,
>> anything else?), so overall impact will be much lower.
> Feasible> certainly not on a short timescale.
> One issue which cropped up when discussing this option is that xenheap
> allocations use the directmap mappings to function.  vmap regions are
> another where we need to maintain permanent mappings to specific guest
> frames.
> Register state in struct vcpus, or stack frames including GPR content
> are probably the most directly-interesting information to read, but
> things like the console ring or grant frames might be equally lucrative.

That is to say, we are certainly working on solutions which will allow
PV guests to run in PV mode again.  Andrew posted an early draft of his
"KPTI-like solution" last week [1], and the solution you mention, of
essentially assuming that the guest can read hypervisor memory and
trying to make sure there's nothing there worth seeing, is being
discussed as well (in the same thread).



Xen-devel mailing list



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