From: "H. Peter Anvin" Subject: Re: [RFC 20/22] x86/relocs: Add option to generate 64-bit relocations Date: Wed, 19 Jul 2017 16:45:37 -0700 Message-ID: <201707192346.v6JNk3QR002981__21538.7534270578$1500509861$gmane$org@mail.zytor.com> References: <20170718223333.110371-1-thgarnie@google.com> <20170718223333.110371-21-thgarnie@google.com> <89b77a4a-ef77-f746-1ae5-79bfc0d12ab0@zytor.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8BIT Cc: Herbert Xu , "David S . Miller" , Thomas Gleixner , Ingo Molnar , Peter Zijlstra , Josh Poimboeuf , Arnd Bergmann , Matthias Kaehlcke , Boris Ostrovsky , Juergen Gross , Paolo Bonzini , =?UTF-8?B?UmFkaW0gS3LEjW3DocWZ?= , Joerg Roedel , Andy Lutomirski , Borislav Petkov , "Kirill A . Shutemov" , Brian Gerst , Borislav Petkov , Christian Borntraeger , "Rafael J . Wy To: Thomas Garnier Return-path: Received: from terminus.zytor.com ([65.50.211.136]:40745 "EHLO mail.zytor.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932791AbdGTARM (ORCPT ); Wed, 19 Jul 2017 20:17:12 -0400 In-Reply-To: Sender: linux-crypto-owner@vger.kernel.org List-ID: ,"Paul E . McKenney" ,Andrew Morton ,Christopher Li ,Dou Liyang ,Masahiro Yamada ,Daniel Borkmann ,Markus Trippelsdorf ,Peter Foley ,Steven Rostedt ,Tim Chen ,Ard Biesheuvel ,Catalin Marinas ,Matthew Wilcox ,Michal Hocko ,Rob Landley ,Jiri Kosina ,"H . J . Lu" ,Paul Bolle ,Baoquan He ,Daniel Micay ,the arch/x86 maintai ners ,linux-crypto@vger.kernel.org,LKML ,xen-devel@lists.xenproject.org,kvm list ,Linux PM list ,linux-arch ,linux-sparse@vger.kernel.org,Kernel Hardening From: hpa@zytor.com Message-ID: <0EF6FAAA-A99C-4F0D-9E4A-AD25E93957FB@zytor.com> On July 19, 2017 4:25:56 PM PDT, Thomas Garnier wrote: >On Wed, Jul 19, 2017 at 4:08 PM, H. Peter Anvin wrote: >> On 07/19/17 15:47, Thomas Garnier wrote: >>> On Wed, Jul 19, 2017 at 3:33 PM, H. Peter Anvin >wrote: >>>> On 07/18/17 15:33, Thomas Garnier wrote: >>>>> The x86 relocation tool generates a list of 32-bit signed >integers. There >>>>> was no need to use 64-bit integers because all addresses where >above the 2G >>>>> top of the memory. >>>>> >>>>> This change add a large-reloc option to generate 64-bit unsigned >integers. >>>>> It can be used when the kernel plan to go below the top 2G and >32-bit >>>>> integers are not enough. >>>> >>>> Why on Earth? This would only be necessary if the *kernel itself* >was >>>> more than 2G, which isn't going to happen for the forseeable >future. >>> >>> Because the relocation integer is an absolute address, not an offset >>> in the binary. Next iteration, I can try using a 32-bit offset for >>> everyone. >> >> It is an absolute address *as the kernel was originally linked*, for >> obvious reasons. > >Sure when the kernel was just above 0xffffffff80000000, it doesn't >work when it goes down to 0xffffffff00000000. That's why using an >offset might make more sense in general. > >> >> -hpa >> What is the motivation for changing the pre linked address at all? -- Sent from my Android device with K-9 Mail. Please excuse my brevity.