Messages in this thread | | | From | Linus Torvalds <> | Date | Thu, 7 Feb 2019 11:50:52 +0000 | Subject | Re: [GIT PULL] x86/mm changes for v4.21 |
| |
On Thu, Feb 7, 2019 at 10:18 AM Peter Zijlstra <peterz@infradead.org> wrote: > > So now the question is where to put it back in, I'm thinking this might > want to be in __cpa_addr().
Wasn't one of the goals to *not* keep the real virtual address around to avoid speculation, since we don't want some random speculation using that address to then trigger more MCE's?
If you re-generate the canonical address in __cpa_addr(), now we'll actually have the real virtual address around for a lot of code-paths (pte lookup etc), which was what people wanted to avoid in the first place.
NOTE! I may be *entirely* off on this, and just confused about exactly which speculative accesses people were worried about.
But at the same time, looking at all the other cases, it does look like we need to do it in __cpa_addr(), because we also have other tsts for an actual valid virtual address, ie all the
vaddr = __cpa_addr(cpa, cpa->curpage); if (!(within(vaddr, PAGE_OFFSET, PAGE_OFFSET + (max_pfn_mapped << PAGE_SHIFT)))) {
kind of checks.
What's the exact rule and path from "set_mce_nospec()" (which is what sets that "decoy" address with the high bit clear) to when we can then use the address for tlb flushing?)
Adding Dan Williams to the participants, because it's really only set_mce_nospec() that triggers this, and where should try to be careful that that path really doesn't use the actual real virtual address. He touched it last.
But I guess the whole decoy_addr thing goes back to Tony Luck and commit ce0fa3e56ad2 ("x86/mm, mm/hwpoison: Clear PRESENT bit for kernel 1:1 mappings of poison pages").
Do we really need it?
Linus
| |