Path: ...!news.nobody.at!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: bart <bc@freeuk.com>
Newsgroups: comp.lang.c
Subject: Re: A Famous Security Bug
Date: Tue, 26 Mar 2024 00:34:14 +0000
Organization: A noiseless patient Spider
Lines: 73
Message-ID: <utt567$1dair$1@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>
 <utqaak$kfuv$2@dont-email.me> <20240325141628.00006170@yahoo.com>
 <utrqgp$12v02$1@dont-email.me> <uts7e0$1686i$1@dont-email.me>
 <20240325195118.0000333a@yahoo.com> <utsemf$18477$1@dont-email.me>
 <20240326000501.00007d6d@yahoo.com> <utsq47$1atlm$1@dont-email.me>
 <20240326023103.00004ea0@yahoo.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Tue, 26 Mar 2024 01:34:15 +0100 (CET)
Injection-Info: dont-email.me; posting-host="7b32b1f0d0f59a306dc9e204152d2f32";
	logging-data="1485403"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1/x1dSkta66zBNPuTb4IpcA"
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:2Me7X53TngAT9tKRp3qLn2TaF3A=
In-Reply-To: <20240326023103.00004ea0@yahoo.com>
Content-Language: en-GB
Bytes: 4684

On 25/03/2024 23:31, Michael S wrote:
> On Mon, 25 Mar 2024 21:25:27 +0000
> bart <bc@freeuk.com> wrote:

>>> Your explanation exactly matches what I was imagining.
>>> The technology for relocation of non-PIC code is already here, in
>>> file format definitions and in OS loader code. The linker or the
>>> part of compiler that serves the role of linker can decide to not
>>> generate required tables. Operation in such mode will have small
>>> benefits in EXE size and in quicker load time, but IMHO nowadays it
>>> should be used rarely, only in special situations rather than serve
>>> as a default of the tool.
>>
>> There are two aspects to be considered:
>>
>> * Relocating a program to a different address below 2GB
>>
>> * Relocating a program to any address including above 2GB
>>
>> The first can be accommodated with tables derived from the reloc info
>> of object files.
>>
>> But the second requires compiler cooperation in generating code that
>> will work above 2GB.
>>
>> Part of that can be done with RIP-relative address modes as I touched
>> on. But not all; RIP-relative won't work here:
>>
>>       movsx rax, dword [i]
>>       mov rax, [rbx*8 + abc]
>>
>> where the address works with registers. This requires something like:
>>
>>       lea rcx, [rip:abc]         # or mov rcx, abc   (64-bit abs addr)
>>       mov rax, [rbx*8 + rcx]
>>
>> This is specific to x64, but other processors will have their issues.
>> Like ARM64 which doesn't even have the 32-bit displayment used with
>> rip here.
>>
> 
> You mean, when compiler knows that the program is loaded at low address
> and when combined data segments are relatively small then compiler can
> use zero-extended or sign-extended 32-bit literals to form 64-bit
> addresses of static/global objects?
> I see how relocation of such program is a problem in 64-bit mode, but
> still fail to see how similar problem could happen in 32-bit mode.
> 

At 32 bits the problems of high-loading disappear, as programs and data 
need to fit into 2GB.

Some problems with relocating remain. RIP-relative can't be used, as I 
believe that works only in 64-bit mode.

What remains are the base-relocations, which had in the past only been 
needed when generating dynamic libraries like DLLs. They just weren't a 
thing for EXE.

This then reduces to whether the C toolset will generate the right EXE. 
Either it does or doesn't, but you can always choose a different compiler.

All I can tell you is that of the suite of 5 compilers I've tried, 4 of 
them, including in 32-bit mode if supported, don't generate an EXE that 
will be loaded at an arbitrary address. Only gcc will do that.

The same goes for Clang run at rextester.com: that doesn't load high 
(but it could also be an old version).

Maybe some don't think it's that important. But it's not as 
straightforward as you seem to think. Yes, it might have been a bit 
simpler with 32 bits, but it wasn't trendy then, and not not many still 
use 32 bits.