2017-03-08 06:58:49

by Dave Young

Subject: Re: [RFC PATCH v4 14/28] Add support to access boot related data in the clear

On 02/16/17 at 09:45am, Tom Lendacky wrote:
[snip]
> + * This function determines if an address should be mapped encrypted.
> + * Boot setup data, EFI data and E820 areas are checked in making this
> + * determination.
> + */
> +static bool memremap_should_map_encrypted(resource_size_t phys_addr,
> + unsigned long size)
> +{
> + /*
> + * SME is not active, return true:
> + * - For early_memremap_pgprot_adjust(), returning true or false
> + * results in the same protection value
> + * - For arch_memremap_do_ram_remap(), returning true will allow
> + * the RAM remap to occur instead of falling back to ioremap()
> + */
> + if (!sme_active())
> + return true;

>From the function name shouldn't above be return false?

> +
> + /* Check if the address is part of the setup data */
> + if (memremap_is_setup_data(phys_addr, size))
> + return false;
> +
> + /* Check if the address is part of EFI boot/runtime data */
> + switch (efi_mem_type(phys_addr)) {
> + case EFI_BOOT_SERVICES_DATA:
> + case EFI_RUNTIME_SERVICES_DATA:

Only these two types needed? I'm not sure about this, just bring up the
question.

> + return false;
> + default:
> + break;
> + }
> +
> + /* Check if the address is outside kernel usable area */
> + switch (e820__get_entry_type(phys_addr, phys_addr + size - 1)) {
> + case E820_TYPE_RESERVED:
> + case E820_TYPE_ACPI:
> + case E820_TYPE_NVS:
> + case E820_TYPE_UNUSABLE:
> + return false;
> + default:
> + break;
> + }
> +
> + return true;
> +}
> +

Thanks
Dave

2017-03-17 19:54:52

by Tom Lendacky

Subject: Re: [RFC PATCH v4 14/28] Add support to access boot related data in the clear

On 3/8/2017 12:55 AM, Dave Young wrote:
> On 02/16/17 at 09:45am, Tom Lendacky wrote:
> [snip]
>> + * This function determines if an address should be mapped encrypted.
>> + * Boot setup data, EFI data and E820 areas are checked in making this
>> + * determination.
>> + */
>> +static bool memremap_should_map_encrypted(resource_size_t phys_addr,
>> + unsigned long size)
>> +{
>> + /*
>> + * SME is not active, return true:
>> + * - For early_memremap_pgprot_adjust(), returning true or false
>> + * results in the same protection value
>> + * - For arch_memremap_do_ram_remap(), returning true will allow
>> + * the RAM remap to occur instead of falling back to ioremap()
>> + */
>> + if (!sme_active())
>> + return true;
>
> From the function name shouldn't above be return false?

I've re-worked this so that the check is in a different location and
doesn't cause confusion.

>
>> +
>> + /* Check if the address is part of the setup data */
>> + if (memremap_is_setup_data(phys_addr, size))
>> + return false;
>> +
>> + /* Check if the address is part of EFI boot/runtime data */
>> + switch (efi_mem_type(phys_addr)) {
>> + case EFI_BOOT_SERVICES_DATA:
>> + case EFI_RUNTIME_SERVICES_DATA:
>
> Only these two types needed? I'm not sure about this, just bring up the
> question.

I've re-worked this code so that there is a single EFI routine that
checks boot_params.efi_info.efi_memmap/efi_systab, EFI tables and the
EFI memtype. As for the EFI memtypes, I believe those are the only
ones required. Some of the other types will be picked up by the e820
checks (ACPI, NVS, etc.).

Thanks,
Tom

>
>> + return false;
>> + default:
>> + break;
>> + }
>> +
>> + /* Check if the address is outside kernel usable area */
>> + switch (e820__get_entry_type(phys_addr, phys_addr + size - 1)) {
>> + case E820_TYPE_RESERVED:
>> + case E820_TYPE_ACPI:
>> + case E820_TYPE_NVS:
>> + case E820_TYPE_UNUSABLE:
>> + return false;
>> + default:
>> + break;
>> + }
>> +
>> + return true;
>> +}
>> +
>
> Thanks
> Dave
>