stop breaking dosemu (Re: x86/kconfig/32: Rename CONFIG_VM86 and default it to 'n')

stop breaking dosemu (Re: x86/kconfig/32: Rename CONFIG_VM86 and default it to 'n')

[Stas Sergeev]

https://lkml.org/lkml/2015/7/21/208

Guys, you gonna be kidding.
Is this a new trend of breaking dosemu, or what?

> 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

It is a CPU feature that kernel should support, and always
did without any problems. If it started to have problems because
of your actions, then you can as well fix your code.

 > No one should be using it anyway. Use DOSBOX or KVM instead.

Have you done the benchmarks between dosbox and dosemu
before saying that? Please do, thanks. (don't forget to include
dosemu2 in your benchmarks too, as it outperforms both)

> Let's accelerate its slow death.


 > + Enabling this option adds considerable attack surface to the
 > + kernel and slows down system calls and exception handling.

Yes, I realize that threatening people with the "considerable attack 
surface"
is a good way to "accelerate its slow death", but please care to explain
that attack surface, thankyou.

Re: stop breaking dosemu (Re: x86/kconfig/32: Rename CONFIG_VM86 and default it to 'n')

[Andy Lutomirski]

On Sep 2, 2015 2:51 AM, "Stas Sergeev" <stsp@list.ru> wrote:
>
> https://lkml.org/lkml/2015/7/21/208
>
> Guys, you gonna be kidding.
> Is this a new trend of breaking dosemu, or what?
>
>> 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
>
>
> It is a CPU feature that kernel should support, and always
> did without any problems. If it started to have problems because
> of your actions, then you can as well fix your code.
>
> > No one should be using it anyway. Use DOSBOX or KVM instead.
>
> Have you done the benchmarks between dosbox and dosemu
> before saying that? Please do, thanks. (don't forget to include
> dosemu2 in your benchmarks too, as it outperforms both)

I wasn't aware of your dosemu variant at the time, and I incorrectly
thought that dosemu was unmaintained.

Does real mode performance matter any more?

>
>> Let's accelerate its slow death.
>
>

Dosemu is much less dead than I thought it was when I wrote that
patch.  Sorry :(

>
> > + Enabling this option adds considerable attack surface to the
> > + kernel and slows down system calls and exception handling.
>
> Yes, I realize that threatening people with the "considerable attack surface"
> is a good way to "accelerate its slow death", but please care to explain
> that attack surface, thankyou.

The user_mode vs user_mode_vm thing was scary and contained at least
one real bug.  That particular issue is gone now, though.

Before Brian's cleanups, vm86 did horrible things to the entry asm,
the stack layout, and signal handling, and that scared me.  That's
hopefully in much better shape now, though.

The mark_screen_rdonly thing is still kind of scary.  It changes PTEs
on arbitrary mappings behind the vm's back.

I'd be amenable to switching the default back to y and perhaps adding
a sysctl to make the distros more comfortable.  Ingo, Kees, Brian,
what do you think?

--Andy

Re: stop breaking dosemu (Re: x86/kconfig/32: Rename CONFIG_VM86 and default it to 'n')

[Kees Cook]

On Wed, Sep 2, 2015 at 7:08 AM, Andy Lutomirski <luto@amacapital.net> wrote:
> On Sep 2, 2015 2:51 AM, "Stas Sergeev" <stsp@list.ru> wrote:
>>
>> https://lkml.org/lkml/2015/7/21/208
>>
>> Guys, you gonna be kidding.
>> Is this a new trend of breaking dosemu, or what?
>>
>>> 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
>>
>>
>> It is a CPU feature that kernel should support, and always
>> did without any problems. If it started to have problems because
>> of your actions, then you can as well fix your code.
>>
>> > No one should be using it anyway. Use DOSBOX or KVM instead.
>>
>> Have you done the benchmarks between dosbox and dosemu
>> before saying that? Please do, thanks. (don't forget to include
>> dosemu2 in your benchmarks too, as it outperforms both)
>
> I wasn't aware of your dosemu variant at the time, and I incorrectly
> thought that dosemu was unmaintained.
>
> Does real mode performance matter any more?
>
>>
>>> Let's accelerate its slow death.
>>
>>
>
> Dosemu is much less dead than I thought it was when I wrote that
> patch.  Sorry :(
>
>>
>> > + Enabling this option adds considerable attack surface to the
>> > + kernel and slows down system calls and exception handling.
>>
>> Yes, I realize that threatening people with the "considerable attack surface"
>> is a good way to "accelerate its slow death", but please care to explain
>> that attack surface, thankyou.
>
> The user_mode vs user_mode_vm thing was scary and contained at least
> one real bug.  That particular issue is gone now, though.
>
> Before Brian's cleanups, vm86 did horrible things to the entry asm,
> the stack layout, and signal handling, and that scared me.  That's
> hopefully in much better shape now, though.
>
> The mark_screen_rdonly thing is still kind of scary.  It changes PTEs
> on arbitrary mappings behind the vm's back.
>
> I'd be amenable to switching the default back to y and perhaps adding
> a sysctl to make the distros more comfortable.  Ingo, Kees, Brian,
> what do you think?

Yeah, I think putting this under distro control (and user control) is
the best option here.

-Kees


-- 
Kees Cook
Chrome OS Security

Re: stop breaking dosemu (Re: x86/kconfig/32: Rename CONFIG_VM86 and default it to 'n')

[Stas Sergeev]

02.09.2015 17:08, Andy Lutomirski пишет:
> On Sep 2, 2015 2:51 AM, "Stas Sergeev" <stsp@list.ru> wrote:
>>
>> https://lkml.org/lkml/2015/7/21/208
>>
>> Guys, you gonna be kidding.
>> Is this a new trend of breaking dosemu, or what?
>>
>>> 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
>>
>>
>> It is a CPU feature that kernel should support, and always
>> did without any problems. If it started to have problems because
>> of your actions, then you can as well fix your code.
>>
>>> No one should be using it anyway. Use DOSBOX or KVM instead.
>>
>> Have you done the benchmarks between dosbox and dosemu
>> before saying that? Please do, thanks. (don't forget to include
>> dosemu2 in your benchmarks too, as it outperforms both)
> 
> I wasn't aware of your dosemu variant at the time, and I incorrectly
> thought that dosemu was unmaintained.
This is roughly true to my knowledge, hence the forks.

> Does real mode performance matter any more?
People that control their legacy HW with DOS program wants
the real-time performance. They even run dosemu with non-default
scheduling policies sometimes (although I doubt it really helps).

> The mark_screen_rdonly thing is still kind of scary.  It changes PTEs
> on arbitrary mappings behind the vm's back.
Then you can start removing things step-by-step.
mark_screen_rdonly is likely a bad interface, I wonder if someone
uses it. There are indeed too many legacy things in vm86(), but there
is no point to disable it completely.

> I'd be amenable to switching the default back to y and perhaps adding
> a sysctl to make the distros more comfortable.  Ingo, Kees, Brian,
> what do you think?
I'd say you can just remove what looks bad and fix the rest.
Then disabling it can be done under "if EMBEDDED" only.
Eg, the BIOSSEG stuff looks like a candidate for removal,
return_for_pic, screen_rdonly and many other absolutely
useless things. If it is reduced to the bare minimum, I wonder
if there will still be the desire to make it configurable under
non-if-EMBEDDED.

Re: stop breaking dosemu (Re: x86/kconfig/32: Rename CONFIG_VM86 and default it to 'n')

[Josh Boyer]

On Wed, Sep 2, 2015 at 10:08 AM, Andy Lutomirski <luto@amacapital.net> wrote:
> I'd be amenable to switching the default back to y and perhaps adding
> a sysctl to make the distros more comfortable.  Ingo, Kees, Brian,
> what do you think?

Can you please leave the default as N, and have a sysctl option to
enable it instead?  While dosemu might still be in use, it isn't going
to be the common case at all.  So from a distro perspective, I think
we'd probably rather have the default match the common case.

As an aside, the "distros can use a sysctl" thing is kind of
misleading.  The default should be the common case, and the sysctl
knobs should be for end users that wish to differ.  That might not
sound like much of a difference from an upstream kernel perspective,
but it is.  Having to install sysctl config files to get a proper
default set distro-wide, and then having the end users either remove
them or edit them is a lot of hassle from a distro perspective.

josh

Re: stop breaking dosemu (Re: x86/kconfig/32: Rename CONFIG_VM86 and default it to 'n')

[Stas Sergeev]

02.09.2015 20:46, Josh Boyer пишет:
> On Wed, Sep 2, 2015 at 10:08 AM, Andy Lutomirski <luto@amacapital.net> wrote:
>> I'd be amenable to switching the default back to y and perhaps adding
>> a sysctl to make the distros more comfortable.  Ingo, Kees, Brian,
>> what do you think?
> 
> Can you please leave the default as N, and have a sysctl option to
> enable it instead?  While dosemu might still be in use, it isn't going
> to be the common case at all.  So from a distro perspective, I think
> we'd probably rather have the default match the common case.
The fact that fedora doesn't package dosemu, doesn't automatically
mean all other distros do not too. Since when kernel defaults should
match the ones of fedora?
vm86() is a mess, but it can be cleaned up so much that it just won't
be a big deal at all.

Re: stop breaking dosemu (Re: x86/kconfig/32: Rename CONFIG_VM86 and default it to 'n')

[Josh Boyer]

On Wed, Sep 2, 2015 at 1:50 PM, Stas Sergeev <stsp@list.ru> wrote:
> 02.09.2015 20:46, Josh Boyer пишет:
>> On Wed, Sep 2, 2015 at 10:08 AM, Andy Lutomirski <luto@amacapital.net> wrote:
>>> I'd be amenable to switching the default back to y and perhaps adding
>>> a sysctl to make the distros more comfortable.  Ingo, Kees, Brian,
>>> what do you think?
>>
>> Can you please leave the default as N, and have a sysctl option to
>> enable it instead?  While dosemu might still be in use, it isn't going
>> to be the common case at all.  So from a distro perspective, I think
>> we'd probably rather have the default match the common case.
> The fact that fedora doesn't package dosemu, doesn't automatically
> mean all other distros do not too. Since when kernel defaults should
> match the ones of fedora?

I didn't say that.  The default right now is N.  I asked it be left
that way.  That's all.

josh

Re: stop breaking dosemu (Re: x86/kconfig/32: Rename CONFIG_VM86 and default it to 'n')

[Stas Sergeev]

02.09.2015 23:22, Josh Boyer пишет:
> On Wed, Sep 2, 2015 at 1:50 PM, Stas Sergeev <stsp@list.ru> wrote:
>> 02.09.2015 20:46, Josh Boyer пишет:
>>> On Wed, Sep 2, 2015 at 10:08 AM, Andy Lutomirski <luto@amacapital.net> wrote:
>>>> I'd be amenable to switching the default back to y and perhaps adding
>>>> a sysctl to make the distros more comfortable.  Ingo, Kees, Brian,
>>>> what do you think?
>>> Can you please leave the default as N, and have a sysctl option to
>>> enable it instead?  While dosemu might still be in use, it isn't going
>>> to be the common case at all.  So from a distro perspective, I think
>>> we'd probably rather have the default match the common case.
>> The fact that fedora doesn't package dosemu, doesn't automatically
>> mean all other distros do not too. Since when kernel defaults should
>> match the ones of fedora?
> I didn't say that.
What you said was:
---

While dosemu might still be in use, it isn't going
to be the common case at all.  So from a distro perspective

---
... which is likely true only in fedora circe.

>    The default right now is N.
In a not yet released kernel, unless I am mistaken.
If fedora already provides that kernel, other distros likely not.

>    I asked it be left
> that way.  That's all.
Lets assume its not yet N, unless there was a kernel release already.
Its easy to get back if its not too late.

Re: stop breaking dosemu (Re: x86/kconfig/32: Rename CONFIG_VM86 and default it to 'n')

[Andy Lutomirski]

On Wed, Sep 2, 2015 at 1:47 PM, Stas Sergeev <stsp@list.ru> wrote:
> 02.09.2015 23:22, Josh Boyer пишет:
>>
>> On Wed, Sep 2, 2015 at 1:50 PM, Stas Sergeev <stsp@list.ru> wrote:
>>>
>>> 02.09.2015 20:46, Josh Boyer пишет:
>>>>
>>>> On Wed, Sep 2, 2015 at 10:08 AM, Andy Lutomirski <luto@amacapital.net>
>>>> wrote:
>>>>>
>>>>> I'd be amenable to switching the default back to y and perhaps adding
>>>>> a sysctl to make the distros more comfortable.  Ingo, Kees, Brian,
>>>>> what do you think?
>>>>
>>>> Can you please leave the default as N, and have a sysctl option to
>>>> enable it instead?  While dosemu might still be in use, it isn't going
>>>> to be the common case at all.  So from a distro perspective, I think
>>>> we'd probably rather have the default match the common case.
>>>
>>> The fact that fedora doesn't package dosemu, doesn't automatically
>>> mean all other distros do not too. Since when kernel defaults should
>>> match the ones of fedora?
>>
>> I didn't say that.
>
> What you said was:
> ---
>
> While dosemu might still be in use, it isn't going
> to be the common case at all.  So from a distro perspective
>
> ---
> ... which is likely true only in fedora circe.
>
>>    The default right now is N.
>
> In a not yet released kernel, unless I am mistaken.
> If fedora already provides that kernel, other distros likely not.
>
>>    I asked it be left
>> that way.  That's all.
>
> Lets assume its not yet N, unless there was a kernel release already.
> Its easy to get back if its not too late.

How about CONFIG_SYSCTL_VM86_DEFAULT which defaults to Y?  Fedora
could set it to N.

--Andy

-- 
Andy Lutomirski
AMA Capital Management, LLC

Re: stop breaking dosemu (Re: x86/kconfig/32: Rename CONFIG_VM86 and default it to 'n')

[Josh Boyer]

On Wed, Sep 2, 2015 at 4:55 PM, Andy Lutomirski <luto@amacapital.net> wrote:
> On Wed, Sep 2, 2015 at 1:47 PM, Stas Sergeev <stsp@list.ru> wrote:
>> 02.09.2015 23:22, Josh Boyer пишет:
>>>
>>> On Wed, Sep 2, 2015 at 1:50 PM, Stas Sergeev <stsp@list.ru> wrote:
>>>>
>>>> 02.09.2015 20:46, Josh Boyer пишет:
>>>>>
>>>>> On Wed, Sep 2, 2015 at 10:08 AM, Andy Lutomirski <luto@amacapital.net>
>>>>> wrote:
>>>>>>
>>>>>> I'd be amenable to switching the default back to y and perhaps adding
>>>>>> a sysctl to make the distros more comfortable.  Ingo, Kees, Brian,
>>>>>> what do you think?
>>>>>
>>>>> Can you please leave the default as N, and have a sysctl option to
>>>>> enable it instead?  While dosemu might still be in use, it isn't going
>>>>> to be the common case at all.  So from a distro perspective, I think
>>>>> we'd probably rather have the default match the common case.
>>>>
>>>> The fact that fedora doesn't package dosemu, doesn't automatically
>>>> mean all other distros do not too. Since when kernel defaults should
>>>> match the ones of fedora?
>>>
>>> I didn't say that.
>>
>> What you said was:
>> ---
>>
>> While dosemu might still be in use, it isn't going
>> to be the common case at all.  So from a distro perspective
>>
>> ---
>> ... which is likely true only in fedora circe.
>>
>>>    The default right now is N.
>>
>> In a not yet released kernel, unless I am mistaken.
>> If fedora already provides that kernel, other distros likely not.

We do.

>>>    I asked it be left
>>> that way.  That's all.
>>
>> Lets assume its not yet N, unless there was a kernel release already.
>> Its easy to get back if its not too late.

You are correct.

> How about CONFIG_SYSCTL_VM86_DEFAULT which defaults to Y?  Fedora
> could set it to N.

Works for me.

josh

Re: stop breaking dosemu (Re: x86/kconfig/32: Rename CONFIG_VM86 and default it to 'n')

[Stas Sergeev]

02.09.2015 23:55, Andy Lutomirski пишет:
> On Wed, Sep 2, 2015 at 1:47 PM, Stas Sergeev <stsp@list.ru> wrote:
>> 02.09.2015 23:22, Josh Boyer пишет:
>>> On Wed, Sep 2, 2015 at 1:50 PM, Stas Sergeev <stsp@list.ru> wrote:
>>>> 02.09.2015 20:46, Josh Boyer пишет:
>>>>> On Wed, Sep 2, 2015 at 10:08 AM, Andy Lutomirski <luto@amacapital.net>
>>>>> wrote:
>>>>>> I'd be amenable to switching the default back to y and perhaps adding
>>>>>> a sysctl to make the distros more comfortable.  Ingo, Kees, Brian,
>>>>>> what do you think?
>>>>> Can you please leave the default as N, and have a sysctl option to
>>>>> enable it instead?  While dosemu might still be in use, it isn't going
>>>>> to be the common case at all.  So from a distro perspective, I think
>>>>> we'd probably rather have the default match the common case.
>>>> The fact that fedora doesn't package dosemu, doesn't automatically
>>>> mean all other distros do not too. Since when kernel defaults should
>>>> match the ones of fedora?
>>> I didn't say that.
>> What you said was:
>> ---
>>
>> While dosemu might still be in use, it isn't going
>> to be the common case at all.  So from a distro perspective
>>
>> ---
>> ... which is likely true only in fedora circe.
>>
>>>     The default right now is N.
>> In a not yet released kernel, unless I am mistaken.
>> If fedora already provides that kernel, other distros likely not.
>>
>>>     I asked it be left
>>> that way.  That's all.
>> Lets assume its not yet N, unless there was a kernel release already.
>> Its easy to get back if its not too late.
> How about CONFIG_SYSCTL_VM86_DEFAULT which defaults to Y?  Fedora
> could set it to N.
Sorry, I don't understand this sysctl proposal.
Could you please educate me what is it all about?
This sysctl will disable or enable the vm86() syscall at run-time,
right? What does it give us? If you disable something in the
config, this gives you, say, smaller kernel image. If OTOH you
add the run-time switch, it gives you a bigger image, regardless
of its default value.
I might be missing something, but I don't understand what
problem will this solve? Have I missed some earlier message
in this thread?

Re: stop breaking dosemu (Re: x86/kconfig/32: Rename CONFIG_VM86 and default it to 'n')

[Andy Lutomirski]

On Wed, Sep 2, 2015 at 2:12 PM, Stas Sergeev <stsp@list.ru> wrote:
> 02.09.2015 23:55, Andy Lutomirski пишет:
>
>> On Wed, Sep 2, 2015 at 1:47 PM, Stas Sergeev <stsp@list.ru> wrote:
>>>
>>> 02.09.2015 23:22, Josh Boyer пишет:
>>>>
>>>> On Wed, Sep 2, 2015 at 1:50 PM, Stas Sergeev <stsp@list.ru> wrote:
>>>>>
>>>>> 02.09.2015 20:46, Josh Boyer пишет:
>>>>>>
>>>>>> On Wed, Sep 2, 2015 at 10:08 AM, Andy Lutomirski <luto@amacapital.net>
>>>>>> wrote:
>>>>>>>
>>>>>>> I'd be amenable to switching the default back to y and perhaps adding
>>>>>>> a sysctl to make the distros more comfortable.  Ingo, Kees, Brian,
>>>>>>> what do you think?
>>>>>>
>>>>>> Can you please leave the default as N, and have a sysctl option to
>>>>>> enable it instead?  While dosemu might still be in use, it isn't going
>>>>>> to be the common case at all.  So from a distro perspective, I think
>>>>>> we'd probably rather have the default match the common case.
>>>>>
>>>>> The fact that fedora doesn't package dosemu, doesn't automatically
>>>>> mean all other distros do not too. Since when kernel defaults should
>>>>> match the ones of fedora?
>>>>
>>>> I didn't say that.
>>>
>>> What you said was:
>>> ---
>>>
>>> While dosemu might still be in use, it isn't going
>>> to be the common case at all.  So from a distro perspective
>>>
>>> ---
>>> ... which is likely true only in fedora circe.
>>>
>>>>     The default right now is N.
>>>
>>> In a not yet released kernel, unless I am mistaken.
>>> If fedora already provides that kernel, other distros likely not.
>>>
>>>>     I asked it be left
>>>> that way.  That's all.
>>>
>>> Lets assume its not yet N, unless there was a kernel release already.
>>> Its easy to get back if its not too late.
>>
>> How about CONFIG_SYSCTL_VM86_DEFAULT which defaults to Y?  Fedora
>> could set it to N.
>
> Sorry, I don't understand this sysctl proposal.
> Could you please educate me what is it all about?
> This sysctl will disable or enable the vm86() syscall at run-time,
> right? What does it give us? If you disable something in the
> config, this gives you, say, smaller kernel image. If OTOH you
> add the run-time switch, it gives you a bigger image, regardless
> of its default value.
> I might be missing something, but I don't understand what
> problem will this solve? Have I missed some earlier message
> in this thread?

For the 99%+ of users who don't use dosemu, it prevents exploits that
target vm86 from attacking their kernel.

--Andy

-- 
Andy Lutomirski
AMA Capital Management, LLC

Re: stop breaking dosemu (Re: x86/kconfig/32: Rename CONFIG_VM86 and default it to 'n')

[Stas Sergeev]

03.09.2015 00:40, Andy Lutomirski пишет:
> On Wed, Sep 2, 2015 at 2:12 PM, Stas Sergeev <stsp@list.ru> wrote:
>> 02.09.2015 23:55, Andy Lutomirski пишет:
>>
>>> On Wed, Sep 2, 2015 at 1:47 PM, Stas Sergeev <stsp@list.ru> wrote:
>>>> 02.09.2015 23:22, Josh Boyer пишет:
>>>>> On Wed, Sep 2, 2015 at 1:50 PM, Stas Sergeev <stsp@list.ru> wrote:
>>>>>> 02.09.2015 20:46, Josh Boyer пишет:
>>>>>>> On Wed, Sep 2, 2015 at 10:08 AM, Andy Lutomirski <luto@amacapital.net>
>>>>>>> wrote:
>>>>>>>> I'd be amenable to switching the default back to y and perhaps adding
>>>>>>>> a sysctl to make the distros more comfortable.  Ingo, Kees, Brian,
>>>>>>>> what do you think?
>>>>>>> Can you please leave the default as N, and have a sysctl option to
>>>>>>> enable it instead?  While dosemu might still be in use, it isn't going
>>>>>>> to be the common case at all.  So from a distro perspective, I think
>>>>>>> we'd probably rather have the default match the common case.
>>>>>> The fact that fedora doesn't package dosemu, doesn't automatically
>>>>>> mean all other distros do not too. Since when kernel defaults should
>>>>>> match the ones of fedora?
>>>>> I didn't say that.
>>>> What you said was:
>>>> ---
>>>>
>>>> While dosemu might still be in use, it isn't going
>>>> to be the common case at all.  So from a distro perspective
>>>>
>>>> ---
>>>> ... which is likely true only in fedora circe.
>>>>
>>>>>      The default right now is N.
>>>> In a not yet released kernel, unless I am mistaken.
>>>> If fedora already provides that kernel, other distros likely not.
>>>>
>>>>>      I asked it be left
>>>>> that way.  That's all.
>>>> Lets assume its not yet N, unless there was a kernel release already.
>>>> Its easy to get back if its not too late.
>>> How about CONFIG_SYSCTL_VM86_DEFAULT which defaults to Y?  Fedora
>>> could set it to N.
>> Sorry, I don't understand this sysctl proposal.
>> Could you please educate me what is it all about?
>> This sysctl will disable or enable the vm86() syscall at run-time,
>> right? What does it give us? If you disable something in the
>> config, this gives you, say, smaller kernel image. If OTOH you
>> add the run-time switch, it gives you a bigger image, regardless
>> of its default value.
>> I might be missing something, but I don't understand what
>> problem will this solve? Have I missed some earlier message
>> in this thread?
> For the 99%+ of users who don't use dosemu, it prevents exploits that
> target vm86 from attacking their kernel.
I don't think the attack scenario was satisfactory explained.
IIRC you only said that
---

The mark_screen_rdonly thing is still kind of scary.  It changes PTEs
on arbitrary mappings behind the vm's back.

---
Just go ahead and remove mark_screen_rdonly, big deal.
Is this all of the threat?
Or do we treat _every_ syscall as the potential attack target?

Re: stop breaking dosemu (Re: x86/kconfig/32: Rename CONFIG_VM86 and default it to 'n')

[Austin S Hemmelgarn]

[-- Attachment #1: Type: text/plain, Size: 3739 bytes --]

On 2015-09-02 17:53, Stas Sergeev wrote:
> 03.09.2015 00:40, Andy Lutomirski пишет:
>> On Wed, Sep 2, 2015 at 2:12 PM, Stas Sergeev <stsp@list.ru> wrote:
>>> 02.09.2015 23:55, Andy Lutomirski пишет:
>>>
>>>> On Wed, Sep 2, 2015 at 1:47 PM, Stas Sergeev <stsp@list.ru> wrote:
>>>>> 02.09.2015 23:22, Josh Boyer пишет:
>>>>>> On Wed, Sep 2, 2015 at 1:50 PM, Stas Sergeev <stsp@list.ru> wrote:
>>>>>>> 02.09.2015 20:46, Josh Boyer пишет:
>>>>>>>> On Wed, Sep 2, 2015 at 10:08 AM, Andy Lutomirski
>>>>>>>> <luto@amacapital.net>
>>>>>>>> wrote:
>>>>>>>>> I'd be amenable to switching the default back to y and perhaps
>>>>>>>>> adding
>>>>>>>>> a sysctl to make the distros more comfortable.  Ingo, Kees, Brian,
>>>>>>>>> what do you think?
>>>>>>>> Can you please leave the default as N, and have a sysctl option to
>>>>>>>> enable it instead?  While dosemu might still be in use, it isn't
>>>>>>>> going
>>>>>>>> to be the common case at all.  So from a distro perspective, I
>>>>>>>> think
>>>>>>>> we'd probably rather have the default match the common case.
>>>>>>> The fact that fedora doesn't package dosemu, doesn't automatically
>>>>>>> mean all other distros do not too. Since when kernel defaults should
>>>>>>> match the ones of fedora?
>>>>>> I didn't say that.
>>>>> What you said was:
>>>>> ---
>>>>>
>>>>> While dosemu might still be in use, it isn't going
>>>>> to be the common case at all.  So from a distro perspective
>>>>>
>>>>> ---
>>>>> ... which is likely true only in fedora circe.
>>>>>
>>>>>>      The default right now is N.
>>>>> In a not yet released kernel, unless I am mistaken.
>>>>> If fedora already provides that kernel, other distros likely not.
>>>>>
>>>>>>      I asked it be left
>>>>>> that way.  That's all.
>>>>> Lets assume its not yet N, unless there was a kernel release already.
>>>>> Its easy to get back if its not too late.
>>>> How about CONFIG_SYSCTL_VM86_DEFAULT which defaults to Y?  Fedora
>>>> could set it to N.
>>> Sorry, I don't understand this sysctl proposal.
>>> Could you please educate me what is it all about?
>>> This sysctl will disable or enable the vm86() syscall at run-time,
>>> right? What does it give us? If you disable something in the
>>> config, this gives you, say, smaller kernel image. If OTOH you
>>> add the run-time switch, it gives you a bigger image, regardless
>>> of its default value.
>>> I might be missing something, but I don't understand what
>>> problem will this solve? Have I missed some earlier message
>>> in this thread?
>> For the 99%+ of users who don't use dosemu, it prevents exploits that
>> target vm86 from attacking their kernel.
> I don't think the attack scenario was satisfactory explained.
> IIRC you only said that
> ---
>
> The mark_screen_rdonly thing is still kind of scary.  It changes PTEs
> on arbitrary mappings behind the vm's back.
>
> ---
> Just go ahead and remove mark_screen_rdonly, big deal.
> Is this all of the threat?
> Or do we treat _every_ syscall as the potential attack target?
Anything that messes with the VM subsystem (doubly if it does so without 
actually calling into the VM subsystem) is a potential target, as is 
anything that messes with execution mode or privilege level (as in, 
possibly messes with which ring (or whatevere equivalent metaphor other 
processors use) execution is happening in).  This does potentially all 
three (depending on how it's called).  Just because there are no known 
working exploits doesn't mean it's not possible, and in the case of this 
code, I'd say there is almost certainly some way to exploit it either to 
crash the system or gain root-equivalent privileges.



[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 3019 bytes --]

Re: stop breaking dosemu (Re: x86/kconfig/32: Rename CONFIG_VM86 and default it to 'n')

[Stas Sergeev]

03.09.2015 15:11, Austin S Hemmelgarn пишет:
> On 2015-09-02 17:53, Stas Sergeev wrote:
>> 03.09.2015 00:40, Andy Lutomirski пишет:
>>> On Wed, Sep 2, 2015 at 2:12 PM, Stas Sergeev <stsp@list.ru> wrote:
>>>> 02.09.2015 23:55, Andy Lutomirski пишет:
>>>>
>>>>> On Wed, Sep 2, 2015 at 1:47 PM, Stas Sergeev <stsp@list.ru> wrote:
>>>>>> 02.09.2015 23:22, Josh Boyer пишет:
>>>>>>> On Wed, Sep 2, 2015 at 1:50 PM, Stas Sergeev <stsp@list.ru> wrote:
>>>>>>>> 02.09.2015 20:46, Josh Boyer пишет:
>>>>>>>>> On Wed, Sep 2, 2015 at 10:08 AM, Andy Lutomirski
>>>>>>>>> <luto@amacapital.net>
>>>>>>>>> wrote:
>>>>>>>>>> I'd be amenable to switching the default back to y and perhaps
>>>>>>>>>> adding
>>>>>>>>>> a sysctl to make the distros more comfortable.  Ingo, Kees, Brian,
>>>>>>>>>> what do you think?
>>>>>>>>> Can you please leave the default as N, and have a sysctl option to
>>>>>>>>> enable it instead?  While dosemu might still be in use, it isn't
>>>>>>>>> going
>>>>>>>>> to be the common case at all.  So from a distro perspective, I
>>>>>>>>> think
>>>>>>>>> we'd probably rather have the default match the common case.
>>>>>>>> The fact that fedora doesn't package dosemu, doesn't automatically
>>>>>>>> mean all other distros do not too. Since when kernel defaults should
>>>>>>>> match the ones of fedora?
>>>>>>> I didn't say that.
>>>>>> What you said was:
>>>>>> ---
>>>>>>
>>>>>> While dosemu might still be in use, it isn't going
>>>>>> to be the common case at all.  So from a distro perspective
>>>>>>
>>>>>> ---
>>>>>> ... which is likely true only in fedora circe.
>>>>>>
>>>>>>>      The default right now is N.
>>>>>> In a not yet released kernel, unless I am mistaken.
>>>>>> If fedora already provides that kernel, other distros likely not.
>>>>>>
>>>>>>>      I asked it be left
>>>>>>> that way.  That's all.
>>>>>> Lets assume its not yet N, unless there was a kernel release already.
>>>>>> Its easy to get back if its not too late.
>>>>> How about CONFIG_SYSCTL_VM86_DEFAULT which defaults to Y?  Fedora
>>>>> could set it to N.
>>>> Sorry, I don't understand this sysctl proposal.
>>>> Could you please educate me what is it all about?
>>>> This sysctl will disable or enable the vm86() syscall at run-time,
>>>> right? What does it give us? If you disable something in the
>>>> config, this gives you, say, smaller kernel image. If OTOH you
>>>> add the run-time switch, it gives you a bigger image, regardless
>>>> of its default value.
>>>> I might be missing something, but I don't understand what
>>>> problem will this solve? Have I missed some earlier message
>>>> in this thread?
>>> For the 99%+ of users who don't use dosemu, it prevents exploits that
>>> target vm86 from attacking their kernel.
>> I don't think the attack scenario was satisfactory explained.
>> IIRC you only said that
>> ---
>>
>> The mark_screen_rdonly thing is still kind of scary.  It changes PTEs
>> on arbitrary mappings behind the vm's back.
>>
>> ---
>> Just go ahead and remove mark_screen_rdonly, big deal.
>> Is this all of the threat?
>> Or do we treat _every_ syscall as the potential attack target?
> Anything that messes with the VM subsystem (doubly if it does so without actually calling into the VM subsystem) is a potential target
... and should be removed.
Remove mark_screen_rdonly hack.

> as is anything that messes with execution mode or privilege
> level (as in, possibly messes with which ring (or whatevere equivalent metaphor other processors use) execution is happening in).  This does potentially all three (depending on how it's called).  Just
> because there are no known working exploits doesn't mean it's not possible, and in the case of this code, I'd say there is almost certainly some way to exploit it either to crash the system or gain
> root-equivalent privileges.
Please be specific, show the dangerous code, we'll then remove it
or fix it.

Re: stop breaking dosemu (Re: x86/kconfig/32: Rename CONFIG_VM86 and default it to 'n')

[Austin S Hemmelgarn]

[-- Attachment #1: Type: text/plain, Size: 5499 bytes --]

On 2015-09-03 08:15, Stas Sergeev wrote:
> 03.09.2015 15:11, Austin S Hemmelgarn пишет:
>> On 2015-09-02 17:53, Stas Sergeev wrote:
>>> 03.09.2015 00:40, Andy Lutomirski пишет:
>>>> On Wed, Sep 2, 2015 at 2:12 PM, Stas Sergeev <stsp@list.ru> wrote:
>>>>> 02.09.2015 23:55, Andy Lutomirski пишет:
>>>>>
>>>>>> On Wed, Sep 2, 2015 at 1:47 PM, Stas Sergeev <stsp@list.ru> wrote:
>>>>>>> 02.09.2015 23:22, Josh Boyer пишет:
>>>>>>>> On Wed, Sep 2, 2015 at 1:50 PM, Stas Sergeev <stsp@list.ru> wrote:
>>>>>>>>> 02.09.2015 20:46, Josh Boyer пишет:
>>>>>>>>>> On Wed, Sep 2, 2015 at 10:08 AM, Andy Lutomirski
>>>>>>>>>> <luto@amacapital.net>
>>>>>>>>>> wrote:
>>>>>>>>>>> I'd be amenable to switching the default back to y and perhaps
>>>>>>>>>>> adding
>>>>>>>>>>> a sysctl to make the distros more comfortable.  Ingo, Kees, Brian,
>>>>>>>>>>> what do you think?
>>>>>>>>>> Can you please leave the default as N, and have a sysctl option to
>>>>>>>>>> enable it instead?  While dosemu might still be in use, it isn't
>>>>>>>>>> going
>>>>>>>>>> to be the common case at all.  So from a distro perspective, I
>>>>>>>>>> think
>>>>>>>>>> we'd probably rather have the default match the common case.
>>>>>>>>> The fact that fedora doesn't package dosemu, doesn't automatically
>>>>>>>>> mean all other distros do not too. Since when kernel defaults should
>>>>>>>>> match the ones of fedora?
>>>>>>>> I didn't say that.
>>>>>>> What you said was:
>>>>>>> ---
>>>>>>>
>>>>>>> While dosemu might still be in use, it isn't going
>>>>>>> to be the common case at all.  So from a distro perspective
>>>>>>>
>>>>>>> ---
>>>>>>> ... which is likely true only in fedora circe.
>>>>>>>
>>>>>>>>       The default right now is N.
>>>>>>> In a not yet released kernel, unless I am mistaken.
>>>>>>> If fedora already provides that kernel, other distros likely not.
>>>>>>>
>>>>>>>>       I asked it be left
>>>>>>>> that way.  That's all.
>>>>>>> Lets assume its not yet N, unless there was a kernel release already.
>>>>>>> Its easy to get back if its not too late.
>>>>>> How about CONFIG_SYSCTL_VM86_DEFAULT which defaults to Y?  Fedora
>>>>>> could set it to N.
>>>>> Sorry, I don't understand this sysctl proposal.
>>>>> Could you please educate me what is it all about?
>>>>> This sysctl will disable or enable the vm86() syscall at run-time,
>>>>> right? What does it give us? If you disable something in the
>>>>> config, this gives you, say, smaller kernel image. If OTOH you
>>>>> add the run-time switch, it gives you a bigger image, regardless
>>>>> of its default value.
>>>>> I might be missing something, but I don't understand what
>>>>> problem will this solve? Have I missed some earlier message
>>>>> in this thread?
>>>> For the 99%+ of users who don't use dosemu, it prevents exploits that
>>>> target vm86 from attacking their kernel.
>>> I don't think the attack scenario was satisfactory explained.
>>> IIRC you only said that
>>> ---
>>>
>>> The mark_screen_rdonly thing is still kind of scary.  It changes PTEs
>>> on arbitrary mappings behind the vm's back.
>>>
>>> ---
>>> Just go ahead and remove mark_screen_rdonly, big deal.
>>> Is this all of the threat?
>>> Or do we treat _every_ syscall as the potential attack target?
>> Anything that messes with the VM subsystem (doubly if it does so without actually calling into the VM subsystem) is a potential target
> ... and should be removed.
> Remove mark_screen_rdonly hack.
>
>> as is anything that messes with execution mode or privilege
>> level (as in, possibly messes with which ring (or whatevere equivalent metaphor other processors use) execution is happening in).  This does potentially all three (depending on how it's called).  Just
>> because there are no known working exploits doesn't mean it's not possible, and in the case of this code, I'd say there is almost certainly some way to exploit it either to crash the system or gain
>> root-equivalent privileges.
> Please be specific, show the dangerous code, we'll then remove it
> or fix it.
>
The problem is we don't _know_ what could be exploited in there.  There 
is no way to know for certain without a full audit of the code (and even 
that wouldn't be certain to catch everything), which is almost certainly 
not going to happen unless someone pays a very large amount of money for it.

We should not however, wait to disable something by default that 
(probably) less than 1% of the people who are running Linux on systems 
that can even use this are actually using until someone demonstrates a 
workable exploit. Security is not just a reactionary endeavor, you need 
to be proactive about it as well.  This means minimizing the attack 
surface whenever possible (and yes, this an potential attack vector, 
regardless of whether there are known workable exploits or not).

What has been proposed follows the existing convention on Linux (don't 
break userspace, and provide the option to people who actually care 
about their systems being secure to turn it off), the current proposal 
is to make it default to on in the defconfig, and have the sysctl 
default to leaving it enabled.

On top of this, vm86 has a set of very specific niche use cases, most 
syscalls like this (AIO, bpf(), seccomp(), {m,f}advise(), etc) can only 
be turned on and off by completely rebuilding the kernel.  This lets you 
turn this on or off at runtime.


[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 3019 bytes --]

Re: stop breaking dosemu (Re: x86/kconfig/32: Rename CONFIG_VM86 and default it to 'n')

[Stas Sergeev]

03.09.2015 18:44, Austin S Hemmelgarn пишет:
> On 2015-09-03 08:15, Stas Sergeev wrote:
>> 03.09.2015 15:11, Austin S Hemmelgarn пишет:
>>> On 2015-09-02 17:53, Stas Sergeev wrote:
>>>> 03.09.2015 00:40, Andy Lutomirski пишет:
>>>>> On Wed, Sep 2, 2015 at 2:12 PM, Stas Sergeev <stsp@list.ru> wrote:
>>>>>> 02.09.2015 23:55, Andy Lutomirski пишет:
>>>>>>
>>>>>>> On Wed, Sep 2, 2015 at 1:47 PM, Stas Sergeev <stsp@list.ru> wrote:
>>>>>>>> 02.09.2015 23:22, Josh Boyer пишет:
>>>>>>>>> On Wed, Sep 2, 2015 at 1:50 PM, Stas Sergeev <stsp@list.ru> wrote:
>>>>>>>>>> 02.09.2015 20:46, Josh Boyer пишет:
>>>>>>>>>>> On Wed, Sep 2, 2015 at 10:08 AM, Andy Lutomirski
>>>>>>>>>>> <luto@amacapital.net>
>>>>>>>>>>> wrote:
>>>>>>>>>>>> I'd be amenable to switching the default back to y and perhaps
>>>>>>>>>>>> adding
>>>>>>>>>>>> a sysctl to make the distros more comfortable.  Ingo, Kees, Brian,
>>>>>>>>>>>> what do you think?
>>>>>>>>>>> Can you please leave the default as N, and have a sysctl option to
>>>>>>>>>>> enable it instead?  While dosemu might still be in use, it isn't
>>>>>>>>>>> going
>>>>>>>>>>> to be the common case at all.  So from a distro perspective, I
>>>>>>>>>>> think
>>>>>>>>>>> we'd probably rather have the default match the common case.
>>>>>>>>>> The fact that fedora doesn't package dosemu, doesn't automatically
>>>>>>>>>> mean all other distros do not too. Since when kernel defaults should
>>>>>>>>>> match the ones of fedora?
>>>>>>>>> I didn't say that.
>>>>>>>> What you said was:
>>>>>>>> ---
>>>>>>>>
>>>>>>>> While dosemu might still be in use, it isn't going
>>>>>>>> to be the common case at all.  So from a distro perspective
>>>>>>>>
>>>>>>>> ---
>>>>>>>> ... which is likely true only in fedora circe.
>>>>>>>>
>>>>>>>>>       The default right now is N.
>>>>>>>> In a not yet released kernel, unless I am mistaken.
>>>>>>>> If fedora already provides that kernel, other distros likely not.
>>>>>>>>
>>>>>>>>>       I asked it be left
>>>>>>>>> that way.  That's all.
>>>>>>>> Lets assume its not yet N, unless there was a kernel release already.
>>>>>>>> Its easy to get back if its not too late.
>>>>>>> How about CONFIG_SYSCTL_VM86_DEFAULT which defaults to Y?  Fedora
>>>>>>> could set it to N.
>>>>>> Sorry, I don't understand this sysctl proposal.
>>>>>> Could you please educate me what is it all about?
>>>>>> This sysctl will disable or enable the vm86() syscall at run-time,
>>>>>> right? What does it give us? If you disable something in the
>>>>>> config, this gives you, say, smaller kernel image. If OTOH you
>>>>>> add the run-time switch, it gives you a bigger image, regardless
>>>>>> of its default value.
>>>>>> I might be missing something, but I don't understand what
>>>>>> problem will this solve? Have I missed some earlier message
>>>>>> in this thread?
>>>>> For the 99%+ of users who don't use dosemu, it prevents exploits that
>>>>> target vm86 from attacking their kernel.
>>>> I don't think the attack scenario was satisfactory explained.
>>>> IIRC you only said that
>>>> ---
>>>>
>>>> The mark_screen_rdonly thing is still kind of scary.  It changes PTEs
>>>> on arbitrary mappings behind the vm's back.
>>>>
>>>> ---
>>>> Just go ahead and remove mark_screen_rdonly, big deal.
>>>> Is this all of the threat?
>>>> Or do we treat _every_ syscall as the potential attack target?
>>> Anything that messes with the VM subsystem (doubly if it does so without actually calling into the VM subsystem) is a potential target
>> ... and should be removed.
>> Remove mark_screen_rdonly hack.
>>
>>> as is anything that messes with execution mode or privilege
>>> level (as in, possibly messes with which ring (or whatevere equivalent metaphor other processors use) execution is happening in).  This does potentially all three (depending on how it's called).  Just
>>> because there are no known working exploits doesn't mean it's not possible, and in the case of this code, I'd say there is almost certainly some way to exploit it either to crash the system or gain
>>> root-equivalent privileges.
>> Please be specific, show the dangerous code, we'll then remove it
>> or fix it.
>>
> The problem is we don't _know_ what could be exploited in there.  There is no way to know for certain without a full audit of the code
As was indicated in this thread already:
https://lkml.org/lkml/2015/9/2/317
Brian Gerst recently audited it:
---
That's
hopefully in much better shape now, though.
---

> We should not however, wait to disable something by default that (probably) less than 1% of the people who are running Linux on systems that can even use this are actually using
I am puzzled with this "probably".
Given that ubuntu and debian do provide it, and that (unmaintained)
SF page shows a few hundreds of downloads per week, how have you calculated
the probability of its user base being below 1% of all linux users?
Please provide more details so that I can double-check.


> until someone
> demonstrates a workable exploit. Security is not just a reactionary endeavor, you need to be proactive about it as well.  This means minimizing the attack surface whenever possible (and yes, this an
> potential attack vector, regardless of whether there are known workable exploits or not).
There are ways to minimize the risk: just remove the bloat, then
see what remains.
If you leave the bloat and just call it "dangerous", people will
start disabling it, because _then_ it will really be an unmaintained
attack target. So what you propose, is the worst solution, not the best.
It will threaten the current vm86() users instead of doing them a
favour by cleaning and fixing the code, and they will start looking
into abandoning it.

> What has been proposed follows the existing convention on Linux (don't break userspace, and provide the option to people who actually care about their systems being secure to turn it off), the current
> proposal is to make it default to on in the defconfig, and have the sysctl default to leaving it enabled.
> 
> On top of this, vm86 has a set of very specific niche use cases, most syscalls like this (AIO, bpf(), seccomp(), {m,f}advise(), etc) can only be turned on and off by completely rebuilding the kernel. 
"on and off"? Nice, but they are On by default (except for bpf()).
So the fact that they have no runtime knob doesn't look like a big
surprise.

> This lets you turn this on or off at runtime.
With a big warning that "it is an attack surface and less than
1% of people use it, please don't touch"? No thankyou.

I'll be looking into testing and sending the patch that removes
mark_screen_rdonly. Maybe then this thread will shift a bit from
guesses and assumptions.

Re: stop breaking dosemu (Re: x86/kconfig/32: Rename CONFIG_VM86 and default it to 'n')

[Austin S Hemmelgarn]

[-- Attachment #1: Type: text/plain, Size: 7608 bytes --]

On 2015-09-03 12:34, Stas Sergeev wrote:
> 03.09.2015 18:44, Austin S Hemmelgarn пишет:
>> On 2015-09-03 08:15, Stas Sergeev wrote:
>>> 03.09.2015 15:11, Austin S Hemmelgarn пишет:
>>>> On 2015-09-02 17:53, Stas Sergeev wrote:
[... trimmed for brevity ...]
>>>>> I don't think the attack scenario was satisfactory explained.
>>>>> IIRC you only said that
>>>>> ---
>>>>>
>>>>> The mark_screen_rdonly thing is still kind of scary.  It changes PTEs
>>>>> on arbitrary mappings behind the vm's back.
>>>>>
>>>>> ---
>>>>> Just go ahead and remove mark_screen_rdonly, big deal.
>>>>> Is this all of the threat?
>>>>> Or do we treat _every_ syscall as the potential attack target?
>>>> Anything that messes with the VM subsystem (doubly if it does so without actually calling into the VM subsystem) is a potential target
>>> ... and should be removed.
>>> Remove mark_screen_rdonly hack.
>>>
>>>> as is anything that messes with execution mode or privilege
>>>> level (as in, possibly messes with which ring (or whatevere equivalent metaphor other processors use) execution is happening in).  This does potentially all three (depending on how it's called).  Just
>>>> because there are no known working exploits doesn't mean it's not possible, and in the case of this code, I'd say there is almost certainly some way to exploit it either to crash the system or gain
>>>> root-equivalent privileges.
>>> Please be specific, show the dangerous code, we'll then remove it
>>> or fix it.
>>>
>> The problem is we don't _know_ what could be exploited in there.  There is no way to know for certain without a full audit of the code
> As was indicated in this thread already:
> https://lkml.org/lkml/2015/9/2/317
> Brian Gerst recently audited it:
> ---
> That's
> hopefully in much better shape now, though.
> ---
By audit, I don't mean just one person trying to make it more 
maintainable and fixing any bugs he found, I mean a team of people 
actively trying to make it break in every way imaginable. I'd be 
particularly interested to see how it reacts to being hit from multiple 
cores concurrently with trinity.
>> We should not however, wait to disable something by default that (probably) less than 1% of the people who are running Linux on systems that can even use this are actually using
> I am puzzled with this "probably".
> Given that ubuntu and debian do provide it, and that (unmaintained)
> SF page shows a few hundreds of downloads per week, how have you calculated
> the probability of its user base being below 1% of all linux users?
> Please provide more details so that I can double-check.
A few hundred downloads per week, as compared to tens of millions of 
people using Linux worldwide (rough guess, although probably 
conservative), with 10% of the Linux users using 32-bit x86 (again, 
another rough guess, although this one is more generous), still works 
out to around 1%.  It's not possible to get exact numbers for this, and 
downloads from the SF page also happen for the automated build testing 
that most modern distributions do these days and a number of reasons 
other than people using it.
>> until someone
>> demonstrates a workable exploit. Security is not just a reactionary endeavor, you need to be proactive about it as well.  This means minimizing the attack surface whenever possible (and yes, this an
>> potential attack vector, regardless of whether there are known workable exploits or not).
> There are ways to minimize the risk: just remove the bloat, then
> see what remains.
> If you leave the bloat and just call it "dangerous", people will
> start disabling it, because _then_ it will really be an unmaintained
> attack target. So what you propose, is the worst solution, not the best.
> It will threaten the current vm86() users instead of doing them a
> favour by cleaning and fixing the code, and they will start looking
> into abandoning it.
As of right now, the only open-source project that I know of that is 
actually actively used by people on new kernels that uses vm86 is dosemu 
(and the forked dosemu2).  the only other open source user of vm86() 
that I know of is v86d, which is no longer needed except on ancient 
hardware with old kernels.  And as far as proprietary code goes, they 
need to pull their heads out of DOS, realize that sane people use 
protected or long mode for modern software, and get on with their lives.

I'm not saying that we shouldn't improve the code, but that we need to 
provide the option to turn this off at runtime.  Just one program that 
isn't used by a large segment of the community depending on something is 
not a good reason to make everyone have it turned on.

There are servers out there that have this enabled and _never_ use it at 
all, having a system call like this one usable but unused is a potential 
security hole, period, irrespective of the quality of the code the 
syscall executes.

As for abandoning it, that is happening already, 32-bit x86 systems are 
becoming more and more difficult to find, and it's not supported at all 
on 64-bit kernels.
>
>> What has been proposed follows the existing convention on Linux (don't break userspace, and provide the option to people who actually care about their systems being secure to turn it off), the current
>> proposal is to make it default to on in the defconfig, and have the sysctl default to leaving it enabled.
>>
>> On top of this, vm86 has a set of very specific niche use cases, most syscalls like this (AIO, bpf(), seccomp(), {m,f}advise(), etc) can only be turned on and off by completely rebuilding the kernel.
> "on and off"? Nice, but they are On by default (except for bpf()).
> So the fact that they have no runtime knob doesn't look like a big
> surprise.
Most of those (other than seccomp) are used almost exclusively in server 
applications, and in the case of AIO, it is possible to prevent anything 
from using it at runtime, but this can't be sanely relayed to any 
applications that use it (bonus points if you can figure out how to stop 
everyone from using it and why applications can't easily detect this).
>> This lets you turn this on or off at runtime.
> With a big warning that "it is an attack surface and less than
> 1% of people use it, please don't touch"? No thankyou.
I'm not saying that such a warning should be put in, and based on the 
backlash that the original change that sparked this thread got, nothing 
like that is going to be put in, but there is no reason to not be able 
to enable/disable it at runtime.  Most people who are using desktop 
systems are not going to inherently know if they need it or not until 
they do need it, and unlike many of the other syscalls that can be 
disabled, many people who are likely to be using it aren't the type who 
are comfortable compiling their own kernel.
> I'll be looking into testing and sending the patch that removes
> mark_screen_rdonly. Maybe then this thread will shift a bit from
> guesses and assumptions.
My statement that there is a potential security risk inherent in vm86 is 
not a guess or assumption, it's a fact.  Every single way that user code 
can call into the kernel is a potential attack vector, period, 
irrespective of what it does.  You can't say with 100% certainty that 
something is not a possible attack vector unless it isn't there to begin 
with.  While disabling it at runtime is not the best option from a 
security standpoint, it makes it a much more difficult to even try to 
exploit the code.



[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 3019 bytes --]

Re: stop breaking dosemu (Re: x86/kconfig/32: Rename CONFIG_VM86 and default it to 'n')

[Stas Sergeev]

03.09.2015 21:51, Austin S Hemmelgarn пишет:
> On 2015-09-03 12:34, Stas Sergeev wrote:
>> https://lkml.org/lkml/2015/9/2/317
>> Brian Gerst recently audited it:
>> ---
>> That's
>> hopefully in much better shape now, though.
>> ---
> By audit, I don't mean just one person trying to make it more 
> maintainable and fixing any bugs he found, I mean a team of people 
> actively trying to make it break in every way imaginable. I'd be 
> particularly interested to see how it reacts to being hit from 
> multiple cores concurrently with trinity.
Well, without a good clean-up first, such a test
makes no sense. If you know beforehand that the code
is in a bad state and use test to prove that and disable
(instead of fixing), then its not the best way to go.
I'd like to see "how it reacts to being hit from multiple
cores concurrently with trinity", but only after the already
known bloat is stripped.

>>> We should not however, wait to disable something by default that 
>>> (probably) less than 1% of the people who are running Linux on 
>>> systems that can even use this are actually using
>> I am puzzled with this "probably".
>> Given that ubuntu and debian do provide it, and that (unmaintained)
>> SF page shows a few hundreds of downloads per week, how have you 
>> calculated
>> the probability of its user base being below 1% of all linux users?
>> Please provide more details so that I can double-check.
> A few hundred downloads per week, as compared to tens of millions of 
> people using Linux worldwide
Who cares about the absolute numbers of SF downloads?
Ubuntu and debian do provide it - that gives the majority
of users. SF download numbers should IMHO only be compared
to the SF numbers of other SF-hosted projects. Getting some
extrapolation from that is difficult but possible if you can find
out the user base for a few of those "other" projects. I have never
done such a research of course.

> As of right now, the only open-source project that I know of that is 
> actually actively used by people on new kernels that uses vm86 is 
> dosemu (and the forked dosemu2).  the only other open source user of 
> vm86() that I know of is v86d,
svgalib too.
Not sure how dead it is though (likely incompatible with KMS).

> which is no longer needed except on ancient hardware with old kernels. 
> And as far as proprietary code goes, they need to pull their heads out 
> of DOS, realize that sane people use protected or long mode for modern 
> software, and get on with their lives.
Software is usually not such a big deal as the hardware is.
Some unsupported but expensive HW may be difficult to replace,
and that's where dosemu helps.

> I'm not saying that we shouldn't improve the code, but that we need to 
> provide the option to turn this off at runtime.
With Linus's proposal there will be one.
It is so because the option he proposed is meaningful: it disables
the well-known attack scenario - NULL pointer deref in kernel.
Facing with that option, user knows what risk does he accept
(and that risk is known to be small).
But having a meaningless knob with a strange "attack surface"
threat is IMO absolutely unacceptable.

> There are servers out there that have this enabled and _never_ use it 
> at all,
Unless I am mistaken, servers usually use special flavour of the
distro (different from desktop install), where of course this will
be disabled _compile time_.

> As for abandoning it, that is happening already, 32-bit x86 systems 
> are becoming more and more difficult to find, and it's not supported 
> at all on 64-bit kernels.
Maybe, but please let users to abandon it themselves when they
are ready to, rather than with the rude actions (disabling by default
or threatening).

>> This lets you turn this on or off at runtime.
>> With a big warning that "it is an attack surface and less than
>> 1% of people use it, please don't touch"? No thankyou.
> I'm not saying that such a warning should be put in, and based on the 
> backlash that the original change that sparked this thread got, 
> nothing like that is going to be put in,

+	  Enabling this option adds considerable attack surface to the
+	  kernel and slows down system calls and exception handling.

It is _already_ there.

> but there is no reason to not be able to enable/disable it at 
> runtime.  Most people who are using desktop systems are not going to 
> inherently know if they need it or not until they do need it, and 
> unlike many of the other syscalls that can be disabled,
1. How many syscalls can currently be disabled at run-time?
2. How many of them are called an "attack surface", forcing users
to disable them?
3. For how many of the above, the attack scenario was not
even outlined? (other than that any syscall is a potential threat)

If, as you say, that action followed some existing practice,
there should be some more to fit all 3 above criteries.

>> I'll be looking into testing and sending the patch that removes
>> mark_screen_rdonly. Maybe then this thread will shift a bit from
>> guesses and assumptions.
> My statement that there is a potential security risk inherent in vm86 
> is not a guess or assumption, it's a fact.  Every single way that user 
> code can call into the kernel is a potential attack vector, period, 
> irrespective of what it does.
Maybe, but then, please mark every syscall with the above
statement in Kconfig and provide a knob. So far only vm86()
was marked as such, it seems. My question is simple: what
makes vm86() so much different? If the answer is "the reluctance
to fix it", then the treatment was likely not adequate.

>   You can't say with 100% certainty that something is not a possible 
> attack vector unless it isn't there to begin with.
I am only asking to not make an exceptions for vm86(),
unless the reason can be clearly stated. If it is not any
worse than all other syscalls, then please treat it fairly.
Linus recalled about the mmap_min_addr - now it can be
treated fairly, in a light of a well-known low-risk threat.
But the above Kconfig statement should IMHO be removed.

Re: stop breaking dosemu (Re: x86/kconfig/32: Rename CONFIG_VM86 and default it to 'n')

[Chuck Ebbert]

On Fri, 4 Sep 2015 00:28:04 +0300
Stas Sergeev <stsp@list.ru> wrote:

> 03.09.2015 21:51, Austin S Hemmelgarn пишет:
> > There are servers out there that have this enabled and _never_ use it 
> > at all,
> Unless I am mistaken, servers usually use special flavour of the
> distro (different from desktop install), where of course this will
> be disabled _compile time_.
> 

Many (most?) distros use just one kernel for everything, because it's
just too much work to have a separate flavor for servers.

Re: stop breaking dosemu (Re: x86/kconfig/32: Rename CONFIG_VM86 and default it to 'n')

[Stas Sergeev]

04.09.2015 13:09, Chuck Ebbert пишет:
> On Fri, 4 Sep 2015 00:28:04 +0300
> Stas Sergeev <stsp@list.ru> wrote:
> 
>> 03.09.2015 21:51, Austin S Hemmelgarn пишет:
>>> There are servers out there that have this enabled and _never_ use it 
>>> at all,
>> Unless I am mistaken, servers usually use special flavour of the
>> distro (different from desktop install), where of course this will
>> be disabled _compile time_.
> Many (most?) distros use just one kernel for everything, because it's
> just too much work to have a separate flavor for servers.
But for example menuconfig promotes CONFIG_PREEMPT_NONE for server
and CONFIG_PREEMPT for desktop. Also perhaps server would need an
lts version rather than latest.
I wonder if RHEL Server offers the generic desktop-suited kernel
with vm86() enabled?

In any case, if there is some generic mechanism to selectively
disable syscalls at run-time for server, then vm86() is of course
a good candidate. I wonder how many other syscalls are currently
run-time controlled? (those that are not marked as an "attack surface"
and defaulted to Y; I suppose the "attack surface" is currently only vm86())

Re: stop breaking dosemu (Re: x86/kconfig/32: Rename CONFIG_VM86 and default it to 'n')

[Austin S Hemmelgarn]

[-- Attachment #1: Type: text/plain, Size: 2737 bytes --]

On 2015-09-04 06:46, Stas Sergeev wrote:
> 04.09.2015 13:09, Chuck Ebbert пишет:
>> On Fri, 4 Sep 2015 00:28:04 +0300
>> Stas Sergeev <stsp@list.ru> wrote:
>>
>>> 03.09.2015 21:51, Austin S Hemmelgarn пишет:
>>>> There are servers out there that have this enabled and _never_ use it
>>>> at all,
>>> Unless I am mistaken, servers usually use special flavour of the
>>> distro (different from desktop install), where of course this will
>>> be disabled _compile time_.
>> Many (most?) distros use just one kernel for everything, because it's
>> just too much work to have a separate flavor for servers.
> But for example menuconfig promotes CONFIG_PREEMPT_NONE for server
> and CONFIG_PREEMPT for desktop. Also perhaps server would need an
> lts version rather than latest.
> I wonder if RHEL Server offers the generic desktop-suited kernel
> with vm86() enabled?
>
> In any case, if there is some generic mechanism to selectively
> disable syscalls at run-time for server, then vm86() is of course
> a good candidate. I wonder how many other syscalls are currently
> run-time controlled? (those that are not marked as an "attack surface"
> and defaulted to Y; I suppose the "attack surface" is currently only vm86())
>
OK, I think I need to clarify something here.

The attack surface of a given system refers to the number of different 
ways that someone could potentially attack that system.  An individual 
syscall is not in itself an attack surface, but is part of the attack 
surface for the whole system.  One of the core concepts of proactive 
security is to minimize the attack surface, because the fewer ways 
someone could possibly attack you, the less likely it is that they will 
succeed.

I however, referred to vm86 as a potential attack vector, which refers 
one way in which someone could attempt to attack the system (be it 
through arbitrary code execution , privilege escalation, or some other 
type of exploit), note that something does not need to have a known 
exploit to be classified as a potential attack vector (most black hat's 
out there will keep quiet about discovered exploits until they can 
actually make use of them themselves).  By their very definition, every 
single site that userspace can call into the kernel is a _potential_ 
attack vector, including vm86().  vm86() is one of the more attractive 
syscalls to attempt to use as an attack vector on 32-bit x86 systems 
because it's relatively unaudited, significantly modifies the execution 
state of the processor, and is available on a majority of 32-bit x85 
systems in the wild.  This does not mean that it is exploitable 
directly, just that it's a possible target for an exploit.


[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 3019 bytes --]

Re: stop breaking dosemu (Re: x86/kconfig/32: Rename CONFIG_VM86 and default it to 'n')

[Stas Sergeev]

04.09.2015 15:34, Austin S Hemmelgarn пишет:
> On 2015-09-04 06:46, Stas Sergeev wrote:
>> 04.09.2015 13:09, Chuck Ebbert пишет:
>>> On Fri, 4 Sep 2015 00:28:04 +0300
>>> Stas Sergeev <stsp@list.ru> wrote:
>>>
>>>> 03.09.2015 21:51, Austin S Hemmelgarn пишет:
>>>>> There are servers out there that have this enabled and _never_ use it
>>>>> at all,
>>>> Unless I am mistaken, servers usually use special flavour of the
>>>> distro (different from desktop install), where of course this will
>>>> be disabled _compile time_.
>>> Many (most?) distros use just one kernel for everything, because it's
>>> just too much work to have a separate flavor for servers.
>> But for example menuconfig promotes CONFIG_PREEMPT_NONE for server
>> and CONFIG_PREEMPT for desktop. Also perhaps server would need an
>> lts version rather than latest.
>> I wonder if RHEL Server offers the generic desktop-suited kernel
>> with vm86() enabled?
>>
>> In any case, if there is some generic mechanism to selectively
>> disable syscalls at run-time for server, then vm86() is of course
>> a good candidate. I wonder how many other syscalls are currently
>> run-time controlled? (those that are not marked as an "attack surface"
>> and defaulted to Y; I suppose the "attack surface" is currently only vm86())
>>
> OK, I think I need to clarify something here.
> 
> The attack surface of a given system refers to the number of different ways that someone could potentially attack that system.  An individual syscall is not in itself an attack surface, but is part of
> the attack surface for the whole system.  One of the core concepts of proactive security is to minimize the attack surface, because the fewer ways someone could possibly attack you, the less likely it
> is that they will succeed.
> 
> I however, referred to vm86 as a potential attack vector, which refers one way in which someone could attempt to attack the system (be it through arbitrary code execution , privilege escalation, or
> some other type of exploit), note that something does not need to have a known exploit to be classified as a potential attack vector (most black hat's out there will keep quiet about discovered
> exploits until they can actually make use of them themselves).  By their very definition, every single site that userspace can call into the kernel is a _potential_ attack vector, including vm86(). 
But they are not marked as such, while vm86() is.
And they do not have a run-time disabling knob.
So why is such a big difference?

> vm86() is one of the more attractive syscalls to attempt to use as an attack vector on 32-bit x86 systems because it's relatively unaudited,
This can be changed if it is at least stripped from the known
bloat, for example. This could have been done _before_ taking any
other actions on it, because the actions would then be entirely
different. Maybe, if it is properly cleaned up, the action will
change from disabling or introducing a knob to auditing it?

> significantly modifies the execution state of the
> processor, and is available on a majority of 32-bit x85 systems in the wild.  This does not mean that it is exploitable directly, just that it's a possible target for an exploit.
So you say it is more dangerous than other syscalls, and I can
believe you, but this needs a proper justification. Someone have
to write why exactly it is more dangerous, can it be fixed or not,
etc. Like it was done for mark_screen_rdonly - I am not asking you
how it can be exploited because I take your word that this code is
a potential risk. But it can be removed. If there are other risky
parts, they also have to be identified. I simply don't think the
sufficient justification was spelled to consider it as more dangerous
than all other syscalls (modulo mmap_min_addr - that one was identified).

What I mean is that when you add some knob for the user to make his
system more (or less) secure, you have to also supply him with the
information on what exactly risk does he accept. Eg if he writes 0
to mmap_min_addr, he knows exactly what risk does he accept, and that
risk is low, he knows. But if he enables vm86() via some magic sysctl,
the only info he has, is a vague "attack surface" in Kconfig. Do you
really think it is enough for the user to make a decision and accept
the risk? I think it is just a threatening attempt which will force
him to never enable that, because he knows exactly zero about the
risk he is going to accept.
So what I ask for, is just:
1. Strip the bloat that is _already_ identified as dangerous
2. See what remains and properly document the danger
3. If that is _still_ needed, add a knob and document exactly what
risk the user have to accept. But likely it won't be needed at that
point at all.
Instead, people go right to 3, shifting all the problems to the user,
without even giving him the needed hint. I don't believe this follows
an existing kernel policy at all.

Re: stop breaking dosemu (Re: x86/kconfig/32: Rename CONFIG_VM86 and default it to 'n')

[Austin S Hemmelgarn]

[-- Attachment #1: Type: text/plain, Size: 7685 bytes --]

On 2015-09-04 09:06, Stas Sergeev wrote:
> 04.09.2015 15:34, Austin S Hemmelgarn пишет:
>> On 2015-09-04 06:46, Stas Sergeev wrote:
>>> 04.09.2015 13:09, Chuck Ebbert пишет:
>>>> On Fri, 4 Sep 2015 00:28:04 +0300
>>>> Stas Sergeev <stsp@list.ru> wrote:
>>>>
>>>>> 03.09.2015 21:51, Austin S Hemmelgarn пишет:
>>>>>> There are servers out there that have this enabled and _never_ use it
>>>>>> at all,
>>>>> Unless I am mistaken, servers usually use special flavour of the
>>>>> distro (different from desktop install), where of course this will
>>>>> be disabled _compile time_.
>>>> Many (most?) distros use just one kernel for everything, because it's
>>>> just too much work to have a separate flavor for servers.
>>> But for example menuconfig promotes CONFIG_PREEMPT_NONE for server
>>> and CONFIG_PREEMPT for desktop. Also perhaps server would need an
>>> lts version rather than latest.
>>> I wonder if RHEL Server offers the generic desktop-suited kernel
>>> with vm86() enabled?
>>>
>>> In any case, if there is some generic mechanism to selectively
>>> disable syscalls at run-time for server, then vm86() is of course
>>> a good candidate. I wonder how many other syscalls are currently
>>> run-time controlled? (those that are not marked as an "attack surface"
>>> and defaulted to Y; I suppose the "attack surface" is currently only vm86())
>>>
>> OK, I think I need to clarify something here.
>>
>> The attack surface of a given system refers to the number of different ways that someone could potentially attack that system.  An individual syscall is not in itself an attack surface, but is part of
>> the attack surface for the whole system.  One of the core concepts of proactive security is to minimize the attack surface, because the fewer ways someone could possibly attack you, the less likely it
>> is that they will succeed.
>>
>> I however, referred to vm86 as a potential attack vector, which refers one way in which someone could attempt to attack the system (be it through arbitrary code execution , privilege escalation, or
>> some other type of exploit), note that something does not need to have a known exploit to be classified as a potential attack vector (most black hat's out there will keep quiet about discovered
>> exploits until they can actually make use of them themselves).  By their very definition, every single site that userspace can call into the kernel is a _potential_ attack vector, including vm86().
> But they are not marked as such, while vm86() is.
> And they do not have a run-time disabling knob.
> So why is such a big difference?
Take for example read(), this is not a very likely attack vector because:
1. It does exactly _one_ thing.
2. It only copies data to the calling process.
3. It has no odd interactions with mm.
4. The only modification it does to how the processor is executing is 
for the context switch to kernel mode and back to user mode.
5. It is _very_ well audited.
Overall, this means that read() is a relatively low risk.
fork() is slightly more attractive as an exploit target, because it 
doesn't fit points 2 and 4 above.
vm86() is much more attractive because it doesn't fit any of the 5 
points above.  Other system calls that I know of that fit less than 3 of 
the 5 points above are: modify_ldt(), perf_event_open(), ptrace(), and 
bpf().  I regard all of these as potentially more attractive than vm86 
because they are available on a wider range of platforms.  modify_ldt, 
perf_event_open, and ptrace all have ways to disable or significantly 
secure them, and have also all had exploits at some point in time.  bpf 
is able to be disabled, but has not yet had any publicly documented 
exploits that I know of, but this does not mean that it is secure 
(especially considering how new it is).
>
>> vm86() is one of the more attractive syscalls to attempt to use as an attack vector on 32-bit x86 systems because it's relatively unaudited,
> This can be changed if it is at least stripped from the known
> bloat, for example. This could have been done _before_ taking any
> other actions on it, because the actions would then be entirely
> different. Maybe, if it is properly cleaned up, the action will
> change from disabling or introducing a knob to auditing it?
If you clean it up, I'd be happy to throw every thing I can think of at 
it.  Even if I don't manage to discover any exploits in that case, I 
would still advocate against having it availible by default because it's 
functionality that is used by an consistently decreasing percentage of 
users (yes, I know lots of people use dosemu, the number of people who 
use Linux is however going up faster than the number of people who use 
dosemu (no, I don't have numbers to back this up, but it is 
statistically very likely to be the case), and I know a number of people 
who used to use it (myself included) who are moving to dosbox because 
the performance difference is getting less significant as computers get 
faster).
>> significantly modifies the execution state of the
>> processor, and is available on a majority of 32-bit x85 systems in the wild.  This does not mean that it is exploitable directly, just that it's a possible target for an exploit.
> So you say it is more dangerous than other syscalls, and I can
> believe you, but this needs a proper justification. Someone have
> to write why exactly it is more dangerous, can it be fixed or not,
> etc. Like it was done for mark_screen_rdonly - I am not asking you
> how it can be exploited because I take your word that this code is
> a potential risk. But it can be removed. If there are other risky
> parts, they also have to be identified. I simply don't think the
> sufficient justification was spelled to consider it as more dangerous
> than all other syscalls (modulo mmap_min_addr - that one was identified).
I've already stated _why_ it's more dangerous:
1. It interacts in odd ways with memory management.
2. It directly modifies the execution state of the processor.
It is no more potentially dangerous than any other system call that fits 
either description, I'm not trying to single out vm86, that just happens 
to be the syscall we are discussing right now.  Another syscall that is 
a perfect example of both 1 and 2 would be modify_ldt, which _does_ have 
known exploits that required a rewrite, and now has a knob to disable it 
because most people don't use it.  On almost any other OS out there, 
anything that did either 1 or 2 wouldn't have been merged in the first 
place (this is not intended as a statement against Linux), and to be 
honest, if someone tried to merge vm86 into Linux today, they would have 
a very hard time convincing people it is worth it.

Reiterating what I've said before, albeit paraphrased:
1. If you can call code, there is a possibility that you can exploit it.
2. Just because there are no publicly documented exploits for something 
does not mean that it is secure.
3. Having functionality enabled by default that you don't need is a Very 
Bad Thing, this is why Windows has historically had so many security issues.
4. Reactive security is utterly useless for any system that has already 
been exploited.  If you have been hacked by someone who actually knows 
what they are doing, then even your hardware is suspect at that point, 
and patching the initial entry point will not provide any reasonable 
degree of safety.

Also, this will be the last reply I make on this sub-thread, if this 
does not convince you of any of the points I've made, then nothing I can 
say is likely to.


[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 3019 bytes --]

Re: stop breaking dosemu (Re: x86/kconfig/32: Rename CONFIG_VM86 and default it to 'n')

[Stas Sergeev]

04.09.2015 22:51, Austin S Hemmelgarn пишет:
> On 2015-09-04 09:06, Stas Sergeev wrote:
>> 04.09.2015 15:34, Austin S Hemmelgarn пишет:
>>> On 2015-09-04 06:46, Stas Sergeev wrote:
>>>> 04.09.2015 13:09, Chuck Ebbert пишет:
>>>>> On Fri, 4 Sep 2015 00:28:04 +0300
>>>>> Stas Sergeev <stsp@list.ru> wrote:
>>>>>
>>>>>> 03.09.2015 21:51, Austin S Hemmelgarn пишет:
>>>>>>> There are servers out there that have this enabled and _never_ 
>>>>>>> use it
>>>>>>> at all,
>>>>>> Unless I am mistaken, servers usually use special flavour of the
>>>>>> distro (different from desktop install), where of course this will
>>>>>> be disabled _compile time_.
>>>>> Many (most?) distros use just one kernel for everything, because it's
>>>>> just too much work to have a separate flavor for servers.
>>>> But for example menuconfig promotes CONFIG_PREEMPT_NONE for server
>>>> and CONFIG_PREEMPT for desktop. Also perhaps server would need an
>>>> lts version rather than latest.
>>>> I wonder if RHEL Server offers the generic desktop-suited kernel
>>>> with vm86() enabled?
>>>>
>>>> In any case, if there is some generic mechanism to selectively
>>>> disable syscalls at run-time for server, then vm86() is of course
>>>> a good candidate. I wonder how many other syscalls are currently
>>>> run-time controlled? (those that are not marked as an "attack surface"
>>>> and defaulted to Y; I suppose the "attack surface" is currently 
>>>> only vm86())
>>>>
>>> OK, I think I need to clarify something here.
>>>
>>> The attack surface of a given system refers to the number of 
>>> different ways that someone could potentially attack that system.  
>>> An individual syscall is not in itself an attack surface, but is 
>>> part of
>>> the attack surface for the whole system.  One of the core concepts 
>>> of proactive security is to minimize the attack surface, because the 
>>> fewer ways someone could possibly attack you, the less likely it
>>> is that they will succeed.
>>>
>>> I however, referred to vm86 as a potential attack vector, which 
>>> refers one way in which someone could attempt to attack the system 
>>> (be it through arbitrary code execution , privilege escalation, or
>>> some other type of exploit), note that something does not need to 
>>> have a known exploit to be classified as a potential attack vector 
>>> (most black hat's out there will keep quiet about discovered
>>> exploits until they can actually make use of them themselves).  By 
>>> their very definition, every single site that userspace can call 
>>> into the kernel is a _potential_ attack vector, including vm86().
>> But they are not marked as such, while vm86() is.
>> And they do not have a run-time disabling knob.
>> So why is such a big difference?
> Take for example read(), this is not a very likely attack vector because:
> 1. It does exactly _one_ thing.
> 2. It only copies data to the calling process.
> 3. It has no odd interactions with mm.
> 4. The only modification it does to how the processor is executing is 
> for the context switch to kernel mode and back to user mode.
> 5. It is _very_ well audited.
> Overall, this means that read() is a relatively low risk.
> fork() is slightly more attractive as an exploit target, because it 
> doesn't fit points 2 and 4 above.
> vm86() is much more attractive because it doesn't fit any of the 5 
> points above.
I agree. vm86() is a mess.
My point is that its risky parts and useless funtionality
is _already_ known (even I can point to the particular code
parts than can simply be removed). As such, it simply had
to be re-visited and cleaned up to match at least 1 and 3
(and then maybe 5). This wasn't done, and the knob was
introduced _instead_ of doing this. I am not saying the knob
should not exist. Actually the mmap_min_addr is exactly the
knob I am asking for: well justified, well known.

> Other system calls that I know of that fit less than 3 of the 5 points 
> above are: modify_ldt(), perf_event_open(), ptrace(), and bpf().  I 
> regard all of these as potentially more attractive than vm86
Agree!
Are they marked as "attack surface" in the Kconfig or
elsewhere? Or maybe their risk is properly documented?
Or not documented at all? IMHO when security is concerned,
documenting things properly is very important.

>>> vm86() is one of the more attractive syscalls to attempt to use as 
>>> an attack vector on 32-bit x86 systems because it's relatively 
>>> unaudited,
>> This can be changed if it is at least stripped from the known
>> bloat, for example. This could have been done _before_ taking any
>> other actions on it, because the actions would then be entirely
>> different. Maybe, if it is properly cleaned up, the action will
>> change from disabling or introducing a knob to auditing it?
> If you clean it up, I'd be happy to throw every thing I can think of 
> at it.
I'll look into doing that perhaps.
At least I can try to test it after changes.

>   Even if I don't manage to discover any exploits in that case, I 
> would still advocate against having it availible by default because 
> it's functionality that is used by an consistently decreasing 
> percentage of users (yes, I know lots of people use dosemu, the number 
> of people who use Linux is however going up faster than the number of 
> people who use dosemu (no, I don't have numbers to back this up, but 
> it is statistically very likely to be the case),
Yes, I won't challenge that expectation.
dosemu supports legacy system, so its user base is
doomed to decrease. I was only against the assumptions
that it is below 1%. In fact, if we consider the users that
run dosemu just once, type "dir" in the dos prompt, get
some nostalgie and close it forever, I guess we'll get the
surprisingly large numbers. :)

> and I know a number of people who used to use it (myself included) who 
> are moving to dosbox because the performance difference is getting 
> less significant as computers get faster).
dosemu is not only about performance, but also about
a better HW support for which only the DOS drivers exist.
Also I wonder how well dosbox scales and performes in a
multicore setup. dosemu2 had a lot of manpower invested
into a multicore scalability. As a result, you can play Need For
Speed on an old dual-core notebook.

>>> significantly modifies the execution state of the
>>> processor, and is available on a majority of 32-bit x85 systems in 
>>> the wild.  This does not mean that it is exploitable directly, just 
>>> that it's a possible target for an exploit.
>> So you say it is more dangerous than other syscalls, and I can
>> believe you, but this needs a proper justification. Someone have
>> to write why exactly it is more dangerous, can it be fixed or not,
>> etc. Like it was done for mark_screen_rdonly - I am not asking you
>> how it can be exploited because I take your word that this code is
>> a potential risk. But it can be removed. If there are other risky
>> parts, they also have to be identified. I simply don't think the
>> sufficient justification was spelled to consider it as more dangerous
>> than all other syscalls (modulo mmap_min_addr - that one was 
>> identified).
> I've already stated _why_ it's more dangerous:
> 1. It interacts in odd ways with memory management.
If you mean the mark_screen_rdonly hack, then it can just
be removed.

> 2. It directly modifies the execution state of the processor.
Yes.

> It is no more potentially dangerous than any other system call that 
> fits either description, I'm not trying to single out vm86,
Not you, but in Kconfig it has the "attack surface" tag,
which singles it out quite a lot. This alone is a big part
of the problem. Well, for you it is just a minor detail, but
for me - it is a direct threatening of my users.

> that just happens to be the syscall we are discussing right now. 
> Another syscall that is a perfect example of both 1 and 2 would be 
> modify_ldt, which _does_ have known exploits that required a rewrite,
So why not to rewrite (or actually just clean up) the vm86()
syscall _before_ any exploit is found? Part of that was already
done AFAIK, but there are still the things to strip.

> and now has a knob to disable it because most people don't use it.
Well, a very recent knob, I didn't know about it yet.
But please, see the difference:
1. As you said, the code was first rewritten to stay in shape
2. There was no known security threats at the point of
adding the knob, so there was a much softer wording
in Kconfig (I admit it could have been even softer though).

What we have in vm86() case:
1. It is full of risky code which no one rewrites (a lie, Brian Gerst does,
but its still there)
2. The knob is added with an intention for it to always
stay disabled; the heavy wording in Kconfig just confirms
this and threatens the users.

I am not against the knob as a whole, just against how
it was done in this particular case. It have been done much
better in case of modify_ldt().

> Reiterating what I've said before, albeit paraphrased:
> 1. If you can call code, there is a possibility that you can exploit it.
> 2. Just because there are no publicly documented exploits for 
> something does not mean that it is secure.
> 3. Having functionality enabled by default that you don't need is a 
> Very Bad Thing, this is why Windows has historically had so many 
> security issues.
> 4. Reactive security is utterly useless for any system that has 
> already been exploited.  If you have been hacked by someone who 
> actually knows what they are doing, then even your hardware is suspect 
> at that point, and patching the initial entry point will not provide 
> any reasonable degree of safety.
>
> Also, this will be the last reply I make on this sub-thread, if this 
> does not convince you of any of the points I've made, then nothing I 
> can say is likely to 
Its not that I disagree with this your e-mail.
I am actually agree with most. But we see the problem
from different sides. I care about my users that will be
presented with the strange knob, enabling which will allow
them to run dosemu, but will "turn their OS into an attack
surface". What will they choose? I care. But you care about
your users, so you do not share my concerns. When the
user is asked to accept some risk, IMHO he needs some
description of this risk. And he needs to know that this
risk was at least minimized as possible by the developers.
If he knows the otherwise, he'll never accept the risk and
never enable vm86(). This is what important to me, but
you have different objectives, so for you this is just a minor
detail.

Re: stop breaking dosemu (Re: x86/kconfig/32: Rename CONFIG_VM86 and default it to 'n')

[Stas Sergeev]

05.09.2015 00:16, Stas Sergeev пишет:
> I agree. vm86() is a mess.
> My point is that its risky parts and useless funtionality
> is _already_ known (even I can point to the particular code
> parts than can simply be removed). As such, it simply had
> to be re-visited and cleaned up to match at least 1 and 3
> (and then maybe 5). This wasn't done, and the knob was
> introduced _instead_ of doing this.
Grr, I mean it was disabled by default instead of doing this,
and the knob was only proposed, not added.

Re: stop breaking dosemu (Re: x86/kconfig/32: Rename CONFIG_VM86 and default it to 'n')

[Raymond Jennings]

On 09/04/15 14:30, Stas Sergeev wrote:
> 05.09.2015 00:16, Stas Sergeev пишет:
>> I agree. vm86() is a mess.
>> My point is that its risky parts and useless funtionality
>> is _already_ known (even I can point to the particular code
>> parts than can simply be removed). As such, it simply had
>> to be re-visited and cleaned up to match at least 1 and 3
>> (and then maybe 5). This wasn't done, and the knob was
>> introduced _instead_ of doing this.
> Grr, I mean it was disabled by default instead of doing this,
> and the knob was only proposed, not added.

You can't just pull vm86 out of the kernel anyway.  dosemu is a 
userspace application that depends on it, so pulling this feature out 
would be a big fat regression, period.

I would personally rather not hear about how "it's a legacy program so 
its userbase is shrinking" used as any sort of excuse to ignore the fact 
that we shouldn't break userspace.

I can even say as a user that vm86 is important to me.

By all means, cleaning up vm86 is a good idea.  But removing it or 
fencing it off with a strong deprecation doesn't sound like the right idea.
> -- 
> 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/

Re: stop breaking dosemu (Re: x86/kconfig/32: Rename CONFIG_VM86 and default it to 'n')

[Stas Sergeev]

05.09.2015 01:46, Raymond Jennings пишет:
> On 09/04/15 14:30, Stas Sergeev wrote:
>> 05.09.2015 00:16, Stas Sergeev пишет:
>>> I agree. vm86() is a mess.
>>> My point is that its risky parts and useless funtionality
>>> is _already_ known (even I can point to the particular code
>>> parts than can simply be removed). As such, it simply had
>>> to be re-visited and cleaned up to match at least 1 and 3
>>> (and then maybe 5). This wasn't done, and the knob was
>>> introduced _instead_ of doing this.
>> Grr, I mean it was disabled by default instead of doing this,
>> and the knob was only proposed, not added.
>
> You can't just pull vm86 out of the kernel anyway.  dosemu is a 
> userspace application that depends on it, so pulling this feature out 
> would be a big fat regression, period.
>
> I would personally rather not hear about how "it's a legacy program so 
> its userbase is shrinking" used as any sort of excuse to ignore the 
> fact that we shouldn't break userspace.
>
> I can even say as a user that vm86 is important to me.
>
> By all means, cleaning up vm86 is a good idea.  But removing it or 
> fencing it off with a strong deprecation doesn't sound like the right 
> idea.
Yes, that's what I was saying lengthy.
Fencing it off may help those who does not use it,
and that's what most people here worry about.
BUT it will also do a big harm to those who uses it,
unless done properly like for modify_ldt(), or *sigh*
just with mmap_min_addr.

Re: stop breaking dosemu (Re: x86/kconfig/32: Rename CONFIG_VM86 and default it to 'n')

[Stas Sergeev]

03.09.2015 21:51, Austin S Hemmelgarn пишет:
> As of right now, the only open-source project that I know of that is 
> actually actively used by people on new kernels that uses vm86 is 
> dosemu (and the forked dosemu2).  the only other open source user of 
> vm86() that I know of is v86d,
According to this:
http://lrmi.cvs.sourceforge.net/viewvc/lrmi/lrmi/README?revision=1.2&view=markup
we have to be careful with at least MPlayer, MPlayerXP and svgalib
(svgalib was already mentioned).
Maybe all of them already stopped using vm86().

Re: stop breaking dosemu (Re: x86/kconfig/32: Rename CONFIG_VM86 and default it to 'n')

[Linus Torvalds]

On Thu, Sep 3, 2015 at 8:44 AM, Austin S Hemmelgarn
<ahferroin7@gmail.com> wrote:
>
> This lets you turn this on or off at runtime.

Tangential aside: we already effectively have a flag that could turn
off vm86 mode dynamically: /proc/sys/vm/mmap_min_addr.

Sadly (or not) we default it to 4096, which still leaves vm86 mode
usable, although it effectively disables *dos* use for it. Which is
kind of the worst of both worlds: you can use the vm86() system call
for bad things (if you can find a hole in it), but you probably cannot
actually use it for DOS emulation, because the traditional BIOS data
segment is at 0040.

Anyway, what that means is that pretty much the only *valid* use of
vm86() mode is probably when the system maintainer has set
'mmap_min_addr' to zero. So we could probably use that as an already
existing flag that disallows vm86 by our current default values.

Stas - can you confirm that to actually use vm86 mode, you end up
setting that mmap_min_addr thing to zero? Or do you end up using a
mixed-mode setup, where you use vm86() for most things, but emulate
things that trap in the zero page?

                  Linus

Re: stop breaking dosemu (Re: x86/kconfig/32: Rename CONFIG_VM86 and default it to 'n')

[Stas Sergeev]

03.09.2015 19:57, Linus Torvalds пишет:
> On Thu, Sep 3, 2015 at 8:44 AM, Austin S Hemmelgarn
> <ahferroin7@gmail.com> wrote:
>>
>> This lets you turn this on or off at runtime.
> 
> Tangential aside: we already effectively have a flag that could turn
> off vm86 mode dynamically: /proc/sys/vm/mmap_min_addr.
> 
> Sadly (or not) we default it to 4096, which still leaves vm86 mode
> usable, although it effectively disables *dos* use for it. Which is
> kind of the worst of both worlds: you can use the vm86() system call
> for bad things (if you can find a hole in it), but you probably cannot
> actually use it for DOS emulation, because the traditional BIOS data
> segment is at 0040.
> 
> Anyway, what that means is that pretty much the only *valid* use of
> vm86() mode is probably when the system maintainer has set
> 'mmap_min_addr' to zero. So we could probably use that as an already
> existing flag that disallows vm86 by our current default values.
> 
> Stas - can you confirm that to actually use vm86 mode, you end up
> setting that mmap_min_addr thing to zero? Or do you end up using a
> mixed-mode setup, where you use vm86() for most things, but emulate
> things that trap in the zero page?
Yes, good point.
dosemu complains about /proc/sys/vm/mmap_min_addr.
Trapping on zero-page access will likely not work, because
IIRC some distros raise that value even more.
So yes, please use that to completely disable vm86().
You won't even break dosemu's checks, because it (obviously)
tries mmap() before trying vm86().

Thanks!

Re: stop breaking dosemu (Re: x86/kconfig/32: Rename CONFIG_VM86 and default it to 'n')

[Andy Lutomirski]

On Thu, Sep 3, 2015 at 10:19 AM, Stas Sergeev <stsp@list.ru> wrote:
> 03.09.2015 19:57, Linus Torvalds пишет:
>> On Thu, Sep 3, 2015 at 8:44 AM, Austin S Hemmelgarn
>> <ahferroin7@gmail.com> wrote:
>>>
>>> This lets you turn this on or off at runtime.
>>
>> Tangential aside: we already effectively have a flag that could turn
>> off vm86 mode dynamically: /proc/sys/vm/mmap_min_addr.
>>
>> Sadly (or not) we default it to 4096, which still leaves vm86 mode
>> usable, although it effectively disables *dos* use for it. Which is
>> kind of the worst of both worlds: you can use the vm86() system call
>> for bad things (if you can find a hole in it), but you probably cannot
>> actually use it for DOS emulation, because the traditional BIOS data
>> segment is at 0040.
>>
>> Anyway, what that means is that pretty much the only *valid* use of
>> vm86() mode is probably when the system maintainer has set
>> 'mmap_min_addr' to zero. So we could probably use that as an already
>> existing flag that disallows vm86 by our current default values.
>>
>> Stas - can you confirm that to actually use vm86 mode, you end up
>> setting that mmap_min_addr thing to zero? Or do you end up using a
>> mixed-mode setup, where you use vm86() for most things, but emulate
>> things that trap in the zero page?
> Yes, good point.
> dosemu complains about /proc/sys/vm/mmap_min_addr.
> Trapping on zero-page access will likely not work, because
> IIRC some distros raise that value even more.
> So yes, please use that to completely disable vm86().
> You won't even break dosemu's checks, because it (obviously)
> tries mmap() before trying vm86().
>

I'm okay with that.  Shall I send a patch?

There's also vbetool, but I think that almost everyone considers it
dead at this point, and it seems reasonably likely that it needs
mmap_min_addr == 0 as well.

--Andy

Re: stop breaking dosemu (Re: x86/kconfig/32: Rename CONFIG_VM86 and default it to 'n')

[Stas Sergeev]

03.09.2015 20:21, Andy Lutomirski пишет:
> On Thu, Sep 3, 2015 at 10:19 AM, Stas Sergeev <stsp@list.ru> wrote:
>> 03.09.2015 19:57, Linus Torvalds пишет:
>>> On Thu, Sep 3, 2015 at 8:44 AM, Austin S Hemmelgarn
>>> <ahferroin7@gmail.com> wrote:
>>>>
>>>> This lets you turn this on or off at runtime.
>>>
>>> Tangential aside: we already effectively have a flag that could turn
>>> off vm86 mode dynamically: /proc/sys/vm/mmap_min_addr.
>>>
>>> Sadly (or not) we default it to 4096, which still leaves vm86 mode
>>> usable, although it effectively disables *dos* use for it. Which is
>>> kind of the worst of both worlds: you can use the vm86() system call
>>> for bad things (if you can find a hole in it), but you probably cannot
>>> actually use it for DOS emulation, because the traditional BIOS data
>>> segment is at 0040.
>>>
>>> Anyway, what that means is that pretty much the only *valid* use of
>>> vm86() mode is probably when the system maintainer has set
>>> 'mmap_min_addr' to zero. So we could probably use that as an already
>>> existing flag that disallows vm86 by our current default values.
>>>
>>> Stas - can you confirm that to actually use vm86 mode, you end up
>>> setting that mmap_min_addr thing to zero? Or do you end up using a
>>> mixed-mode setup, where you use vm86() for most things, but emulate
>>> things that trap in the zero page?
>> Yes, good point.
>> dosemu complains about /proc/sys/vm/mmap_min_addr.
>> Trapping on zero-page access will likely not work, because
>> IIRC some distros raise that value even more.
>> So yes, please use that to completely disable vm86().
>> You won't even break dosemu's checks, because it (obviously)
>> tries mmap() before trying vm86().
>>
> 
> I'm okay with that.  Shall I send a patch?
I wonder if this patch will also stop calling it an attack surface. :)

> There's also vbetool, but I think that almost everyone considers it
> dead at this point, and it seems reasonably likely that it needs
> mmap_min_addr == 0 as well.
Most certainly, as vbios IIRC wants to read the addresses around 0x400,
which it fills during POST.
At least when dosemu used to map real vbios (long time ago), it also
used to copy these values from /dev/mem, and they are within the first page.

Re: stop breaking dosemu (Re: x86/kconfig/32: Rename CONFIG_VM86 and default it to 'n')

[Stas Sergeev]

03.09.2015 18:44, Austin S Hemmelgarn пишет:
> On 2015-09-03 08:15, Stas Sergeev wrote:
>> 03.09.2015 15:11, Austin S Hemmelgarn пишет:
>>> On 2015-09-02 17:53, Stas Sergeev wrote:
>>>> 03.09.2015 00:40, Andy Lutomirski пишет:
>>>>> On Wed, Sep 2, 2015 at 2:12 PM, Stas Sergeev <stsp@list.ru> wrote:
>>>>>> 02.09.2015 23:55, Andy Lutomirski пишет:
>>>>>>
>>>>>>> On Wed, Sep 2, 2015 at 1:47 PM, Stas Sergeev <stsp@list.ru> wrote:
>>>>>>>> 02.09.2015 23:22, Josh Boyer пишет:
>>>>>>>>> On Wed, Sep 2, 2015 at 1:50 PM, Stas Sergeev <stsp@list.ru> wrote:
>>>>>>>>>> 02.09.2015 20:46, Josh Boyer пишет:
>>>>>>>>>>> On Wed, Sep 2, 2015 at 10:08 AM, Andy Lutomirski
>>>>>>>>>>> <luto@amacapital.net>
>>>>>>>>>>> wrote:
>>>>>>>>>>>> I'd be amenable to switching the default back to y and perhaps
>>>>>>>>>>>> adding
>>>>>>>>>>>> a sysctl to make the distros more comfortable.  Ingo, Kees, Brian,
>>>>>>>>>>>> what do you think?
>>>>>>>>>>> Can you please leave the default as N, and have a sysctl option to
>>>>>>>>>>> enable it instead?  While dosemu might still be in use, it isn't
>>>>>>>>>>> going
>>>>>>>>>>> to be the common case at all.  So from a distro perspective, I
>>>>>>>>>>> think
>>>>>>>>>>> we'd probably rather have the default match the common case.
>>>>>>>>>> The fact that fedora doesn't package dosemu, doesn't automatically
>>>>>>>>>> mean all other distros do not too. Since when kernel defaults should
>>>>>>>>>> match the ones of fedora?
>>>>>>>>> I didn't say that.
>>>>>>>> What you said was:
>>>>>>>> ---
>>>>>>>>
>>>>>>>> While dosemu might still be in use, it isn't going
>>>>>>>> to be the common case at all.  So from a distro perspective
>>>>>>>>
>>>>>>>> ---
>>>>>>>> ... which is likely true only in fedora circe.
>>>>>>>>
>>>>>>>>>       The default right now is N.
>>>>>>>> In a not yet released kernel, unless I am mistaken.
>>>>>>>> If fedora already provides that kernel, other distros likely not.
>>>>>>>>
>>>>>>>>>       I asked it be left
>>>>>>>>> that way.  That's all.
>>>>>>>> Lets assume its not yet N, unless there was a kernel release already.
>>>>>>>> Its easy to get back if its not too late.
>>>>>>> How about CONFIG_SYSCTL_VM86_DEFAULT which defaults to Y?  Fedora
>>>>>>> could set it to N.
>>>>>> Sorry, I don't understand this sysctl proposal.
>>>>>> Could you please educate me what is it all about?
>>>>>> This sysctl will disable or enable the vm86() syscall at run-time,
>>>>>> right? What does it give us? If you disable something in the
>>>>>> config, this gives you, say, smaller kernel image. If OTOH you
>>>>>> add the run-time switch, it gives you a bigger image, regardless
>>>>>> of its default value.
>>>>>> I might be missing something, but I don't understand what
>>>>>> problem will this solve? Have I missed some earlier message
>>>>>> in this thread?
>>>>> For the 99%+ of users who don't use dosemu, it prevents exploits that
>>>>> target vm86 from attacking their kernel.
>>>> I don't think the attack scenario was satisfactory explained.
>>>> IIRC you only said that
>>>> ---
>>>>
>>>> The mark_screen_rdonly thing is still kind of scary.  It changes PTEs
>>>> on arbitrary mappings behind the vm's back.
>>>>
>>>> ---
>>>> Just go ahead and remove mark_screen_rdonly, big deal.
>>>> Is this all of the threat?
>>>> Or do we treat _every_ syscall as the potential attack target?
>>> Anything that messes with the VM subsystem (doubly if it does so without actually calling into the VM subsystem) is a potential target
>> ... and should be removed.
>> Remove mark_screen_rdonly hack.
>>
>>> as is anything that messes with execution mode or privilege
>>> level (as in, possibly messes with which ring (or whatevere equivalent metaphor other processors use) execution is happening in).  This does potentially all three (depending on how it's called).  Just
>>> because there are no known working exploits doesn't mean it's not possible, and in the case of this code, I'd say there is almost certainly some way to exploit it either to crash the system or gain
>>> root-equivalent privileges.
>> Please be specific, show the dangerous code, we'll then remove it
>> or fix it.
>>
> The problem is we don't _know_ what could be exploited in there.  There is no way to know for certain without a full audit of the code (and even that wouldn't be certain to catch everything), which is
> almost certainly not going to happen unless someone pays a very large amount of money for it.
> 
> We should not however, wait to disable something by default that (probably) less than 1% of the people who are running Linux on systems that can even use this are actually using until someone
> demonstrates a workable exploit. Security is not just a reactionary endeavor, you need to be proactive about it as well.  This means minimizing the attack surface whenever possible (and yes, this an
> potential attack vector, regardless of whether there are known workable exploits or not).
> 
> What has been proposed follows the existing convention on Linux (don't break userspace, and provide the option to people who actually care about their systems being secure to turn it off), the current
> proposal is to make it default to on in the defconfig, and have the sysctl default to leaving it enabled.
> 
> On top of this, vm86 has a set of very specific niche use cases, most syscalls like this (AIO, bpf(), seccomp(), {m,f}advise(), etc) can only be turned on and off by completely rebuilding the kernel. 
Please also note that none of the above are called an
"attack surface" in Kconfig.
Simply providing the new knob to disable looks harmless by
itself, but if you explicitly called something an "attack target",
unused, unmaintained etc and added a knob to disable it - this is
an entirely different story. It means you don't want to fix the
problems, but want to shift them to users, saying that they use it
on their own risk. This is what annoys me the most here.
If you claim this "follows the existing convention on Linux", then
please call all of the above syscalls an "attack target" in Kconfig
and add a knobs to them as well. Otherwise this doesn't follow any
convention at all. Adding a knob is an assertion that it _is_ dangerous.
It can't go as "oh, we just added a small knob, who cares". And the
fact that other rare syscalls do not have such knob, just confirms that.

Re: stop breaking dosemu (Re: x86/kconfig/32: Rename CONFIG_VM86 and default it to 'n')

[Austin S Hemmelgarn]

[-- Attachment #1: Type: text/plain, Size: 2754 bytes --]

On 2015-09-02 17:12, Stas Sergeev wrote:
> 02.09.2015 23:55, Andy Lutomirski пишет:
>> On Wed, Sep 2, 2015 at 1:47 PM, Stas Sergeev <stsp@list.ru> wrote:
>>> 02.09.2015 23:22, Josh Boyer пишет:
>>>> On Wed, Sep 2, 2015 at 1:50 PM, Stas Sergeev <stsp@list.ru> wrote:
>>>>> 02.09.2015 20:46, Josh Boyer пишет:
>>>>>> On Wed, Sep 2, 2015 at 10:08 AM, Andy Lutomirski
>>>>>> <luto@amacapital.net>
>>>>>> wrote:
>>>>>>> I'd be amenable to switching the default back to y and perhaps
>>>>>>> adding
>>>>>>> a sysctl to make the distros more comfortable.  Ingo, Kees, Brian,
>>>>>>> what do you think?
>>>>>> Can you please leave the default as N, and have a sysctl option to
>>>>>> enable it instead?  While dosemu might still be in use, it isn't
>>>>>> going
>>>>>> to be the common case at all.  So from a distro perspective, I think
>>>>>> we'd probably rather have the default match the common case.
>>>>> The fact that fedora doesn't package dosemu, doesn't automatically
>>>>> mean all other distros do not too. Since when kernel defaults should
>>>>> match the ones of fedora?
>>>> I didn't say that.
>>> What you said was:
>>> ---
>>>
>>> While dosemu might still be in use, it isn't going
>>> to be the common case at all.  So from a distro perspective
>>>
>>> ---
>>> ... which is likely true only in fedora circe.
>>>
>>>>     The default right now is N.
>>> In a not yet released kernel, unless I am mistaken.
>>> If fedora already provides that kernel, other distros likely not.
>>>
>>>>     I asked it be left
>>>> that way.  That's all.
>>> Lets assume its not yet N, unless there was a kernel release already.
>>> Its easy to get back if its not too late.
>> How about CONFIG_SYSCTL_VM86_DEFAULT which defaults to Y?  Fedora
>> could set it to N.
> Sorry, I don't understand this sysctl proposal.
> Could you please educate me what is it all about?
> This sysctl will disable or enable the vm86() syscall at run-time,
> right? What does it give us? If you disable something in the
> config, this gives you, say, smaller kernel image. If OTOH you
> add the run-time switch, it gives you a bigger image, regardless
> of its default value.
> I might be missing something, but I don't understand what
> problem will this solve? Have I missed some earlier message
> in this thread?
The problem this solves is not kernel size, that is not the only reason 
for wanting to disable a system call.  In this case, it's a system call 
that is unused by all but a very few programs, which are in turn used by 
a small percentage of users, and said system call does quite a few 
things that are potentially very dangerous.  Disabling it reduces the 
attack surface of the system.




[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 3019 bytes --]

Re: stop breaking dosemu (Re: x86/kconfig/32: Rename CONFIG_VM86 and default it to 'n')

[Stas Sergeev]

03.09.2015 15:01, Austin S Hemmelgarn пишет:
> On 2015-09-02 17:12, Stas Sergeev wrote:
>> 02.09.2015 23:55, Andy Lutomirski пишет:
>>> On Wed, Sep 2, 2015 at 1:47 PM, Stas Sergeev <stsp@list.ru> wrote:
>>>> 02.09.2015 23:22, Josh Boyer пишет:
>>>>> On Wed, Sep 2, 2015 at 1:50 PM, Stas Sergeev <stsp@list.ru> wrote:
>>>>>> 02.09.2015 20:46, Josh Boyer пишет:
>>>>>>> On Wed, Sep 2, 2015 at 10:08 AM, Andy Lutomirski
>>>>>>> <luto@amacapital.net>
>>>>>>> wrote:
>>>>>>>> I'd be amenable to switching the default back to y and perhaps
>>>>>>>> adding
>>>>>>>> a sysctl to make the distros more comfortable.  Ingo, Kees, Brian,
>>>>>>>> what do you think?
>>>>>>> Can you please leave the default as N, and have a sysctl option to
>>>>>>> enable it instead?  While dosemu might still be in use, it isn't
>>>>>>> going
>>>>>>> to be the common case at all.  So from a distro perspective, I think
>>>>>>> we'd probably rather have the default match the common case.
>>>>>> The fact that fedora doesn't package dosemu, doesn't automatically
>>>>>> mean all other distros do not too. Since when kernel defaults should
>>>>>> match the ones of fedora?
>>>>> I didn't say that.
>>>> What you said was:
>>>> ---
>>>>
>>>> While dosemu might still be in use, it isn't going
>>>> to be the common case at all.  So from a distro perspective
>>>>
>>>> ---
>>>> ... which is likely true only in fedora circe.
>>>>
>>>>>     The default right now is N.
>>>> In a not yet released kernel, unless I am mistaken.
>>>> If fedora already provides that kernel, other distros likely not.
>>>>
>>>>>     I asked it be left
>>>>> that way.  That's all.
>>>> Lets assume its not yet N, unless there was a kernel release already.
>>>> Its easy to get back if its not too late.
>>> How about CONFIG_SYSCTL_VM86_DEFAULT which defaults to Y?  Fedora
>>> could set it to N.
>> Sorry, I don't understand this sysctl proposal.
>> Could you please educate me what is it all about?
>> This sysctl will disable or enable the vm86() syscall at run-time,
>> right? What does it give us? If you disable something in the
>> config, this gives you, say, smaller kernel image. If OTOH you
>> add the run-time switch, it gives you a bigger image, regardless
>> of its default value.
>> I might be missing something, but I don't understand what
>> problem will this solve? Have I missed some earlier message
>> in this thread?
> The problem this solves is not kernel size, that is not the only reason for wanting to disable a system call.  In this case, it's a system call that is unused by all but a very few programs, which are
> in turn used by a small percentage of users, and said system call does quite a few things that are potentially very dangerous.  Disabling it reduces the attack surface of the system.
Well, thanks for explaining the marketing part of the problem
(initially I wasn't aware, but now Andy already spelled it too),
but the reality is different.

Re: stop breaking dosemu (Re: x86/kconfig/32: Rename CONFIG_VM86 and default it to 'n')

[Kees Cook]

On Wed, Sep 2, 2015 at 10:46 AM, Josh Boyer <jwboyer@fedoraproject.org> wrote:
> On Wed, Sep 2, 2015 at 10:08 AM, Andy Lutomirski <luto@amacapital.net> wrote:
>> I'd be amenable to switching the default back to y and perhaps adding
>> a sysctl to make the distros more comfortable.  Ingo, Kees, Brian,
>> what do you think?
>
> Can you please leave the default as N, and have a sysctl option to
> enable it instead?  While dosemu might still be in use, it isn't going
> to be the common case at all.  So from a distro perspective, I think
> we'd probably rather have the default match the common case.

Linus will say the default must not break existing userspace...

-Kees

-- 
Kees Cook
Chrome OS Security

Re: stop breaking dosemu (Re: x86/kconfig/32: Rename CONFIG_VM86 and default it to 'n')

[Josh Boyer]

On Wed, Sep 2, 2015 at 1:52 PM, Kees Cook <keescook@chromium.org> wrote:
> On Wed, Sep 2, 2015 at 10:46 AM, Josh Boyer <jwboyer@fedoraproject.org> wrote:
>> On Wed, Sep 2, 2015 at 10:08 AM, Andy Lutomirski <luto@amacapital.net> wrote:
>>> I'd be amenable to switching the default back to y and perhaps adding
>>> a sysctl to make the distros more comfortable.  Ingo, Kees, Brian,
>>> what do you think?
>>
>> Can you please leave the default as N, and have a sysctl option to
>> enable it instead?  While dosemu might still be in use, it isn't going
>> to be the common case at all.  So from a distro perspective, I think
>> we'd probably rather have the default match the common case.
>
> Linus will say the default must not break existing userspace...

Yeah, I guess.  Which is weird when it's already N in his tree and
we're talking about a config option that is explicitly there to
disable things.  Something will be broken if it's toggled, but oh
well.

josh

Re: stop breaking dosemu (Re: x86/kconfig/32: Rename CONFIG_VM86 and default it to 'n')

[Andy Lutomirski]

On Wed, Sep 2, 2015 at 10:46 AM, Josh Boyer <jwboyer@fedoraproject.org> wrote:
> On Wed, Sep 2, 2015 at 10:08 AM, Andy Lutomirski <luto@amacapital.net> wrote:
>> I'd be amenable to switching the default back to y and perhaps adding
>> a sysctl to make the distros more comfortable.  Ingo, Kees, Brian,
>> what do you think?
>
> Can you please leave the default as N, and have a sysctl option to
> enable it instead?  While dosemu might still be in use, it isn't going
> to be the common case at all.  So from a distro perspective, I think
> we'd probably rather have the default match the common case.

We can give a separate option that changes the default sysctl value at
kernel config time.

--Andy

Re: stop breaking dosemu (Re: x86/kconfig/32: Rename CONFIG_VM86 and default it to 'n')

[Josh Boyer]

On Wed, Sep 2, 2015 at 2:19 PM, Andy Lutomirski <luto@amacapital.net> wrote:
> On Wed, Sep 2, 2015 at 10:46 AM, Josh Boyer <jwboyer@fedoraproject.org> wrote:
>> On Wed, Sep 2, 2015 at 10:08 AM, Andy Lutomirski <luto@amacapital.net> wrote:
>>> I'd be amenable to switching the default back to y and perhaps adding
>>> a sysctl to make the distros more comfortable.  Ingo, Kees, Brian,
>>> what do you think?
>>
>> Can you please leave the default as N, and have a sysctl option to
>> enable it instead?  While dosemu might still be in use, it isn't going
>> to be the common case at all.  So from a distro perspective, I think
>> we'd probably rather have the default match the common case.
>
> We can give a separate option that changes the default sysctl value at
> kernel config time.

I'd certainly appreciate that.  We've had terrible luck getting such
options added to other things (like YAMA).

josh