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:	Thu, 9 Jul 2015 11:33:05 -0700
From:	Andy Lutomirski <luto@...capital.net>
To:	Ingo Molnar <mingo@...nel.org>, Paolo Bonzini <pbonzini@...hat.com>
Cc:	Brian Gerst <brgerst@...il.com>,
	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 10:59 PM, Ingo Molnar <mingo@...nel.org> wrote:
>
> * Ingo Molnar <mingo@...nel.org> wrote:
>
>> > Without something like that, we'll be in the awkward position of having some
>> > of the selectors (DS, ES, FS, and GS) in both the normal pt_regs slot and in
>> > the extended hardware frame during execution of normal vm86-unaware kernel
>> > code.  If, on the other hand, we copied the selectors across in
>> > enter_from_user_mode and prepare_return_from_usermode, then pt_regs would work
>> > normally even for tasks that are running in v8086 mode.
>> >
>> > regs->flags & X86_EFLAGS_VM will be true regardless, so all of the asm that
>> > decides to invoke those helpers should work fine.
>>
>> Btw., has anyone considered an entirely different approach: using KVM's
>> instruction emulator to emulate vm86 16-bit code execution? Basically the vm86
>> system call would be kept compatible, but fully emulated, the CPU never enters
>> true 16-bit mode, just iterates pt_regs as if it had.
>>
>> This approach has four main advantages:
>>
>>  - we could remove the fragile vm86 code from the entry code
>>
>>  - it might even be faster for certain workloads than faulting in and out all
>>    the time and using ancient, fragile hardware mode of the CPU. (For example it
>>    could detect the VGA screen write patterns and accelerate them.)
>>
>>  - it could be made to work on 64-bit as well, FWIIW
>>
>>  - it would provide another angle of testing for the KVM emulator
>
> So there's a fifth advantage as well that I think needs to be stressed:
>
>    - it's an _obviously_ much more secure design, as we only iterate user-space
>      pt_regs and never truly touch any security relevant CPU state. The whole
>      nested pt_regs and different hw frame entry complications would go away
>      entirely. All CPU semantics would not be just assumed implicitly, but would
>      be very much present in the CPU emulator and would be reviewable.
>

Hmm.

If we did this, I think I'd prefer a slightly more general approach.
First teach KVM to support a mode in which it's purely an emulator
(Paolo: how hard is this?  It would also make testing the emulator
much easier).  Then re-implement vm86 on top of that.

The big downside of that, or of writing a more ad-hoc emulator, is
understanding what the semantics of all the weird vm86plus stuff is
supposed to be in the first place.  It's completely undocumented and
it's not at all obvious what it's all supposed to do.  This sounds
like a fairly large project.

I think I'd rather get all the distros to turn vm86 off and let it
slowly die in a dark corner.  After all, dosemu and vbetool both
already contain emulators that seem to work, and dosbox (which is, by
all reports, better than dosemu) never used vm86 in the first place.

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