Re: A Famous Security Bug

On Sun, 24 Mar 2024 19:12:35 +0000
bart <bc@freeuk.com> wrote:

On 24/03/2024 14:26, Michael S wrote:

On Sat, 23 Mar 2024 11:26:03 +0000
bart <bc@freeuk.com> 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.
 

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.
 

 
Does it apply to your aarch64 compiler as well? 

 
I don't support arm64 as a native C (only via intermediate C). Why,
is there something peculiar about that architecture?
>

Nothing specific to ARM64 in this particular case. The same problem
would apply to any instruction set with maximal instruction width <= 32
bits.

For smaller immediates, ARM64 does have encoding rules that can be
surprising.

I would expect that 0x12345678 pattern to still be in memory but
probably not in an immediate instruction field.

Not necessarily. Compiler can use several strategies.
E.g. https://godbolt.org/z/vMcaxcs7G

So if wanted to mark
a location in the code, I might need a different approach.
>

Exactly.

If I ever do directly target that processor, I'll be able to tell you
more.