From: james.harris.1@gmail.com   
      
   On 30/11/2023 06:35, wolfgang kern wrote:   
   > On 29/11/2023 09:49, James Harris wrote:   
   >> On 28/11/2023 11:26, wolfgang kern wrote:   
   > ...   
   >   
   >>>> How would you get the right address if you don't work it out   
   >>>> relative to RIP? AIUI the UEFI firmware makes no guarantees as to   
   >>>> where it loads you code.   
   >   
   >>> while with 32bit it can use CS override.   
   >>> with 64bit I need a one time "where I am" like:   
   >>> CALL next   
   >>> next:   
   >>> POP R15   
   >   
   >> A few points:   
   >>   
   >> 1. x86 32-bit UEFI boot may not be widely supported. You may be better   
   >> to be able to boot a 64-bit UEFI OS loader and switch to 32-bit mode   
   >> if you want to start a 32-bit OS.   
   >>   
   >> 2. If UEFI load addresses aren't guaranteed then consider these   
   >> scenarios:   
   >>   
   >> a) Code at 1000, data at 1400   
   >> b) Code at 2000, data at 2400   
   >   
   > I cannot believe that it may randomly load to different locations.   
      
   Why not? A UEFI app (such as a bootloader) is just an app as far as UEFI   
   is concerned. Where it gets loaded is not specified as it was with BIOS.   
   There's no simple 0x7c00 any more! The actual location of one's   
   bootloader will likely depend on who wrote the firmware, what /version/   
   of the firmware is being used, what drivers have been loaded beforehand,   
   what happened on the machine before it loaded our bootloader, etc.   
      
   > there must be some rule ie: dependent on media sector size.   
   >   
   >> What you need is data /relative to code/. Having a CS override   
   >> wouldn't help if you don't know where your code and data will be   
   >> relative to CS.   
   >   
   > when I write the file I know the data offset from within the code.   
   > yours is 0x0400 for the text test. Mine will be much larger (>64K).   
   >   
   >> 3) If writing a 32-bit UEFI OS loader you could use call/pop to get   
   >> data address relative to wherever the code happens to have been loaded.   
   >>   
   >> 4) In x64 you don't need call/pop but can use RIP-relative references   
   >> as in   
   >>   
   >>    lea rdx, [rel msg_hello]   
   >>   
   >> for which the hex is   
   >>   
   >>    48 8d 15 e7 1f 00 00     lea    rdx,[rip+0x1fe7]   
   >   
   > OK I see it, but it is limited to 64k distance (same as in 32bit).   
      
   Are you sure it's not +/- 2G? (Those zeroes...!)   
      
   >   
   > my one time self relocation used on start of several temporary dynamic   
   > loaded modules (all static stuff is at fixed offsets as part of OS).   
   >   
   > E8 0000_0000  CALL next   
   > 5A            POP  ESI   
   > ...           adjust with known offsets   
      
   That's fine, too, especially if used only once and not in tight nested   
   loops.   
      
   >   
   > How would a 64bit version with larger than 64k code size look like?   
      
   As I say, +/- 2G should be available.   
      
   >   
   >   
   >> 5) The choices are to write PIC code or use relocation but bear in   
   >> mind that UEFI firmware has to see your final PE file as something it   
   >> is willing to load and execute so it might expect some flags or   
   >> indicators to tell it that the file is PIC or, failing that, that it   
   >> comes with a relocation section.   
   >   
   > you mean UEFI will disassemble my code before loading it ?   
      
   :-)   
      
   No, but remember that a bootloader has to be in PE format and such a   
   format has descriptive fields in its headers. The firmware will   
   naturally only load files if it likes what it sees in the headers.   
      
   > we need to learn what exactly is required to make UEFI load and execute.   
      
   That has to come from the spec because there are many implementations -   
   both present and future.   
      
   >   
   >> UEFI is a lot more fussy than BIOS as to what it will hand control to.   
   >   
   > Oh yeah, that was the reason for I stopped all business with KESYS.   
   >   
   > BTW, you have a working text test?   
   > can you read out a few registers and print the values?   
   > it would be interesting what we get on start, especially RSP.   
      
   I have working text output but not number output in Asm. I could add it   
   but it doesn't seem useful for this as the contents of registers which   
   are not mentioned in the spec are unlikely to be consistent, AFIACS.   
      
      
   --   
   James Harris   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)