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

41–50 of 408 posts

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

#41

Post by detaro »

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?

In the mail the quote is from, he lists security issues that can't fixed otherwise as one of the reasons exceptions happen.

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

#42

Post by bjourne »

John Johansen will survive. Linus has made it incredibly damn clear what "no user space regressions ever" mean. See f.e the similar rant from 2012: https://lkml.org/lkml/2012/12/23/75 And it is his kernel so it is his rules. John Johansen admitted he messed up (http://lkml.iu.edu/hypermail/linux/kernel/1710.3/02539.html) and promised to handle things better in the future so all is well.

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

#43

Post by wolfwyrd »

bonzini wrote: post #21
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 not clear to me either. From John's replies it also seemed to be an OpenSUSE bug. On the other hand, if it's bad enough it certainly makes sense to treat it as a kernel bug. The difficulty lies in finding where to draw the line.

It's laid out further in the thread [1]. The key quote comes from Thorsten:

> All that afaics doesn't matter. If a new kernel breaks things for people > (that especially includes people that do not update their userland) > then it's a kernel regression, even if the root of the problem is in > usersland. Linus (CCed) said that often enough

[1] http://lkml.iu.edu/hypermail/linux/kernel/1710.3/02487.html

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

#45

Post by delroth »

wolfwyrd wrote: post #43
bonzini wrote: post #21

Earlier quoted context omitted.

It's not clear to me either. From John's replies it also seemed to be an OpenSUSE bug. On the other hand, if it's bad enough it certainly makes sense to treat it as a kernel bug. The difficulty lies in finding where to draw the line.

It's laid out further in the thread [1]. The key quote comes from Thorsten: > All that afaics doesn't matter. If a new kernel breaks things for people > (that especially includes people that do not update their userland) > then it's a kernel regression, even if the root of the problem is in > usersland. Linus (CCed) said that often enough [1] http://lkml.iu.edu/hypermail/linux/kernel/1710.3/02487.html

Does that mean the kernel is not allowed to change version number anymore because I could write an app that segfaults if it sees Linux >= 4.14?

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

#46

Post by emeraldd »

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?

That's one of the specific exceptions he mentions.

    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.
i.e. the kernel may not do what it did before but your tool shouldn't crash. It may not have all the info you used to see though ...

Edit: fix styling

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

#48

Post by bluGill »

ChrisSD wrote: post #33
cesarb wrote: post #31

Earlier quoted context omitted.

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.

No, it is neutral from a security point of view: previously you couldn't configure the new thing at all, now you upgrade to where you can configure it, but isn't you didn't configure it the last time you configured everything (because you couldn't) so it default to as if you had enabled it. When you come back latter and think about this again you enable the new configuration with the right whitelist, but until then things work just as well as before.

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

#49

Post by chii »

piker wrote: post #38
__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 n…

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

if your app didn't used to handle the 'zero' case (assuming zero was a "valid" value for said field), then the app was poorly written and would'be been broken in the first place. However, if the app _did_ handle the 'zero' case, then the app continued to work! The end user would've been none-the-wiser about the change (mostly), and some time later, the app could be upgraded to ignore those known fields.

Causing a parse error would mean the app stopped working altogether. Much worse a result for the end user.

Post reply on HN