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: Mon, 25 Mar 2024 19:07:35 +0100
Organization: A noiseless patient Spider
Lines: 95
Message-ID: <utseh7$181cd$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>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Mon, 25 Mar 2024 19:07:36 +0100 (CET)
Injection-Info: dont-email.me; posting-host="8bb1363eb201d723c16a92a0d69da8a9";
	logging-data="1312141"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX199sdb8q2U5r6AdFZeMRA3FubFkpvs2Ib8="
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:jNXWfRIY5DO/1hoLu//8GKyTcyQ=
In-Reply-To: <uts7e0$1686i$1@dont-email.me>
Content-Language: en-GB
Bytes: 4925

On 25/03/2024 17:06, bart wrote:
> On 25/03/2024 12:26, David Brown wrote:
>> On 25/03/2024 12:16, Michael S wrote:
>>> On Sun, 24 Mar 2024 23:43:32 +0100
>>> David Brown <david.brown@hesbynett.no> wrote:
>>>>
>>>> I could be  wrong here, of course.
>>>>
>>>
>>> It seems, you are.
>>>
>>
>> It happens - and it was not unexpected here, as I said.  I don't have 
>> all these compilers installed to test.
>>
>> But it would be helpful if you had a /little/ more information.  If 
>> you don't know why some compilers generate binaries that have memory 
>> mapped at 0x400000, and others do not, fair enough.  I am curious, but 
>> it's not at all important.
>>
> 
> In the PE EXE format, the default image load base is specified in a 
> special header in the file:
> 
>    Magic:            20B
>    Link version:     1.0
>    Code size:        512 200
>    Idata size:       1024 400
>    Zdata size:       512
>    Entry point:      4096 1000 in data:0
>    Code base:        4096
>    Image base:       4194304 400000
>    Section align:    4096
> 
> By convention it is at 0x40'0000 (I've no idea why).
> 
> More recently, dynamic loading, regardless of what it says in the PE 
> header, has become popular with linkers. So, while there is still a 
> fixed value in the Image Base file, which might be 0x140000000, it gets 
> loaded at some random address, usually in high memory above 2GB.
> 
> I don't know what's responsible for that, but presumably the OS must be 
> in on the act.
> 
> To make this possible, both for loading above 2GB, and for loading at an 
> address not known by the linker, the code inside the EXE must be 
> position-independent, and have relocation info for any absolute 64-bit 
> static addresses. 32-bit static addresses won't work.
> 
> If I take this C program:
> 
>      #include <stdio.h>
>      int main(void) {
>          printf("%p\n", main);
>      }
> 
> This shows 0000000000401000 when compiled with mcc or tcc, or 
> 0000000000401020 with lccwin32 (the exact address of 'main' relative to 
> the image base will vary). With DMC (32 bits) it's 0040210. All load at 
> 0x400000.
> 
> With gcc, it shows: 00007ff6e63a1591.
> 
> Dynamic loading can be disabled by passing --disable-dynamicbase to ld, 
> then it might show something like 0000000140001000, which corresponds to 
> the default Image Base file in the EXE header
> 
> Not dynamic, but still high.
> 
> (My compilers, both for C and M, did not generate code suitable for 
> high-loading until a few months ago. That didn't matter since the EXEs 
> loaded at the fixed 0x400000 adddress. But it can matter for DLL files 
> and will do for OBJ files, since the latter would need to use an 
> external linker.
> 
> So if I do this with a mix of mcc and gcc:
> 
>    C:\c>mcc test -c
>    Compiling test.c to test.obj
> 
>    C:\c>gcc test.obj
> 
>    C:\c>a
>    00007FF613311540
> 
> I get the same high-loaded address. I don't think that Tiny C has that 
> support yet for high-loading code.)
> 
> To summarise: the high-loading is not directly to do with compilers, but 
> the program that generates the EXE. But the compiler does need to 
> generate code that could be loaded high if needed.

Thanks for that explanation - it fills in some blanks in my understanding.