* Linus Torvalds 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
On Fri, Jul 10, 2015 at 10:39:02AM -0700, Linus Torvalds wrote:
> 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
On Fri, Jul 10, 2015 at 10:39 AM, Linus Torvalds
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
On Fri, Jul 10, 2015 at 10:13 AM, Andy Lutomirski 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 nev
On Fri, Jul 10, 2015 at 10:04 AM, Linus Torvalds
wrote:
> On Fri, Jul 10, 2015 at 9:44 AM, Andy Lutomirski 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
On Fri, Jul 10, 2015 at 9:44 AM, Andy Lutomirski 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 t
On Fri, Jul 10, 2015 at 9:35 AM, Linus Torvalds
wrote:
> On Fri, Jul 10, 2015 at 7:37 AM, Andy Lutomirski 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 actual
On Fri, Jul 10, 2015 at 7:37 AM, Andy Lutomirski 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
On Fri, Jul 10, 2015 at 4:16 AM, Paolo Bonzini wrote:
>
>
> On 09/07/2015 20:33, Andy Lutomirski wrote:
>> On Wed, Jul 8, 2015 at 10:59 PM, Ingo Molnar wrote:
>
>> The big downside of that, or of writing a more ad-hoc emulator, is
>> understanding what the semantics of all the weird vm86plus stuf
On Fri, Jul 10, 2015 at 7:12 AM, Eric W. Biederman
wrote:
> Andy Lutomirski writes:
>
>> 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
On 10/07/2015 16:13, Ingo Molnar wrote:
> > This isn't hard, at least for Intel: make emulation_required() return true
> > always (and fix the fallout). However, it's not necessary. The emulator
> > is
> > designed to be independent from the rest of KVM. At some point I think Avi
> > was
Andy Lutomirski writes:
> On Wed, Jul 8, 2015 at 9:59 AM, Linus Torvalds
> wrote:
>> On Tue, Jul 7, 2015 at 7:33 PM, Arjan van de Ven
>> 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
* Paolo Bonzini wrote:
> > 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).
>
> This isn't hard, a
On 09/07/2015 20:33, Andy Lutomirski wrote:
> On Wed, Jul 8, 2015 at 10:59 PM, Ingo Molnar wrote:
>>
>> * Ingo Molnar 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
On Wed, Jul 8, 2015 at 10:59 PM, Ingo Molnar wrote:
>
> * Ingo Molnar 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 ex
On Thu, Jul 9, 2015 at 10:57 AM, Andy Lutomirski wrote:
>
> Perhaps we should instead move CONFIG_VM86 out of EXPERT, default it
> to n, and suggest that everyone running a reasonably modern distro
> (2006 and up?) turn it off.
Ack. Changing the default and trying to deprecate it sounds like a
go
On Thu, Jul 9, 2015 at 10:57 AM, Andy Lutomirski wrote:
> On Jul 9, 2015 2:03 AM, "Pavel Machek" wrote:
>>
>> On Wed 2015-07-08 16:00:48, Thomas Gleixner wrote:
>> > On Tue, 7 Jul 2015, Arjan van de Ven wrote:
>> >
>> > > On 7/7/2015 6:25 PM, Andy Lutomirski wrote:
>> > > > VM86 is entirely broke
On Jul 9, 2015 2:03 AM, "Pavel Machek" wrote:
>
> On Wed 2015-07-08 16:00:48, Thomas Gleixner wrote:
> > On Tue, 7 Jul 2015, Arjan van de Ven wrote:
> >
> > > On 7/7/2015 6:25 PM, Andy Lutomirski wrote:
> > > > VM86 is entirely broken if ptrace, syscall auditing, or NOHZ_FULL is
> > > > in use. T
On Wed 2015-07-08 16:00:48, Thomas Gleixner wrote:
> On Tue, 7 Jul 2015, Arjan van de Ven wrote:
>
> > On 7/7/2015 6:25 PM, Andy Lutomirski wrote:
> > > VM86 is entirely broken if ptrace, syscall auditing, or NOHZ_FULL is
> > > in use. The code is a big undocumented mess, it's a real PITA to
> >
* Ingo Molnar 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
* Andy Lutomirski wrote:
> >> I look forward to it.
> >>
> >> However: I imagine that, if you do this, you may need to be quite careful
> >> about an x86_32-ism. Currently, if you have a pt_regs pointer for the
> >> current entry and user_mode(regs) returns true, then regs ==
> >> current_pt
On Wed, Jul 8, 2015 at 12:39 PM, Brian Gerst wrote:
> On Wed, Jul 8, 2015 at 3:14 PM, Andy Lutomirski wrote:
>> On Wed, Jul 8, 2015 at 12:05 PM, Brian Gerst wrote:
>>> On Wed, Jul 8, 2015 at 1:30 PM, Andy Lutomirski wrote:
On Wed, Jul 8, 2015 at 9:59 AM, Linus Torvalds
wrote:
> O
On Wed, Jul 8, 2015 at 3:14 PM, Andy Lutomirski wrote:
> On Wed, Jul 8, 2015 at 12:05 PM, Brian Gerst wrote:
>> On Wed, Jul 8, 2015 at 1:30 PM, Andy Lutomirski wrote:
>>> On Wed, Jul 8, 2015 at 9:59 AM, Linus Torvalds
>>> wrote:
On Tue, Jul 7, 2015 at 7:33 PM, Arjan van de Ven
wrote
On Wed, Jul 8, 2015 at 12:05 PM, Brian Gerst wrote:
> On Wed, Jul 8, 2015 at 1:30 PM, Andy Lutomirski wrote:
>> On Wed, Jul 8, 2015 at 9:59 AM, Linus Torvalds
>> wrote:
>>> On Tue, Jul 7, 2015 at 7:33 PM, Arjan van de Ven
>>> wrote:
if this patch would not be acceptable, at minimum w
* Linus Torvalds wrote:
> On Tue, Jul 7, 2015 at 7:33 PM, Arjan van de Ven
> 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
On Wed, Jul 8, 2015 at 1:30 PM, Andy Lutomirski wrote:
> On Wed, Jul 8, 2015 at 9:59 AM, Linus Torvalds
> wrote:
>> On Tue, Jul 7, 2015 at 7:33 PM, Arjan van de Ven
>> wrote:
>>>
>>> if this patch would not be acceptable, at minimum we need some sort of "off
>>> by default
>>> unless the sysadm
On Wed, Jul 8, 2015 at 11:48 AM, Kees Cook wrote:
> On Wed, Jul 8, 2015 at 10:55 AM, Linus Torvalds
> wrote:
>> On Wed, Jul 8, 2015 at 10:49 AM, Andy Lutomirski wrote:
>>>
>>> I don't know how to tell whether something is trying to use real mode,
>>> but I can play this just fine in DOSEMU on my
On 2015-07-08 13:55, Linus Torvalds wrote:
On Wed, Jul 8, 2015 at 10:49 AM, Andy Lutomirski wrote:
I don't know how to tell whether something is trying to use real mode,
but I can play this just fine in DOSEMU on my 64-bit laptop:
So a 64-bit distro obviously will never have used vm86 mode -
On Wed, Jul 8, 2015 at 11:47 AM, Andy Lutomirski wrote:
> Fedora doesn't package dosemu at all, and Ubuntu turns off CONFIG_VM86
> AFAIK. RPMFusion does package dosemu.
Just for reference, here's the config on latest Ubuntu:
http://kernel.ubuntu.com/git/ubuntu/ubuntu-vivid.git/tree/debian.master
On Wed, Jul 8, 2015 at 10:55 AM, Linus Torvalds
wrote:
> On Wed, Jul 8, 2015 at 10:49 AM, Andy Lutomirski wrote:
>>
>> I don't know how to tell whether something is trying to use real mode,
>> but I can play this just fine in DOSEMU on my 64-bit laptop:
>
> So a 64-bit distro obviously will never
On Wed, Jul 8, 2015 at 10:55 AM, Linus Torvalds
wrote:
> On Wed, Jul 8, 2015 at 10:49 AM, Andy Lutomirski wrote:
>>
>> I don't know how to tell whether something is trying to use real mode,
>> but I can play this just fine in DOSEMU on my 64-bit laptop:
>
> So a 64-bit distro obviously will never
On Wed, Jul 8, 2015 at 10:49 AM, Andy Lutomirski wrote:
>
> I don't know how to tell whether something is trying to use real mode,
> but I can play this just fine in DOSEMU on my 64-bit laptop:
So a 64-bit distro obviously will never have used vm86 mode - it
doesn't work there. Never has. There's
On Wed, Jul 8, 2015 at 10:30 AM, Andy Lutomirski wrote:
> I'll try to confirm later this week that dosemu can really handle real
> mode without sys_vm86.
I don't know how to tell whether something is trying to use real mode,
but I can play this just fine in DOSEMU on my 64-bit laptop:
http://dos
On Wed, Jul 8, 2015 at 9:59 AM, Linus Torvalds
wrote:
> On Tue, Jul 7, 2015 at 7:33 PM, Arjan van de Ven
> 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
On Tue, Jul 7, 2015 at 7:33 PM, Arjan van de Ven 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.
If peo
On Tue, Jul 7, 2015 at 9:25 PM, Andy Lutomirski wrote:
> VM86 is entirely broken if ptrace, syscall auditing, or NOHZ_FULL is
> in use. The code is a big undocumented mess, it's a real PITA to
> test, and it looks like a big chunk of vm86_32.c is dead code. It
> also plays awful games with the e
* Thomas Gleixner wrote:
> On Tue, 7 Jul 2015, Arjan van de Ven wrote:
>
> > On 7/7/2015 6:25 PM, Andy Lutomirski wrote:
> > > VM86 is entirely broken if ptrace, syscall auditing, or NOHZ_FULL is
> > > in use. The code is a big undocumented mess, it's a real PITA to
> > > test, and it looks li
On Tue, 7 Jul 2015, Arjan van de Ven wrote:
> On 7/7/2015 6:25 PM, Andy Lutomirski wrote:
> > VM86 is entirely broken if ptrace, syscall auditing, or NOHZ_FULL is
> > in use. The code is a big undocumented mess, it's a real PITA to
> > test, and it looks like a big chunk of vm86_32.c is dead code
On 7/7/2015 6:25 PM, Andy Lutomirski wrote:
VM86 is entirely broken if ptrace, syscall auditing, or NOHZ_FULL is
in use. The code is a big undocumented mess, it's a real PITA to
test, and it looks like a big chunk of vm86_32.c is dead code. It
also plays awful games with the entry asm.
No one
VM86 is entirely broken if ptrace, syscall auditing, or NOHZ_FULL is
in use. The code is a big undocumented mess, it's a real PITA to
test, and it looks like a big chunk of vm86_32.c is dead code. It
also plays awful games with the entry asm.
No one should be using it anyway. Use DOSBOX or KVM
40 matches
Mail list logo
