Path: ...!2.eu.feeder.erje.net!3.eu.feeder.erje.net!feeder.erje.net!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Kaz Kylheku <433-929-6894@kylheku.com>
Newsgroups: comp.lang.c
Subject: Re: A Famous Security Bug
Date: Sat, 23 Mar 2024 16:06:34 -0000 (UTC)
Organization: A noiseless patient Spider
Lines: 65
Message-ID: <20240323085544.1@kylheku.com>
References: <bug-20240320191736@ram.dialup.fu-berlin.de>
 <20240320114218.151@kylheku.com>
 <20240321211306.779b21d126e122556c34a346@gmail.moc>
 <20240321131621.321@kylheku.com> <utk1k9$2uojo$1@dont-email.me>
 <20240322083037.20@kylheku.com> <utkgd2$32aj7$1@dont-email.me>
 <wwva5mpwbh0.fsf@LkoBDZeT.terraraq.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Injection-Date: Sat, 23 Mar 2024 16:06:34 -0000 (UTC)
Injection-Info: dont-email.me; posting-host="bc8ead67574eda43cc8acb80cc4a36a2";
	logging-data="3926330"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX19D4IiLDlMKPlmV1RbUgDeU18Yz6AVmGGI="
User-Agent: slrn/pre1.0.4-9 (Linux)
Cancel-Lock: sha1:jukafmldlcFSJXR04xl5LEG2bI4=
Bytes: 4104

On 2024-03-23, Richard Kettlewell <invalid@invalid.invalid> wrote:
> David Brown <david.brown@hesbynett.no> writes:
>> I have tried to explain the reality of what the C standards say in a
>> couple of posts (including one that I had not posted before you wrote
>> this one).  I have tried to make things as clear as possible, and
>> hopefully you will see the point.
>>
>> If not, then you must accept that you interpret the C standards in a
>> different manner from the main compile vendors, as well as some "big
>> names" in this group.  That is, of course, not proof in itself - but
>> you must realise that for practical purposes you need to be aware of
>> how others interpret the standard, both for your own coding and for
>> the advice or recommendations you give to others.
>
> Agreed that the ship has sailed on whether LTO is a valid optimization.

There is no question that LTO is a "valid" optimization for reasonable
definitions of valid.

> But it’s understandable why someone might reach a different conclusion.

That alone is a problem.

> - Phase 7 says the tokens are “semantically analyzed and translated as a
>   translation unit”.
>
> - Phase 8 does not use either verb, “analyzed” or “translated”.

That adds up to requirements that are /obviously/ violated by LTO.

Someone might reach a different conclusion simply by reading the
black-and-white text, which obviously spells out what is required.

When reading the standard, you can't just ignore bits you think
are wrong.

It may be the case that a strictly conforming program cannot tell
whether these requirements are violated.

Strictly conforming programs are not the be all and end all of what is
important.

In the academic paradigm of a strictly conforming program, a security
problem of bytes not being nulled out (or any other such thing) does not
exist.

> This would be very easy to address, by replacing “collected” with a word
> or phrase that makes clear that further analysis and translation can
> happen outside the “as a translation unit” context.

No, it's not that easy to address. The standard should make explicit
provisions for LTO. There should be an optional translation phase
between the current 7 and 8 in which translation units may be
partitioned into subsets, an then subject to semantic analysis
and further translation within the subsets, prior to linking.

The standard wouldn't describe how the partitioning is requested from
the implementation, since it is part of the manner in which a program is
presented to it.  All implementations should support a translation mode
in which no partitioning into subsets takes place.

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