On 2015-09-03 12:34, Stas Sergeev wrote:Well, without a good clean-up first, such a test
https://lkml.org/lkml/2015/9/2/317By 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.
Brian Gerst recently audited it:
hopefully in much better shape now, though.
Who cares about the absolute numbers of SF downloads?A few hundred downloads per week, as compared to tens of millions of people using Linux worldwideWe 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 usingI 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.
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.
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.
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.
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
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
This lets you turn this on or off at runtime.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,
With a big warning that "it is an attack surface and less than
1% of people use it, please don't touch"? No thankyou.
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?
Maybe, but then, please mark every syscall with the aboveI'll be looking into testing and sending the patch that removesMy 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.
mark_screen_rdonly. Maybe then this thread will shift a bit from
guesses and assumptions.
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(),