Re: A Famous Security Bug

On 23/03/2024 22:21, bart wrote:

On 23/03/2024 16:51, David Brown wrote:

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.

 Well, Forth is certainly cruder than C (it's barely a language IMO). But I don't remember seeing anything in it resembling a type system that corresponds to the 'i8-i64 u8-u64 f32-f64' types typical in current hardware. (Imagine trying to create a precisely laid out struct.)

Forth can be considered a typeless language - you deal with cells (or double cells, etc.), which have contents but not types.  And you can define structs with specific layouts quite easily.  (Note that I've never tried this myself - my Forth experience is /very/ limited, and you will get much more accurate information in comp.lang.forth or another place Forth experts hang out.)
A key thing you miss, in comparison to C, is the type checking and the structured identifier syntax.
In C, if you have :
struct foo {
int32_t x;
int8_t y;
uint16_t z;
};
struct foo obj;
obj.x = obj.y + obj.z;
then you access the fields as "obj.x", etc.  Your struct may or may not have padding, depending on the target and compiler (or compiler-specific extensions).  If "obj2" is an object of a different type, then "obj2.x" might be a different field or a compile-time error if that type has no field "x".
In Forth, you write (again, I could be inaccurate here) :
struct
4 field >x
1 field >y
2 field >z
constant /foo
The names - including the punctuation (punctuation characters can be freely used in identifiers in Forth) - are arbitrary.  This is equivalent to :
: >x 0 + ;
: >y 4 + ;
: >z 5 + ;
: /foo 7 ;
You make your instance "obj" by :
create obj /foo allot
which makes "obj" the address of a block of 7 bytes - but does not give it a type in any sense.  ("/foo" simply means "7").
The equivalent of "obj.x = obj.y + obj.z" would be :
obj >y c@ obj >z w@ + obj >x l!
That is :
1. Put the address of obj on the stack.
2. Add 4 to it (the definition of >y)
3. Use that as an address and fetch the 8-bit value from that address, putting it on the stack.
4. Put the address of obj on the stack.
5. Add 5 to it (the definition of >z)
6. Use that as an address and fetch the 16-bit value from that address, putting it on the stack.
7. Add the top two values from the stack and put the result on the stack.
8. Put the address of obj on the stack.
9. Add 0 to it (the definition of >x)
10. Use that as an address and store the 32-bit value from the top of the stack to that address.
I'm assuming this Forth uses 32-bit stack cells, and ignoring signed/unsigned issues for simplicity.  There are, after all, better places to find Forth tutorials for the details.
At no point is the definition of the struct type attached to "obj".  In fact, there is no struct type - there's just some defined words for adding offsets to an address (or adding those values to anything else). You can just as well write "10 >y ." to do "printf("%i", 10 + 4);".
There's therefore also no connection between the field accessor words and the type, or any requirement that they are only used with the right kind of object.  On the other hand, suppose you wanted to dispense with storing the field "x" and calculate it as "p->y + p->z" every time you needed it.  In C, you'd write:
int32_t calc_x(const struct foo * p) { return p->x + p->y; }
and replace uses of "obj.x" with "calc_x(&obj)".
In Forth, you might have defined :
: >x@ >x l@ ;
: >y@ >y c@ ;
: >z@ >z w@ ;
and used >x@ as your accessor for reading obj.x (as "obj >x@") in the rest of your code.  Now you can remove ">x" from the struct definition and write:
: >x@ dup >y@ over >z@ + ;
and all your uses of "obj >x@" remain unchanged in the rest of your code, but now they calculate x on the fly.
This is all /way/ off-topic for comp.lang.c, but it's perhaps interesting to see a completely different way of doing things in a very different language.
And note that although Forth is often byte-compiled very directly to give you exactly the actions you specify in the source code, it is also sometimes compiled to machine code - using optimisations.

 It is just too weird. I think I'd rather take my chances with C.

Forth does take some getting used to!

  > BASIC, ..., Lua, and Micropython.
 Hmm, I think my own scripting language is better at low level than any of these.

These all have one key advantage over your language - they are real languages, available for use by /other/ programmers for development of products.

It supports those low-level types for a start. And I can do stuff like this:
     println peek(0x40'0000, u16):"m"
     fun peek(addr, t=byte) = makeref(addr, t)^
 This displays 'MZ', the signature of the (low-)loaded EXE image on Windows
 Possibly it is even better than C; is this little program valid (no UB) C, even when it is known that the program is low-loaded:
     #include <stdio.h>
    typedef unsigned char byte;
     int main(void) {
        printf("%c%c\n", *(byte*)0x400000, *(byte*)0x400001);
    }
 This works on DMC, tcc, mcc, lccwin, but not gcc because that loads programs at high addresses. The problem being that the address involved, while belonging to the program, is outside of any C data objects.
 

I think you are being quite unreasonable in blaming gcc - or C - for generating code that cannot access that particular arbitrary address! The addresses accessible in a program are defined by the OS and the target environment, not the language or compiler.  And C has a perfectly good way of forcing access to addresses - use "volatile".