Re: A Famous Security Bug

On Sat, 23 Mar 2024 21:21:58 +0000
bart <bc@freeuk.com> 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.)
 
It is just too weird. I think I'd rather take my chances with C.
 
 > BASIC, ..., Lua, and Micropython. 
 
Hmm, I think my own scripting language is better at low level than
any of these. 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.
 
 

#include <stdio.h>
#include <stddef.h>

int main(void)
{
  char* p0 = (char*)((size_t)main & -(size_t)0x10000);
  printf("%c%c\n", p0[0], p0[1]);
  return 0;
}


That would work for small programs. Not necessarily for bigger
programs.