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