All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Michael S. Tsirkin" <mst@redhat.com>
To: Andy Lutomirski <luto@amacapital.net>
Cc: Paolo Bonzini <pbonzini@redhat.com>,
	"ksummit-discuss@lists.linuxfoundation.org"
	<ksummit-discuss@lists.linuxfoundation.org>
Subject: Re: [Ksummit-discuss] late self-nomination
Date: Tue, 2 Aug 2016 20:37:34 +0300	[thread overview]
Message-ID: <20160802203444-mutt-send-email-mst@kernel.org> (raw)
In-Reply-To: <CALCETrWyHZ5+mZnzgm_j=8N3-thznVmxrov1N7Lns45w2V0X8A@mail.gmail.com>

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

  reply	other threads:[~2016-08-02 17:37 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-08-02 17:23 [Ksummit-discuss] late self-nomination Michael S. Tsirkin
2016-08-02 17:28 ` Andy Lutomirski
2016-08-02 17:37   ` Michael S. Tsirkin [this message]
2016-08-02 19:00     ` Paolo Bonzini
2016-08-02 22:44       ` Michael S. Tsirkin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20160802203444-mutt-send-email-mst@kernel.org \
    --to=mst@redhat.com \
    --cc=ksummit-discuss@lists.linuxfoundation.org \
    --cc=luto@amacapital.net \
    --cc=pbonzini@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.