Announcement

Collapse
No announcement yet.

Proposed GCC 12 Security Option Would Auto Initialize Automatic Variables

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

  • Proposed GCC 12 Security Option Would Auto Initialize Automatic Variables

    Phoronix: Proposed GCC 12 Security Option Would Auto Initialize Automatic Variables

    An Oracle engineer has proposed introducing a new "-ftrivial-auto-var-init=" option for the GCC compiler that would allowing initializing automatic variables with either a pattern or zeroes in the name of security...

    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
    I can see how uninitialized variables are a concern. I wonder, though, why one would try to solve it by automatically initializing them. It makes sense that a zero-value or a possibly crash-inducing pattern is better than taking whatever was in memory before (and could have possibly been manipulated by an attacker).

    But, if the programmer has not initialized the variable, using zero or a pattern as the value could still lead to behavior that the programmer did not think about. Wouldn't it preferable, for a security-enhanced build-setting, to use -Wuninitialized and make it an error? Then the programmer has to put the zero or other value in there explicitly and will also have to think about the implications. This sounds better than just silently writing the zero into the variable at a place that the programmer is not aware of because it was overlooked.

    Comment


    • #3
      Originally posted by tinko View Post
      I can see how uninitialized variables are a concern. I wonder, though, why one would try to solve it by automatically initializing them. It makes sense that a zero-value or a possibly crash-inducing pattern is better than taking whatever was in memory before (and could have possibly been manipulated by an attacker).

      But, if the programmer has not initialized the variable, using zero or a pattern as the value could still lead to behavior that the programmer did not think about. Wouldn't it preferable, for a security-enhanced build-setting, to use -Wuninitialized and make it an error? Then the programmer has to put the zero or other value in there explicitly and will also have to think about the implications. This sounds better than just silently writing the zero into the variable at a place that the programmer is not aware of because it was overlooked.
      I think it mostly comes down to backward compatibility at this point. You can not just switch this on by default because it would break existing code.

      Comment


      • #4
        Originally posted by cen1 View Post

        I think it mostly comes down to backward compatibility at this point. You can not just switch this on by default because it would break existing code.
        I'm quite eager to see someone's code blowing up some time down the line due to using uninitialized reads as a source of randomness

        Comment


        • #5
          Originally posted by tinko View Post
          I can see how uninitialized variables are a concern. I wonder, though, why one would try to solve it by automatically initializing them. It makes sense that a zero-value or a possibly crash-inducing pattern is better than taking whatever was in memory before (and could have possibly been manipulated by an attacker).

          But, if the programmer has not initialized the variable, using zero or a pattern as the value could still lead to behavior that the programmer did not think about. Wouldn't it preferable, for a security-enhanced build-setting, to use -Wuninitialized and make it an error? Then the programmer has to put the zero or other value in there explicitly and will also have to think about the implications. This sounds better than just silently writing the zero into the variable at a place that the programmer is not aware of because it was overlooked.
          Mostly C++ but has been ported/proposed for C.
          In C it usually comes down to "Well. It's pretty sane to propose default initialization. So what is the cost?"
          So this feature is mostly meh, depending on how you look at it.
          I suppose that we'll get default local variable init in the kernel at some point...
          when someone proves "minor performance issue".

          Comment


          • #6
            Originally posted by tinko View Post
            I can see how uninitialized variables are a concern. I wonder, though, why one would try to solve it by automatically initializing them. It makes sense that a zero-value or a possibly crash-inducing pattern is better than taking whatever was in memory before (and could have possibly been manipulated by an attacker).

            But, if the programmer has not initialized the variable, using zero or a pattern as the value could still lead to behavior that the programmer did not think about. Wouldn't it preferable, for a security-enhanced build-setting, to use -Wuninitialized and make it an error? Then the programmer has to put the zero or other value in there explicitly and will also have to think about the implications. This sounds better than just silently writing the zero into the variable at a place that the programmer is not aware of because it was overlooked.
            Could not agree more. Besides initializing to unsigned -1 instead of 0 would probably help catch most problems / wreck havoc much quicker , making it easier to catch errors IMHO.

            http://www.dirtcellar.net

            Comment


            • #7
              Originally posted by intelfx View Post

              I'm quite eager to see someone's code blowing up some time down the line due to using uninitialized reads as a source of randomness
              Been there when it happened. Was a shitstorm at work :/

              Comment


              • #8
                Could this be good? Of course yes, for debugging purposes.
                Could this be bad? Of course yes, it can hit performance.

                Could this really be good? No, even for debugging -Wuninitialized/-Wmaybe-uninitialized should be used instead. It does not have a performance penalty.

                Should this patch be accepted? No, there is a feature in gcc for exactly this reason. And it is supposed to do a better job. If it doesn't work as expected a patch that improves this should be written instead.

                Comment


                • #9
                  Zero would be a bad choice. I think Microsoft's debugger uses 0xB4DF00D to initialize memory, which is a lot easier to notice when something goes wrong and you inspect the values of variables in a debugger. When you see 0xB4DF00D or a value close to that, you immediately know what the issue is. It's also more likely to cause a crash when it comes to uninitialized pointers.

                  Comment


                  • #10
                    I would imagine that, in large code bases where porting away from C++ (Java? This is Oracle we're talking about) is not an immediate possibility, having the option of turning this on and fixing the fallout might yield an increase in security/reliability at a much lower price than other solutions?

                    I can't imagine that an Oracle engineer *wouldn't* have considered the relevant alternatives and tradeoffs, given that it seems to be a company which is pretty focused on their bottom line and extracting as much revenue from its products and customers as possible.

                    Comment

                    Working...
                    X