Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: David Brown <david.brown@hesbynett.no>
Newsgroups: comp.lang.c
Subject: Re: A Famous Security Bug
Date: Sun, 24 Mar 2024 23:43:32 +0100
Organization: A noiseless patient Spider
Lines: 40
Message-ID: <utqaak$kfuv$2@dont-email.me>
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>
 <utn1a0$3ogob$1@dont-email.me> <utnh5m$3sdhk$1@dont-email.me>
 <utpenn$dtnq$1@dont-email.me> <utq0gh$i9hm$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Sun, 24 Mar 2024 23:43:33 +0100
Injection-Info: dont-email.me; posting-host="af297f15341d352325f54a52911dae41";
	logging-data="671711"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1/ZaXxSPCiN5bKtCJu08OJ6HGCGgZzWcXw="
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:/IBhr1YZ5LThPCtObaGDXCLTC5g=
In-Reply-To: <utq0gh$i9hm$1@dont-email.me>
Content-Language: en-GB
Bytes: 2922

On 24/03/2024 20:56, bart wrote:
> On 24/03/2024 14:52, David Brown wrote:
>> On 23/03/2024 22:21, bart wrote:
> 

> 
>>> 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! 
> 
> There were two separate points here. One is that a gcc-compiled version 
> won't work because exe images are not loaded at 0x40'0000. 

I think that is because your gcc toolchain is creating 64-bit Windows 
binaries, while the others are creating 32-bit binaries.  I could be 
wrong here, of course.

> The other was 
> me speculating whether the access to 0x40'0000, even when valid memory 
> for this process, was UB in C.
> 

Trying to access non-existent memory is UB, yes.  I can't imagine a 
language where such a thing would be anything else than undefined 
behaviour, or defined as a hard run-time error.

But you can run something with UB if you want - at your own risk, 
because C and the compiler give you no guarantees of what will happen. 
But if you write "x = *(volatile uint8_t *) 0x400000;", then you can 
guarantee that the code will at least /try/ to read that address.  What 
happens depends on the OS, memory protection systems, etc.  But it is 
not exactly difficult to do this kind of thing in C - that's why 
"volatile" exists.