Re: Xen Project Spectre/Meltdown FAQ

[Peter <xen@randomwebstuff.com>]

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@gmail.com>
>> 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.

>> 
>> Best Regards
>> Lars
>> 
>> On 10 Jan 2018, at 06:03, Juergen Gross <jgross@suse.com> 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@gmail.com
>> <mailto:lars.kurth.xen@gmail.com>> 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@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel