Announcement

Collapse
No announcement yet.

Linux 5.15 Enabling "-Werror" By Default For All Kernel Builds

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • #11
    Originally posted by JustRob View Post
    Ideally they'll add "-Werror=format-security" to new versions, like Fedora does. Don't complain that it's more difficult for someone else to write defensive code, when you're the one most affected.

    https://fedoraproject.org/wiki/Format-Security-FAQ
    Linux kernel doesn’t use standard IO functions provided by C stdio.h, so this option likely do nothing.

    Comment


    • #12
      Originally posted by coder View Post
      The biggest problem I have with static analysis (besides too much time wasted "fixing" false-positive warnings) is the false sense of security some people seem to take from it. It's only one tool in the toolbox. Over-reliance on any one tool is going to be unproductive.
      Very true, and I think this is a great argument against it.

      Comment


      • #13
        Originally posted by brad0 View Post

        Why would they want to do the right thing when they can do the wrong thing instead.
        Sometimes you gotta do the wrong thing, before the right thing becomes apparent.

        (Linus could also be sending a message to developers and then just revert this next kernel as a troll move. Totally a Linus move. He's capable of said trolling.)

        Comment


        • #14
          Originally posted by perpetually high View Post
          Sometimes you gotta do the wrong thing, before the right thing becomes apparent.
          Except this was apparent 20 years ago.

          Comment


          • #15
            Originally posted by perpetually high View Post

            Very true, and I think this is a great argument against it.
            or - and hear me out here - getting devs to write code that is of better quality is just a net positive.

            true that it is is a bit of an annoyance, but that helps you (the dev maintaining the code) in the long run.

            As an example - there are no warnings in Golang, it's either an error or not worth surfacing - unused variables are errors, unused imports too.

            I never once thought of things being "more secure" because I have no errors.

            I just want my code to run. I suspect this will be the same kernel devs - the bar to getting new code in is just a little higher and while you might trip over it a few times, you train yourself to not to do the things and you are back to clearing the bar easily.

            net positive!

            Comment


            • #16
              I don't care about Linus's explanations, this thing stays off in my custom builds.

              Comment


              • #17
                Originally posted by boxie View Post

                or - and hear me out here - getting devs to write code that is of better quality is just a net positive.

                true that it is is a bit of an annoyance, but that helps you (the dev maintaining the code) in the long run.

                As an example - there are no warnings in Golang, it's either an error or not worth surfacing - unused variables are errors, unused imports too.

                I never once thought of things being "more secure" because I have no errors.

                I just want my code to run. I suspect this will be the same kernel devs - the bar to getting new code in is just a little higher and while you might trip over it a few times, you train yourself to not to do the things and you are back to clearing the bar easily.

                net positive!
                Gross annoying, net positive : )

                Yeah, but it's just a thorn in the side and maybe slows them down. I'm not disagreeing so much, I just don't think it should be a default behavior. More opt-in. But again, I understand why Linus did it, and it's worth experimenting to see what happens, and if it works out well, then experiment successful.

                Comment


                • #18
                  Originally posted by brad0 View Post

                  Except this was apparent 20 years ago.
                  Fair, but the kernel and kernel development seems to have been doing good so far. (I say that with no inside knowledge, however)

                  The Linux kernel is a really interesting beast. There's no benchmark for it. Nothing to compare it to. Stands on its own mountain.

                  With that, it's hard to say what's the best way. Linus literally made git because svn wasn't sufficient for Linux. Now look at git. Now look at GitHub. Now look at everything.

                  I'm so impressed with the Linux kernel, GNU/userspace, all of it. I'm trying to do my best to give back now. With as little complaining, and more doing.

                  Comment


                  • #19
                    Originally posted by perpetually high View Post
                    (I say that with no inside knowledge, however)
                    That is very evident.

                    Comment


                    • #20
                      Originally posted by boxie View Post
                      I never once thought of things being "more secure" be
                      I just want my code to run. I suspect this will be the same kernel devs - the bar to getting new code in is just a little higher and while you might trip over it a few times, you train yourself to not to do the things and you are back to clearing the bar easily.

                      net positive!
                      This does not change the bar for code getting in. This is only for robots who otherwise might not flag warnings. Linus has never tolerated warnings and if you ask him to pull code that outputs warnings he will likely not accept it. He also hates useless warnings and patches that do nothing useful except shut them up. So, either the warning is helpful and the code is fixed, or it's useless and shut off. The reason he does not tolerate 'benign' warnings is that they then build up and it's hard to see a warning that merits attention. The reason this was not turned on before was that it simply was not required by Linus' workflow; he immediately sees any warning in his build and pushes back. The number of robots building and testing the kernel has increased drastically in the last few years, so this is just a response to people using them more, not any significant policy change.

                      Comment

                      Working...
                      X