Re: A Famous Security Bug

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

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

At best we may be able to say that if those requirements with regard
to translation phase 7 and 9 separation are assiduously followed, the
implementation belongs to a certain identifiable class, which is
suitable for certain purposes (or for certain ways of expressing those
purposes in a program).  Certain techniques will be reliable that
would otherwise be not. However, since it is something not reflected in
observable behavior (as defined in ISO C), the class division does not
land along the line of conforming versus non-conforming.

Any method of achieving observable behavior that matches the behavior
that would be permitted if the abstract semantics were followed, is
permitted, even if the actual semantics producing that behavior are
quite different from those specified.

I've never lost sight of that; however, in this case somehow,
there is something different.

The problem is that that requirements in question, that I have
been concerned about, are not in fact necessary, the first place, for
establishing what the observable behavior is.

It's not the case that the requirements are necesary, but then
another path can be found to that observable behavior.

That is to say, the description of translation phase 7 (for the purposes
of observable behavior and conformance) could as well say that "the
tokens are smantically analyzed and translated, possibly with the help
of access to any truth whatsoever related to the entire program's
observable behavior, by means of a magic oracle." As long as no
falsehood in relation to observable behavior is relied upon by mistake,
all is well as far as ensuring the right observable behavior,
which is synonymous with conforming.