5 ms·

There are three things I expect to find in mailing list discussions before going off and reading them: * Someone suggests that the kernel return EINVAL for nul

• nikanj 3y ago
  The last point ("we don't break userspace") has always been a core tenet of Linux. Linus essentially refuses to alter kernel behaviour just to be "correct" according to POSIX lawyers
  • JdeBP 3y ago
    No, that would be the first point. The last point is retaining the status quo simply for the sake of it, which sometimes happens but quite often does not, or out of a misinformed idea of what historically has actually been the case, which happens sometimes too. It's worth noting that being correct according to the SUS would have avoided the problem, since the SUS calls out the applications-code assumptions that cause the vulnerabilities in its rationale.
  • arp242 3y ago
    Linux does break userspace; either when no one would notice (in which case it's arguably not really "breakage") or when there's a serious enough issue that really can't be resolved in any other way. "Don't break userspace" is a hard rule, except when it's not. The question here is: will anyone notice the breakage? And is this a serious enough issue to risk it?
    • denotational 3y ago
      > either when no one would notice (in which case it's arguably not really "breakage") This is the idea, but the Kernel maintainers aren’t omniscient, so “no one would notice” really means “the maintainers don’t think anyone would notice”, and this ends up being somewhat arbitrary. A breaking change is a breaking change: just because you don’t think anyone is relying on the existing behaviour doesn’t make it any less of a breaking change. I really don’t like it when Linus says the Kernel never breaks userspace (he says this a lot and uses it as an excuse to abuse people on the mailing list) because it’s just factually inaccurate, and “no one will notice” isn’t really good enough if you expect people to actually rely on this property.
      • ilyt 3y ago
        Well, adding two paragraph long disclaimer where people competent enough know what he means anyway would be counter-productive. The fact it sometimes need to be broken if it is unfixably insecure is obvious conclusion for anyone that thinks about the problem instead of looking for reasons to complain
      • arp242 3y ago
        > “no one would notice” really means “the maintainers don’t think anyone would notice”, and this ends up being somewhat arbitrary. Yeah, that's pretty much what I meant, but this is phrased better than I did. I do think that "Kernel never breaks userspace" is accurate in the common-understanding sense and a good policy to have, even though it's indeed not accurate in the sense that it's "100% technically accurate" (Linux also just breaks things by accident for example). You could use a qualified statement like "Linux takes great care not to break userspace, except when there is a overwhelming case in favour of it, or when we think no real applications will break with it, and we don't always roll back accidental breakage if we don't think it's worth it" and that would be more accurate, but that's rather vague, and a clear "never break userspace" is a much clearer better as a policy for everyone. In interviews and such Linus is of course much more nuanced than "never break userspace".
• jmclnx 3y ago
  >This came from OpenBSD Thanks, you saved me some looking, I thought OpenBSD did something in this case and was going to poke around. To bad the BSDs and Linux could not agree on what to do :) But really, for what I develop this is a non issue.
• pwdisswordfishc 3y ago
  > Someone else tries to weasel a difference between "shall" and "should", I find this sentiment surprising coming from someone pedantic enough to have written: https://jdebp.uk/FGA/han-unification.html https://jdebp.uk/FGA/han-unification.html https://jdebp.uk/FGA/fga-not-faq.html https://jdebp.uk/FGA/fga-not-faq.html https://jdebp.uk/FGA/questions-with-yes-or-no-answers.html https://jdebp.uk/FGA/questions-with-yes-or-no-answers.html
  • Joker_vD 3y ago
    That "Only ask questions with yes/no answers if you want "yes" or "no" as the answer" is so tilting... by the way, did you know that in e.g. Russian there are no separate words for "can" and "may", so the taunts of the "Can I please go to the bathroom? — I don't know, can you?" kind are even more infuriating than in English?
    • tetromino_ 3y ago
      > in e.g. Russian there are no separate words for "can" and "may" I disagree. For "can", in Russian you would use the verb мочь (in the case of your example: я могу сходить в туалет?, lit. "I can / am able to go to the bathroom?"); for "may", you would use the predicative можно (in the case of your example: можно сходить в туалет?, lit. "is one allowed / is it possible to go to the bathroom?").
• petemir 3y ago
  > Someone else then comes up with a mad but very real mainstream program that relies upon the system call succeeding. Mandatory xkcd reference https://xkcd.com/1172/ https://xkcd.com/1172/
  • JdeBP 3y ago
    In this case, it was a kernel filesystem driver test suite, and the test suite isn't in fact relying at all upon argv being a zero-length array. It's not part of any workflow. Indeed, the test suite is, rather, this very bug waiting to happen. Still. Two years later. https://git.kernel.org/pub/scm/fs/xfs/xfstests-dev.git/tree/src/vfs/vfstest.c#n503 https://git.kernel.org/pub/scm/fs/xfs/xfstests-dev.git/tree/... Easily solved by: static char *argv[] = { FILE1, NULL, }; The xfs test program invoked by the execve() is calling getopt_long_only() passing the zero argc and a zero-length argv that execve() was given. It is quite ironic that that test program is thus exceeding the argument vector bounds and going off into some adjacent part of memory, because one of the first things that getopt_long_only() does is: optind = 1; /* Don't scan ARGV[0], the program name. */