linux-kernel - Re: [PATCH] x86/kconfig/32: Mark CONFIG

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]

Date:	Fri, 10 Jul 2015 09:44:01 -0700
From:	Andy Lutomirski <luto@...capital.net>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	"Eric W. Biederman" <ebiederm@...ssion.com>,
	Arjan van de Ven <arjan@...ux.intel.com>,
	Andy Lutomirski <luto@...nel.org>,
	"the arch/x86 maintainers" <x86@...nel.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Oleg Nesterov <oleg@...hat.com>,
	Kees Cook <keescook@...omium.org>,
	Peter Zijlstra <peterz@...radead.org>,
	Borislav Petkov <bp@...en8.de>
Subject: Re: [PATCH] x86/kconfig/32: Mark CONFIG_VM86 as BROKEN

On Fri, Jul 10, 2015 at 9:35 AM, Linus Torvalds
<torvalds@...ux-foundation.org> wrote:
> On Fri, Jul 10, 2015 at 7:37 AM, Andy Lutomirski <luto@...capital.net> wrote:
>>
>> Having just written a pile of tests for it, I don't think so, as long as none
>> of the syscall slow path stuff is in use :(
>
> It seems that you are thinking that people actually use vm86 mode as a
> real Linux mode, and do system calls from it etc.

Nope.

>
> The common situation is that you enter vm86 mode with vm86(), and that
> you exit it due to one of the (many) unhandled situations or a signal
> or whatever. Yeah,we handle a few sad instructions directly, but most
> vm86 exits just return to user mode.
>
> The system call paths just aren't an issue in reality, because they
> just aren't used.
>

That's not what I mean.  I'm referring to the vm86 syscall itself.  If
you have a ti flag that causes the slow exit path to be used, then you
call vm86.  vm86 sets up the ludicrous double stack frame that it uses
and jumps back to the exit asm.  The exit asm then branches off to the
slow path, hits the notifysig_v86 kludge, calls save_v86_state, tears
down its double stack frame, and keeps meandering back through the
exit asm.  We finally IRET right back to protected mode, and the code
that userspace was trying to execute in v8086 mode never actually
runs.

That code looked fishy when I first read it, and it is, indeed,
entirely incorrect.

So the vm86 syscall itself is broken if the slow path is in use.

Fortunately, you can't do an a syscall inside vm86.  If you could, I
think it would be a disaster, because the double stack means that the
syscall would run in a completely bogus context.

--Andy
--
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/