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] [day] [month] [year] [list]
Date:	Sat, 11 Jul 2015 11:18:39 +0200
From:	Ingo Molnar <mingo@...nel.org>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	Andy Lutomirski <luto@...capital.net>,
	"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


* Linus Torvalds <torvalds@...ux-foundation.org> wrote:

> [...]
> 
> So no marking it "BROKEN". No calling it names just because it doesn't work in 
> insane situations that nobody cares about. It's a legacy thing, and it probably 
> has very few users, but I'm getting the vibe that you want to remove it or hate 
> it just because it might not work in situations that simply don't make sense in 
> the first place, and that it was never used for anyway.

So just to make it clear that we are on the same page: I voiced a number of bad 
ideas in this thread that got you (rightfully) worried. Those bad ideas are all 
off the table:

  - We won't mark VM86 as BROKEN (which effectively disables it permanently)

  - We won't do SW emulation either.

The current plans with the vm86 ABI are the following:

  - We change the name to VM86_LEGACY and mark it default n to flush out
    people/distros who had it enabled for no good reason. Anyone who builds a new
    kernel for an old kernel and needs it for old hardware or DOS games can still
    enable it, and v86 will continue to work to the best of our abilities. (in 
    fact it will work better, now that we are gradually making the x86 entry code 
    more maintainable.)

  - We enhance the help text so that people who enable it make an informed choice.

  - We apply Brian's and Andy's various fixes and cleanups to fix all known vm86 
    bugs and to make it more maintainable.

Agreed?

Btw., what do you think about one more measure to make vm86 more configurable, and 
to allow the locking down of the default some more:

  - Introduce a sysctl that globally disables/enables the sys_vm86 and sys_vm86old
    syscalls by default for non-privileged users, i.e. something like:

    static int __read_mostly sysctl_x86_vm86_paranoia = 1;
    ...

	switch (sysctl_x86_vm86_paranoia) {
		case 0:
			/* Not paranoid at all: allow everyone vm86 access: */
			break;
		case 1:
			/* Somewhat paranoid: only allow privileged users vm86 access: */
			if (!capable(CAP_SYS_ADMIN))
				return -EPERM;
			break;
		case 2:
		default:
			/* Very paranoid, turn off the syscall: */
			return -EPERM;
	}

    Note that with this we also introduce the '2' setting: users in such a distro
    could still disable vm86 globally, as if it had been turned off in the kernel
    config.

Thanks,

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ