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

[David Blaikie via cfe-dev]

Ah - thanks for the clarification

On Wed, Apr 22, 2020 at 11:37 AM Joe Bialek <jobialek at microsoft.com> wrote:

> We still make fixes to up level code. We just don’t have to fix existing
> in-market code.
>
>
>
> For the end-users who consume the binaries you are generating, the
> behavior I am describing is preferable to having to install an update to
> fix a fault that could have been silently fixed. People don’t like
> installing updates and often don’t. It also saves a lot of money on our end
> to not be required to service something that is working. We can verify the
> code is working correctly, make the change only in our active development
> branch for the next version of the product, and move on.
>
>
>
> Joe
>
>
>
> *From:* David Blaikie <dblaikie at gmail.com>
> *Sent:* Wednesday, April 22, 2020 11:07 AM
> *To:* Joe Bialek <jobialek at microsoft.com>
> *Cc:* Kees Cook <keescook at chromium.org>; Richard Smith <
> richard at metafoo.co.uk>; Clang Dev <cfe-dev at lists.llvm.org>
> *Subject:* Re: [cfe-dev] [EXTERNAL] Re: making
> -ftrivial-auto-var-init=zero a first-class option
>
>
>
>
>
>
>
> On Wed, Apr 22, 2020 at 10:50 AM Joe Bialek via cfe-dev <
> cfe-dev at lists.llvm.org> wrote:
>
> How are you going to efficiently check that something wasn't initialized
> at runtime? In a way that results in better codegen than just doing pattern
> initialization? I'm happy to see a solution but I don't see how this can be
> done in a way that doesn't involve metadata and checks. If you could do
> this at compile-time, you'd just issue a warning rather than let the issue
> hang around for someone to discover at runtime.
>
>
> At least in Clang, what powers warnings versus what powers optimizations
> are quite different - there are lots of things we could trap on that we
> couldn't warn on. (because the warning would have to describe to the user
> what codepath was taken, what values were needed to take those paths, etc -
> but trap wouldn't)
>
>
> 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. If you have a non-recoverable trap you are now
> turning these bugs in to kernel crashes which is sort of a crappy user
> experience compared to just silently fixing the bug and allowing the OS to
> work as normal. As it is right now, we can just ignore the issues because
> they have no security or reliability impact which is great because it saves
> us time and money not having to service things, and customers don't have to
> install a code update either.
>
>
>
> This is the thing the folks concerned about "forking the language" are
> trying to avoid - not wanting that code to be considered correct/OK/not
> needing of any changes/corrections.
>
>
>
>
>
> Joe
> ------------------------------
>
> *From:* Kees Cook <keescook at chromium.org>
> *Sent:* Wednesday, April 22, 2020 10:40 AM
> *To:* Richard Smith <richard at metafoo.co.uk>
> *Cc:* Arthur O'Dwyer <arthur.j.odwyer at gmail.com>; Joe Bialek <
> jobialek at microsoft.com>; Clang Dev <cfe-dev at lists.llvm.org>
> *Subject:* [EXTERNAL] Re: [cfe-dev] making -ftrivial-auto-var-init=zero a
> first-class option
>
>
>
> On Tue, Apr 21, 2020 at 04:54:25PM -0700, Richard Smith wrote:
> > The existence of the
> > --long-ugly-flag-name-that-says-we'll-remove-the-feature is the way we
> > currently try to avoid introducing a language dialect. If we remove that
> > flag as is proposed, then we are effectively relitigating the question of
> > whether to have the feature at all.
>
> What about renaming the enable flag so it doesn't imply that zero-init
> is going to be removed?
>
> > And indeed it might even be OK if the initial behavior is that we
> *always*
> > zero-initialize (as Philip asked), so long as our documentation clearly
> > says that we do not guarantee that the value will be zero (only that we
> > guarantee that *if the program continues*, the value will be zero), and
> our
> > intent is that we may still produce traps or otherwise abort the
> > computation.
>
> Right -- I would see adding a trap path as a nice improvement. I still
> think it'll be be too much overhead, though, given needing to check all
> corners of a struct: accessing any padding bytes would need to trap,
> etc.
>
> --
> Kees Cook
>
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.llvm.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fcfe-dev&data=02%7C01%7Cjobialek%40microsoft.com%7C3954fcdb3a784f80e5a408d7e6e7f13d%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637231756169472859&sdata=DKfkGle1Bj1otbr%2FdfeIyY2cMySiXv1o76mztZm1dcE%3D&reserved=0>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20200422/06226114/attachment.html>