linux-kernel - Re: [PATCH] x86: entry_32.S: change ESPFIX test to not touch PT

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: <CAK1hOcOtCuuFJoCmR_T=K9=g-i0cqmu4QYoQJ6C2Utg6wbNf4A@mail.gmail.com>
Date:	Mon, 9 Mar 2015 16:00:42 +0100
From:	Denys Vlasenko <vda.linux@...glemail.com>
To:	Andy Lutomirski <luto@...capital.net>
Cc:	Denys Vlasenko <dvlasenk@...hat.com>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Steven Rostedt <rostedt@...dmis.org>,
	Ingo Molnar <mingo@...nel.org>, Borislav Petkov <bp@...en8.de>,
	"H. Peter Anvin" <hpa@...or.com>, 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>, X86 ML <x86@...nel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] x86: entry_32.S: change ESPFIX test to not touch PT_OLDSS(%esp)

On Mon, Mar 9, 2015 at 3:18 PM, Andy Lutomirski <luto@...capital.net> wrote:
> Do we actually need espfix on all returns to vm86 mode?

No, the current code (and my new version) does *not* do
espfix for vm86. It's not needed (apparently).

>> +       btl     $X86_EFLAGS_VM_BIT,PT_EFLAGS(%esp)
>> +       jc      restore_nocheck         # VM set, not it
>
> This seems useless.  In vm86 mode, espfix should work fine (even if
> pointlessly), CS won't have the two low bits set, and SS won't
> reference the LDT because it's not a selector at all.

You seem to suggest we can drop VM flag test.

If we do that, the tests for CS and SS will work on bogus data.
I.e. they will semi-randomly rouse execution through espfix.

Which will probably work correctly, but IIRC espfix does crazy stuff
which is likely to be slow.

What we definitely should do here is at least frame this check with
"#ifdef CONFIG_VM86".

> That being said, what ends up in the high bits of esp when we iret to
> vm86 mode?

I don't know. I guess it's time to write an actual vm86 testcase :)
--
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/