All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andi Kleen <ak@linux.intel.com>
To: speck@linutronix.de
Subject: [MODERATED] Re: [PATCH 1/6] Patch 1
Date: Wed, 25 Apr 2018 14:19:01 -0700	[thread overview]
Message-ID: <20180425211901.GN14273@tassilo.jf.intel.com> (raw)
In-Reply-To: <alpine.LFD.2.21.999.1804251313340.3798@i7.lan>

On Wed, Apr 25, 2018 at 01:15:35PM -0700, speck for Linus Torvalds wrote:
> On Wed, 25 Apr 2018, speck for Andi Kleen wrote:
> > 
> > This doesn't help unfortunately because it could also leak data inside
> > the guest. If skipping EPT causes the PA to point to some other page
> > inside the same guest you can leak that data. And that other page might
> > be owned by the kernel or by some other process.
> 
> Do you even read what I write?
> 
> THAT'S EXACTLY WHAT I TALKED ABOUT IN THE REST OF THE EMAIL.

Ok so I reread what you wrote. I think you're saying it's not a problem
because it's too hard to know what the other page is?

I can think of various ways around this:

Assume the attacker process owns most of the memory and
the attacked process is very small. It fills its own memory
with a known pattern. Then it checks against that pattern.
If it's not the pattern it's someone elses. 

Or it does the mprotect attack on a lot of different pages
that it cycles through, and tries on each of them, looking
for some known pattern?

Or the attacker uses memory pressure to force another 
process to cycle through a lot of memory, and always
retries inbetween until it sees some known pattern.

Considering all these cases, do you still say that mprotect does
not need to be mitigated?

It would seem very risky to me.

BTW people like Amazon care actually a lot about
security inside their guests.

-Andi

  reply	other threads:[~2018-04-25 21:19 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-04-25  3:29 [MODERATED] [PATCH 1/6] Patch 1 Andi Kleen
2018-04-25 15:51 ` [MODERATED] " Linus Torvalds
2018-04-25 16:06   ` Andi Kleen
2018-04-25 17:25     ` Linus Torvalds
2018-04-25 17:36       ` Andi Kleen
2018-04-25 18:00         ` Linus Torvalds
2018-04-25 18:11           ` Andi Kleen
2018-04-25 18:26             ` Thomas Gleixner
2018-04-25 18:30             ` [MODERATED] " Linus Torvalds
2018-04-25 18:51               ` Andi Kleen
2018-04-25 20:15                 ` Linus Torvalds
2018-04-25 21:19                   ` Andi Kleen [this message]
2018-04-25 22:35                     ` Linus Torvalds
2018-04-25 23:12                       ` Andi Kleen
2018-04-25 23:21                         ` Linus Torvalds
2018-04-25 23:39                           ` Andi Kleen
2018-04-26  3:22                             ` Linus Torvalds
2018-04-26  3:39                               ` Jon Masters
2018-04-26 13:59                           ` Michal Hocko
2018-04-26 17:14                             ` Linus Torvalds
2018-04-27  0:05                               ` Andi Kleen

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=20180425211901.GN14273@tassilo.jf.intel.com \
    --to=ak@linux.intel.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 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.