Re: A Famous Security Bug

On 24/03/2024 06:50, Kaz Kylheku wrote:

On 2024-03-23, James Kuyper <jameskuyper@alumni.caltech.edu> wrote:

On 3/23/24 12:07, Kaz Kylheku wrote:

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

...

That is true - /if/ you make the restriction that the translation unit
is complied completely to linkable machine code or assembly, and that it
is not changed in any way when it is combined into the new program.
Such a setup is common in practice, but it is in no way required by the
C standards and does not apply for more advanced compilation and build
scenarios.

>
Well, it's only not required if you hand-wave away the sentences in
section 5.

>
Or, you could read the whole of section 5. 5.1.2.3p6 makes it clear that
all of the other requirements of the standard apply only insofar as the

 Aha, so you agree there are requirements, just that the behavior they
imply can be achieved without them being followed in every detail.
 

observable behavior of the program is concerned.

 I believe what you're referring to is now in 5.1.2.4¶6 in N3220.

Yes.  Usually the C standards committee try to avoid inserting sections and the resulting changes in numbering, but they have, for some reason, given the first paragraph of 5.1.2 its own section number in n3220 and bumped everything down a step.

 Yes, you make the excellent point.
 If we make any claim about conformance, it has to be rooted in
observable behavior, which is the determiner of conformance.

Agreed.

 But we will not find that problem in LTO. If any empirical test of a LTO
implementation shows that there is a difference in the ISO C observable
behavior of a strictly conforming program, that LTO implementation
obviously has a bug, not LTO itself.

Yes.  Any optimisation that changes the observable behaviour of a program (other than amongst alternative correct behaviours - sometimes there are several for the same input, as a result of unspecified behaviours) is invalid as an optimisation.  (I am assuming the program does not execute any undefined behaviour - otherwise all bets are off.)
This applies to all optimisations and to the compilation itself - optimisations don't get to change the observable behaviour.  Equally, any re-arrangement of code or other effects of the compiler that don't change the observable behaviour are perfectly valid and don't imply non-conformity.

(So why bother looking.) I mean,
the absolute baseline requirement any LTO implementor strives toward is
no change in observable behavior in a strictly conforming program, which
would be a showstopper.
 

Yes.
I don't believe anyone - except you - has said anything otherwise.  A C implementation is conforming if and only if it takes any correct C source code and generates a program image that always has correct observable behaviour when no undefined behaviour is executed.  There are no extra imaginary requirements to be conforming, such as not being allowed to use extra information while compiling translation units.