Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
MIME-Version: 1.0
References: <20210202201846.716915-1-timur@kernel.org> <202102021351.AEDE896AB3@keescook>
 <9ce56a1c-9ea6-996b-84c6-cfde908c2ecd@kernel.org> <20210202173436.6516c676@gandalf.local.home>
In-Reply-To: <20210202173436.6516c676@gandalf.local.home>
From:   Linus Torvalds <torvalds@linux-foundation.org>
Date:   Tue, 2 Feb 2021 14:51:00 -0800
Message-ID: <CAHk-=wgaK4cz=K-JB4p-KPXBV73m9bja2w1W1Lr3iu8+NEPk7A@mail.gmail.com>
Subject: Re: [PATCH] lib/vsprintf: make-printk-non-secret printks all
 addresses as unhashed
To:     Steven Rostedt <rostedt@goodmis.org>
Cc:     Timur Tabi <timur@kernel.org>, Kees Cook <keescook@chromium.org>,
        Petr Mladek <pmladek@suse.com>,
        Sergey Senozhatsky <sergey.senozhatsky@gmail.com>,
        Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
        Linux-MM <linux-mm@kvack.org>,
        Matthew Wilcox <willy@infradead.org>,
        Andrew Morton <akpm@linux-foundation.org>,
        roman.fietze@magna.com, John Ogness <john.ogness@linutronix.de>,
        Akinobu Mita <akinobu.mita@gmail.com>
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

On Tue, Feb 2, 2021 at 2:34 PM Steven Rostedt <rostedt@goodmis.org> wrote:
>
>   "I also suspect that everybody has already accepted that KASLR isn't
>    really working locally anyway (due to all the hw leak models with
>    cache and TLB timing), so anybody who can look at kernel messages
>    already probably could figure most of those things out."

Honestly, if you have to pass a kernel command line, and there's a big
notice in the kernel messages about this, I no longer care.

Because it means that people who _do_ care will know about it.

But I don't want it to be a kernel config option - if you do
debugging, and you want unhidden pointers, you can add it to the
kernel command line and make sure it's *your* choice and not some
random kernel config by somebody else (ie distro).

And yes, my opinion is that KASRL really only works remotely anyway. I
think we might as well accept that as a fact, and that it's unlikely
that hardware will be fixed in general, even if on _some_ hardware
might make it work better than it works in general.

Instead of fighting windmills, accept that KASRL is dead locally for
the "wide access" cases (ie not necessarily just "shell access", but
"local JIT of uncontrolled code"), but do it because the remote case
still matters, and because a lot of local accesses are fairly
constrained in that they do *not* give random code execution to the
local users (but that "fairly constrained" presumably also generally
means that they can't do dmesg).

             Linus