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

[Hans van Kranenburg <hans@xxxxxxxxxxx>]

On 01/11/2018 08:22 PM, Peter wrote:
> On 2018-01-11 22:16, Lars Kurth wrote:
>> And this time with attachment
>>> On 11 Jan 2018, at 09:15, Lars Kurth <lars.kurth.xen@xxxxxxxxx>
>>> wrote:
>>>
>>> I am wondering whether something like the attached table would make
>>> understanding the FAQ easier. Page 1 is clearly what is Xen specific
>>> and we definitely should cover.
>>> Page 2 in general covers Linux and guests. The first block is
>>> relatively straightforward.
>>>
>>> The 2nd and 3rd block is based on information from Doug: as there
>>> are many gaps, I would be uneasy about publishing these somewhere
>>> prominent.
>>>
>>> Also
>>>
>>>> As this is really guest specific this information can't be
>>>> provided by
>>>> Xen.
>>>
>>> which carries a risk that any analysis made by anyone might only
>>> apply to the context in which the analysis was done.
>>>
>>> But the question keeps coming up, so making this clearer is maybe
>>> sensible.
> 
> In the matrix I see "Is a user space attack on the guest kernel possible
> (when running in a Xen VM)?" For PVH (and HVM) = Yes[1] where [1]
> Impacts Intel CPUs only.
> 
> Is there any mitigation for this?  i.e. How to protect a guest VM from
> its own userspace processes.

That part is handled by the kernel inside the guest. Xen doesn't see
that happening.

It's for example the KPTI/KAISER patches that got into the linux kernels
now.

>>>
>>> Best Regards
>>> Lars
>>>
>>> On 10 Jan 2018, at 06:03, Juergen Gross <jgross@xxxxxxxx> wrote:
>>> On 10/01/18 04:58, Peter wrote:
>>> On 2018-01-09 15:04, Stefano Stabellini wrote:
>>> On Sun, 7 Jan 2018, 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.
>>
>> +1
>>
>> I believe
>> https://blog.xenproject.org/2018/01/04/xen-project-spectremeltdown-faq/
>> is clear re VMs attacking/accessing the host/dom0/hypervisor and the
>> mitigations for that.
>>
>> However the page seems ambiguous about whether 64 bit VMs running as
>> PVHv2 with host provided kernels are protected or not (from each VM's
>> own processes).
>>
>> PVHv2 is using exactly the same runtime environment as HVM seen from
>> the
>> hypervisor. So a guest running as PVHv2 needs a PTI like approach like
>> HVM in its kernel.
>>
>>> Can the page be updated to be more explicit and perhaps describe how
>>> the
>>> VM kernel or how the PVHv2 virtualization provides that protection.
>>> And
>>> ideally how that could be checked from the VM itself.  e.g. grep pti
>>> /proc/cpuinfo?
>>
>> As this is really guest specific this information can't be provided by
>> Xen.
>>
>>> e.g. the page says: "Guest kernels running in 64-bit PV mode are not
>>> directly vulnerable to attack using SP3, because 64-bit PV guests
>>> already run in a KPTI-like mode." but it does not mention PVHv2 for
>>> that.  Is it protected under PVHv2?  Does it depend on the kernel?
>>> Is
>>> so what is the patchset/option/mechanism that protects the VM from
>>> its
>>> own processes?
>>
>> This question should have been answered above already.
>>
>> Juergen
>>
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@xxxxxxxxxxxxxxxxxxxx
> https://lists.xenproject.org/mailman/listinfo/xen-devel


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel