Re: [RFC PATCH v3 10/20] Add support to access boot related data in the clear
On Wed, 2016-11-09 at 18:36 -0600, Tom Lendacky wrote: > Boot data (such as EFI related data) is not encrypted when the system > is booted and needs to be accessed unencrypted. Add support to apply > the proper attributes to the EFI page tables and to the > early_memremap and memremap APIs to identify the type of data being > accessed so that the proper encryption attribute can be applied. : > +static bool memremap_apply_encryption(resource_size_t phys_addr, > + unsigned long size) > +{ > + /* SME is not active, just return true */ > + if (!sme_me_mask) > + return true; > + > + /* Check if the address is part of the setup data */ > + if (memremap_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: > + return false; > + } > + > + /* Check if the address is outside kernel usable area */ > + switch (e820_get_entry_type(phys_addr, phys_addr + size - > 1)) { > + case E820_RESERVED: > + case E820_ACPI: > + case E820_NVS: > + case E820_UNUSABLE: > + return false; > + } > + > + return true; > +} Are you supporting encryption for E820_PMEM ranges? If so, this encryption will persist across a reboot and does not need to be encrypted again, right? Also, how do you keep a same key across a reboot? Thanks, -ToshiN�r��yb�X��ǧv�^�){.n�+{�v�"��^n�r���z���h�&���G���h�(�階�ݢj"���m��z�ޖ���f���h���~�m�
Re: [RFC PATCH v3 02/20] x86: Set the write-protect cache mode for full PAT support
On Thu, 2016-11-10 at 14:14 +0100, Borislav Petkov wrote: > + Toshi. > > On Wed, Nov 09, 2016 at 06:34:48PM -0600, Tom Lendacky wrote: > > > > For processors that support PAT, set the write-protect cache mode > > (_PAGE_CACHE_MODE_WP) entry to the actual write-protect value > > (x05). Using slot 6 may be more cautious (for the same reason slot 7 was used for WT), but I do not have a strong opinion for it. set_page_memtype() cannot track the use of WP type since there is no extra-bit available for WP, but WP is only supported by early_memremap_xx() interfaces in this series. So, I think we should just document that WP is only intended for temporary mappings at boot- time until this issue is resolved. Also, we need to make sure that this early_memremap for WP is only called after pat_init() is done. A nit - please add WP to the function header comment below. "This function initializes PAT MSR and PAT table with an OS-defined value to enable additional cache attributes, WC and WT." Thanks, -Toshi