On 6/22/2017 5:56 AM, Borislav Petkov wrote:
On Fri, Jun 16, 2017 at 01:54:59PM -0500, Tom Lendacky wrote:
The IOMMU is programmed with physical addresses for the various tables
and buffers that are used to communicate between the device and the
driver. When the driver allocates this memory it i
On Fri, 16 Jun, at 01:53:26PM, 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.
>
> Update early_memremap() to provide an
On Fri, 16 Jun, at 01:53:17PM, Tom Lendacky wrote:
> When SME is active, pagetable entries created for EFI need to have the
> encryption mask set as necessary.
>
> When the new pagetable pages are allocated they are mapped encrypted. So,
> update the efi_pgt value that will be used in cr3 to inclu
On Fri, 16 Jun, at 01:52:53PM, Tom Lendacky wrote:
> Add a function that will determine if a supplied physical address matches
> the address of an EFI table.
>
> Reviewed-by: Borislav Petkov
> Signed-off-by: Tom Lendacky
> ---
> drivers/firmware/efi/efi.c | 33
On Fri, Jun 16, 2017 at 01:54:59PM -0500, Tom Lendacky wrote:
> The IOMMU is programmed with physical addresses for the various tables
> and buffers that are used to communicate between the device and the
> driver. When the driver allocates this memory it is encrypted. In order
> for the IOMMU to a
On Fri, 16 Jun, at 01:53:06PM, Tom Lendacky wrote:
> The efi_mem_type() function currently returns a 0, which maps to
> EFI_RESERVED_TYPE, if the function is unable to find a memmap entry for
> the supplied physical address. Returning EFI_RESERVED_TYPE implies that
> a memmap entry exists, when it
On Fri, Jun 16, 2017 at 01:54:47PM -0500, Tom Lendacky wrote:
> Move the setting of the cpuinfo_x86.microcode field from amd_init() to
> early_amd_init() so that it is available earlier in the boot process. This
> avoids having to read MSR_AMD64_PATCH_LEVEL directly during early boot.
>
> Signed-o
On 06/22/2017 at 01:44 AM, Michael Holzheu wrote:
> Am Fri, 9 Jun 2017 10:17:05 +0800
> schrieb Xunlei Pang :
>
>> S390 KEXEC_NOTE_BYTES is not used by note_buf_t as before, which
>> is now defined as follows:
>> typedef u32 note_buf_t[CRASH_CORE_NOTE_BYTES/4];
>> It was changed by the CONFIG_