Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Michael S <already5chosen@yahoo.com>
Newsgroups: comp.lang.c
Subject: Re: A Famous Security Bug
Date: Sun, 24 Mar 2024 22:33:13 +0300
Organization: A noiseless patient Spider
Lines: 92
Message-ID: <20240324223313.000045f1@yahoo.com>
References: <bug-20240320191736@ram.dialup.fu-berlin.de>
	<20240320114218.151@kylheku.com>
	<20240321211306.779b21d126e122556c34a346@gmail.moc>
	<utkea9$31sr2$1@dont-email.me>
	<utktul$35ng8$1@dont-email.me>
	<utm06k$3glqc$1@dont-email.me>
	<utme8b$3jtip$1@dont-email.me>
	<20240324172641.00005ede@yahoo.com>
	<utptv2$hmpr$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Injection-Info: dont-email.me; posting-host="f2656d1f9feae47f01e62012b9105a2c";
	logging-data="580272"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1+e4oDnH6OH7JHAfFji/pA7DhX+PNjEwV8="
Cancel-Lock: sha1:HHikZb1dBfXFAmWyPoJCLi3iDrw=
X-Newsreader: Claws Mail 4.1.1 (GTK 3.24.34; x86_64-w64-mingw32)
Bytes: 4165

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.
> 
>