Sujet : Re: A Famous Security Bug
De : Keith.S.Thompson+u (at) *nospam* gmail.com (Keith Thompson)
Groupes : comp.lang.cDate : 22. Mar 2024, 19:21:40
Autres entêtes
Organisation : None to speak of
Message-ID : <87cyrmyvnv.fsf@nosuchdomain.example.com>
References : 1 2 3 4 5 6 7 8
User-Agent : Gnus/5.13 (Gnus v5.13) Emacs/27.2 (gnu/linux)
Kaz Kylheku <
433-929-6894@kylheku.com> writes:
On 2024-03-22, Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
Kaz Kylheku <433-929-6894@kylheku.com> writes:
Since ISO C says that the semantic analysis has been done (that
unit having gone through phase 7), we can take it for granted as a
done-and-dusted property of that translation unit that it calls bar
whenever its foo is invoked.
>
We can take it for granted that the output performed by the printf call
will be performed, because output is observable behavior. If the
external function bar is modified, the LTO step has to be redone.
>
That's what undeniably has to be done in the LTO world. Nothing that
is done brings that world into conformance, though.
>
Say I have a call to foo in main, and the definition of foo is in
another translation unit. In the absence of LTO, the compiler will have
to generate a call to foo. If LTO is able to determine that foo doesn't
do anything, it can remove the code for the function call, and the
resulting behavior of the linked program is unchanged.
>
There always situations in which optimizations that have been forbidden
don't cause a problem, and are even desirable.
>
If you have LTO turned on, you might be programming in GNU C or Clang C
or whatever, not standard C.
>
Sometimes programs have the same interpretation in GNU C and standard
C, or the same interpretation to someone who doesn't care about certain
differences.
>
Are you claiming that a function call is observable behavior?
>
Yes. It is the observable behavior of an unlinked translation unit.
An unlinked translation unit has no observable behavior in the way that
term is defined by the standard.
It can be observed by linking a harness to it, with a main() function
and all else that is required to make it a complete program.
That harness becomes an instrument for observation.
And a "call" instruction in a program consisting of a single translation
unit can be observed in a variety of ways. That doesn't make it
"observable behavior".
Are you using the phrase "observable behavior" in a sense other than
what's defined in N1570 5.1.2.3?
[...]
Are you saying that the "call" instruction generated for the function
call is *observable behavior*?
>
Of course; it can be observed externally, without doing any reverse
engineering on the translated unit.
Is the "call" instruction *observable behavior* as defined in 5.1.2.3?
[...]
In phase 8:
All external object and function references are resolved. Library
components are linked to satisfy external references to functions
and objects not defined in the current translation. All such
translator output is collected into a program image which contains
information needed for execution in its execution environment.
>
I don't see anything about required CPU instructions.
>
I don't see anything about /removing/ instructions that have to be
there according to the semantic analysis performed in order to
translate those units from phases 1 - 7, and that can be confirmed
to be present with a test harness.
The standard doesn't mention either adding or removing instructions.
Running a program under a test harness is effectively running a
different program. Of course it can yield information about the
original program, but in effect you're linking the program with a
different set of libraries.
I can use a test harness to observe whether a program uses an add or inc
instruction to evaluate `i++` (assuming the CPU has both instructions).
The standard doesn't care how the increment happens, as long as the
result is correct. It doesn't care *whether* the increment happens
unless the result affects the programs *observable behavior*.
What in the description of translation phases 7 and 8 makes
behavior-preserving optimizations valid in phase 7 and forbidden in
phase 8? (Again, insert weasel words about unspecified behavior.)
-- Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.comWorking, but not speaking, for Medtronicvoid Void(void) { Void(); } /* The recursive call of the void */