On Wed, 21 Jun 2023 at 13:09, Borislav Petkov <bp@xxxxxxxxx> wrote: > > On Wed, Jun 07, 2023 at 09:23:27AM +0200, Ard Biesheuvel wrote: > > The 32-bit decompressor does not actually use a global offset table > > (GOT), but as is common for 32-bit position independent code, it uses > > the magic symbol _GLOBAL_OFFSET_TABLE_ as an anchor from which to derive > > the actual runtime addresses of other symbols, using special @GOTOFF > > symbol references that are resolved at link time, and populated with the > > distance between the address of the magic _GLOBAL_OFFSET_TABLE_ anchor > > and the address of the symbol in question. > > > > This means _GLOBAL_OFFSET_TABLE_ is the only symbol whose actual runtime > > address needs to be determined explicitly, which is one of the first > > things that happens in startup_32. However, it does so by taking the > > absolute address via the immediate field of an ADD instruction (plus a > > small offset), which seems to defeat the point. > > > > Fortunately, the assembler knows that _GLOBAL_OFFSET_TABLE_ is magic, > > and emits a special relative relocation instead, and so the resulting > > Which special relocation do you mean? > > This guy: > > Relocation section '.rel.head.text' at offset 0x3a0 contains 12 entries: > Offset Info Type Sym.Value Sym. Name > 00000010 00000d0a R_386_GOTPC 00000000 _GLOBAL_OFFSET_TABLE_ > > ? Yep. if you assemble this movl $_GLOBAL_OFFSET_TABLE_, %eax movl $_GLOBAL_OFFSET_TABLE, %eax you'll end up with 0: b8 01 00 00 00 mov $0x1,%eax 1: R_386_GOTPC _GLOBAL_OFFSET_TABLE_ 5: b8 00 00 00 00 mov $0x0,%eax 6: R_386_32 _GLOBAL_OFFSET_TABLE So it is not possible to take the absolute address of _GLOBAL_OFFSET_TABLE_ via an absolute relocation, you will always get the relative offset instead.
