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