[cfe-dev] [EXTERNAL] Re: making -ftrivial-auto-var-init=zero a first-class option

[Reid Kleckner via cfe-dev]

JF: To Richard's point about raising this at the C++ committee level, has
that already been explored? I got the impression that Richard mostly wanted
to see an *attempt* to standardize the behavior across implementations. If
an attempt has already been made and there is evidence of disagreement,
then it seems like we may already have fulfilled point 4 of the clang
language extension policy, and we can go forward with renaming the flag and
making it permanent. It seems clear that there is adequate appetite for
this feature.

I suppose Richard is the C++ project editor, he would know if an attempt
has been made, but I do not personally have any visibility into the WG21
proceedings or communications.

On Wed, Apr 29, 2020 at 6:17 PM JF Bastien via cfe-dev <
cfe-dev at lists.llvm.org> wrote:

> I’ve consulted with folks in security, compilers, and developers of
> security-sensitive codebases. A few points:
>
>
>    - They like that automatic variable initialization provides a security
>    mitigation for a significant percentage of observed zero-day exploits, at
>    extremely low cost, with little chance of regression.
>    - They like that pattern initialization is a “smoking gun” when seen
>    in a crash log. The size+performance costs have decreased in the last year,
>    but they’d like to see it improve further.
>    - They like the lower size+performance cost of zero initialization as
>    well as the safety it offers for e.g. size variables (because a size of
>    0xAA…AA is “infinite” which is bad for bounds checking, whereas zero
>    isn’t). They don’t like that zero is often a valid pointer sentinel value
>    (i.e. initializing pointers to zero can be used in unexpected data flow).
>    They don’t like the silly long compiler flag.
>    - We’ve deployed automatic variable initialization in a significant
>    amount of code. The vast majority of our deployment uses pattern
>    initialization. A small number uses zero, of which you’ll note XNU
>    <https://opensource.apple.com/source/xnu/xnu-6153.11.26/makedefs/MakeInc.def.auto.html>.
>    We’ve only chosen zero in cases where size or performance were measured
>    issues.
>    - Automatic variable initialization which might sometimes trap (as
>    Richard suggests) is a proposal we’d like to see implemented, but we’d like
>    to see it under its own separate flag, something like UBSan does with
>    developers choosing trapping or logging modes. The main reason is that pure
>    trapping with zero-init will make deployment significantly harder (it’s no
>    longer a low-risk mitigation), and it’ll make updating our compiler
>    significantly harder (because it might change where it generates traps over
>    time). We also think that trapping behavior would need good tooling, for
>    example through opt remarks, to help find and fix parts of the code where
>    the compiler added traps. A logging mode would ease some of this burden. As
>    well, we’re not convinced on the size+performance cost of either tapping
>    nor logging, complicating the adoption of the mitigation.
>    - We don’t think the design space has been explored enough. We might
>    want to differentiate initialization more than just “floating point is
>    0xFF…FF, everything else is 0xAA…AA”. For example:
>       - We could pattern-init pointers (maybe with compile-time random
>       different patterns), and zero-init scalars. This has a good mix of
>       performance and security upsides.
>       - We could key off heuristics to choose how to initialize, such as
>       variable names, function names, or some machine learning model (and for
>       those who know me: I’m not joking).
>       - We could use a variety of runtime pseudo-random sources to
>       initialize values.
>       - We could add a new IR “undef” type, or different late-stage
>       treatment of “undef”, to apply initialization after optimizations have
>       found interesting facts about the program.
>
>
> We’d like to see work continue on improving this mitigation, optimizations
> around it, and other similar mitigations.
>
>
> On Apr 22, 2020, at 1:55 PM, Kees Cook via cfe-dev <cfe-dev at lists.llvm.org>
> wrote:
>
> On Wed, Apr 22, 2020 at 01:08:03PM -0700, Richard Smith wrote:
>
> On Wed, 22 Apr 2020 at 10:49, Joe Bialek <jobialek at microsoft.com> wrote:
>
> Also not clear to me what the OS is expected to do with this trap. We have
> a number of information leak vulnerabilities where force initialization
> kills the bug silently.
>
>
> Do you really mean "kills the bug"? I would certainly believe you have a
> number of information leak vulnerabilities where zero-init fixes the
> *vulnerability* (and we should definitely provide tools to harden programs
> against such vulnerabilities), but the program is still using an
> uninitialized value and still has a bug. The idea that this compiler change
> fixes or removes the bug is precisely the language dialect problem that I'm
> concerned about. Developers must still think that reading an uninitialized
> value is a bug (even if it's not a vulnerability any more) or they're
> writing a program in a language dialect where doing that is not a bug.
>
>
> Yeah, this is another "different communities mean different things"
> terminology glitch. For the security folks, "bug" tends to stand in for
> "security bug" or "security flaw". But yes, as you say, the "bug"
> (misuse of the C language) is present, but the "security flaw" gets
> downgraded to "just a bug" in the zero-init case. :)
>
> --
> Kees Cook
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>
>
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20200430/cb00a9c5/attachment.html>