[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CALCETrUjtfZDnpcAWVR94ubf3UEhPykRU-EhQDS6JSdCaZhuwQ@mail.gmail.com>
Date: Fri, 8 Apr 2016 09:03:12 -0700
From: Andy Lutomirski <luto@...capital.net>
To: Ingo Molnar <mingo@...nel.org>
Cc: Andy Lutomirski <luto@...nel.org>, Borislav Petkov <bp@...en8.de>,
"security@...nel.org" <security@...nel.org>,
X86 ML <x86@...nel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
Linus Torvalds <torvalds@...ux-foundation.org>,
Rudolf Marek <r.marek@...embler.cz>,
Denys Vlasenko <dvlasenk@...hat.com>,
Thomas Gleixner <tglx@...utronix.de>,
"H. Peter Anvin" <hpa@...or.com>
Subject: Re: [PATCH v3 2/7] x86/arch_prctl: Fix ARCH_GET_FS and ARCH_GET_GS
On Fri, Apr 8, 2016 at 12:13 AM, Ingo Molnar <mingo@...nel.org> wrote:
>
> * Andy Lutomirski <luto@...nel.org> wrote:
>
>> ARCH_GET_FS and ARCH_GET_GS attempted to figure out the fsbase and
>> gsbase respectively from saved thread state. This was wrong: fsbase
>> and gsbase live in registers while a thread is running, not in
>> memory.
>
> So I'm wondering, the current code looks totally broken,what user-space code can
> possibly use this? I checked glibc and Wine, and neither of them does. Wine uses
> ARCH_SET_GS and glibc uses ARCH_SET_FS, but that's all - neither actually tries to
> use the ARCH_GET_* reading APIs.
>
> So for backporting purposes I'd be much happier about simply returning -EINVAL or
> -ENOSYS, and we could re-introduce this code in v4.7.
>
Let's just not backport this one. There's no security issue here. If
you like the rest of the series, can you remove the stable tag from
this patch when you apply it?
I think the old code was at least correct enough that if you did
ARCH_GET_FS after ARCH_SET_FS with no funny business in between, it
would work.
--Andy
--
Andy Lutomirski
AMA Capital Management, LLC
Powered by blists - more mailing lists