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

[Peter <xen@xxxxxxxxxxxxxxxxxx>]

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.
> > 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