4 ms·

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 insta

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, and with these restrictive policies it's causing daemons to crash (because it gets auto-denied). The whole point of these policies is to not expose new attack surface if it's not needed by the software. It's going to break whenever AppArmor will start supporting more checks, unless policies get pinned to a specific version of AppArmor. But AppArmor doesn't currently support this (they refer to it as "features ABI" in the thread). WAI?

bonzini 9y ago
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.
- wolfwyrd 9y ago
  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 http://lkml.iu.edu/hypermail/linux/kernel/1710.3/02487.html
  - delroth 9y ago
    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?
    - Ntrails 9y ago
      You're just being disingenuous, what does that help? It's clearly an error on the part of the kernel if the owner of said kernel has specific expectations of behaviour on upgrade with respect to user spaces and those are not being met.
      - delroth 9y ago
        It is just as disingenuous as saying "details don't matter". bonzini's comment was saying a line needs to be drawn, and I agree with that. It's pretty clear the line needs to not include "breaking on version number updates", less clear what it also needs to not include.
        _jal 9y ago
        No, in fact, it is pretty obvious, at least to people doing kernel dev. The contract in this case is that there will always be a version number, and anyone who expects it not to change is an idiot or just being obtuse.
        bonzini 9y ago
        Well, I do kernel dev. I am the maintainer of KVM. :) > anyone who expects it not to change is an idiot or just being obtuse If this was the case, Microsoft would have never had to skip from Windows 8 to Windows 10 (see below in another comment: "starts with Windows 9" was used in the wild to detect Windows 95/98).
        _jal 9y ago
        Eh? The version number changed. MSFT just changed to something not completely predictable in advance. Or am I missing your point?
        bonzini 9y ago
        They _had_ to change it to "10" because there was existing code in the wild that misbehaved for a hypothetical Windows 9.
  - bonzini 9y ago
    And the other key quote from John: "It is a userspace configuration issue. Your userspace is set up to basically do policy development". The problem is that apparently this is true for all of OpenSUSE, Debian and Ubuntu, and that's when a userspace bug becomes in practice a kernel regression.
cesarb 9y ago
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.
- ChrisSD 9y ago
  That's not good from a security point of view but I guess it does avoid breakages.
  - bluGill 9y ago
    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.
  - coldtea 9y ago
    >That's not good from a security point It is. You get the security you explicitly ask for, no more, no less. If you want more, you get to know what new is there, and enable it.
brudgers 9y ago
The principal here is not technical, it is cultural. It exists to prevent the community from having to having to debate this class of pseudo-issue. There is reasonable logic on both sides and the choice of one or the other is somewhat arbitrary. Being part of the Linux kernel community means doing it in one arbitrary way and not the other. The convention provides organizational efficiency. This is an example of Torvaldes saying exactly what everyone knew he would say about the technical issue and knowing exactly what Torvaldes would say about the technical issue means core developers don't have to waste his time asking him and the feature developers don't have to waste the core developers' time asking them and those with limited commit rights don't have to waste time debating with people submitting outside patches. In the end, having a clear principal pushes people predisposed to argue their nonconforming point of view is valid or better toward the periphery of the kernel community because the behavior is deemed unproductive. The community operates because there is trust that people won't waste each other's time. That's the violation here...e.g. "three weeks".

bonzini 9y ago

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.

wolfwyrd 9y ago
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 http://lkml.iu.edu/hypermail/linux/kernel/1710.3/02487.html
- delroth 9y ago
  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?
  - Ntrails 9y ago
    You're just being disingenuous, what does that help? It's clearly an error on the part of the kernel if the owner of said kernel has specific expectations of behaviour on upgrade with respect to user spaces and those are not being met.
    - delroth 9y ago
      It is just as disingenuous as saying "details don't matter". bonzini's comment was saying a line needs to be drawn, and I agree with that. It's pretty clear the line needs to not include "breaking on version number updates", less clear what it also needs to not include.
      - _jal 9y ago
        No, in fact, it is pretty obvious, at least to people doing kernel dev. The contract in this case is that there will always be a version number, and anyone who expects it not to change is an idiot or just being obtuse.
        bonzini 9y ago
        Well, I do kernel dev. I am the maintainer of KVM. :) > anyone who expects it not to change is an idiot or just being obtuse If this was the case, Microsoft would have never had to skip from Windows 8 to Windows 10 (see below in another comment: "starts with Windows 9" was used in the wild to detect Windows 95/98).
        _jal 9y ago
        Eh? The version number changed. MSFT just changed to something not completely predictable in advance. Or am I missing your point?
        bonzini 9y ago
        They _had_ to change it to "10" because there was existing code in the wild that misbehaved for a hypothetical Windows 9.
- bonzini 9y ago
  And the other key quote from John: "It is a userspace configuration issue. Your userspace is set up to basically do policy development". The problem is that apparently this is true for all of OpenSUSE, Debian and Ubuntu, and that's when a userspace bug becomes in practice a kernel regression.

cesarb 9y ago

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.

ChrisSD 9y ago
That's not good from a security point of view but I guess it does avoid breakages.
- bluGill 9y ago
  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.
- coldtea 9y ago
  >That's not good from a security point It is. You get the security you explicitly ask for, no more, no less. If you want more, you get to know what new is there, and enable it.

brudgers 9y ago

The principal here is not technical, it is cultural. It exists to prevent the community from having to having to debate this class of pseudo-issue. There is reasonable logic on both sides and the choice of one or the other is somewhat arbitrary. Being part of the Linux kernel community means doing it in one arbitrary way and not the other. The convention provides organizational efficiency. This is an example of Torvaldes saying exactly what everyone knew he would say about the technical issue and knowing exactly what Torvaldes would say about the technical issue means core developers don't have to waste his time asking him and the feature developers don't have to waste the core developers' time asking them and those with limited commit rights don't have to waste time debating with people submitting outside patches. In the end, having a clear principal pushes people predisposed to argue their nonconforming point of view is valid or better toward the periphery of the kernel community because the behavior is deemed unproductive. The community operates because there is trust that people won't waste each other's time. That's the violation here...e.g. "three weeks".