Slashdot Mirror
Torvalds On Pluggable Security Models
eldavojohn writes "The KernelTrap highlights an interesting discussion on pluggable security models including some commentary by Linus Torvalds. While Torvalds argued against pluggable schedulers, he's all for pluggable security. Other members were voicing concerns with the pluggable nature of the Linux Security Model, but Torvalds put his foot down and said it stays. When asked why his stance was different between schedulers and security, he replied, 'Schedulers can be objectively tested. There's this thing called 'performance,' that can generally be quantified on a load basis. Yes, you can have crazy ideas in both schedulers and security. Yes, you can simplify both for a particular load. Yes, you can make mistakes in both. But the *discussion* on security seems to never get down to real numbers. So the difference between them is simple: one is hard science. The other one is people wanking around with their opinions.'"
He's right.
I've been wanking around with pluggable opinions for years, and I turned out okay.
If not, an artificial limit onto the integrity of the system would be created. Sure SELinux is a viable option, but why should we think it is the best ?
Walk with Music;
"But the *discussion* on security seems to never get down to real numbers. So the difference between them is simple: one is hard science. The other one is people wanking around with their opinions"
Thanks Linus, that cracked me up. I've always felt that way about a lot of the stuff the security guys do. I'm gonna forward that to our local security guys and see what they think!
I am government man, come from the government. The government has sent me. -- G.I.R.
I think Linus may want to think hard about creating a distinction there.
``...the subjectivist states his judgments, whereas the objectivist sweeps them under the carpet by calling assumptions knowledge, and he basks in the glorious objectivity of science.'' - I.J. Good
"oohhh... I didn't know Schopenhauer was a philosopher!"
I wasn't aware we'd completely solved problems of responsiveness vs throughput, or of normal vs soft realtime vs hard realtime.
/etc/fstab be removed?
If we don't keep scheduling modular, an artificial limit on the performance of the system will be created. Sure, CFS is a viable option, but why should we think it is the best ?
What's more, "wanking around with your settings" has often been what Linux has always been about. Ubuntu never uses chroot in a normal situation; does that mean it should be taken out? My GUI and hotplug utilities can automount anything I plug in; should
We haven't used anything but ELF for probably 5-10 years, yet, last I checked, a.out is still supported.
Why should the system be made non-modular?
Don't thank God, thank a doctor!
The moment I saw the word "scheduler".
Damn I'm sick of scheduler FUD. It makes its way into every single linux conversation now, now matter how unrelated.
Just disrupt the deflector shield with a tachyon burst.
That hot chick on Television who asks if I have worms, and sells antivirus software. That's one pluggable security model right there.
09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0 is the magic number.
His complete email reads:
Schedulers can be objectively tested. There's this thing called "performance", that can generally be quantified on a load basis.
Yes, you can have crazy ideas in both schedulers and security. Yes, you can simplify both for a particular load. Yes, you can make mistakes in both. But the *discussion* on security seems to never get down to real numbers.
So the difference between them is simple: one is "hard science". The other one is "people wanking around with their opinions".
If you guys had been able to argue on hard data and be in agreement, LSM wouldn't have been needed in the first place.
BUT THAT WAS NOT THE CASE.
And perhaps more importantly:
BUT THAT IS *STILL* NOT THE CASE!
Sorry for the shouting, but I'm serious about this.
Al I alone in thinking that Linux basically says:
"Look I'm no security expert, and I'd be happy to follow your collective expert guidance if only:
(a) you could quantify what you're saying and turn it into engineering instead of a religious argument
(b) the lot of you could agree on *one* set of guidelines/features as being best all-around
Unfortunately it appears you can't do either. That being so, I'm not going to burn my fingers and blindly choose one security boondoggle over all the others. I'll just make them pluggable so that every one of you can have his own personal security system. End of discussion. Now go away and be happy."
I mean, Theo's the security guy, right? I'm sure Linus would have no problem whatsoever agreeing to abide by his decision...
I can't videoconference, edit videos, make mp3s, play video games or make a slideshow in Linux. How about a couple of kernel devs drop off and help Linux go the last mile.
Other than video conferencing (haven't tried), my wife and 13 year old son can do everything on your list (using SuSE, Fedora or Ubuntu).
Shouldn't you be posting questions to http://www.linuxquestions.org/ or http://www.justlinux.com/ ?
You wont get a RTFM response.
Slashdot isn't a Linux help forum.
Enjoy,
It's just the normal noises in here.
Computer security isn't hard science? Someone should point Linus to the Orange Book or the Common Criteria.
This post expresses my opinion, not that of my employer. And yes, IAAL.
Correct me if I'm wrong, wouldn't a security plugin have to be authenticated? That would add a couple of extra layers not required for a scheduler. A "Rock Solid" built in security scheme might be better (Unlike the Windows address relocation method). Linus is correct in the fact that there is a new security method every week. Whats the correct one to choose?
/proc/sys/scheduler (if it existed). RedHat, Ubuntu, SuSE, etc. could set the defaults based on user selection at install (Work Station vs Server).
As for the Linux scheduler, I wouldn't mind a choice in desktop vs server tweak settings in (a)
Enjoy,
It's just the normal noises in here.
At some point, you have to deal with the fact that there is going to be some overhead in dealing with an object-oriented approach. Even if the significance is near 0, the scheduler is pushing operations on the CPU on an incredibly large scale, which might show its ugly face in performance. IMHO, it wouldn't, but I guess Linus knows better than I...
Anyway, there is this great site called the Linux Kernel Archives, which has the source code for every version of the Linux kernel ever put out. If somebody was really serious about using their own CPU scheduler, all they have to do is take the latest version of the kernel, download the source code and modify sched.c to fit their needs. Even if it isn't object-oriented, that doesn't change the fact that everything else in the kernel only cares that default_wake_function tries to wake up a thread - it doesn't matter how it works on the inside. All the other parts know about is the sched.h header file.
Sure, it isn't on-the-fly pluggable, but different distributions could easily use different schedulers if they simply compile the kernel. A distribution could make a sched.c that is pluggable (it would have an interesting look to it, but it could be done). I wouldn't want to debug it, but for all this complaining, you'd think somebody would do something about it.
My UID is a prime number. Yeah, I planned that.
Actually, that would be a security 'hole' now, wouldn't it?
I think there's some real irony here. Linus says that scheduling performance is "hard science" therefore it is easy to make a decision. But he did not make his scheduler decision based on "hard science" he based it on personal preference.
Ahh, the "when in doubt claim OO is expensive" defense. Please tell me, how long does a modern CPU need to take a branch to an address in a well known fixed memory cell which is guaranteed to be in L1-cache? Do you think it is longer than a conditional branch needed to handle the case single core dual core? Is it longer than the combined times needed to additionally handle the case one CPU-chip two CPU-chips? I don't know, I haven't done the measuring, but I have doubts the first is the slowest as the opcode scheduler should be able to handle the first and especially has the advantage of an always taken jump. We are heading in a parallel future, there are scheduling differences between single core/dual core and single CPU/multiple CPU. Why on earth should the scheduler written for the most complicated case (it has to handle cases like one dual core and two triple cores and one quad core efficiently or it is not the best scheduler, no?) be more efficient than a single core scheduler on a machine with only a single core? Or are the benchmarks "tweaked" so the first is the "right" case to benchmark?
As written by multiple posters, yes, you can get benchmark results for schedulers, but what is the correct benchmark? Is it the maximum throughput model you don't want to have as a desktop box or the minimum waiting time for interactive jobs you don't want on a compute server? And if you need numbers to come up with the best security model, count line numbers, it is about as relevant.
Never having used that software, I had a look at http://www.pidgin.im/about/. It says
Pidgin is an instant messaging program for Windows, Linux, BSD, and other Unixes.
How is a shortcoming of this software a shortcoming of Linux? You may be right to say there is no combined im/VOIP/video conferencing suites for Linux. Sounds strange to me, though. Perhaps you can make a feature request for Pidgin.
I'm sorry if I haven't offended anyone
The reason why the scheduler is so performance sensitive, is that it uses close to the worst case branching behavior possible. The following steps happen:
1. An interrupt occurs. The entire register set is pushed, page tables in the MMU are reloaded, and kernel code is executed. L1 and L2 cache are reloaded with kernel code and data.
2. Kernel code is executed. Hardware response issued.
3. Scheduler is executed. Per scheduling rules based on waiting processes, new process awakes.
4. New process executes. L1 and L2 caches reloaded. Page tables reloaded.
Massive amounts of CPU data are flushed and reloaded as the ISR / scheduler process executes. Additionally, the scheduler executes frequently. Sometimes the scheduler executes and changes processes once per interrupt, depending on what processes are waiting on what resources. Interrupt frequency significantly affects affects system performance, and the schedulers performance directly affects expensive activities like reloading the page table and reloading the L1 and L2 caches.
The last time I benchmarked the effect of interrupts on system performance, the numbers were like this:
At 1 kHz interrupt rate, the effect of a short background ISR on foreground performance was minimal. About 5% - 10%, depending on the computer.
At 10 kHz interrupt rate, the effect was significant (about 50%).
Between 20-30 kHz interrupt rate, almost all CPU time was being devoted to the ISR. Foreground processes almost stopped.
Testing was on a fast P-III machine or a slow P-4 machine. It has been a few years.
Modern multi-tasking 32-bit CPUs just can't handle very many interrupts per second. The problem is that both the L1 and L2 caches and the memory management tables get reloaded every time a major task switch occurs.
Even if the scheduling penalties were not significant, it is still not desirable to have a pluggable object oriented scheduler. A normal function call is:
CALL function_address
A call to a virtual function in an OO langauge is usually implemented as: // Indirect call
MOV EBX, vtable_address
CALL [EBX]
The OO code uses a fully indirect jump, which is significantly slower. However, the big issue is reliability. If the vtable accidentally gets clobbered due to bad code or a hardware fault, then the CALL instruction is a branch to nowhere. Your computer will crash. This fault is non-recoverable since it is in the scheduler itself. If instead we use the faster direct CALL instruction, we know that the scheduler always executes and hopefully some task will run (even if it is the wrong one.) Thus a reliability penalty is paid if we use an object-oriented pluggable scheduler approach.
For performance reasons, and for reliability reasons, it is a really good idea not to have indirect function calls in the scheduler code.