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:	Wed, 8 Jul 2015 15:05:37 -0400
From:	Brian Gerst <brgerst@...il.com>
To:	Andy Lutomirski <luto@...capital.net>
Cc:	Linus Torvalds <torvalds@...ux-foundation.org>,
	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 Wed, Jul 8, 2015 at 1:30 PM, Andy Lutomirski <luto@...capital.net> wrote:
> On Wed, Jul 8, 2015 at 9:59 AM, Linus Torvalds
> <torvalds@...ux-foundation.org> wrote:
>> On Tue, Jul 7, 2015 at 7:33 PM, Arjan van de Ven <arjan@...ux.intel.com> wrote:
>>>
>>> if this patch would not be acceptable, at minimum we need some sort of "off
>>> by default
>>> unless the sysadmin flips a sysfs thing", which is really just a huge hack.
>>
>> The only thing that matters is whether people use this or not.
>>
>
> I think that the world contains precisely two programs that use the
> vm86 syscalls.  One is dosemu, and one is a test case I wrote.  (There
> are probably some exploits written by other people that I don't know
> about.  Certainly Spender has been patching vm86 for long enough that
> he must have an exploit or two up his sleeve.)
>
> As far as I can tell (and I'll try to test this better for real later
> this week), dosemu already knows how to emulate real mode if vm86 is
> unavailable.  So it's unclear that turning off the vm86 syscalls
> actually breaks anything whatsoever.
>
> On the other hand, sys_vm86 fails if the syscall slow path is in use.
> That means that quite a few Fedora versions (auditing), anything with
> ptrace, seccomp (before 3.16 IIRC), and anything with context tracking
> is probably actually *improved* by turning off the vm86 syscalls even
> for dosemu users.
>
> And apparently Ubuntu has had CONFIG_VM86 disabled forever.
>
> IOW, vm86 really is broken.
>
>> If people use vm86 mode, we can't just disable it. It's that simple.
>> "It's poorly maintained" isn't an argument for removal. Only "nobody
>> cares" works as an argument for that.
>>
>> My suspicion is that people still do use vm86 mode, but who knows..
>> Quite frankly, rather than disable it, I'd much rather see people who
>> modify low-level x86 code (yes, that means you, Luto) *test* it. If
>> you aren't willign to test the modifications you make, I don't think
>> those modifications should be merged, regardless of how nice a cleanup
>> they are.
>
> I tried to test it.  As far as I know, my changes in -tip have no
> effect on vm86, and the changes I'm planning on sending this week will
> make it work better.  I still thing that Linux users should have it
> configured out or deleted altogether.  Especially people who care at
> all about security.
>
> It's easy to try the easy case (run from tools/testing/selftests/x86)
> -- this is v4.2-rc1, but most recent versions should be identical:
>
> $ ./entry_from_vm86_32
> [RUN]    #BR from vm86 mode
> [OK]    Exited vm86 mode due to #BR
> [RUN]    SYSENTER from vm86 mode
> [OK]    Exited vm86 mode due to unhandled GP fault
>
> $ strace -e vm86 ./entry_from_vm86_32
> [RUN]    #BR from vm86 mode
> vm86(0x1, 0xbfa50fcc, 0xbfa50fcc, 0x80488bb, 0x1000) = -1 ENOSYS
> (Function not implemented)
> [OK]    Exited vm86 mode due to type 0, arg 0
> [RUN]    SYSENTER from vm86 mode
> vm86(0x1, 0xbfa50fcc, 0xbfa50fcc, 0x80488bb, 0x1000) = -1 ENOSYS
> (Function not implemented)
> [OK]    Exited vm86 mode due to type 0, arg 0
>
> It only says "[OK]" because my test case isn't careful enough.  That's
> a failure.  I suspect it was a much worse failure a couple versions
> ago before my ENOSYS-reworking patch went in.
>
> Replace "-e vm86" with "-e write" and be puzzled.  The failure mode is
> really pretty bad.
>
> This only tests easy stuff.  The integration between vm86 and fault
> handling is truly awful and I don't even know how to approach testing
> it.  I'd probably have to run twenty or thirty old real-mode games to
> even exercise those code paths.
>
> I'll try to confirm later this week that dosemu can really handle real
> mode without sys_vm86.

None of these issues are unfixable.  As I said before, many of them
can be resolved if vm86 is changed to use the normal syscall/exception
exit paths.  Give me a few days to finish off that patch set.

--
Brian Gerst
--
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/