Re: A Famous Security Bug

On Sun, 24 Mar 2024 18:58:24 +0000
bart <bc@freeuk.com> wrote:

On 24/03/2024 15:53, Michael S wrote:

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.
 

 
I'm not sure how that works.

Neither do I.

Are EXE images always loaded at multiple
of 64KB? I suppose on larger programs it could search backwards 64KB
at a time (although it could also hit on a rogue 'MZ' in program
data).
 
My point however was whether C considered that p0[0] access UB
because it doesn't point into any C data object.
>

Well, C does not even have to run on von Neumann computers. Harward or
even less obvious targets than Harward are both legal and used in
practice. So, of course, any use of code object as data object is UB.

The code below is not UB. IMHO. But it is not portable outside of
compilers based on gcc infrastructure. Probably, not portable outside of
Windows OS, too. But who needs to look for 'MZ' outside Windows?

#include <stdio.h>
extern char __image_base__[];
int main(void)
{
  printf("%c%c\n", __image_base__[0], __image_base__[1]);
  return 0;
}

If so, it would make access to memory-mapped devices or
frame-buffers, or implementing things like garbage collectors,
problematical.

Implementation-defined linker tricks like the one above can be used
(or should I say "are used" ?) for implementing dynamic memory. I don't
see why they can't be used to implement GC. They are not portable, but
I don't believe that they are UB. At least not as long as one does not
consider data races.