Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: David Brown <david.brown@hesbynett.no>
Newsgroups: comp.lang.c
Subject: Re: A Famous Security Bug
Date: Sat, 23 Mar 2024 17:51:12 +0100
Organization: A noiseless patient Spider
Lines: 125
Message-ID: <utn1a0$3ogob$1@dont-email.me>
References: <bug-20240320191736@ram.dialup.fu-berlin.de>
 <20240320114218.151@kylheku.com>
 <20240321211306.779b21d126e122556c34a346@gmail.moc>
 <utkea9$31sr2$1@dont-email.me> <utktul$35ng8$1@dont-email.me>
 <utm06k$3glqc$1@dont-email.me> <utme8b$3jtip$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Sat, 23 Mar 2024 16:51:12 -0000 (UTC)
Injection-Info: dont-email.me; posting-host="78504154b5b778976e0d4e96fcf6a85e";
	logging-data="3949323"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1+qajFyIj7wSLAML8V7iOyhBVamO5AU3NM="
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:Ls7+v8SAyy7e3my4bOwW2O5FrCY=
Content-Language: en-GB
In-Reply-To: <utme8b$3jtip$1@dont-email.me>
Bytes: 6378

On 23/03/2024 12:26, bart wrote:
> On 23/03/2024 07:26, James Kuyper wrote:
>> bart <bc@freeuk.com> writes:
>>> On 22/03/2024 17:14, James Kuyper wrote:
>> [...]
>>>> If you want to tell a system not only what a program must do, but
>>>> also how it must do it, you need to use a lower-level language than
>>>> C.
>>>
>>> Which one?
>>
>> That's up to you. The point is, C is NOT that language.
> 
> I'm asking which /mainstream/ HLL is lower level than C. So specifically 
> ruling out assembly.
> 
> If there is no such choice, then this is the problem: it has to be C or 
> nothing.

How much of a problem is it, really?

My field is probably the place where low level programming is most 
ubiquitous.  There are plenty of people who use assembly - for good 
reasons or for bad (or for reasons that some people think are good, 
other people think are bad).  C is the most common choice.

Other languages used for small systems embedded programming include C++, 
Ada, Forth, BASIC, Pascal, Lua, and Micropython.  Forth is the only one 
that could be argued as lower-level or more "directly translated" than C.

The trick to writing low-level code in C (or C++) is not to pretend that 
C is a "directly translated" language, or to fight with your compiler. 
It is to learn how to work /with/ your compiler and its optimisations to 
get what you need.  Complaining that "LTO broke my code" does not make 
your product work.  Arbitrarily disabling optimisations that you feel 
are "bad" or imagine to be non-conforming is just kicking the can down 
the road.  You learn what /actually/ works - as guaranteed by the C 
standards, or by your compiler.

Sometimes that means using compiler-specific or target-specific 
extensions.  That's okay.  No one ever suggested that pure C-standard C 
code was sufficient for all tasks.  C was designed to allow some coding 
to be done in a highly portable and re-usable manner, and also to 
support non-portable systems programming relying on the implementation, 
and this has not changed.  When I write code for low-level use on a 
specific microcontroller, I am not writing portable code anyway.

So what language is lower level than C?  GCC C (or clang C, or IAR C for 
the 8051, or any other specific C compiler).

How would /I/ ensure that after "memset(buffer, 0, sizeof(buffer));" 
that the buffer was really written with zeros?  I'd follow it with:

	asm ("" : "+m" (buffer));

That's a gcc extension, but it will guarantee that the buffer is cleared 
- without any other costs.

(Alternatively, I'd clear the memory using volatile writes, rather than 
memset.)

> 
>>> I don't think anyone seriously wants to switch to assembly for the
>>> sort of tasks they want to use C for.
>>
>> Why not? Assembly provides the kind of control you're looking for; C
>> does not. If that kind of control is important to you, you have to find
>> a language which provides it. If not assembler or C, what would you use?
> 
> Among non-mainstream ones, my own would fit the bill. Since I write the 
> implementations, I can ensure the compiler doesn't have a mind of its own.
> 
> However if somebody else tried to implement it, then I can't guarantee 
> the same behaviour. This would need to somehow be enforced with a 
> precise language spec, or mine would need to be a reference 
> implementation with a lot of test cases.
> 
> 
> -----------------
> 
> Take this program:
> 
>    #include <stdio.h>
>    int main(void) {
>        goto L;
>        0x12345678;
>    L:
>        printf("Hello, World!\n");
>    }
> 
> If I use my compiler, then that 12345678 pattern gets compiled into the 
> binary (because it is loaded into a register then discarded). That means 
> I can use that value as a marker or sentinel which can be searched for.
> 
> However no other compiler I tried will do that. If I instead change that 
> line to:
> 
>      int a = 0x12345678;
> 
> then a tcc-compiled binary will contain that value. So will 
> lccwin32-compiled (with a warning). But not DMC or gcc.
> 
> If I get rid of the 'goto' , then gcc-O0 will work, but still not DMC or 
> gcc-O3.
> 
> Here I can use `volatile` to ensure that value stays in, but not if I 
> put the 'goto' back in!
> 
> It's all too unpredictable.
> 

The /minimum/ requirements of the compiler are very predictable.  The 
details beyond that are not - which is completely as expected.  You are 
trying to achieve an effect that cannot be expressed in C, and thus it 
is folly to expect a simple way to achieve it with any C compiler.  You 
will find that with many C compilers you can get what you want, but you 
have to write it in a way that suits the compiler.  For gcc, you might 
do it by putting a const variable in an explicit linker section using a 
gcc-specific __attribute__.  Maybe you can get it by using a volatile 
and /not/ removing the "goto".

But if you want to do something that has no semantic meaning in the 
language you are using, you can't expect compilers to support a 
particular way to achieve this!