linux-kernel - Re: [PATCH] x86_64, asm: Work around AMD SYSRET SS descriptor attribute issue

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20150427164024.GD28871@pd.tnic>
Date:	Mon, 27 Apr 2015 18:40:24 +0200
From:	Borislav Petkov <bp@...en8.de>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	Andy Lutomirski <luto@...capital.net>,
	Andy Lutomirski <luto@...nel.org>, X86 ML <x86@...nel.org>,
	"H. Peter Anvin" <hpa@...or.com>,
	Denys Vlasenko <vda.linux@...glemail.com>,
	Brian Gerst <brgerst@...il.com>,
	Denys Vlasenko <dvlasenk@...hat.com>,
	Ingo Molnar <mingo@...nel.org>,
	Steven Rostedt <rostedt@...dmis.org>,
	Oleg Nesterov <oleg@...hat.com>,
	Frederic Weisbecker <fweisbec@...il.com>,
	Alexei Starovoitov <ast@...mgrid.com>,
	Will Drewry <wad@...omium.org>,
	Kees Cook <keescook@...omium.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] x86_64, asm: Work around AMD SYSRET SS descriptor
 attribute issue

On Mon, Apr 27, 2015 at 09:00:08AM -0700, Linus Torvalds wrote:
> On Mon, Apr 27, 2015 at 8:46 AM, Borislav Petkov <bp@...en8.de> wrote:
> >
> > Right, what about the false positives:
> 
> Anybody who tries to return to kernel addresses with sysret is
> suspect. It's more likely to be an attack vector than anything else
> (ie somebody who is trying to take advantage of a CPU bug).
> 
> I don't think there are any false positives. The only valid sysret
> targets are in normal user space.
> 
> There's the "vsyscall" area, I guess, but we are actively discouraging

vsyscall=native on old glibc, says Andy.

> people from using it (it's emulated by default) and using iret to
> return from it is fine if somebody ends up using it natively. It was a
> mistake to have fixed addresses with known code in it, so I don't
> think we should care.
> 
> We've had the inexact version for a long time, and the exact canonical
> address check hasn't even hit my tree yet. I wouldn't worry about it.
> 
> And since we haven't even merged the "better check for canonical
> addresses" it cannot even be a regression if we never really use it.

Well, it certainly sounds to me like not really worth the trouble to do
the exact check. So I'm all for dropping it. Unless Andy doesn't come up
with a "but but, there's this use case..."

Either way, the NOPs-version is faster and I'm running the test with the
F16h-specific NOPs to see how they perform.

-- 
Regards/Gruss,
    Boris.

ECO tip #101: Trim your mails when you reply.
--
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/