Announcement

Collapse
No announcement yet.

Torvalds Voices Thoughts On Linux Mitigating Unexpected Arithmetic Overflows/Underflows

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

  • Torvalds Voices Thoughts On Linux Mitigating Unexpected Arithmetic Overflows/Underflows

    Phoronix: Torvalds Voices Thoughts On Linux Mitigating Unexpected Arithmetic Overflows/Underflows

    For those interested in some insightful Linux kernel mailing list reading this weekend, there's been a vibrant discussion on the ability for the Linux kernel to mitigate unexpected arithmetic overflows/underflows/wraparounds...

    Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite

  • #2
    As long as you are approaching this from a "this puts the onus on others", *YOU* are the problem.
    Be the solution, not the problem.​
    That's just good advice for any job, very much so for us in IT/Technology.

    Comment


    • #3
      Kees is probably accustomed to Google where more cognitive load for somebody else and more line codes are not that big of an issue...but the overall attitude is plain wrong, a sign of these times:

      I'm seeking some general consensus on taking approach #1 above -> he wants his idea to gain consensus without bothering if it's good or not
      so that's a universal pain point -> he's already tagged any resistance as lazyness
      But I've been beating the "make Linux safer" drum for a long time now -> he's already the good guy
      and I hope I can convince folks that we need to actually make a change here -> MY change is better than whatever you orangutans have come up with in the last decades
      The status quo isn't good enough-> everybody else is lazy and defending the status quo
      and we can do better-> MY idea is clearly better
      I just need to find a common solution we can agree on and realistically apply over the coming years-> you don't need to do as I say now, you can vow to do as I say in the following months
      What are your thoughts, suggestions, alternatives?"​-> "NOPE" is not among the options, you can pick your favourite flavour of what I've told you to do

      Geez, what a dumba**.

      Comment


      • #4
        I obviously don't know what the best solution would be, but he's not necessarily wrong. So many exploits take advantage of known knowns and known unknowns which then falls onto what Linus said, "Be the solution, not the problem." One can argue that the Linux coding standards are too lax and, if that's the case, then Linus and other kernel maintainers are the problem by staying the course with the status quo. Or would it be C and GCC? A little of both?

        aerospace NOPE is totally an option out of thoughts, suggestions, alternatives. I think NOPE because that idea is stupid. I suggest you go tell it on the mountain. Alternatively, piss off you bloody wanker.

        Comment


        • #5
          Well, in userland such tools might be implemented as part of a static code analyzer and/or valgrind plugin. Get a feel for the utlility and gotcha's. About kernel space I wouldn't know.

          Comment


          • #6
            Torvalds is right, wraparound is fine. You know what sounds absolutely horrific? This nonsense:
            ... or a recent C language proposal for operator overloading without name mangling. In the latter proposal as a potential solution, C operator overloading could allow for arbitrary handling of overflows within the helpers.

            Comment


            • #7
              Originally posted by skeevy420 View Post
              I obviously don't know what the best solution would be, but he's not necessarily wrong. So many exploits take advantage of known knowns and known unknowns which then falls onto what Linus said, "Be the solution, not the problem." One can argue that the Linux coding standards are too lax and, if that's the case, then Linus and other kernel maintainers are the problem by staying the course with the status quo. Or would it be C and GCC? A little of both?

              aerospace NOPE is totally an option out of thoughts, suggestions, alternatives. I think NOPE because that idea is stupid. I suggest you go tell it on the mountain. Alternatively, piss off you bloody wanker.
              Or a language that in 50+ still hasn't nailed these use cases? Not that is going to change anything right now, but I see it as part of the reasons why people prefer to use more modern languages.

              Comment


              • #8
                unsigned arithmetic being well defined is a no brainer for most devs I hope. I suppose Mr. Torvalds wants just to make sure nobody is trying to reinvent the wheel on that side
                Last edited by AdelKS; 11 May 2024, 03:56 PM.

                Comment


                • #9
                  I kinda disagree with Linus on this one. Wrap-around is expected for anyone with a diploma in electrical engineering or computer science that understands the inner workings of arithmetic operations. It is the opposite of "expected" for pretty much everyone else.
                  We got accustomed to that for decades because we had to. But if if can get un-accustomed, I'd say go for it. Sure, it can't happen overnight. But go for it anyway.

                  Comment


                  • #10
                    Originally posted by bug77 View Post
                    Wrap-around is expected for anyone with a diploma in electrical engineering or computer science that understands the inner workings of arithmetic operations. It is the opposite of "expected" for pretty much everyone else.
                    Since this is about kernel developers, they must fit into at least similar categories

                    Comment

                    Working...
                    X