Re: A Famous Security Bug

On 25/03/2024 13:11, Michael S wrote:

On Mon, 25 Mar 2024 13:26:01 +0100
David Brown <david.brown@hesbynett.no> 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.
>

 I am not an expert, but it does not look like the problem is directly
related to compiler or linker. All 32-bit Windows compilers/linkers,
including gcc, clang and MSVC, by default put symbol ___ImageBase at
address 4 MB. However loader relocates it to wherever it wants,
typically much higher.
I don't know for sure why loader does it to images generated by gcc,
clang and MSVC and does not do it to images generated by lccwin and
others, but I have an educated guess: most likely, these other compilers
link by default with an option similar to Microsoft's /Fixed
https://learn.microsoft.com/en-us/cpp/build/reference/fixed-fixed-base-address?view=msvc-170

It's all up to the options written to the EXE file headers.
By setting the same options (plus generating base-reloc tables, plus ensuring the code can run above 2GB), I can get the EXEs written by my two compilers (for C and for my language) to be loaded at a high address too.
My compilers don't use a linker.
Some of those options are normally used only for DLLs; they would need to be set for EXEs too.
This was just an experiment; I will try adding it as a formal option to each compiler.