[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAHk-=wgB39j-fwYz3A4a6AZymT21BjJv0SvrQNTJfZk9N+sv0A@mail.gmail.com>
Date: Sun, 29 Mar 2020 10:05:38 -0700
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Andy Lutomirski <luto@...capital.net>
Cc: Ingo Molnar <mingo@...nel.org>, Al Viro <viro@...iv.linux.org.uk>,
Thomas Gleixner <tglx@...utronix.de>, X86 ML <x86@...nel.org>,
LKML <linux-kernel@...r.kernel.org>,
Borislav Petkov <bp@...en8.de>
Subject: Re: [RFC][PATCH 01/22] x86 user stack frame reads: switch to explicit __get_user()
On Sun, Mar 29, 2020 at 9:50 AM Andy Lutomirski <luto@...capital.net> wrote:
>
> My incliniation is to just get rid of the __get_user()-style APIs.
That's definitely the direction we're going in, and Al has already
been moving that way.
There is basically zero advantage of __get_user() over get_user() these days.
Historically the advantage used to be quite noticeable (one could be
inlined and generated nice dense code for repeated single accesses),
but with CLAC/STAC that simply isn't the case any more.
> (It's possible that some arch code somewhere uses __get_user as a way
> to say "access user or kernel memory -- I know what I'm doing".
Not just possible - it was what was literally happening in tracing.
Except for the "I know what I'm doing" part, where tracing code used a
pointer that could be user pointer or kernel pointer interchangeably.
Which isn't even possible on some architectures (it just happens to
work on the common ones), because the same pointer bit pattern can be
either or.
But that got fixed, and hopefully there aren't other cases around any
more. But slowly converting away from __get_user() and friends should
end up fixing them all, since objtool will then verify that you do the
right user_access_begin() etc.
Linus
Powered by blists - more mailing lists