Re: [PATCH 2/5] x86/mm/kaiser: Add a banner

[Andy Lutomirski]

On Mon, Nov 27, 2017 at 2:31 PM, Peter Zijlstra <peterz@xxxxxxxxxxxxx> wrote:
> So we can more easily see if the shiny got enabled.
>
> Signed-off-by: Peter Zijlstra (Intel) <peterz@xxxxxxxxxxxxx>
> ---
>  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.