Re: A Famous Security Bug

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

Is the "call" instruction *observable behavior* as defined in 5.1.2.3?

No it isn't. The Boolean fact whether or not that call is taken can be
tied to observable behavior elsewhere, though.

>
[...]
>

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.

It's a different program, but the retained translation unit must be the
same, except that the external references it makes are resolved to
different entities.

If in one program we have an observable behavior which implies that a
call took place (that itself not being directly observable, by
definition, I again acknowledge) then under the same conditions in
another program, that call also has to take place, by the fact that the
translation unit has not changed.

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

If i is an object with external linkage defined outside of some
tranlation unit and some function in the translation unit
unconditionally increments i (without further using its value), then
that has to happen, even in a program in which nothing else uses i.

By this blackbox method I'm describing, no, we cannot confirm whether
it's by an inc instruction or whatever. Just, does it happen.

In one test program we can tie that to observable behavior, like
printing the value of i before and after calling that function.

Though the increment isn't observable behavior (unless i is volatile?),
since it has been confirmed that the translation unit does that, it does
that.

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

That translation phase 7 is described as completing semantic analysis,
resulting in a translated unit which may be retained. (Moreover,
analysis of a single unit, not multiple.) and that 8 is described
as only resolving references and linking.

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca