[Ksummit-discuss] late self-nomination

[Ksummit-discuss] late self-nomination

[Michael S. Tsirkin]

Hi folks!

Likely too late, but oh well.
I would like to self-nominate for kernel summit this year.

I am the maintainer of the virtio subsystem, and within KVM, of the PC
and PCI subsystems.  Intelnally within Red Hat I'm a tech lead for the
team handling the networking for VMs.

I would like to participate in self-hardening to see whether
hypervisor extensions (like e.g. kernel guard technology)
can benefit that project, in the memory model discussions
as virtio is a heavy user of memory barriers and could benefit
a lot e.g. from faster mb implementations. I would
also like to learn more about group maintainership
as we are seeing issues scaling co-maintainership with
our current structure with virtio.

Cheers,

-- 
MST

Re: [Ksummit-discuss] late self-nomination

[Andy Lutomirski]

On Tue, Aug 2, 2016 at 10:23 AM, Michael S. Tsirkin <mst@redhat.com> wrote:
> Hi folks!
>
> Likely too late, but oh well.
> I would like to self-nominate for kernel summit this year.
>
> I am the maintainer of the virtio subsystem, and within KVM, of the PC
> and PCI subsystems.  Intelnally within Red Hat I'm a tech lead for the
> team handling the networking for VMs.
>
> I would like to participate in self-hardening to see whether
> hypervisor extensions (like e.g. kernel guard technology)
> can benefit that project,

This isn't quite on-topic, but I suggested something that I think
would be useful last year (possibly off-list -- I don't remember):

On x86 with VMX, the EPT page tables have separate R, W, and X bits.
If a hypervisor were to limit the guest physical address space to the
lower half (high bit always clear) and then alias all of it with the
high guest physical address bit set and R clear, then the guest could
use the high physical address bit as an effective R bit.  That would
allow PROT_WRITE, PROT_EXEC, and PROT_WRITE|PROT_EXEC mappings to work
without granting read access.

Doing this would provide some protection against attacks that use a
wild read to scan for code or data structures at otherwise
unpredictable addresses or to blindly search for ROP gadgets.

Re: [Ksummit-discuss] late self-nomination

[Michael S. Tsirkin]

On Tue, Aug 02, 2016 at 10:28:43AM -0700, Andy Lutomirski wrote:
> On Tue, Aug 2, 2016 at 10:23 AM, Michael S. Tsirkin <mst@redhat.com> wrote:
> > Hi folks!
> >
> > Likely too late, but oh well.
> > I would like to self-nominate for kernel summit this year.
> >
> > I am the maintainer of the virtio subsystem, and within KVM, of the PC
> > and PCI subsystems.  Intelnally within Red Hat I'm a tech lead for the
> > team handling the networking for VMs.
> >
> > I would like to participate in self-hardening to see whether
> > hypervisor extensions (like e.g. kernel guard technology)
> > can benefit that project,
> 
> This isn't quite on-topic, but I suggested something that I think
> would be useful last year (possibly off-list -- I don't remember):
> 
> On x86 with VMX, the EPT page tables have separate R, W, and X bits.
> If a hypervisor were to limit the guest physical address space to the
> lower half (high bit always clear) and then alias all of it with the
> high guest physical address bit set and R clear, then the guest could
> use the high physical address bit as an effective R bit.  That would
> allow PROT_WRITE, PROT_EXEC, and PROT_WRITE|PROT_EXEC mappings to work
> without granting read access.
> 
> Doing this would provide some protection against attacks that use a
> wild read to scan for code or data structures at otherwise
> unpredictable addresses or to blindly search for ROP gadgets.

Thanks - I expect we'll discuss this topic with other kvm folks quite a
bit on the kvm forum end of August, as well.

-- 
MST

Re: [Ksummit-discuss] late self-nomination

[Paolo Bonzini]

> > On x86 with VMX, the EPT page tables have separate R, W, and X bits.
> > If a hypervisor were to limit the guest physical address space to the
> > lower half (high bit always clear) and then alias all of it with the
> > high guest physical address bit set and R clear, then the guest could
> > use the high physical address bit as an effective R bit.  That would
> > allow PROT_WRITE, PROT_EXEC, and PROT_WRITE|PROT_EXEC mappings to work
> > without granting read access.
> > 
> > Doing this would provide some protection against attacks that use a
> > wild read to scan for code or data structures at otherwise
> > unpredictable addresses or to blindly search for ROP gadgets.
> 
> Thanks - I expect we'll discuss this topic with other kvm folks quite a
> bit on the kvm forum end of August, as well.

I won't be able to attend kernel summit (I haven't nominated me for this
reason) so I support Michael's presence!

Paolo

Re: [Ksummit-discuss] late self-nomination

[Michael S. Tsirkin]

On Tue, Aug 02, 2016 at 03:00:13PM -0400, Paolo Bonzini wrote:
> > > On x86 with VMX, the EPT page tables have separate R, W, and X bits.
> > > If a hypervisor were to limit the guest physical address space to the
> > > lower half (high bit always clear) and then alias all of it with the
> > > high guest physical address bit set and R clear, then the guest could
> > > use the high physical address bit as an effective R bit.  That would
> > > allow PROT_WRITE, PROT_EXEC, and PROT_WRITE|PROT_EXEC mappings to work
> > > without granting read access.
> > > 
> > > Doing this would provide some protection against attacks that use a
> > > wild read to scan for code or data structures at otherwise
> > > unpredictable addresses or to blindly search for ROP gadgets.
> > 
> > Thanks - I expect we'll discuss this topic with other kvm folks quite a
> > bit on the kvm forum end of August, as well.
> 
> I won't be able to attend kernel summit (I haven't nominated me for this
> reason) so I support Michael's presence!
> 
> Paolo

I didn't realize. In that case I might be able to also give some
kind of summary from the kvm forum as well, if there's interest.

-- 
MST