On Tue, May 30, 2017 at 11:46:52AM -0500, Tom Lendacky wrote:
> Check if you have CONFIG_DEBUG_SECTION_MISMATCH=y
$ grep MISM .config
CONFIG_DEBUG_SECTION_MISMATCH=y
CONFIG_SECTION_MISMATCH_WARN_ONLY=y
Still no joy.
Can you give me your .config?
--
Regards/Gruss,
Boris.
Good mailing
On 5/26/2017 11:35 AM, Borislav Petkov wrote:
On Fri, May 26, 2017 at 11:22:36AM -0500, Tom Lendacky wrote:
In addition to the same issue as efi.memmap.phys_map, efi_phys has
the __initdata attribute so it will be released/freed which will cause
problems in checks performed afterwards.
Sounds
On 5/21/2017 2:16 AM, Borislav Petkov wrote:
On Fri, May 19, 2017 at 03:50:32PM -0500, Tom Lendacky wrote:
The "worker" function would be doing the loop through the setup data,
but since the setup data is mapped inside the loop I can't do the __init
calling the non-init function and still hope
On 5/18/2017 2:50 PM, Matt Fleming wrote:
On Mon, 15 May, at 08:35:17PM, Borislav Petkov wrote:
On Tue, Apr 18, 2017 at 04:19:21PM -0500, Tom Lendacky wrote:
+ paddr = boot_params.efi_info.efi_memmap_hi;
+ paddr <<= 32;
+ paddr |=
On Fri, May 19, 2017 at 03:50:32PM -0500, Tom Lendacky wrote:
> The "worker" function would be doing the loop through the setup data,
> but since the setup data is mapped inside the loop I can't do the __init
> calling the non-init function and still hope to consolidate the code.
> Maybe I'm
On 5/18/2017 4:02 AM, Borislav Petkov wrote:
On Wed, May 17, 2017 at 01:54:39PM -0500, Tom Lendacky wrote:
I was worried what the compiler might do when CONFIG_EFI is not set,
but it appears to take care of it. I'll double check though.
There's a efi_enabled() !CONFIG_EFI version too, so
On Wed, May 17, 2017 at 01:54:39PM -0500, Tom Lendacky wrote:
> I was worried what the compiler might do when CONFIG_EFI is not set,
> but it appears to take care of it. I'll double check though.
There's a efi_enabled() !CONFIG_EFI version too, so should be fine.
> I may introduce a length
On 5/15/2017 1:35 PM, Borislav Petkov wrote:
On Tue, Apr 18, 2017 at 04:19:21PM -0500, Tom Lendacky wrote:
Boot data (such as EFI related data) is not encrypted when the system is
booted because UEFI/BIOS does not run with SME active. In order to access
this data properly it needs to be mapped
On Tue, Apr 18, 2017 at 04:19:21PM -0500, Tom Lendacky wrote:
> Boot data (such as EFI related data) is not encrypted when the system is
> booted because UEFI/BIOS does not run with SME active. In order to access
> this data properly it needs to be mapped decrypted.
>
> The early_memremap()
Boot data (such as EFI related data) is not encrypted when the system is
booted because UEFI/BIOS does not run with SME active. In order to access
this data properly it needs to be mapped decrypted.
The early_memremap() support is updated to provide an arch specific
routine to modify the
10 matches
Mail list logo
