Announcement

Collapse
No announcement yet.

GCC 12 Adds Stack Variable Auto-Initialization, Other Security Improvements Forthcoming

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

  • GCC 12 Adds Stack Variable Auto-Initialization, Other Security Improvements Forthcoming

    Phoronix: GCC 12 Adds Stack Variable Auto-Initialization, Other Security Improvements Forthcoming

    Qing Zhao of Oracle presented yesterday during the LPC2021 GNU Tools Track around the work they and others have been engaged in for improving the security of the GNU Compiler Collection (GCC)...

    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
    Who in the right mind would want unsigned overflow protection?

    Comment


    • #3
      Originally posted by ddriver View Post
      Who in the right mind would want unsigned overflow protection?
      yes, the proper solution is: if you don't need modulo arithmetic, you should use signed integers.
      -ftrivial-auto-var-init=zero also looks strange: there's a warning for use of uninitialized variable, why not fix warnings instead of papering them over. maybe some var should be initialized with something other than zero

      Comment


      • #4
        Originally posted by ddriver View Post
        Who in the right mind would want unsigned overflow protection?
        People using unsigned integers for buffer lengths. But yeah I do wonder how that would work with all the other stuff unsigned ints needs to do that does require overflow acting as prescribed.

        Comment


        • #5
          But but.. not having uninitialized stack variables makes the high efficiency C code slow and bloated like in Java or C#. The whole point of using C is to maximize the performance.

          Comment


          • #6
            Originally posted by caligula View Post
            But but.. not having uninitialized stack variables makes the high efficiency C code slow and bloated like in Java or C#. The whole point of using C is to maximize the performance.
            It is just one of the many reasons.

            I can see the motivation here, in C++ you can simply use wrappers around stuff that you want initialized and stuff you don't want to overflow, and it will be a drop in substitute.

            In C you'd have to write a lot of extra code to achieve the same, so they are squeezing it on compiler level, although it absolutely isn't the proper approach.

            Comment


            • #7
              Originally posted by caligula View Post
              But but.. not having uninitialized stack variables makes the high efficiency C code slow and bloated like in Java or C#. The whole point of using C is to maximize the performance.
              Just like the compiler can, in most cases, warn when using an uninitialized variable, it could elide zeroing the variable if it's set later on.

              Heck, this is even one of the "standard" optimizer passes you'll find described in your favorite compiler textbook, i.e. Dead Store Elimination (DSE).

              Comment


              • #8
                Originally posted by ddriver View Post
                Who in the right mind would want unsigned overflow protection?
                Unsigned integer overflow detection by ubsan has helped me find some nasty bugs more than once. Just because it's "not UB" does not make it correct at all:

                vec.size() - 1

                will give you not what you expect when vec.size() == 0 for instance:

                int main() { std::vector<int> arr; std::cout << (arr.size() - 1) << std::endl; }


                Yes, it's technically not UB. Yes, I also want my compiler to scream at me when that happens and prevent it in every possible way because it's still a bug. The only relevant place where one should do unsigned operations is in hash functions and similar.
                Last edited by doom_Oo7; 23 September 2021, 02:41 PM.

                Comment


                • #9
                  Originally posted by doom_Oo7 View Post
                  Unsigned integer overflow detection by ubsan has helped me find some nasty bugs more than once. Just because it's "not UB" does not make it correct at all:

                  vec.size() - 1

                  will give you not what you expect when vec.size() == 0 for instance:
                  int main() { std::vector<int> arr; std::cout << (arr.size() - 1) << std::endl; }
                  you are describing underflow. overflow is in the other direction. it's 0xffffffff << 1 for example.
                  int main() { unsigned a = -1; std::cout &lt;&lt; std::hex &lt;&lt; (a &lt;&lt; 1) &lt;&lt; std::endl; }


                  and proper solution(as mentioned in post #3, i.e. it applies to unsigned underflow as well) to your problem looks like this: ssize(vec) - 1
                  int main() { std::vector&lt;int&gt; arr; std::cout &lt;&lt; (ssize(arr) - 1) &lt;&lt; std::endl; }
                  Last edited by pal666; 23 September 2021, 07:21 PM.

                  Comment


                  • #10
                    Originally posted by carewolf View Post
                    People using unsigned integers for buffer lengths.
                    unsigned overflow makes index smaller, i.e. if anything, it can protect against buffer overflow. you are talking about something else

                    Comment

                    Working...
                    X