On Mon, Nov 27, 2017 at 9:03 PM, Josh Poimboeuf <[email protected]> wrote: > On Mon, Nov 27, 2017 at 07:36:40PM -0800, Andy Lutomirski wrote: >> On Mon, Nov 27, 2017 at 2:31 PM, Peter Zijlstra <[email protected]> wrote: >> > So we can more easily see if the shiny got enabled. >> > >> > Signed-off-by: Peter Zijlstra (Intel) <[email protected]> >> > --- >> > arch/x86/mm/kaiser.c | 2 ++ >> > 1 file changed, 2 insertions(+) >> > >> > --- a/arch/x86/mm/kaiser.c >> > +++ b/arch/x86/mm/kaiser.c >> > @@ -425,6 +425,8 @@ void __init kaiser_init(void) >> > if (!kaiser_enabled) >> > return; >> > >> > + printk("All your KAISER are belong to us\n"); >> > + >> >> All your incomprehensible academic names are belong to us. >> >> On a serious note, can we please banish the name KAISER from all the >> user-facing bits? No one should be setting a boot option that has a >> name based on an academic project called "Kernel Address Isolation to >> have Side-channels Efficiently Removed". We're not efficiently >> removing side channels. The side channels are still very much there. >> Heck, the series as currently presented doesn't even rescue kASLR. It >> could*, if we were to finish the work that I mostly started and >> completely banish all the normal kernel mappings from the shadow** >> tables. We're rather inefficiently (and partially!) mitigating the >> fact that certain CPU designers have had their heads up their >> collective arses for *years* and have failed to pay attention to >> numerous academic papers documenting that fact. >> >> Let's call the user facing bits "separate user pagetables". If we >> want to make it conditioned on a future cpu cap called >> X86_BUG_REALLY_DUMB_SIDE_CHANNELS, great, assuming a better CPU ever >> shows up. But please let's not make users look up WTF "KAISER" means. >> >> * No one ever documented the %*!& side channels AFAIK, so everything >> we're talking about here is mostly speculation. >> >> ** The word "shadow" needs to die, too. I know what shadow page >> tables are, and they have *nothing* to do with KAISER. > > +1. Somebody please rename KAISER and shadow page tables for more > clarity. > > To fix KASLR I think we need to move (at least parts of) .entry.text, > .irqentry.text, and .entry_trampoline into their own fixed section(s). > Is there anything else missing?
We need to completely eliminate anything that maps normal kernel addresses into the usermode tables. > > -- > Josh
