Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1181736 > unrolled thread

Re: [PATCH] x86/kconfig/32: Mark CONFIG_VM86 as BROKEN

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [PATCH] x86/kconfig/32: Mark CONFIG_VM86 as BROKEN Linus Torvalds <torvalds@linux-foundation.org> - 2015-07-10 18:40 +0200
    Re: [PATCH] x86/kconfig/32: Mark CONFIG_VM86 as BROKEN Andy Lutomirski <luto@amacapital.net> - 2015-07-10 18:50 +0200
      Re: [PATCH] x86/kconfig/32: Mark CONFIG_VM86 as BROKEN Linus Torvalds <torvalds@linux-foundation.org> - 2015-07-10 19:10 +0200
        Re: [PATCH] x86/kconfig/32: Mark CONFIG_VM86 as BROKEN Andy Lutomirski <luto@amacapital.net> - 2015-07-10 19:20 +0200
          Re: [PATCH] x86/kconfig/32: Mark CONFIG_VM86 as BROKEN Linus Torvalds <torvalds@linux-foundation.org> - 2015-07-10 19:40 +0200
            Re: [PATCH] x86/kconfig/32: Mark CONFIG_VM86 as BROKEN Andy Lutomirski <luto@amacapital.net> - 2015-07-10 20:00 +0200
            Re: [PATCH] x86/kconfig/32: Mark CONFIG_VM86 as BROKEN Ingo Molnar <mingo@kernel.org> - 2015-07-11 11:20 +0200

#1181736 — Re: [PATCH] x86/kconfig/32: Mark CONFIG_VM86 as BROKEN

On Fri, Jul 10, 2015 at 7:37 AM, Andy Lutomirski <luto@amacapital.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.

I'm sure that has happened in some crazy situation (people doing some
random pseudo-BIOS etc), but it's not the common situation at all.

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.

And I'm personally violently against Ingo's idea of emulating this
with an instruction emulator. Hell no. That's what user mode does, and
it's fine there. In the kernel, we either support the hardware vm86
mode, or we phase it out because we can show that nobody uses it any
more. None of that "let's emulate it in software" crud.

                      Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [next] | [standalone]

#1181741

On Fri, Jul 10, 2015 at 9:35 AM, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
> On Fri, Jul 10, 2015 at 7:37 AM, Andy Lutomirski <luto@amacapital.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@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1181767

On Fri, Jul 10, 2015 at 9:44 AM, Andy Lutomirski <luto@amacapital.net> wrote:
>
> 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.

So?

Yes, we exit vm86 mode if anything odd happens. That's very much part
of the whole vm86() model. If the kernel needs to do anything, it
saves off the vm86 state and returns to regular 32-bit mode. That's
how it's designed to be.

What's your point?

The user mode "vm86 hypervisor" will call vm86() in a loop. Always
has. Always will.

And yes, that can mean that you never execute even a single
instruction in vm86 mode, if one of the "we have other work to do"
flags are set. Maybe a signal came in. Maybe just a delayed work
happened. Maybe it has nothing to do with user space, and we *could*
have returned to vm86 mode, but the thing is, that code sequence is
_designed_ that way - it's very much minimizing the impact of vm86
mode. Pretty much the *only* thing we ever do with the vm86 stack
still active is reschedule. Pretty much *any* other context change
issue will get rid of the vm86 mode in kernel space, saving back the
state to user space so that user space can try again.

An it was done that way to minimize the vm86 impact on the rest of the
kernel. Basically there's a few hooks in a couple of traps that say
"ok, let's handle this case for vm86 mode", and there's the "let's
reschedule without exiting the user vm86 state", but the code is
designed so that we'll just say "screw it, the user can restart, we'll
go back to normal 32-bit code because something else than just plain
returning to vm86 mode happend".

vm86() mode is not some kind of "run this DOS program to completion".
It's exactly like a (very stupid) vmx mode. There are exit conditions,
and while many of them are about the code it executes, equally many of
them are "oh, we may have some event that cannot be handled in vm86
mode like a signal happened" etc.

So yes, if the thread work flags are set, we never enter vm86 mode.
BUT THAT'S EXACTLY WHAT SHOULD HAPPEN.

It worries me that you think these kinds of fundamental issues are
completely broken.

No, I wouldn't be surprised at all if there is actual breakage, just
because vm86 mode clearly gets very little testing, but the things you
have pointed out as "broken" really haven't been as far as I can tell.

And yes, if you enable system call auditing, and you actually audit
the vm86 mode system call, that probably causes an exit condition,
which means that you can't actually run vm86 mode and make progress if
you audit that system call. Big f*cking deal. People who enable system
call auditing break many more important things (eg basic performance)
that that isn't even an argument. Do you really think that people who
wanted to run DOS games at hardware speeds wanted to _audit_ those
games? No.

                   Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1181779

On Fri, Jul 10, 2015 at 10:04 AM, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
> On Fri, Jul 10, 2015 at 9:44 AM, Andy Lutomirski <luto@amacapital.net> wrote:
>>
>> 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.
>
> So?

>
> So yes, if the thread work flags are set, we never enter vm86 mode.
> BUT THAT'S EXACTLY WHAT SHOULD HAPPEN.
>
> It worries me that you think these kinds of fundamental issues are
> completely broken.
>

The problem is that it's *every* event.  That includes this that
happen literally every time like strace.  (NOHZ_FULL would count, too,
if it worked at all on 32-bit kernels.)

Try it: vm86 will make zero progress if you run it under strace.  It
will also execute the trace hooks the wrong number of times, so strace
gets very confused.  If someone does something daft like using a
systrace-style sandbox, it probably breaks the sandbox.

>
> And yes, if you enable system call auditing, and you actually audit
> the vm86 mode system call, that probably causes an exit condition,
> which means that you can't actually run vm86 mode and make progress if
> you audit that system call. Big f*cking deal. People who enable system
> call auditing break many more important things (eg basic performance)
> that that isn't even an argument. Do you really think that people who
> wanted to run DOS games at hardware speeds wanted to _audit_ those
> games? No.

Not at all.

It does, however, mean that Fedora/RHEL users (who use auditing by
default in most cases, sigh) have a decent change of having had a
non-working vm86 syscall for a long time.  This makes me think that
there really aren't many vm86 users out there, since we'd have heard
about the breakage.

Note that audit is very special, though, since it has its own asm
path.  It might actually work, but I haven't tested it.

In any event, we're quibbling about the wording of the kconfig text
here.  Both Brian and I have patches that fix the ptrace problem, so
it's likely to be a nonissue in 4.3 regardless.

--Andy
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1181797

On Fri, Jul 10, 2015 at 10:13 AM, Andy Lutomirski <luto@amacapital.net> wrote:
>
> The problem is that it's *every* event.  That includes this that
> happen literally every time like strace.  (NOHZ_FULL would count, too,
> if it worked at all on 32-bit kernels.)

But things like strace and auditing etc has probably never worked in
the first place.

So yeah, I can well imagine that vm86 isn't universally useful. And
maybe it's been effectively broken in halfway modern distributions due
to their insane use of auditing - which is wonderful, because it's
just a stronger argument for disabling it by default.

But what I'd worry about is regressions - people who actually want to
upgrade kernels, and had an old machine and had an old distro, and
just want to keep that working. They aren't interested in running
strace on their old DOS game, or on their X server that uses it to run
the video BIOS. They just want it to work.

And it doesn't look "completely broken" to me for that.

Put another way: I think vm86 is very much "legacy". Nobody cares
about it in modern environments. That's not what we should even worry
about. We shouldn't worry about new users, and we _should_ try to
discourage it. But I think we should keep it working for the cases it
used to work before.

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.

                 Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1181841

On Fri, Jul 10, 2015 at 10:39 AM, Linus Torvalds
<torvalds@linux-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.

Oh, right, I didn't realize this was still the v1 thread.  v3 no
longer calls it BROKEN.

That being said, if vm86 actually has feelings, then I'm worried :)

--Andy
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1182115

* Linus Torvalds <torvalds@linux-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@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web