Re: [RFC PATCH 00/13][V3] kexec: A new system call to allow in kernel loading

[H. Peter Anvin]

On 06/06/2014 01:58 PM, Matt Fleming wrote:
> On 6 June 2014 21:37, H. Peter Anvin <hpa@xxxxxxxxx> wrote:
>>
>> OK... this is seriously problematic.
>>
>> #if defined(CONFIG_RELOCATABLE) && defined(CONFIG_X86_64) && \
>>         !defined(CONFIG_EFI_MIXED)
>>    /* kernel/boot_param/ramdisk could be loaded above 4g */
>> # define XLF1 XLF_CAN_BE_LOADED_ABOVE_4G
>> #else
>> # define XLF1 0
>> #endif
>>
>> The fact that even compiling with CONFIG_EFI_MIXED disables
>> XLF_CAN_BE_LOADED_ABOVE_4G is really not going to fly.  We should expect
>> CONFIG_EFI_MIXED to be the norm, but *also* should expect that there is
>> a legitimate need to load above 4G.
>>
>> Matt, could you explain why this is necessary?  We need to figure out a
>> way around this.
>>
>> My thinking is that disabling this flag is unnecessary, since a 32-bit
>> EFI loader should not load above the 4G mark anyway, but if I'm confused
>> and there is a more fundamental requirement, then we need to consider
>> that more carefully.
> 
> No, your comments are absolutely correct. I was the one who was
> confused. I found this in the git history,
> 
> commit 7d453eee36ae
> Author: Matt Fleming <matt.fleming@xxxxxxxxx>
> Date:   Fri Jan 10 18:52:06 2014 +0000
> 
>     x86/efi: Wire up CONFIG_EFI_MIXED
> 
>     Add the Kconfig option and bump the kernel header version so that boot
>     loaders can check whether the handover code is available if they want.
> 
>     The xloadflags field in the bzImage header is also updated to reflect
>     that the kernel supports both entry points by setting both of
>     XLF_EFI_HANDOVER_32 and XLF_EFI_HANDOVER_64 when CONFIG_EFI_MIXED=y.
>     XLF_CAN_BE_LOADED_ABOVE_4G is disabled so that the kernel text is
>     guaranteed to be addressable with 32-bits.
> 
> As you've pointed out above, a 32-bit loader is never going to load
> the kernel above 4G, so we don't need to disable it.
> 
> What's the best way to fix this up? Just undo the change from the above commit?
> 

Yes, presumably (as a separate patch since the actual commit is quite
large.)  The patch needs to have a good description why the original
patch was wrong.

	-hpa

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/