[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAMj1kXEyWJ7GgcLBdqd1GkEGEEX=4vi7d6ZVEAJ0zjU1Y+ioUQ@mail.gmail.com>
Date: Fri, 23 Jun 2023 16:00:30 +0200
From: Ard Biesheuvel <ardb@...nel.org>
To: Borislav Petkov <bp@...en8.de>
Cc: linux-efi@...r.kernel.org, linux-kernel@...r.kernel.org,
Evgeniy Baskov <baskov@...ras.ru>,
Andy Lutomirski <luto@...nel.org>,
Dave Hansen <dave.hansen@...ux.intel.com>,
Ingo Molnar <mingo@...hat.com>,
Peter Zijlstra <peterz@...radead.org>,
Thomas Gleixner <tglx@...utronix.de>,
Alexey Khoroshilov <khoroshilov@...ras.ru>,
Peter Jones <pjones@...hat.com>,
Gerd Hoffmann <kraxel@...hat.com>,
Dave Young <dyoung@...hat.com>,
Mario Limonciello <mario.limonciello@....com>,
Kees Cook <keescook@...omium.org>,
Tom Lendacky <thomas.lendacky@....com>,
"Kirill A . Shutemov" <kirill.shutemov@...ux.intel.com>,
Linus Torvalds <torvalds@...ux-foundation.org>,
Joerg Roedel <jroedel@...e.de>
Subject: Re: [PATCH v5 05/20] x86/decompressor: Use proper sequence to take
the address of the GOT
On Wed, 21 Jun 2023 at 13:09, Borislav Petkov <bp@...en8.de> 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.
Powered by blists - more mailing lists