Re: A Famous Security Bug

On 22/03/2024 16:33, Kaz Kylheku wrote:

On 2024-03-22, David Brown <david.brown@hesbynett.no> wrote:

On 21/03/2024 21:21, Kaz Kylheku wrote:
>

Eliminating dead stores is a very basic dataflow-driven optimization.
>
Because memset is part of the C language, the compiler knows
exactly what effect it has (that it's equivalent to setting
all the bytes to zero, like a sequence of assignments).
>

>
Yes.
>

If you don't want a call to be optimized away, call your
own function in another translation unit.

>
No.
>
There are several ways that guarantee your code will carry out the
writes here (though none that guarantee the secret data is not also
stored elsewhere).  Using a function in a different TU is not one of
these techniques.  You do people a disfavour by recommending it.

 It demonstrably is.

It depends on your compiler and the options you use.  That is not a good choice - especially when better ones are available.

 

(And don't turn
on nonconforming cross-translation-unit optimizations.)
>

>
If I knew of any non-conforming cross-translation-unit optimisations in
a compiler, I would avoid using them until the compiler vendor had fixed
the bug in question.

 They are not fixable. Translation units are separate, subject
to separate semantic analysis, which is settled prior to linkage.
 The semantic analysis of one translation unit must be carried out in the
absence of any information about what is in another translation unit.
 

"Proof by repeated assertion" does not hold.
I have tried to explain the reality of what the C standards say in a couple of posts (including one that I had not posted before you wrote this one).  I have tried to make things as clear as possible, and hopefully you will see the point.
If not, then you must accept that you interpret the C standards in a different manner from the main compile vendors, as well as some "big names" in this group.  That is, of course, not proof in itself - but you must realise that for practical purposes you need to be aware of how others interpret the standard, both for your own coding and for the advice or recommendations you give to others.