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.'"

Comments

Well

[homey of my owney]

He's right.

Re:Well

[QuantumG]

Linus is never right.

He's convincing.

Re:Well

[Trillan]

He is right, definitely But being theoretically able to measure something doesn't mean it's practical or the the results are always useful.

Re:Well

[Acrimonymous]

But, on the other hand, that's also not necessarily a reason not to do it.

Re:Well

[Anonymous Coward]

Who's this linux fellow you're talking about?

I feel sorry for him to have such geeky parents, though.

Re:Well

[HeavensTrash]

Linux is arrogant and clueless? I didn't know an OS could have human traits.

Re:Well

[Anonymous Coward]

as opposed to wanking around on slashdot complaining about Linus. I know what he has done for us lately, what have you done?

Re:Well

[Raineer]

No. Linux is not convincing. He is arrogant and more and more clueless. Unfortunately people seem to be so in awe of him, that allmost nobody is willing to tell him that he has he is "wanking around" about a lot of things he obviously does not really understand. What has been your contribution to the issue?

Re:Well

[Vellmont]

But being theoretically able to measure something doesn't mean it's practical or the the results are always useful.

The thing is that Linus isn't talking about the general case here, he's referring specifically to these two cases. If you've got some kind of performance consideration for scheduling that's not being measured, or have good evidence that the current measurements aren't relevant to the user experience, you should bring it up. If you're just speaking in a general philosophic way, that's nice and all but I don't see how it's relevant.

Re:Well

[rumblin'rabbit]

I've used lots of software that was arrogant and clueless. Hell, I've written software that was arrogant and clueless.

Re:Well

[Anonymous Coward]

No. Linux is not convincing. He is arrogant and more and more clueless. Unfortunately people seem to be so in awe of him, that allmost nobody is willing to tell him that he has he is "wanking around" about a lot of things he obviously does not really understand.

How would you sound if you had been herding cats for years? Linus refuses in this case to chose whether the user cats get their tuna from Starkist or Chicken of the Sea. This makes the cat from Starkist and the cat from Chicken of the Sea mad at him. The user cat gets handed a can opener and while they can chose either source they want some of them complain that they have to chose and open the can. In many cases the distro-cat makes the choice and forks out the tuna from their choice of cans to their user cats. Again, some appreciate the choice and others hiss and threaten to scratch with the target of their threats anywhere from the distro-cat to the security-cats or to Linus.

Every time Linus has a decision to make there are two or more tom-cats out screeching and raising hell on the fence outside his window. Sometimes the tom-cats are looking at him like he is a tabby and your suprised if every so often he throws a boot at the tom-cats?

Re:Well

[QuantumG]

Linux is a kernel.
Linus is an asshole.

Re:Well

[deek]

No. Linux is not convincing. He is arrogant and more and more clueless. Unfortunately people seem to be so in awe of him, that allmost nobody is willing to tell him that he has he is "wanking around" about a lot of things he obviously does not really understand.

You're not being very convincing either. You call Linus all sorts of things, without actually saying specifically why you think he is arrogant, clueless, and has no understanding. I'm open to the idea that he may be, but your post certainly does nothing to convince me of it.

At least Linus has specifically stated why he thinks security guys are "wanking around". It's because security people state that "only my version is correct", when they don't quantify exactly why this is the case. That certainly meets my criteria for "wanking around". Linus appears to have made a good judgement call.

Re:Well

[Amani576]

I like the cat analogy. And you make a very valid point, and one that makes me wonder why people are so pissed of at Linus. It's not like he's really telling anyone what they can or can't do. And hell, even if he is, whoop dee doo... it's Linux, if you don't like what he says to do, change it, put your own scheduler in and shut the hell up. The same goes for security. It's your own choice, much like using Linux and how you want it, over using Windows or Apple and having everything "picked" for you. Get over the ME ideas people... it's not about what YOU want... it's what EVERYONE wants. Linux is a democracy, with nice anarchistic undertones...
But whatever, I'll probably get modded a troll for this.
GR

Re:Well

[RK077208]

exactly, because everything have feelings in this world!

Re:Well

[Daishiman]

There is no security model that's better than others for all cases. They're all tradeoffs between convenience and security at the user level, and no, a security model is not quantifiable, as the amount of variation between specifications is mindboggling. Do you know the difference between RBAC, RAS, SELinux, AppArmor? Between the dozens of different and incompatible security systems used in AIX, Solaris, i5/OS, QNX, z/OS, and VMS? They all have their places, they all have their own advantages and disadvantages. Security doesn't stop with setting the "sticky bit".

But most importantly, security models are not CPU-intensive. Even the most demanding model will check file access permissions once in a blue moon in comparison to a scheduler. Schedulers store and use differnt information in very different ways which makes it difficult to make a generic framework that will support every possible datum they might need without making a significant impact on performance (it's a piece of code called thousands of times a second, performing rather complex computations).

Besides, it doesn't mean that Linux doesn't have several schedulers. It does, but they're kept under different branches, and they're sufficiently tunable to meet all your usual requirements, and CFS is a sufficiently superior alternative with the right stuff to warrant its maintenance in the mainline.

Re:Well

[phantomfive]

Didn't you know? Software wants to be free. Information wants to be anthropomorphized.

Re:Well

[yoprst]

I guess you've never been exposed to Windows

Re:Well

[wellingj]

Linus is an asshole.

But he's an asshole in a good way.

Re:Well

[earnest murderer]

Linus is an asshole.

But he's an asshole in a good way. Indeed, seconded. For that matter, from what I've seen if you don't harass or berate the man you don't get asshole Linus.
Even when you do, getting dressed down by someone who knows WTF is up and is goal oriented and not just fucking with you hurts more, but is less humiliating than the usual abuse we (people) take from know nothing assholes who just want to ruin you for shits and giggles.

Re:Well

[Anonymous Coward]

> Security doesn't stop with setting the "evil bit".

There, fixed that...

Re:Well

[zeromorph]

I think he wrote Clippy.

Re:Well

[ShieldW0lf]

No it doesn't. Information hates being anthropomorphized.

Re:Well

[SL Baur]

His job is to say "no" to ill-advised "features". Naturally, some people aren't going to like that. If you want ill-advised "features" stay with Microsoft Windows XP or whatever.

Saying "no" is the toughest job in the world, but in this case it's a bit different. If you read further down in the thread this article was quoted from, you'd see that the purpose of LSM was so that Linux could keep going forward rather than being engaged in endless security flame wars.

Security is hard and in my own experience MLS guys can be real assholes. I cannot fault Linus for the decisions he made. Based on my own reading of the Smack code, I would think it merits inclusion - it looks very clean.

Re:Well

[DrXym]

Linus is an asshole.

To some perhaps. To others he's just an effective team leader who makes decisions to focus efforts. The alternative is usually a lot of people flapping around like headless chickens since they don't know which way to go. Worse yet if the thing is run by an ineffective person or committee where development slows to a glacial pace because no patches are accepted or bogged down in protracted politics and debate. If you want to see what the kernel development would look like in those circumstances, look up XFree86, Emacs, Hurd etc.

Re:Well

[aproposofwhat]

Damn - just used my last mod point.

Nearly split my sides - funny and insightful!

Kudos to you, my good man :)

Re:Well

[ch0ad]

does *anybody* understand what "wanking" means?

or am i missing some other definition of it that means you can still have this conversation without images of nerds making sexy love to themselves?

Re:Well

[marcosdumay]

Near all my software is arrogant, but I try to make it cluefull :)

Re:Well

[mr_mischief]

Security is not a package. Say it with me now, "Security is not a package".

Security is a process. You make the effort needed to crack or crash a system beyond the value to the attacker, and they won't attack.

There's simply no need of SELinux in a coffee pot or an MP3 player. It's overkill. Linus is concerned with all the targets of the kernel, and not just the Sewper Seekret Survur next to the dresser in some kid's room.

Now _you_ might be using Linux to keep millions of credit card numbers or to process satellite intelligence for some national government, but that's not what everyone does with it. So long as there are reasons to focus more or less on security and different needs among those focusing on it, pluggable security models make sense.

For the vast majority of Linux targets, SELinux in particular is probably overkill. The scheduler effects everyone. If your main goal is security at all costs, use SELinux (it's not hard) or use OpenBSD instead of Linux.

Re:Well

[IT074552]

me too mate..that is awesome..

Re:Well

[Joebert]

Linux is a kernel.
Linus is an asshole.

If it takes one to know one, there's one thing I can't figure out, would you be Colonel or Captain Asshole ?

Re:Well

[DrSkwid]

funny, insightful and old

though the version I know is "don't anthropomorphize $objects, they hate that"

Re:Well

[DrSkwid]

wanking = self indulgence

Re:Well

[turbidostato]

"That's not leadership. It's not solid decision making. It's a lack of interest in taking responsibility"

I think Linus should read this and he, of course, would find it very agreeable since that's *exactly* how he defines his leadership model.

You can read it here (http://lwn.net/Articles/105375/), if you don't believe me.

Just look at its very first paragraph:

"Everybody thinks managers make decisions, and that decision-making is important. The bigger and more painful the decision, the bigger the manager must be to make it. That's very deep and obvious, but it's not actually true.
The name of the game is to _avoid_ having to make a decision. (...)"

Now, you can agree with his managerial style or not. Linus Torvalds provides the Linux kernel as an achievement of his managerial style, what will provide Mr. ShieldW0lf to counterargument?

wanking around

[Anonymous Coward]

I've been wanking around with pluggable opinions for years, and I turned out okay.

Re:wanking around

[thegrassyknowl]

I've just been wanking around for years because finding some one to plug into is just too hard as a bonafide nerd.

Re:wanking around

[ak3ldama]

by Anonymous Coward on Monday October 01, @06:47PM (#20817625)
I've been wanking around with pluggable opinions for years, and I turned out okay. So Linus Torvalds is this Anonymous Coward character that keeps showing up on /.

Spot on Torvalds...

[cez]

I think Torvalds is right on this one. Until we can quantify security as we can scheduling performance, which he argues for, why shouldn't he keep LSM modular?

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 ?

Re:Spot on Torvalds...

[gweihir]

Security cannot be quantified in hard numbers, since security is allways relative to the resources the adversary has. True, you could plan for some specific adversary. But that would be pretty meaningless. Also resources of an adversary is not a simple number that can be compared. Some thinks are limited to pecific attackers. Other stuff depends on money and/or time. Yet other stuff requires a specific type of competence. That is also why there typically is no "best" solution.

So, no, security folks are not "wanking around" as some specific asshole seems to claim, they are using the best tools available to evaluate adequacy of different security solutions. Those that do not get this are not getting what security is about and what the state of the art is. These people should better stay far away from security-relevant decisions and let people that at least understand present technology in that area make the decisions.

Re:Spot on Torvalds...

[QuantumG]

Blah. That's a totally backasswards way of looking at it. Why do you want to make something non-modular? Other than to make it hard for people to make competing implementations. No scheduler is optimal for all applications. You either make the scheduler modular so it can be replaced easily for a given application or you settle for less than optimal performance. Linus knows this too, so I don't know what game he is playing - probably trying to lock out that scheduler implementation that he doesn't like.

Re:Spot on Torvalds...

[Zigurd]

I don't think the pluggable security model is the controversial part. The controversy is about whether measures of scheduler performance are universal, or whether responsiveness metrics are different from, say, throughput metrics.

Re:Spot on Torvalds...

[Solra Bizna]

Yeah, because modularizing the scheduler doesn't have any performance or implementation or maintainance or QA problems.

-:sigma.SB

Re:Spot on Torvalds...

[SanityInAnarchy]

My question is not should we add pluggable everything, but why NOT?

Because that means more code to maintain. Code that might be broken later.

However, I do think there's sufficient reason to keep it pluggable. We have all kinds of other things pluggable that don't need to be, and plenty of other cruft in the kernel -- think binary formats other than ELF, old filesystems that nobody uses, and completely depricated systems like OSS for sound.

This reeks of politics, something I thought Linus was good at avoiding.

Re:Spot on Torvalds...

[cez]

So, no, security folks are not "wanking around" as some specific asshole seems to claim, they are using the best tools available to evaluate adequacy of different security solutions. Those that do not get this are not getting what security is about and what the state of the art is. These people should better stay far away from security-relevant decisions and let people that at least understand present technology in that area make the decisions.

"Wanking around" was a poor word choice at best, and I agree that people "that at least understand present technology in that area make the decisions". However, that doesn't invalidate his argument of modulization.

The best of present technology is modular to a certain extent, from a micro and macro perspective of system or network. Why implement a non-defacto standard of secure by including it in the kernel?

I've run SELinux, and I know that James Morris isn't stating he wants that exact implementation only, but he says choose one. How do we quantify that or any assertion and make an informed decision going forward knowing that there possibly is a more secure path to follow?

Re:Spot on Torvalds...

[Gorshkov]

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 ?

Bingo.

Security is, in fact, quantifyable - you can tell if your data is or is not secure in either absolute or relative terms. But that still misses one basic, very important element .... taste.

Yes, taste *is* involved in security. Just as there are many different ways to sort data, and still wind up with an alphabeticalized list, there are also many different ways to secure your data, and still wind up with it being safe.

I don't do the dishes the same way my daughter does .... but at the end of it, when either of us is finished, they're clean.

So the SELinux folks don't do THEIR thing the same way the LSM folks do .... but who cares? At the end of the day, the dishes are still clean .. assuming, of course, a certain level of competence. But then again, if you *don't* assume that, then no security framework is going to save your hide.

I'm sorry, but I see this as a religious war along the lines of vi vs emacs. Give both camps their tools and let them do things according to their environment, level of risk, and taste.

Re:Spot on Torvalds...

[cez]

Not arguing for his reasoning of adding scheduler to kernel space, just for his viewpoint that security should remain outside it as a module. You are right, "No scheduler is optimal for all applications", but that is something we can determine. How exactly are we to determine, hey that security module is much better for application X as this one is for Y.

besides bonfire tales from the bearded ones on peyote during burning man.

Re:Spot on Torvalds...

[fimbulvetr]

You're right, AFAICT, but you've missed the emphasis on "more" code. From what I've read, the scheduler's tentacles touch just about every portion of vital linux code and making something "pluggable" on the order of this would require an enormous amount of effort - effort that would be pointless for all but very small minorities that can apply a patch easily.

Indeed, it's also been showing (RTFML) that scheduler improvements are mostly trivial and generally don't warrant such an effort.

Finally, one must consider that the enormous amount of bugs being introduced by touching so many different areas and applying different algorithms in different cases.

Maybe this is something for consideration with the 3.x branch (Of which Linus has no intention of making), but it seems like a reasonable decision so far given the data.

Re:Spot on Torvalds...

[Vellmont]

Security cannot be quantified in hard numbers, since security is always relative to the resources the adversary has.

I don't think anyone is asking for hard numbers for some general case. I think people are just asking for numbers for some specific cases. Lots of things in computing vary with one factor or another. I fail to see why one or many factors changing the outcome of what "best" is means you can't supply hard numbers.

Not that I think that hard numbers on which security model is really possible. I think security is a soft science because you can't really run any controlled experiments. Those kind of situations are vulnerable to "But X is better, I SWEAR!" "NO! Y IS BETTER!" since there's no way of finding out in any objective way what the right answer is.


These people should better stay far away from security-relevant decisions and let people that at least understand present technology in that area make the decisions.

I guess I see that as the height of arrogance. If you can't demonstrate why one approach is better than another to someone as technically capable as Linus, I think he's taking exactly the right approach. Maybe there is some kind of true wizardry going on here, and we should just trust you all. But I've never been comfortable with simply the "trust us!" approach to anything.

Re:Spot on Torvalds...

[QuantumG]

Wow, Linus should go into politics. The point of the argument is that Linus refuses to make the scheduler modular. He's taken the argument that he isn't opposed to security modules being modular but he is opposed to the scheduler being modular and turned it around to say that he can't make the security modules not modular because there's no good metrics for determining which is better than the other. This is an irrelevant truth. The fact that you can measure which scheduler is better than another for a particular application supports the notion that schedulers should be pluggable modules.. so you can easily use the one which is most appropriate for the given application.

Re:Spot on Torvalds...

[RedWizzard]

So, no, security folks are not "wanking around" as some specific asshole seems to claim, they are using the best tools available to evaluate adequacy of different security solutions. Those that do not get this are not getting what security is about and what the state of the art is. These people should better stay far away from security-relevant decisions and let people that at least understand present technology in that area make the decisions. If you actually read the article instead of just reacting to the sensationalist quote you'd know that this is exactly what Linus is saying. Security people don't agree and he is not qualified to make a decision so modularization needs to stay. In the case of the scheduler he feels he is qualified to make decisions and has done so. However he does bemoan the fact that the arguments presented by the security experts often don't make a lot of sense. This is where the "wanking around" quote comes from.

Re:Spot on Torvalds...

[Kaenneth]

Even Microsoft knows by now, screwing with the sceduler is a bad idea... See the Vista/Gigabit/Audio issue, where because the system thread scheduler used a different 'mode' while playing multimedia content, it caused problems with high-speed networking.

Now, if we can only kill off Daylight Savings Time. (seriously, if you want to get up an hour earlier, just GET UP AN HOUR EARLIER)

Re:Spot on Torvalds...

[cez]

The fact that you can measure which scheduler is better than another for a particular application supports the notion that schedulers should be pluggable modules..

Ok, agreed... but, you can provide numbers to back that up. Statistics can always lie, regardless of if they are true. It's the fact that they are there and can be seen and visualized that is important. That being the case, it doesn't matter which way you lean towards schedulers. The fact that you cannot quantify security is an argument for keeping it modular.

Re:Spot on Torvalds...

[fabs64]

Did you even read the freakin discussion? The whole thing was about whether security should be modular, linus was arguing that it should stay modular, someone else was arguing that it should not and cited the scheduler as an example of linus preferring a singular option.

Re:Spot on Torvalds...

[FoxconnGuy]

The key here is you have metrics to measure performance of schedulers.

I think some of the key scheduler performance metrics includes:
1. Context switch time.
2. Fair scheduling
3. Interactive tasks are interactive.
4. Certain applications always get larger portion of time if needed.
5. Real time.

There are things called "parameters" that you can adjust to adopt Linux
to your need.

This doesn't say Linux scheduler is perfect. It is evolving, too.
A few years ago, many embedded systems that needs real time scheduler
can't be implemented on Linux because timing requirements. Now the
scheduler supports real time and I can still use any applications
without knowing what the hack they have done to scheduler.

Now.

Give me an example that Linux scheduler can't satisfy your needs, and,
Give me an example that one security architecture satisfies you and me.

Re:Spot on Torvalds...

[kocsonya]

Well, scheduling performance can only be quantified to a degree. When I'm editing a document while running two computationally and disk intensive tasks in the background (e.g big simulations) I don't really care if the background calculations will finish 5 minutes later, but I do care about the editor and every GUI thing I have on the screen being snappy, just as snappy as if there was nothing running in the background. I'm not running the latest&greatest, just some older version of 2.6.??? but that does not seem to be the case, as a matter of fact. So until the for example "perceived responsiveness" gets a firm definition and a method of quantifying it, scheduling performance is scientificly quantified only with the qualifier "..., neglecting all other factors that we can not quantify or care about."

Re:Spot on Torvalds...

[QuantumG]

it's called context my friend.

Re:Spot on Torvalds...

[cez]

yes but, using that context begs the question of why anyone would ever compare the operation of system security vs. performance to begin with?

Apples... Oranges...

Re:Spot on Torvalds...

[TheCoelacanth]

We have all kinds of other things pluggable that don't need to be, and plenty of other cruft in the kernel -- think binary formats other than ELF, old filesystems that nobody uses, and completely depricated systems like OSS for sound.

Those things definitely need to be modular. Unlike a scheduler, you can use multiple binary formats or filesystem types at the same time, you can't use two schedulers at the same time. What if someone comes up with a binary format that's much better than ELF? You probably want to support the new one without getting rid of the old one. For instance, modularity was obviously needed while people were switching from a.out to ELF. As for filesystems, there are so many filesystems that people do need that it would be crazy to try to support them all without modularity. As for sound, some systems don't even need sound, you need modularity to allow them to remove support for it. If you need plugability anyway, why get rid of modules just because few people use them. If no one uses them, no one will compile them, so they won't hurt anybody.

Re:Spot on Torvalds...

[kensan]

Why do you want to make something non-modular?

Modularity brings flexibility but also introduces new attack vectors. It is quite possible that one of these vectors undermines the whole effort to secure the system because an attacker only needs one succesfull exploit while the "defender" would need to avert and disable every possible attack route.

There are various issues with LSM but one concern is that its symbols are exported. Thus, every rootkit and backdoor writer will will be able to use these hooks.

Here are some interesting statements from security related projects and why they decided against supporting LSM: http://grsecurity.net/lsm.php, http://www.rsbac.org/documentation/why_rsbac_does_not_use_lsm

Re:Spot on Torvalds...

[Jay L]

Hah.. I'd read the whole thread and hadn't even thought about that question. Not a bad point. I mean, my word processor can use different fonts and colors, so why can't the scheduler?

Re:Spot on Torvalds...

[SanityInAnarchy]

Specifically, I remember reading about a case in which two contributors kept sending in patches that deliberately broke each others' code.

Linus simply stopped accepting patches from either of them until they sorted out their differences.

He could have chosen sides, but he didn't.

Re:Spot on Torvalds...

[SanityInAnarchy]

Hasn't the work already been done, though?

I understand that it needs to be maintainable, but I would think a flexible architecture would be MORE maintainable, not less.

(I admit that I don't have enough experience to make such a statement, at least about Linux and C.)

Re:Spot on Torvalds...

[SanityInAnarchy]

As for filesystems, there are so many filesystems that people do need that it would be crazy to try to support them all without modularity.

<sarcasm>They only think they need them. Really, they're just wanking around with their settings.</sacrams>

Consider if we only supported, say, ext3 for the root filesystem, and the only filesystem supported for mounting. Anyone who wanted to work on new and exciting stuff, like, say, ext4, would do so with a fork. Access to other filesystems, like network, ISO/UDF, and FAT/NTFS, can be done in userspace -- see the various userspace VFS projects -- they don't have to be fast anyway, since they're generally removable media, or stuff rarely accessed. Anyone booting from the network is probably running a custom kernel anyway.

These are all arguments I've heard people use against pluggable schedulers, which don't make sense here. After all, you can't have two root filesystems at the same time...

As for sound, some systems don't even need sound, you need modularity to allow them to remove support for it.

And some systems don't need pre-emptive scheduling. And some of them could certainly do better with a round-robin scheduler, so that more time is spent crunching and less is spent deciding what to do.

The point is that the main kernel maintainers are deciding what's important and what's not. I don't know enough to understand whether it's seriously problematic to implement a pluggable scheduling system, but this does not get to be dismissed as "not important", and certainly not as "people just wanking with their settings". Multiple schedulers are necessary, in some form, even if they have to be in separate kernel forks.

Re:Spot on Torvalds...

[TheCoelacanth]

Consider if we only supported, say, ext3 for the root filesystem, and the only filesystem supported for mounting. Anyone who wanted to work on new and exciting stuff, like, say, ext4, would do so with a fork. Access to other filesystems, like network, ISO/UDF, and FAT/NTFS, can be done in userspace -- see the various userspace VFS projects -- they don't have to be fast anyway, since they're generally removable media, or stuff rarely accessed. Anyone booting from the network is probably running a custom kernel anyway.

That would lead to major duplication of code. There would probably be a userspace implementation and a kernel implementation of every major filesystem. For instance, the people working on ext4 would most likely create a kernel implementation, because they eventually want it to be a replacement for ext3 on root partition but until it was mature enough to be widely used, there would still need to be a userspace implementation of it. The same would likely happen for many other filesystems, such as reiserfs, as well.

Re:Spot on Torvalds...

[cez]

lmao, you just made me wonder whether my scheduler would have a blue shift or red shift associated with it...

Re:Spot on Torvalds...

[SanityInAnarchy]

That would lead to major duplication of code. There would probably be a userspace implementation and a kernel implementation of every major filesystem.

Yeah. Sounds like ALSA/OSS.

In fact, there already are a few notable instances of this -- NTFS being the obvious example. The userspace NTFS implementation is actually much more robust and featureful.

Moreover, this is already true of every filesystem that I know of, to some extent. Remember that the userspace implementation need not provide everything the kernel implementation does -- even simple APIs to copy whole files in/out of the FS might be sufficient for most workloads.

But just how do you think mkfs.ext3 works? How about fsck.ext3? Or the various debugfs, dump, etc...

because they eventually want it to be a replacement for ext3 on root partition

More likely, they'd develop it as a replacement. They'd use UserMode Linux, and they'd probably start with the ext3 code, so ext4 need never be in a state such that it can't be used as a root FS, even if only for a disk image.

The same would likely happen for many other filesystems, such as reiserfs, as well.

More likely, ReiserFS would only be implemented in userspace. It's irrelevant -- using filesystems other than ext3 (or ext4) for your root filesystem is just wanking with settings, remember? You only need ReiserFS if some poor, uneducated soul happened to format their system with Reiser, then you have to use the userspace driver to back it up.

I imagine there are actually filesystems that have already moved to this level of support -- where the userspace utilities are really the only way of getting at the stuff, as all kernel support has been dropped.

Fortunately, there's still FUSE, but that's a big performance hit, and it does tend to invalidate your case against pluggable schedulers.

Re:Spot on Torvalds...

[TheCoelacanth]

Yeah. Sounds like ALSA/OSS.

There's a difference between allowing duplication and requiring it.

In fact, there already are a few notable instances of this -- NTFS being the obvious example. The userspace NTFS implementation is actually much more robust and featureful.

NTFS is also notable as a filesystem that no one running Linux wants to use for a root filesystem. The same cannot be said of ext3, ext4, reiserfs, or even relatively obscure filesystems such as JFS or XFS.

More likely, ReiserFS would only be implemented in userspace. It's irrelevant -- using filesystems other than ext3 (or ext4) for your root filesystem is just wanking with settings, remember? You only need ReiserFS if some poor, uneducated soul happened to format their system with Reiser, then you have to use the userspace driver to back it up.

Unlikely. Many people use reiserfs for their root filesystem. In fact, I believe it was the default in SUSE until recently.

Re:Spot on Torvalds...

[SanityInAnarchy]

There's a difference between allowing duplication and requiring it.

Indeed. Nothing about the system I proposed requires more duplication than we have, except for people wishing to run a different filesystem as root.

NTFS is also notable as a filesystem that no one running Linux wants to use for a root filesystem. The same cannot be said of ext3, ext4, reiserfs, or even relatively obscure filesystems such as JFS or XFS.

That's a fair point, but then...

Are you saying that what people want should dictate these decisions? Because if so, it seems plenty of people want the pluggable scheduler.

Unlikely. Many people use reiserfs for their root filesystem. In fact, I believe it was the default in SUSE until recently.

In that case, they get to run a patched kernel, and maybe not get updates, until they can either find a bootcd with a tool for migrating their data in-place (difficult to write for any filesystem), or they can back all their data up and restore it.

I seem to remember that Minix was, at one time, supported by the kernel. And I believe it's been removed, so anyone who was still using the original Minix or ext has to upgrade to ext2. And I believe ext2 is format-incompatible, meaning they had to back up and restore, though I could be wrong about that. I'm fairly sure ext4 will be incompatible, though.

Understand, too, that I'm playing devil's advocate here. I'm perfectly happy with pluggable filesystems, although I'm not particularly happy that so much of the filesystem is in the kernel, or that context switches are slow enough that it makes sense for them to be there. I'm just using it as a basis for explaining why I think pluggable schedulers might be a good idea.

Although there was another reply, kind of buried by now, maybe, pointing out that CFQ is very tunable and supports somewhat more limited plugins of its own. That would suggest it's more like replacing the Linux VFS with Reiser4 (and implementing existing filesystems as Reiser4 storage plugins), although I wouldn't recommend that either now, as unstable as Reiser (filesystem and person) can be.

Re:Spot on Torvalds...

[fimbulvetr]

I'm going to refrain from answering authoritatively, as all I do is read the malling list to learn. I would think, though, based on what I've seen, that the work hasn't been done in terms of pluggability. The work has been done it patches for applying different schedulers, but I suspect making it modular is a substantially different beast.

Maybe i dont get the point

[mrwolf007]

... but what would happen if you forgot to "plug in" a scheduler?
Back to single tasking ala DOS?
Being able to choose which (if any) security module to plug in seems to make a lot more sense.

Re:Maybe i dont get the point

[fadilnet]

If that is so, should there be @ least 1 scheduler provided as default? I mean, who wants to end up with an uncompiled kernel? In no time, we'll end up with different versions of kernels, forks of plugins, and we'll end up in a pit of compatibility issues. A default one can be used as part of the failsafe.

Re:Maybe i dont get the point

[AngryLlama]

He is double bluffing an email address snarfing bot. Good for you

Awesome

[obeythefist]

"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!

Re:Awesome

[jofny]

If they're any good, they'll agree with him...security is fundamentally subjective (what you want your box to do vs how much what you have on it is worth vs etc)

Re:Awesome

[poopdeville]

Security, fundamentally, isn't one single thing. It is many. A process. A methodology. A result. Objective. Subjective. Actual. Perceived. False.

Until you understand how it can be all those things at once, please don't comment on what security "fundamentally" is.

Re:Awesome

[Kjella]

I'm gonna forward that to our local security guys and see what they think!

I think someone missed the memo with "don't piss off the guys that could make your life hell". Have you any idea how quickly everything would come to a grinding halt if they were really anal about applying every detail in the security policies? No, I don't mean the normal terror regime, I mean the kind that'd actually kill the business and force change if they ever tried to apply it company-wide. Now, instead imagine that they make a point of applying it just to you...

Re:Awesome

[jofny]

That didnt make a whole lot of sense as a response to me and was trolling a bit, but Ill bite (waiting for a meeting).

You're mixing types here and -fail- at logic. Process and Methodology are synonyms. Results can be from processes and methodologies. Results can be both objective and false/actual/perceived all at the same time. Etc. Were you trying to say "security is a lot of different things"? Thanks captain obvious.

SECURITY is (especially because of the obvious truth you pointed out) a concept with a subjective root: Ie, If I dont want anyone else to access the machine but me, my concept of what it means to secure the box is completely different from someone who runs a honeypot.

And while the fact that Im an enterprise security architect for a large organization (among other things) isn't a guarantee that I know wtf Im talking about, it's a pretty good indication that I have the basics down right :P

Re:Awesome

[obeythefist]

Hilarious, considering I have the same credentials than they do and I know which OU's are exempt from policies anyway. I like how they strut around so self-importantly despite this. If they even tried such a half-arsed scheme I'd be revoking their access to the domain quicker than you can blink. I'd cite a security threat to make it more amusing.

Your comments have thus proven Linus's original comment perfectly valid. Security guys are wankers.

"don't piss off the guys that could make your life hell"

No... don't piss off the guy who administers your account and domain, owns your boxes and allows you to run your little FBI-CIA-NSA wannabe security empire.

Re:Awesome

[poopdeville]

You can accuse me of failing at logic, but it doesn't make it true. For one thing, you mixed up the "types." The security model for pluggable security models is of the "provable security" type. There is a fact of the matter whether a particular model fits a specification -- ACLs can fit any specification, by construction. There is a fact of the matter whether a particular model or implementation can be breached by an adversary, even with infinite resources. (And the answer need not be 'yes'). There is nothing subjective about this. Moreover, if implemented by a third party, using a particular open source security model costs you nothing.

'Process' can be synonymous with 'methodology', but need not be so. A process can be an on-going activity. A methodology is not understood to be an activity at all. You fail at English. My apologies if it isn't your native language, but you should really get to know the language better before criticizing others' use.

Your honeypot example is rather lame. Both "concepts" are going to be "No adversary should gain access to any resource unless implicitly or explicitly authorized to use it".

Re:Awesome

[jofny]

There are legit responses to the rest of your comments, but to keep it simple let's get to the heart of it:

There is a fact of the matter whether a particular model or implementation can be breached by an adversary, even with infinite resources.

"No adversary should gain access to any resource unless implicitly or explicitly authorized to use it".

Both of these are true. But they both assume someone has (subjectively) identified which resources to protect and how much cost/effort should be spent to protect them. Without those subjective decisions, security models are irrelevant

Re:Awesome

[poopdeville]

Both of these are true. But they both assume someone has (subjectively) identified which resources to protect and how much cost/effort should be spent to protect them. Without those subjective decisions, security models are irrelevant

Regarding your second point: As I mentioned, cost/effort is irrelevant in the case of computer security, unless there are very particular circumstances. Encrypting your communications using AES-256 will cost you nothing more than AES-128 will, in most circumstances. Using a one provably secure framework over another will cost you nothing, aside from ease of use in setting them up.

Regarding your first point: I will grant that much. But this is a much weaker statement than you seem to think it is, in the context of our discussion. In particular, you will find that the resources that people subjectively decide to protect are the resources that objectively need protection.

like object oriented?

[fadilnet]

It sure does like an object oriented approach. If the scheduler and other 'components' can be made pluggable, then it eases up the tasks of many. Developers can focus on 1 aspect of the OS, while the core kernel is just there to 'receive' the 'plugin'. How does it differ from the current approach? Are there too 'components' dependent on each other?

Re:like object oriented?

[ASBands]

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.

Re:like object oriented?

[Josef Meixner]

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...

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.

Re:like object oriented?

[marcosdumay]

"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."

Says somebody that, it seems, never tried that on real life.

Good luck with any functionality change in sched.c. And if you really want to mess with the scheduler, not thread wake up, I really desire you a lot of luck to keep the information you need without breaking any unrelated part of the kernel.

Re:like object oriented?

[Cassini2]

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?

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:
MOV EBX, vtable_address
CALL [EBX] // Indirect call

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.

Re:like object oriented?

[Josef Meixner]

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:

MOV EBX, vtable_address
CALL [EBX] // Indirect call

And why would that be relevant in this case? The kernel is written in C, not an OO language so it would have to be simulated in any case. What I would do is to define the interface as a sequence of jump slots. Then when a scheduler is "instantiated" just drop the new jump commands to the scheduler "methods" there. I don't see any reason why I would ever want to use two instances of the scheduler at the same time. When one is created the other can be destroyed. If I want to use two schedulers I would have to write a scheduler scheduler (and I doubt there is anything to be gained down that path). So what you would have instead of the direct call

CALL function_address

is an indirect call:

CALL [function_address]

where the address and also the location to jump to is very likely in L1-cache as it is used very often.

Sorry, I don't see how you get a magic kernel fault only affecting a very specific cell (the vtable). If something in the kernel starts to write to random memory cells, I would call it "reliable" if the system notices the problem, localizes the problem and solves the problem. I would much rather prefer fail-stop behavior (kernel panic).

Cold Hard Engineering Measurement, or Science?

[Alexander]

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

So we can quantify scheduling performance?

[SanityInAnarchy]

I wasn't aware we'd completely solved problems of responsiveness vs throughput, or of normal vs soft realtime vs hard realtime.

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 /etc/fstab be removed?

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?

Re:So we can quantify scheduling performance?

[cez]

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 ?

You are right, there always could possibly be a faster scheduler for a given system / task / embedded system.

One analogy however malformed uneducated and abysmal is:

Sure, it would be cool if you put NOS kit on a ferrari, but once you hit a wall it won't matter if you are going 150 or 225 if you aren't wearing a seatbelt or there are no airbags.

Re:So we can quantify scheduling performance?

[Jah-Wren Ryel]

I wasn't aware we'd completely solved problems of responsiveness vs throughput, or of normal vs soft realtime vs hard realtime. And I don't think we ever will. I think Linus's point that scheduler performance can be measured is the strongest reason to go with pluggable schedulers. I want the scheduler that performs best for the way that I use my system. I don't think anyone gives a ratsass about how well the scheduler works for someone else. I want it to work best for me and my workloads.

Re:So we can quantify scheduling performance?

[mrwolf007]

I wasn't aware we'd completely solved problems of responsiveness vs throughput, or of normal vs soft realtime vs hard realtime.
Hard realtime usually implies severe perfomance penalties. People who really need something like that probably dont use a vanilla kernel.

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 ?
Torvalds usually doesnt care about something being the best. Its supposed to be good enough.
Using the word best requires you to say for what, otherwise you might as well use a word such as coolest, most geeky, most whatsoever.
Since Torvalds usually cares a lot about efficiency i guess that a plugable scheduler would be less performant.

Re:So we can quantify scheduling performance?

[msuarezalvarez]

Torvalds usually doesnt care about something being the best. Its supposed to be good enough.
Using the word best requires you to say for what, otherwise you might as well use a word such as coolest, most geeky, most whatsoever.

So one is required to say for what something is best for, but not for what something is good for?

Maybe you want to think about this a bit more?

Re:So we can quantify scheduling performance?

[mrwolf007]

So one is required to say for what something is best for, but not for what something is good for? Maybe you want to think about this a bit more?
Not really.
I dont have a problem with the scheduler.
I think most people dont have a problem either.
My guess would be that less than 1% of the people using the kernel would need something better, but i think they would actually mean something more specialised for a certain scenario.
So i think its fair enough to say the scheduler is good enough (though you may add "for common load scenarios and uses", if you want to be pedantic).

Re:So we can quantify scheduling performance?

[cmat]

No, Linus' point about schedulers is that to make a pluggable scheduler, you will need to sacrifice performance just to achieve the plug-ability. Linus believes that the most flexible scheduler (i.e. performance, tune-ability) can be discovered at development time with a set of metrics that are defined currently. In which case he feels that the kernel devs can make the "best" choice of scheduler up front. Yes there will be fringe cases, in which case, you have the code, replace/tune/massacre the scheduler to your particular needs.

The security realm however is completely different. For one, the performance requirement does not exist. So the performance penalty that modular architecture brings is largely irrelevant. And since there exist no metrics that can be used to determine whether one security model is better than another without the usage context, a plug-able architecture is the best road to go down to let something that users CAN and WILL want to implement completely differently from one use-case to the next.

Re:So we can quantify scheduling performance?

[msuarezalvarez]

Well, I was commenting on the format structure of your argument: my point is, if you are required to say what something is best for, I see no reason why you should not be able to be required to say what something is good for. Your reply may be cogent or not, I really do not have a strong opinion. I was only pointing that you may want to find a stronger argumentation.

Re:So we can quantify scheduling performance?

[SanityInAnarchy]

No, Linus' point about schedulers is that to make a pluggable scheduler, you will need to sacrifice performance just to achieve the plug-ability.

If it had to be hot-pluggable -- as I believe some of these are -- then yes.

But just run "make menuconfig" and take a look at the insane number of options you have for compiling a Linux kernel. It seems to me that slapping some #ifdef statements around some code isn't going to make it perform any worse.

It might, however, be harder to maintain.

For one, the performance requirement does not exist.

In security? Yes it does!

I mean, yes, we'll often choose the more secure model over the better-performing one, but not always. Consider the performance implications of, for example, trying to predict every possible state a program could be in, so you could determine whether or not to run the program -- programs which might possibly do things they aren't allowed to never get run in the first place.

Obviously, we don't do that. We do the analysis at runtime -- when a program attempts to do something it's not allowed to, we block it then, we don't try to predict it happening.

And since there exist no metrics that can be used to determine whether one security model is better than another without the usage context, a plug-able architecture is the best road to go down to let something that users CAN and WILL want to implement completely differently from one use-case to the next.

Except from what I understand, SELinux and ACLs are a superset of traditional Unix security, and could, in fact, completely replace it (and emulate it). So why not make SELinux the only security architecture?

Re:So we can quantify scheduling performance?

[SanityInAnarchy]

Hard realtime usually implies severe perfomance penalties. People who really need something like that probably dont use a vanilla kernel.

True enough, or at least, they don't use a kernel compiled with vanilla options.

Using the word best requires you to say for what, otherwise you might as well use a word such as coolest, most geeky, most whatsoever.

The whole point of wanting a pluggable scheduler is to let the end-user answer that "for what" question, instead of having Linus answer it for you, or have to use a fork.

I don't argue that it has to be pluggable at runtime, and though I haven't been following this, I suspect that "at runtime" is what would slow down the architecture. Because if it's just another menuconfig option, that slows down development, not execution.

I stopped reading TFA

[kwabbles]

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.

Re:I stopped reading TFA

[Dr. Evil]

You'll reprioritize when your starving children become zombies and your parent tries to kill you.

What about

[sokoban]

That hot chick on Television who asks if I have worms, and sells antivirus software. That's one pluggable security model right there.

Re:What about

[goombah99]

I'll wank to that!

Re:What about

[ScrewMaster]

That hot chick on Television who asks if I have worms, and sells antivirus software. That's one pluggable security model right there.

Yes, but that's an iterative solution with a known end condition.

yawn

[kennedy]

c'mon - this is open source.

why not have both? linux-smack and linux-selinux could co-exist. fork the kernel and find some people to maintain an selinux fork - there has to be some out there if there's front-page worthy drama going on...

How's THAT for a pluggable security model?!

(yeah i rtfa'ed... lulz)

Language abuse

[midnighttoadstool]

"Wanking" is rough-slang English from England, and means 'masturbating'. But Torvalds sure ain't one of us.

Re:Language abuse

[theNeophile]

"Wanking" is rough-slang English from England, and means 'masturbating'. But Torvalds sure ain't one of us. All of the other words he used also come from England. How dare he!

Re:Language abuse

[Mjlner]

"Wanking" is rough-slang English from England, and means 'masturbating'. But Torvalds sure ain't one of us.

Speaking as someone from the same demographics as Linus, I can assure you that he's familiar with the meaning of the word. It makes sense to him (and to me) and, yes, he is definitely expressing an opinion. He said what he meant and he meant what he said.

Re:Language abuse

[midnighttoadstool]

"He said what he meant and he meant what he said."

Just like a private, except that he's a general.

Re:Language abuse

[CortoMaltese]

Speaking as someone from the same demographics as Linus, I can assure you that he's familiar with the meaning of the word. Newsflash! Two nerds are familiar with wanking.

If you read all of it ...

[golodh]

Perhaps if people read all of Linux's email they would be more understanding and less quick to condemn him.

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."

Re:If you read all of it ...

[TubeSteak]

FTFA

LSM's weak semantics and pervasive deep hooking of the kernel means that
> we'll have to continue dealing with several unpleasant issues, such as the
> abuse of the API by out of tree vendors, Exactly what kind of API abuse are they talking about?

Re:If you read all of it ...

[Anonymous Coward]

I'll never understand why Linus Torvalds can belittle the developers contributing to the kernel and be praised as a passionate and pragmatic engineer while Theo de Raadt gets schoolyard insults hurled at him every time he voices an opinion (which is admittedly quite often, but no more often than Mr. Torvalds).

This is a quintessentially pragmatic decision (if you can't get people to agree make it so that everyone can make the decision for him or herself) but done in what I feel is very rude manner. Look back at many decisions made around OpenBSD, especially as they relate to security policy, and you'll see the same thing.

The "let everyone decide for themselves" mentality is also very different from the stance Mr. Torvalds took on choosing GNOME over KDE ("The GNOME attitude is a disease. Just tell people to use KDE.") In that case he displayed exactly the hubris Mr. de Raadt is constantly accused of.

So at the end of it all, please tell me: Why do two people with very similar attitudes get labeled by the community so differently?

Re:If you read all of it ...

[QuantumG]

Actually, I think it is because Linus has this whole "exotic foreigner" aura that Theo doesn't. Just listen to people go on about how Finish people tell-it-how-it-is and laugh at others' misfortune as a matter of culture. Call upon the political correctness of moral relativism and all will be forgiven.

Re:If you read all of it ...

[Ari Rahikkala]

Perhaps if people read all of Linus's email they would be more understanding and less quick to condemn him.

If I could read all of Linus's email, I think I would be more understanding of him wanting to be able to work with security models :p.

Re:If you read all of it ...

[IT074552]

u really got a nice opinion about what u are talking about.i'm really agree with u since we human got to be given choices in our life.why have we follow what others thinking or way to get something?n as reminder,not all user can be expected like technical user.this is wrong thinking.

Bring deRaadt in for a consult

[e9th]

I mean, Theo's the security guy, right? I'm sure Linus would have no problem whatsoever agreeing to abide by his decision...

Re:Bring deRaadt in for a consult

[Anonymous Coward]

Last week there happened to be a discussion on the OpenBSD mailing list about SELinux. See http://marc.info/?l=openbsd-misc&m=119047563000795&w=2/

Re:Good.

[webmaster404]

Well I agree that there needs to be better applications for Linux, however your reasons are incorrect. I don't know of an application for videoconferencing off the top of my head because I don't use that, for editing videos try KDENLIVE http://www.kdenlive.org/, for MP3s thats simply a patent restricted format, just tell your government to reject software patents, for video games try to run your windows games in WINE and there are many Linux games, try some of those, just because its not 3-D doesn't mean that its bad. And OOo has a sideshow presentation software included with it.

Re:Good.

[NullProg]

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,

"wanking around with their opinions"

[PaulGaskin]

Who died and made Linus captain of the anti-wanker task force?

Torvolds declares war on physicists!

[NemoinSpace]

You're acting like a string theorist, claiming that there is no other viable theory out there. Stop it. It's been going on for too damn long.

I read as much as I could, till I realized Linus was going to go off on another tirade on people who are presenting their arguments to him. He starting to make Balmer look reasonable. Go ahead, piss off the physicists - Now _everyone_ will stop using linux. :)

Re:Good.

[Salsaman]

Can`t edit videos ? What do you think LiVES is ? A word processor ?

Ahem

[deblau]

Computer security isn't hard science? Someone should point Linus to the Orange Book or the Common Criteria.

Re:Ahem

[GreatBunzinni]

A normalized set of procedures to perform measurements does not a science make. If it was so then phrenology would be almost a pure science.

Re:Ahem

[mapsjanhere]

The first step to science is reproducible data. Phrenology does that. The second step is meaningful interpretations based on established or verifiable principles. That's where phrenology fails. But that still makes it better than string theory, which manages to exist with no data at all.

Scheduler vs Security Plugins

[NullProg]

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?

As for the Linux scheduler, I wouldn't mind a choice in desktop vs server tweak settings in (a) /proc/sys/scheduler (if it existed). RedHat, Ubuntu, SuSE, etc. could set the defaults based on user selection at install (Work Station vs Server).

Enjoy,

Re:Scheduler vs Security Plugins

[Anonymous Coward]

Correct me if I'm wrong, wouldn't a security plugin have to be authenticated? You're wrong, it doesn't need to be authenticated in the way you're inferring.

Only root can load new kernel modules, so you'd have to have the highest permissions to load a new security module into the kernel at runtime.

The integrity of the security module binary would of course depend on your distribution and how you receive new updates over the internet, as well as the security of your file system (permissions should be correctly setup on your filesystem).

Having signed security modules is possible (but is optional, completely isolated and redundant in most cases). This isn't Windows where you are forced to have signed kernel modules/drivers while attackers can work around your security in other ways (patching the binary on your system which does code signing validation, adding new rogue certificates to your certificate store, etc).

Re:Scheduler vs Security Plugins

[TheCoelacanth]

Plugable doesn't necessarily mean that it has to be a module. Almost everything in the kernel can be built directly into the kernel.

If you're referring to pre-compilation, I believe Torvalds already signs the kernel sources.

Ew, redundancy...

[SanityInAnarchy]

has often been what Linux has always been about.

Yay for creative grammar... I apologize to anyone else who caught that. Preview is not my friend today :(

Re:Linus is a foreigner

[obeythefist]

I'm Australian. On that basis therefore I choose to trust Linus implicitly.

Re:What does Linux Torvald know about modularity?

[ScrewMaster]

please type the word in this image: frontal [lobotomy???]

This is Slashdot. Nudity.

Re:Good.

[Eli Gottlieb]

You can definitely edit and make MP3s under Linux. The application I run on my OSX laptop for that purpose, Audacity, was originally written for Linux and then *ported* to OSX.

Phew.

[crhylove]

I knew my karma would get kicked in the teeth over this, but seriously, why can't I just right click on a Pidgin buddy and instantly h.264 and speex to a buddy online? Linux needs to "just work" out of the box, and it still needs a LOT of polish.

rhY

Re:Good.

[crhylove]

I wasn't saying it was IMPOSSIBLE. I'm saying it is difficult and cumbersome. Please review my earlier comment about Pidgin and video conferencing.

rhY

Re:Need to plug goatse

[Zathruss]

Actually, that would be a security 'hole' now, wouldn't it?

irony

[cycoj]

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.

Re:irony

[rawler]

Actually, he based it on previous relations with his maintainer. Right or wrong, that was probably the no.1 reason.

Wanking

[olehenning]

Linus Torvalds lecturing other people on wanking with their opinions. That's almost as funny as George Bush talking about education and literacy.

No, he doesn't understand

[CarpetShark]

Actually, this tells me he doesn't understand one or the other. The only difference between scheduling and security numbers is how you measure. Security can be measured too, if you know what you're measuring -- number of attackers who gain access, number of attacks detected, compromises detected, etc. It's just the same in scheduling -- you can measure scheduling IF you know what you're measuring: realtime desktop performance, IO performance, etc. But similar conflicts arise in both: realtime latency vs. maximum IO bandwidth; hackers prevented from accessing a secure system vs. legitimate users locked out, etc.

Pidgin

[upside]

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 like this guy

[Dagda]

You know, the more I read about Linus and come across his statements, whether others agree with him or not, I do like his frankness.

Re:Need to plug goatse

[IT074552]

a 'hole'?why i'm suddenly like not gud feeling bout it..foget it,let's be on right path now.

Ecosystem diversity

[KJACK98]

From a diversity point of view, its better to have a pluggable security architecture, in the event an application and security architecture was able to be compromised it might be limited to that distro (ie. Redhat = SELinux, Ubuntu = AppArmour).

The points

[gryyphyn]

I do agree that he is right. However there are valid arguments on both sides. SELinux's integration with the kernel is a fantastic feature. I haven't seen any overhead as far as system performance, but it makes it difficult to simply work on the system, either directly or in the sense of remote access to resources (files, ssh, etc...). I don't know much about LSM, to be honest, but there are some advantages that I can see off the line. Configuration is much easier and there's less interop problems (again, from the little I've seen). However removing the kernel integration to such a degree may slow system performance. No security implementation should cause a great deal of overhead. Linus made a fantastic point:

You security people are insane. I'm tired of this "only my version is correct" crap. The whole and only point of LSM was to get away from that. And anybody who claims that there is "consensus" on SELinux is just in denial.

Fights, arguments and disagreements in the security world will never end. Security people would like nothing more than to close and/or disconnect everything. The question, in my experience, most often voiced by security 'gurus' is "do you really need that?". I'm tired of hearing it. Yes, we do need it. SELinux was developed by the government entities with RedHat. Leave it there. I think we do need something else.

Prove it....

[fuliginous]

There is no security model that's better than others for all cases.

Prove it. Hold on didn't someone say the lack of empirical evidence is the whole basis of the problem and Linus argument?

Re:Good.

[MrCopilot]

I can't videoconference, edit videos, make mp3s, play video games or make a slideshow in Linux.

Just because you can't does not mean Linux can't.

VideoConference http://ekiga.org/

Edit Video http://www.kdenlive.org/

Make mp3s: Insert CD copy mp3 folder with kde.org or Create new with http://audacity.sourceforge.net/

play video games with http://www.winehq.org/ or http://www.transgaming.com/ or god forbid you play open source games designed for linux. Too many to list see here http://icculus.org/lgfaq/gamelist.php for a start.

make a slideshow, Ever use http://picasa.google.com/linux/ or KDE creates them on the fly from directory of pictures. Not to mention openoffice Impress http://www.openoffice.org/product/impress.html

How about a couple of kernel devs drop off and help Linux go the last mile.

How about you let the kernel devs do what they do best, and acquaint yourself with a little thing I like to call Google http://www.google.com/webhp.

Re:Good.

[MrCopilot]

My wife walked in just as I was posting my reply. She said what are you doing? I said someone else's homework, I read her what you said. She said and I quote "Loser, go back to windows." She is completely non technical.

Maybe not as helpful, but it cracked me up.

Possibly

[ta bu shi da yu]

He's convincing to server obsessed performance mavens. Desktop users don't get a look in.

Re:Irony?

[jack455]

I've been happily not paying for software or support for years. I guess that does affect the price of software. I love hippies.