Re: A Famous Security Bug

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!