Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A regression is the kernel not giving the same result with the same user space

lkml.iu.edu

Post reply on HN
Print view View original

31–40 of 408 posts

Re: A regression is the kernel not giving the same result with the same user space

#31

Post by cesarb »

delroth wrote: post #19

As much as I think the general principle of "no userspace visible change" is great, I can't make up my mind on whom I agree with the most in this specific instance. My understanding is that some distros (e.g. OpenSUSE) ship with AppArmor in a whitelist mode where things have to be explicitly permitted by policy, otherwise they're denied by default. AppArmor introduced a new class of actions that wasn't there before,…

It's interesting to see how it works with SELinux. The Fedora distribution upgrades to a new kernel version often, so after a few months you start seeing lines like these in the kernel log:

  [   14.586798] SELinux:  Permission getrlimit in class process not defined in policy.
  [...]
  [   14.586887] SELinux:  Class infiniband_pkey not defined in policy.
  [   14.586888] SELinux:  Class infiniband_endport not defined in policy.
  [   14.586888] SELinux: the above unknown classes and permissions will be allowed
That is, the kernel part of SELinux supports more checks, but since the policy is old and doesn't know about them, they are allowed by default.

Re: A regression is the kernel not giving the same result with the same user space

#32

Post by grenoire »

teamhappy wrote: post #27
grenoire wrote: post #20

Earlier quoted context omitted.

You know what? I'm glad he is doing it this way. Hard to imagine the kernel getting to this point if he did not communicate and scrutinise like this.

> Hard to imagine the kernel getting to this point if he did not communicate and scrutinise like this. Not hard to imagine at all. He could exercise the same amount of authority without losing his shit and would get exactly the same result. It's one of his flaws and that's fine, but arguing that this kind of behaviour is somehow helpful is just ridiculous.

To me, it's just reminiscent of the movie Whiplash. Sometimes it helps to lash (excuse the pun) out.

Re: A regression is the kernel not giving the same result with the same user space

#33

Post by ChrisSD »

cesarb wrote: post #31
delroth wrote: post #19

As much as I think the general principle of "no userspace visible change" is great, I can't make up my mind on whom I agree with the most in this specific instance. My understanding is that some distros (e.g. OpenSUSE) ship with AppArmor in a whitelist mode where things have to be explicitly permitted by policy, otherwise they're denied by default. AppArmor introduced a new class of actions that wasn't there before,…

It's interesting to see how it works with SELinux. The Fedora distribution upgrades to a new kernel version often, so after a few months you start seeing lines like these in the kernel log: [ 14.586798] SELinux: Permission getrlimit in class process not defined in policy. [...] [ 14.586887] SELinux: Class infiniband_pkey not defined in policy. [ 14.586888] SELinux: Class infiniband_endport not defined in policy. [ 14…

That's not good from a security point of view but I guess it does avoid breakages.

Re: A regression is the kernel not giving the same result with the same user space

#34

Post by worldsayshi »

signa11 wrote: post #2

and later he clarifies it thusly: ''' People should basically always feel like they can update their kernel and simply not have to worry about it. I refuse to introduce "you can only update the kernel if you also update that other program" kind of limitations. If the kernel used to work for you, the rule is that it continues to work for you. '''

For user experience reasons that seems like a extremely sensible principle. But doesn't this make fixing some security issues impossible?

Re: A regression is the kernel not giving the same result with the same user space

#35

Post by vacri »

orcdork wrote: post #14

In any other kind of social/business arrangement he would be politely but firmly escorted out, possibly by security, for this kind of behavior. Being right or wrong is irrelevant.

You need to work in a wider variety of workplaces, if you genuinely believe that. Perhaps put another way: were Jobs or Ballmer ever escorted out for their obnoxious behaviours?

Re: A regression is the kernel not giving the same result with the same user space

#36

Post by vacri »

OJFord wrote: post #12
bauerd wrote: post #10

Earlier quoted context omitted.

These are normative, not descriptive statements.

How is it normative? Although that's a bit of a rabbit hole, since presumably you won't allow me to appeal to the definition of 'normative'. Torvalds lambasts a developer for making a mistake, swears at him, and tells him the first rule of kernel development is that you don't make mistakes. Great.

The first rule is that you don't break userspace, not that you don't make mistakes. Commits go through a process before being put into the kernel, and if yours is going to break userspace, it won't get in, so don't expect it to. You can make mistakes, but if they're found, you're expected not to say "well, commit it anyway". It's not the mistake that the violation of the rule, but the cavalier attitude.

Re: A regression is the kernel not giving the same result with the same user space

#37

Post by dangoor »

worldsayshi wrote: post #34
signa11 wrote: post #2

and later he clarifies it thusly: ''' People should basically always feel like they can update their kernel and simply not have to worry about it. I refuse to introduce "you can only update the kernel if you also update that other program" kind of limitations. If the kernel used to work for you, the rule is that it continues to work for you. '''

For user experience reasons that seems like a extremely sensible principle. But doesn't this make fixing some security issues impossible?

Linus calls out the fact that there are some times in which breakage is unavoidable, but that should only be after trying very hard to avoid breakage.

Re: A regression is the kernel not giving the same result with the same user space

#38

Post by piker »

__david__ wrote: post #24

Linus's followup post later on in the thread explains his position in more detail and is a pretty good read: http://lkml.iu.edu/hypermail/linux/kernel/1710.3/02487.html

Interesting.

> Behavioral changes happen, and maybe we don't even support some feature any more. There's a number of fields in /proc//stat that are printed out as zeroes, simply because they don't even exist in the kernel any more, or because showing them was a mistake (typically an information leak). But the numbers got replaced by zeroes, so that the code that used to parse the fields still works. The user might not see everything they used to see, and so behavior is clearly different, but things still _work_, even if they might no longer show sensitive (or no longer relevant) information.

I'm not sure I prefer the described result. If my application depends on some of those zero'd fields, it seems like that has potential to cause serious debugging problems, as opposed to just causing an error on the parse.

Re: A regression is the kernel not giving the same result with the same user space

#40

Post by masklinn »

worldsayshi wrote: post #34
signa11 wrote: post #2

and later he clarifies it thusly: ''' People should basically always feel like they can update their kernel and simply not have to worry about it. I refuse to introduce "you can only update the kernel if you also update that other program" kind of limitations. If the kernel used to work for you, the rule is that it continues to work for you. '''

For user experience reasons that seems like a extremely sensible principle. But doesn't this make fixing some security issues impossible?

From the followup message Kalleboo linked to:

> There have been exceptions, but they are few and far between, and they generally have some major and fundamental reasons for having happened, that were basically entirely unavoidable, and people _tried_hard_ to avoid them. Maybe we can't practically support the hardware any more after it is decades old and nobody uses it with modern kernels any more. Maybe there's a serious security issue with how we did things, and people actually depended on that fundamentally broken model. Maybe there was some fundamental other breakage that just _had_ to have a flag day for very core and fundamental reasons.

> And notice that this is very much about breaking peoples environments.

So breaking userland is possible if there is literally no other way, but

1. it's the "nuclear option "of kernel changes

2. it will be acknowledged as breaking users's environments

Post reply on HN