Re: [RFC 20/22] x86/relocs: Add option to generate 64-bit relocations

[H. Peter Anvin]

,"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 maintainers 
,linux-cry...@vger.kernel.org,LKML 
,xen-de...@lists.xenproject.org,kvm list 
,Linux PM list
,linux-arch 
,linux-spa...@vger.kernel.org,Kernel Hardening 

From: h...@zytor.com
Message-ID: <0ef6faaa-a99c-4f0d-9e4a-ad25e9395...@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 0x8000, it doesn't
>work when it goes down to 0x. 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.

Re: [RFC 20/22] x86/relocs: Add option to generate 64-bit relocations

[H. Peter Anvin]

,"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 maintainers 
,linux-cry...@vger.kernel.org,LKML 
,xen-de...@lists.xenproject.org,kvm list 
,Linux PM list
,linux-arch 
,linux-spa...@vger.kernel.org,Kernel Hardening 

From: h...@zytor.com
Message-ID: <0ef6faaa-a99c-4f0d-9e4a-ad25e9395...@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 0x8000, it doesn't
>work when it goes down to 0x. 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.