MIME-Version: 1.0
In-Reply-To: <CALCETrXy+Qh69sfMq9+PFLZ7AD9sCUXrFW0W5hFSVuuoY+Upeg@mail.gmail.com>
References: <5d120f358612d73fc909f5bfa47e7bd082db0af0.1429841474.git.luto@kernel.org>
 <CALCETrXy+Qh69sfMq9+PFLZ7AD9sCUXrFW0W5hFSVuuoY+Upeg@mail.gmail.com>
From: Denys Vlasenko <vda.linux@googlemail.com>
Date: Sun, 26 Apr 2015 14:34:13 +0200
Message-ID: <CAK1hOcOBgfmu9BPjEKpF8GMFcJb2FYRQmU5rc0q3PhVTg_SA=g@mail.gmail.com>
Subject: Re: [PATCH] x86_64, asm: Work around AMD SYSRET SS descriptor
 attribute issue
To: Andy Lutomirski <luto@amacapital.net>
Cc: Andy Lutomirski <luto@kernel.org>, X86 ML <x86@kernel.org>,
        "H. Peter Anvin" <hpa@zytor.com>, Borislav Petkov <bp@alien8.de>,
        Linus Torvalds <torvalds@linux-foundation.org>,
        Brian Gerst <brgerst@gmail.com>, Denys Vlasenko <dvlasenk@redhat.com>,
        Ingo Molnar <mingo@kernel.org>, Steven Rostedt <rostedt@goodmis.org>,
        Oleg Nesterov <oleg@redhat.com>,
        Frederic Weisbecker <fweisbec@gmail.com>,
        Alexei Starovoitov <ast@plumgrid.com>, Will Drewry <wad@chromium.org>,
        Kees Cook <keescook@chromium.org>,
        Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Content-Type: text/plain; charset=UTF-8
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1413
Lines: 26

On Fri, Apr 24, 2015 at 4:18 AM, Andy Lutomirski <luto@amacapital.net> wrote:
> On Thu, Apr 23, 2015 at 7:15 PM, Andy Lutomirski <luto@kernel.org> wrote:
> Even if the issue affects SYSRETQ, it could be that we don't care.  If
> the extent of the info leak is whether we context switched during a
> 64-bit syscall to a non-syscall context, then this is basically
> uninteresting.  In that case, we could either ignore the 64-bit issue
> entirely or fix it the other way: force SS to NULL on context switch
> (much faster, I presume) and fix it up before SYSRETL as Denys
> suggested.
>
> We clearly don't have a spate of crashes in programs that do SYSCALL
> from a 64-bit CS and then far jump/return to a 32-bit CS without first
> reloading SS, since this bug has been here forever.  I agree that the
> issue is ugly (if it exists in the first place), but maybe we don't
> need to fix it.

If you feel that concerned by the speed impact,
you can also disable this fix for !CONFIG_IA32_EMULATION kernels.
If kernel builder declared they don't want 32-bit userspace,
they won't do any ridiculous "I will temporarily
switch to 32-bit mode in 64-bit tasks" stuff either.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/