From: Andy Lutomirski <luto@amacapital.net>
To: "Michael S. Tsirkin" <mst@redhat.com>
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 10:28:43 -0700 [thread overview]
Message-ID: <CALCETrWyHZ5+mZnzgm_j=8N3-thznVmxrov1N7Lns45w2V0X8A@mail.gmail.com> (raw)
In-Reply-To: <20160802172326.GA25195@redhat.com>
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.
next prev parent reply other threads:[~2016-08-02 17:29 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-08-02 17:23 Michael S. Tsirkin
2016-08-02 17:28 ` Andy Lutomirski [this message]
2016-08-02 17:37 ` Michael S. Tsirkin
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='CALCETrWyHZ5+mZnzgm_j=8N3-thznVmxrov1N7Lns45w2V0X8A@mail.gmail.com' \
--to=luto@amacapital.net \
--cc=ksummit-discuss@lists.linuxfoundation.org \
--cc=mst@redhat.com \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox