Re: A Famous Security Bug

On 22/03/2024 18:20, Kaz Kylheku wrote:

On 2024-03-22, Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:

Kaz Kylheku <433-929-6894@kylheku.com> writes:

>
Are you claiming that a function call is observable behavior?

 Yes. It is the observable behavior of an unlinked translation unit.
 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.

That is "observable" in the same sense that the size of a compiled object file is "observable" by executing "ls -l".  It is not "observable behaviour" as defined by the C standards.
C defines "observable behaviour" for /programs/.  Not for translation units, or translated translation units (what one might call an "object file" - be it assembly, machine code, or internal compiler-specific formats).
For C, it makes no sense to talk about "observable behaviour" for a unit.  It is only by linking the unit to your test harness that you get a "program", which then has "observable behaviour".

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

The contents of an object file - or the instructions used in a complete program - are not "observable behaviour" in C.  Again, I refer you to 5.1.2.2.2p6.

 

If an implementation doesn't generate
that "call" instruction because it's able to determine at link time that
the call does nothing, that optimization is forbidden?

 The text says so. Translation units are separate; semantic analysis is
finished in translation phase 7; linking in 8.

The text also says (in footnotes) that the phases are for conceptual description only, and in practice they are typically folded together.

What wording in the standard requires a "call" instruction to be
generated if they're in different translation units?
>
That's a trivial example, but other link time optimizations that don't
change a program's observable behavior (insert weasel words about
unspecified behavior) are also allowed.

 An example would be the removal of material that is not referenced,
like functions not called anywhere, or entire translation units
whose external names are not referenced. That can cause issues too,
and I've run into them, but I can't call that nonconforming.
Nothing is semantically analyzed across translation units, only the
linkage graph itself, which may be found to be disconnected.
 

Removal of unreferenced material at link time is very common.  In some fields, it is standard practice to use compiler and linker flags geared at making this easier.  It is not really any different than using static libraries - the linker will load all requested static libraries, then throw out all parts that are not transitively reachable from non-library code.
The inclusion or not of material in the program image is not directly observable behaviour in C - there is no way to write portable C code to determine if the function "foo" has been included in the image despite never being referenced.  (You can, of course, have the linker include information about the image inside the image itself and read that with volatile accesses from within the program.)
In small-systems embedded programming, "-ffunction-sections" and "-fdata-sections", along with "-Wl,--gc-sections", are almost invariably used for gcc to reduce the size of the final image.  It makes it much more practical to write re-usable code even if not all functions are used in any given application.  I have never heard of it "causing issues", and I cannot see how it might be non-conforming.  (And if it is not a conformance issue, how is it relevant here?)

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 C standard doesn't deal with CPU instructions.  It does not have a concept of "running" a translated translation unit - you can only run a complete program, at which point there is no distinction between the translation units that are "collected" into the program image.  It's all fused together into one big lump, with one set of observable behaviours.