Path: ...!feeds.phibee-telecom.net!2.eu.feeder.erje.net!feeder.erje.net!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Keith Thompson <Keith.S.Thompson+u@gmail.com>
Newsgroups: comp.lang.c
Subject: Re: A Famous Security Bug
Date: Thu, 21 Mar 2024 13:46:18 -0700
Organization: None to speak of
Lines: 82
Message-ID: <87a5mr1ffp.fsf@nosuchdomain.example.com>
References: <bug-20240320191736@ram.dialup.fu-berlin.de>
	<20240320114218.151@kylheku.com> <uthirj$29aoc$1@dont-email.me>
	<20240321092738.111@kylheku.com>
MIME-Version: 1.0
Content-Type: text/plain
Injection-Info: dont-email.me; posting-host="0bf58c5e3e50115de10475b5e7b86fc1";
	logging-data="2555344"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX18YJSAMYzAHgY2S/1mquPZQ"
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.2 (gnu/linux)
Cancel-Lock: sha1:5IwFfga2XoaNsqclJf60yxWh5xw=
	sha1:EVE7EBpS7QvAjLik3VTShMVd0d4=
Bytes: 4826

Kaz Kylheku <433-929-6894@kylheku.com> writes:
> On 2024-03-21, David Brown <david.brown@hesbynett.no> wrote:
>> On 20/03/2024 19:54, Kaz Kylheku wrote:
>>> On 2024-03-20, Stefan Ram <ram@zedat.fu-berlin.de> wrote:
>>>>    A "famous security bug":
>>>>
>>>> void f( void )
>>>> { char buffer[ MAX ];
>>>>    /* . . . */
>>>>    memset( buffer, 0, sizeof( buffer )); }
>>>>
>>>>    . Can you see what the bug is?
>>> 
>>> I don't know about "the bug", but conditions can be identified under
>>> which that would have a problem executing, like MAX being in excess
>>> of available automatic storage.
>>> 
>>> If the /*...*/ comment represents the elision of some security sensitive
>>> code, where the memset is intended to obliterate secret information,
>>> of course, that obliteration is not required to work.
>>> 
>>> After the memset, the buffer has no next use, so the all the assignments
>>> performed by memset to the bytes of buffer are dead assignments that can
>>> be elided.
>>> 
>>> To securely clear memory, you have to use a function for that purpose
>>> that is not susceptible to optimization.
>>> 
>>> If you're not doing anything stupid, like link time optimization, an
>>> external function in another translation unit (a function that the
>>> compiler doesn't recognize as being an alias or wrapper for memset)
>>> ought to suffice.
>>
>> Using LTO is not "stupid".  Relying on people /not/ using LTO, or not 
>> using other valid optimisations, is "stupid".
>
> LTO is a nonconforming optimization. It destroys the concept that
> when a translation unit is translated, the semantic analysis is
> complete, such that the only remaining activity is resolution of
> external references (linkage), and that the semantic analysis of one
> translation unit deos not use information about another translation
> unit.
>
> This has not yet changed in last April's N3096 draft, where
> translation phases 7 and 8 are:
>
>   7. White-space characters separating tokens are no longer significant.
>      Each preprocessing token is converted into a token. The resulting
>      tokens are syntactically and semantically analyzed and translated
>      as a translation unit.
>
>   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.
>
> and before that, the Program Structure section says:
>
>   The separate translation units of a program communicate by (for
>   example) calls to functions whose identifiers have external linkage,
>   manipulation of objects whose identifiers have external linkage, or
>   manipulation of data files. Translation units may be separately
>   translated and then later linked to produce an executable program.
>
> LTO deviates from the the model that translation units are separate,
> and the conceptual steps of phases 7 and 8.
[...]

Link time optimization is as valid as cross-function optimization *as
long as* it doesn't change the defined behavior of the program.

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.

-- 
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Medtronic
void Void(void) { Void(); } /* The recursive call of the void */