From: Jon Masters <jcm@redhat.com>
To: speck@linutronix.de
Subject: [MODERATED] Re: KVM L1TF options
Date: Thu, 5 Jul 2018 15:22:41 -0400 [thread overview]
Message-ID: <a5fc039b-e538-d360-4e83-29b6b06bf1c6@redhat.com> (raw)
In-Reply-To: <47ec967f-ae94-cb68-65ce-64d4aaf14609@suse.de>
[-- Attachment #1: Type: text/plain, Size: 2162 bytes --]
On 07/02/2018 05:41 PM, speck for Alexander Graf wrote:
> 4) EPT with PT sanitization
> We could map additional guest read only RAM in an unused window of the
> guest physical address space as a page table cache. Then trap CR3
> writes. On CR3 writes, check if we have a counter-page to the original
> CR3 entry, point to our sanitized clone instead. Otherwise create one.
> Then we can slowly propagate that clone similar to shadow page tables,
> but we would never have to do the GPA->HVA->GPA dance. Instead, all we
> need to do is check whether a PTE has the P bit set or not. If it does,
> copy it. If it doesn't, just set the whole clone PTE to 0.
I think this would be safe. It took a few minutes thinking about it, but
what you're saying is that the guest *never* has control over its page
tables. It's like shadow page tables but leveraging the hardware assist
from EPT. So if anyone else also wondered, it's not just CR3, it's
actually every page is "shadowed" in this approach. So a guest can't
just toggle it's !P bit (even without doing an invalidation, force TLB
eviction, wait for walker to see the change) and attack the host. It
would be perfectly safe. Slower than EPT, maybe faster than shadow.
> The most annoying part about this approach is that we would need to
> implement A and D bits by hand, because a) the HW walker can not write
> to the clone PTE because it's mapped read-only and b) we should
> propagate the bits immediately into the real PTE anyway.
You could do this periodically though as some kind of background task,
just as long as you didn't then race with the guest also scanning. This
is what will kill performance, and differ between Linux and Windows.
> What I'm not quite sure of yet are page invalidations. Is there
> something we can trap on for those? Otherwise we'd have to set all page
> table pages to read-only in the EPT and that would end up very expensive.
>
> So what do people think about the idea? Does it sound doable?
Depends on the cost of emulating A/D bits and the above question.
Jon.
--
Computer Architect | Sent from my Fedora powered laptop
prev parent reply other threads:[~2018-07-05 19:22 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-07-02 21:41 [MODERATED] KVM L1TF options Alexander Graf
2018-07-02 21:44 ` [MODERATED] " Dave Hansen
2018-07-02 22:02 ` Anthony Liguori
2018-07-02 22:28 ` [MODERATED] Re: ***UNCHECKED*** " Alexander Graf
2018-07-02 22:33 ` Thomas Gleixner
2018-07-02 22:41 ` [MODERATED] " Anthony Liguori
2018-07-03 8:36 ` Paolo Bonzini
2018-07-03 12:50 ` [MODERATED] Re: ***UNCHECKED*** " Alexander Graf
2018-07-04 14:33 ` [MODERATED] " Jiri Kosina
2018-07-04 14:51 ` [MODERATED] Re: ***UNCHECKED*** " Alexander Graf
2018-07-05 19:22 ` Jon Masters [this message]
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=a5fc039b-e538-d360-4e83-29b6b06bf1c6@redhat.com \
--to=jcm@redhat.com \
--cc=speck@linutronix.de \
/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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).