Re: A Famous Security Bug

On 24/03/2024 17:02, Kaz Kylheku wrote:

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

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

(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.

 But the requirement isn't imaginary. The "least requirements"
paragraph doesn't mean that all other requirements are imaginary;
most of them are necessary to describe the language so that we know
how to find the observable behavior.
 

The text is not imaginary - your reading between the lines /is/.  There is no rule in the C standards stopping the compiler from using additional information or knowledge about other parts of the program.

It takes a modicum of inference to deduce that a certain explicitly
stated requirement doesn't exist as far as observability/conformance.
 We are clearly not imagining the sentences which describe a classic
translation and linkage model. The argument that they don't matter
for conformance is different from the argument that we imagined
something between the lines. It is the inference based on 5.1.2.4 that
is between the lines; potentially between any pair of lines anywhere!
 Furthermore, the requirents may matter to other kinds of observability.
 In C programming, we don't always just care about ISO C observability.

I agree on that.  The C standards are not the be all and end all of things of interest to C programmers.  If it were, we'd never have compilers with extensions.
But it /is/ the only thing that matters when you talk about "conforming" compilers.
If you want to say that LTO breaks some of the requirements that /you/ have for the way /you/ want to do unit testing, that's absolutely fine. If you want to say that this applies to many other C developers, I'd prefer to see a bit of evidence or justification for the claim, but I'd take it seriously - I fully appreciate that people have needs beyond what the C standards give them.
But that's not what you have been saying.  You have been saying that LTO breaks the requirements of the C standards, and you are wrong about that.

 In safety critical coding, we might want to conduct a code review of
the disassembly of an object file (does it correctly implement the
intent we believe to be expressed in the source), and then retain that
exact file until wit needs to be recompiled.

Sure.  And for that reason, some developers in that field will not use LTO.  I personally don't make much use of LTO because it makes software a pain to debug.  I do, however, retain the full toolchain used for a project, including all build scripts and flags, libraries and compilers, and make sure my builds are reproducible on multiple computers - then any testing or reviews of the disassembly remain valid over time.  With LTO, at least some parts may need to be re-validated after a build even for source code changes to apparently different parts of the program - that is a cost that must be weighed against the benefits of LTO.  (I have considered doing LTO builds in parallel with non-LTO builds - using the LTO builds solely for more advanced static checking, while using the more debuggable non-LTO build for the "real" binary.)
I have agreed that there are many reasons why LTO might not be a good choice for any given project.  I have merely contended the claim that conformity is such a reason.

If the code is actually a
an intermediate code that is further translated during linking, that's
not good; we face the prospect of reviewing potentially the entire image
each time.  Thus we might want an implementation which has a way of
conforming to the classic linkage model (that happens to be conveniently
described).
 We just may not confuse that conformance (private contract between
implementor and user) with ISO C conformance, as I have.
Sorry about that!
 

Are you saying that after dozens of posts back and forth where you made claims about non-conformity of C compilers handling of C code in comp.lang.c, with heavy references to the C standards which define the term "conformity", you are now saying that you were not talking about C standard conformity?

What is significant is that the concept has support in ISO C wording.
Such a contract can just refer to that: "our project requires the
classic translation and linkage model that arises from the translation
phases descriptions 7 and 8 being closely followed".
As long as you have a way to disable LTO (or not enable it), you have
that.