From: Rik van Riel <riel@redhat.com>
To: Andy Lutomirski <luto@kernel.org>
Cc: Borislav Petkov <bp@alien8.de>,
Linus Torvalds <torvalds@linux-foundation.org>,
Markus Trippelsdorf <markus@trippelsdorf.de>,
Ingo Molnar <mingo@kernel.org>,
Thomas Gleixner <tglx@linutronix.de>,
Peter Zijlstra <peterz@infradead.org>,
LKML <linux-kernel@vger.kernel.org>,
Ingo Molnar <mingo@redhat.com>,
Tom Lendacky <thomas.lendacky@amd.com>
Subject: Re: Current mainline git (24e700e291d52bd2) hangs when building e.g. perf
Date: Mon, 11 Sep 2017 11:08:17 -0400 [thread overview]
Message-ID: <1505142497.21121.36.camel@redhat.com> (raw)
In-Reply-To: <CALCETrU5iZo5_7+cn=NLYws2r8nvu7huxBQOJcMvanGKsFs7+A@mail.gmail.com>
On Sun, 2017-09-10 at 18:46 -0700, Andy Lutomirski wrote:
>
> No, nothing stops the problematic speculative load. Here's the
> issue.
> One CPU removes a reference to a page table from a higher-level page
> table, flushes, and then frees the page table. Then it re-allocates
> it and writes something unrelated there. Another CPU that has CR3
> pointing to the page hierarchy in question could have a reference to
> the freed table in its paging structure cache. Even if it's
> guaranteed to not try to access the addresses in question (because
> they're user addresses and the other CPU is in kernel mode, etc), but
> there is never a guarantee that the CPU doesn't randomly try to fill
> its TLB for the affected addresses. This results in invalid PTEs in
> the TLB, possible accesses using bogus memory types, and maybe even
> reads from IO space.
Good point, I had forgotten all about memory accesses
that do not originate with software behavior.
next prev parent reply other threads:[~2017-09-11 15:08 UTC|newest]
Thread overview: 61+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-09-05 7:27 Current mainline git (24e700e291d52bd2) hangs when building e.g. perf Markus Trippelsdorf
2017-09-05 8:53 ` Peter Zijlstra
2017-09-05 9:55 ` Markus Trippelsdorf
2017-09-06 12:52 ` Thomas Gleixner
2017-09-06 13:15 ` Markus Trippelsdorf
2017-09-07 6:28 ` Markus Trippelsdorf
2017-09-08 5:35 ` Markus Trippelsdorf
2017-09-08 6:26 ` Thomas Gleixner
2017-09-08 8:05 ` Borislav Petkov
2017-09-08 9:16 ` Borislav Petkov
2017-09-08 9:48 ` Markus Trippelsdorf
2017-09-08 10:35 ` Ingo Molnar
2017-09-08 10:39 ` Markus Trippelsdorf
2017-09-08 11:30 ` Markus Trippelsdorf
2017-09-08 16:12 ` Andy Lutomirski
2017-09-08 17:16 ` Markus Trippelsdorf
2017-09-08 21:47 ` Andy Lutomirski
2017-09-08 21:56 ` Borislav Petkov
2017-09-08 23:07 ` Andy Lutomirski
2017-09-08 23:23 ` Linus Torvalds
2017-09-09 0:00 ` Andy Lutomirski
2017-09-09 1:05 ` Linus Torvalds
2017-09-09 1:39 ` Andy Lutomirski
2017-09-09 17:49 ` Andy Lutomirski
2017-09-09 18:02 ` Linus Torvalds
2017-09-09 6:39 ` Markus Trippelsdorf
2017-09-09 10:18 ` Borislav Petkov
2017-09-09 11:07 ` Markus Trippelsdorf
2017-09-09 13:07 ` Borislav Petkov
2017-09-09 13:37 ` Markus Trippelsdorf
2017-09-09 13:39 ` Markus Trippelsdorf
2017-09-09 14:07 ` Borislav Petkov
2017-09-09 14:20 ` Markus Trippelsdorf
2017-09-09 14:33 ` Borislav Petkov
2017-09-09 14:43 ` Markus Trippelsdorf
2017-09-09 16:32 ` Markus Trippelsdorf
2017-09-09 17:05 ` Borislav Petkov
2017-09-09 17:23 ` Markus Trippelsdorf
2017-09-09 17:36 ` Borislav Petkov
2017-09-09 18:14 ` Markus Trippelsdorf
2017-09-09 18:26 ` Borislav Petkov
2017-09-09 18:46 ` Markus Trippelsdorf
2017-09-09 19:11 ` Borislav Petkov
2017-09-09 19:19 ` Borislav Petkov
2017-09-09 18:26 ` Linus Torvalds
2017-09-09 18:29 ` Borislav Petkov
2017-09-09 18:47 ` Linus Torvalds
2017-09-09 19:09 ` Borislav Petkov
2017-09-09 19:21 ` Linus Torvalds
2017-09-09 19:28 ` Andy Lutomirski
2017-09-09 19:37 ` Borislav Petkov
2017-09-10 4:42 ` Andy Lutomirski
2017-09-10 20:22 ` Peter Zijlstra
2017-09-10 20:25 ` Andy Lutomirski
2017-09-17 17:04 ` Ingo Molnar
2017-09-11 1:12 ` Rik van Riel
2017-09-11 1:46 ` Andy Lutomirski
2017-09-11 15:08 ` Rik van Riel [this message]
2017-09-12 7:14 ` Markus Trippelsdorf
2017-09-09 8:13 ` Markus Trippelsdorf
2017-09-08 14:51 ` Borislav Petkov
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=1505142497.21121.36.camel@redhat.com \
--to=riel@redhat.com \
--cc=bp@alien8.de \
--cc=linux-kernel@vger.kernel.org \
--cc=luto@kernel.org \
--cc=markus@trippelsdorf.de \
--cc=mingo@kernel.org \
--cc=mingo@redhat.com \
--cc=peterz@infradead.org \
--cc=tglx@linutronix.de \
--cc=thomas.lendacky@amd.com \
--cc=torvalds@linux-foundation.org \
/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.