Re: [RFC v4 17/17] procfs: display the protection-key number associated with a vma

Ram Pai writes: > Display the pkey number associated with the vma in smaps of a task. > The key will be seen as below: > > VmFlags: rd wr mr mw me dw ac key=0 Why wouldn't we just emit a "ProtectionKey:" line like x86 does? See their arch_show_smap(). You should probably

Re: [PATCH v3 0/4] kmod: help make deterministic

On Tue, Jun 27, 2017 at 05:26:05PM +0200, Jessica Yu wrote: > +++ Luis R. Rodriguez [27/06/17 00:44 +0200]: > > Feel free to decouple it, but note that then the commit log must then be > > changed. My own take is this fix is not so critical as it is a corner case, > > so > > I have instead

Re: [PATCH v8 0/2] dm: boot a mapped device without an initramfs

On Fri, May 19, 2017 at 12:11 AM, Enric Balletbo i Serra wrote: > Dear all, > > So here is a new version of the patches to be reviewed, this time as > suggested by Alasdair the patches are reworked to match with the new > dmsetup bootformat feature [1]. These patches

[PATCH v8 RESEND 34/38] x86/mm: Create native_make_p4d() for PGTABLE_LEVELS <= 4

Currently, native_make_p4d() is only defined when CONFIG_PGTABLE_LEVELS is greater than 4. Create a macro that will allow for defining and using native_make_p4d() when CONFIG_PGTABLES_LEVELS is not greater than 4. Signed-off-by: Tom Lendacky ---

[PATCH v8 RESEND 35/38] x86/mm: Add support to encrypt the kernel in-place

Add the support to encrypt the kernel in-place. This is done by creating new page mappings for the kernel - a decrypted write-protected mapping and an encrypted mapping. The kernel is encrypted by copying it through a temporary buffer. Signed-off-by: Tom Lendacky ---

[PATCH v8 RESEND 36/38] x86/boot: Add early cmdline parsing for options with arguments

Add a cmdline_find_option() function to look for cmdline options that take arguments. The argument is returned in a supplied buffer and the argument length (regardless of whether it fits in the supplied buffer) is returned, with -1 indicating not found. Signed-off-by: Tom Lendacky

[PATCH v8 RESEND 37/38] compiler-gcc.h: Introduce __nostackp function attribute

Create a new function attribute, __nostackp, that can used to turn off stack protection on a per function basis. Signed-off-by: Tom Lendacky --- include/linux/compiler-gcc.h |2 ++ include/linux/compiler.h |4 2 files changed, 6 insertions(+) diff

[PATCH v8 RESEND 38/38] x86/mm: Add support to make use of Secure Memory Encryption

Add support to check if SME has been enabled and if memory encryption should be activated (checking of command line option based on the configuration of the default state). If memory encryption is to be activated, then the encryption mask is set and the kernel is encrypted "in place."

Re: [PATCH v3 0/4] kmod: help make deterministic

+++ Luis R. Rodriguez [27/06/17 00:44 +0200]: On Mon, Jun 26, 2017 at 11:37:36PM +0200, Jessica Yu wrote: +++ Kees Cook [20/06/17 17:23 -0700]: > On Tue, Jun 20, 2017 at 1:56 PM, Luis R. Rodriguez wrote: > > On Fri, May 26, 2017 at 02:12:24PM -0700, Luis R. Rodriguez wrote:

Re: [RFC v4 09/17] powerpc: call the hash functions with the correct pkey value

On Tuesday 27 June 2017 03:41 PM, Ram Pai wrote: Pass the correct protection key value to the hash functions on page fault. Signed-off-by: Ram Pai --- arch/powerpc/include/asm/pkeys.h | 11 +++ arch/powerpc/mm/hash_utils_64.c | 4 arch/powerpc/mm/mem.c

[PATCH v8 RESEND 31/38] x86/mm, kexec: Allow kexec to be used with SME

Provide support so that kexec can be used to boot a kernel when SME is enabled. Support is needed to allocate pages for kexec without encryption. This is needed in order to be able to reboot in the kernel in the same manner as originally booted. Additionally, when shutting down all of the CPUs

[PATCH v8 RESEND 33/38] x86/mm: Use proper encryption attributes with /dev/mem

When accessing memory using /dev/mem (or /dev/kmem) use the proper encryption attributes when mapping the memory. To insure the proper attributes are applied when reading or writing /dev/mem, update the xlate_dev_mem_ptr() function to use memremap() which will essentially perform the same steps

[PATCH v8 RESEND 27/38] iommu/amd: Allow the AMD IOMMU to work with memory encryption

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 access the memory as encrypted the encryption mask needs to be

[PATCH v8 RESEND 29/38] x86, drm, fbdev: Do not specify encrypted memory for video mappings

Since video memory needs to be accessed decrypted, be sure that the memory encryption mask is not set for the video ranges. Reviewed-by: Borislav Petkov Signed-off-by: Tom Lendacky --- arch/x86/include/asm/vga.h | 14 +-

[PATCH v8 RESEND 30/38] kvm: x86: svm: Support Secure Memory Encryption within KVM

Update the KVM support to work with SME. The VMCB has a number of fields where physical addresses are used and these addresses must contain the memory encryption mask in order to properly access the encrypted memory. Also, use the memory encryption mask when creating and using the nested page

[PATCH v8 RESEND 28/38] x86, realmode: Check for memory encryption on the APs

Add support to check if memory encryption is active in the kernel and that it has been enabled on the AP. If memory encryption is active in the kernel but has not been enabled on the AP, then set the memory encryption bit (bit 23) of MSR_K8_SYSCFG to enable memory encryption on that AP and allow

[PATCH v8 23/38] x86/realmode: Decrypt trampoline area if memory encryption is active

When Secure Memory Encryption is enabled, the trampoline area must not be encrypted. A CPU running in real mode will not be able to decrypt memory that has been encrypted because it will not be able to use addresses with the memory encryption mask. Reviewed-by: Borislav Petkov

[PATCH v8 21/38] x86/mm: Add support to access persistent memory in the clear

Persistent memory is expected to persist across reboots. The encryption key used by SME will change across reboots which will result in corrupted persistent memory. Persistent memory is handed out by block devices through memory remapping functions, so be sure not to map this memory as encrypted.

[PATCH v8 25/38] swiotlb: Add warnings for use of bounce buffers with SME

Add warnings to let the user know when bounce buffers are being used for DMA when SME is active. Since the bounce buffers are not in encrypted memory, these notifications are to allow the user to determine some appropriate action - if necessary. Actions can range from utilizing an IOMMU,

[PATCH v8 26/38] x86/CPU/AMD: Make the microcode level available earlier in the boot

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. Reviewed-by: Borislav Petkov Signed-off-by: Tom Lendacky

[PATCH v8 RESEND 24/38] x86, swiotlb: Add memory encryption support

Since DMA addresses will effectively look like 48-bit addresses when the memory encryption mask is set, SWIOTLB is needed if the DMA mask of the device performing the DMA does not support 48-bits. SWIOTLB will be initialized to create decrypted bounce buffers for use by these devices.

[PATCH v8 RESEND 26/38] x86/CPU/AMD: Make the microcode level available earlier in the boot

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. Reviewed-by: Borislav Petkov Signed-off-by: Tom Lendacky

[PATCH v8 29/38] x86, drm, fbdev: Do not specify encrypted memory for video mappings

Since video memory needs to be accessed decrypted, be sure that the memory encryption mask is not set for the video ranges. Reviewed-by: Borislav Petkov Signed-off-by: Tom Lendacky --- arch/x86/include/asm/vga.h | 14 +-

[PATCH v8 28/38] x86, realmode: Check for memory encryption on the APs

Add support to check if memory encryption is active in the kernel and that it has been enabled on the AP. If memory encryption is active in the kernel but has not been enabled on the AP, then set the memory encryption bit (bit 23) of MSR_K8_SYSCFG to enable memory encryption on that AP and allow

[PATCH v8 27/38] iommu/amd: Allow the AMD IOMMU to work with memory encryption

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 access the memory as encrypted the encryption mask needs to be

[PATCH v8 30/38] kvm: x86: svm: Support Secure Memory Encryption within KVM

Update the KVM support to work with SME. The VMCB has a number of fields where physical addresses are used and these addresses must contain the memory encryption mask in order to properly access the encrypted memory. Also, use the memory encryption mask when creating and using the nested page

[PATCH v8 RESEND 25/38] swiotlb: Add warnings for use of bounce buffers with SME

Add warnings to let the user know when bounce buffers are being used for DMA when SME is active. Since the bounce buffers are not in encrypted memory, these notifications are to allow the user to determine some appropriate action - if necessary. Actions can range from utilizing an IOMMU,

[PATCH v8 RESEND 08/38] x86/mm: Add support to enable SME in early boot processing

Add support to the early boot code to use Secure Memory Encryption (SME). Since the kernel has been loaded into memory in a decrypted state, encrypt the kernel in place and update the early pagetables with the memory encryption mask so that new pagetable entries will use memory encryption. The

[PATCH v8 RESEND 06/38] x86/mm: Add Secure Memory Encryption (SME) support

Add support for Secure Memory Encryption (SME). This initial support provides a Kconfig entry to build the SME support into the kernel and defines the memory encryption mask that will be used in subsequent patches to mark pages as encrypted. Reviewed-by: Borislav Petkov

[PATCH v8 RESEND 09/38] x86/mm: Simplify p[g4um]d_page() macros

Create a pgd_pfn() macro similar to the p[4um]d_pfn() macros and then use the p[g4um]d_pfn() macros in the p[g4um]d_page() macros instead of duplicating the code. Reviewed-by: Borislav Petkov Signed-off-by: Tom Lendacky --- arch/x86/include/asm/pgtable.h

[PATCH v8 RESEND 21/38] x86/mm: Add support to access persistent memory in the clear

Persistent memory is expected to persist across reboots. The encryption key used by SME will change across reboots which will result in corrupted persistent memory. Persistent memory is handed out by block devices through memory remapping functions, so be sure not to map this memory as encrypted.

[PATCH v8 24/38] x86, swiotlb: Add memory encryption support

Since DMA addresses will effectively look like 48-bit addresses when the memory encryption mask is set, SWIOTLB is needed if the DMA mask of the device performing the DMA does not support 48-bits. SWIOTLB will be initialized to create decrypted bounce buffers for use by these devices.

[PATCH v8 RESEND 23/38] x86/realmode: Decrypt trampoline area if memory encryption is active

When Secure Memory Encryption is enabled, the trampoline area must not be encrypted. A CPU running in real mode will not be able to decrypt memory that has been encrypted because it will not be able to use addresses with the memory encryption mask. Reviewed-by: Borislav Petkov

[PATCH v8 RESEND 22/38] x86/mm: Add support for changing the memory encryption attribute

Add support for changing the memory encryption attribute for one or more memory pages. This will be useful when we have to change the AP trampoline area to not be encrypted. Or when we need to change the SWIOTLB area to not be encrypted in support of devices that can't support the encryption mask

[PATCH v8 RESEND 12/38] x86/mm: Extend early_memremap() support with additional attrs

Add early_memremap() support to be able to specify encrypted and decrypted mappings with and without write-protection. The use of write-protection is necessary when encrypting data "in place". The write-protect attribute is considered cacheable for loads, but not stores. This implies that the

[PATCH v8 RESEND 13/38] x86/mm: Add support for early encrypt/decrypt of memory

Add support to be able to either encrypt or decrypt data in place during the early stages of booting the kernel. This does not change the memory encryption attribute - it is used for ensuring that data present in either an encrypted or decrypted memory area is in the proper state (for example the

[PATCH v8 RESEND 15/38] x86/boot/e820: Add support to determine the E820 type of an address

Add a function that will return the E820 type associated with an address range. Reviewed-by: Borislav Petkov Signed-off-by: Tom Lendacky --- arch/x86/include/asm/e820/api.h |2 ++ arch/x86/kernel/e820.c | 26 +++--- 2

[PATCH v8 RESEND 19/38] x86/mm: Add support to access boot related data in the clear

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 arch specific routine to modify the pagetable protection

[PATCH v8 RESEND 00/38] x86: Secure Memory Encryption (AMD)

RESENDING - Mail Server Issues This patch series provides support for AMD's new Secure Memory Encryption (SME) feature. SME can be used to mark individual pages of memory as encrypted through the page tables. A page of memory that is marked encrypted will be automatically decrypted when read

[PATCH v8 RESEND 14/38] x86/mm: Insure that boot memory areas are mapped properly

The boot data and command line data are present in memory in a decrypted state and are copied early in the boot process. The early page fault support will map these areas as encrypted, so before attempting to copy them, add decrypted mappings so the data is accessed properly when copied. For the

[PATCH v8 RESEND 20/38] x86, mpparse: Use memremap to map the mpf and mpc data

The SMP MP-table is built by UEFI and placed in memory in a decrypted state. These tables are accessed using a mix of early_memremap(), early_memunmap(), phys_to_virt() and virt_to_phys(). Change all accesses to use early_memremap()/early_memunmap(). This allows for proper setting of the

[PATCH v8 RESEND 17/38] efi: Update efi_mem_type() to return an error rather than 0

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 doesn't. Instead of returning 0, change the function to

[PATCH v8 RESEND 10/38] x86/mm: Provide general kernel support for memory encryption

Changes to the existing page table macros will allow the SME support to be enabled in a simple fashion with minimal changes to files that use these macros. Since the memory encryption mask will now be part of the regular pagetable macros, we introduce two new macros (_PAGE_TABLE_NOENC and

[PATCH v8 RESEND 18/38] x86/efi: Update EFI pagetable creation to work with SME

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 include the encryption mask so that the PGD table can be read

[PATCH v8 RESEND 07/38] x86/mm: Remove phys_to_virt() usage in ioremap()

Currently there is a check if the address being mapped is in the ISA range (is_ISA_range()), and if it is, then phys_to_virt() is used to perform the mapping. When SME is active, the default is to add pagetable mappings with the encryption bit set unless specifically overridden. The resulting

[PATCH v8 RESEND 11/38] x86/mm: Add SME support for read_cr3_pa()

The cr3 register entry can contain the SME encryption mask that indicates the PGD is encrypted. The encryption mask should not be used when creating a virtual address from the cr3 register, so remove the SME encryption mask in the read_cr3_pa() function. During early boot SME will need to use a

[PATCH v8 RESEND 05/38] x86/CPU/AMD: Handle SME reduction in physical address size

When System Memory Encryption (SME) is enabled, the physical address space is reduced. Adjust the x86_phys_bits value to reflect this reduction. Reviewed-by: Borislav Petkov Signed-off-by: Tom Lendacky --- arch/x86/kernel/cpu/amd.c | 10 +++--- 1

[PATCH v8 RESEND 01/38] x86: Document AMD Secure Memory Encryption (SME)

Create a Documentation entry to describe the AMD Secure Memory Encryption (SME) feature and add documentation for the mem_encrypt= kernel parameter. Reviewed-by: Borislav Petkov Signed-off-by: Tom Lendacky ---

[PATCH v8 RESEND 04/38] x86/CPU/AMD: Add the Secure Memory Encryption CPU feature

Update the CPU features to include identifying and reporting on the Secure Memory Encryption (SME) feature. SME is identified by CPUID 0x801f, but requires BIOS support to enable it (set bit 23 of MSR_K8_SYSCFG). Only show the SME feature as available if reported by CPUID and enabled by

[PATCH v8 RESEND 03/38] x86, mpparse, x86/acpi, x86/PCI, x86/dmi, SFI: Use memremap for RAM mappings

The ioremap() function is intended for mapping MMIO. For RAM, the memremap() function should be used. Convert calls from ioremap() to memremap() when re-mapping RAM. This will be used later by SME to control how the encryption mask is applied to memory mappings, with certain memory locations

[PATCH v8 RESEND 02/38] x86/mm/pat: Set write-protect cache mode for full PAT support

For processors that support PAT, set the write-protect cache mode (_PAGE_CACHE_MODE_WP) entry to the actual write-protect value (x05). Acked-by: Borislav Petkov Signed-off-by: Tom Lendacky --- arch/x86/mm/pat.c |6 +++--- 1 file changed, 3

[PATCH v8 16/38] efi: Add an EFI table address match function

Add a function that will determine if a supplied physical address matches the address of an EFI table. Reviewed-by: Matt Fleming Reviewed-by: Borislav Petkov Signed-off-by: Tom Lendacky --- drivers/firmware/efi/efi.c | 33

[PATCH v8 22/38] x86/mm: Add support for changing the memory encryption attribute

Add support for changing the memory encryption attribute for one or more memory pages. This will be useful when we have to change the AP trampoline area to not be encrypted. Or when we need to change the SWIOTLB area to not be encrypted in support of devices that can't support the encryption mask

[PATCH v8 20/38] x86, mpparse: Use memremap to map the mpf and mpc data

The SMP MP-table is built by UEFI and placed in memory in a decrypted state. These tables are accessed using a mix of early_memremap(), early_memunmap(), phys_to_virt() and virt_to_phys(). Change all accesses to use early_memremap()/early_memunmap(). This allows for proper setting of the

[PATCH v8 17/38] efi: Update efi_mem_type() to return an error rather than 0

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 doesn't. Instead of returning 0, change the function to

[PATCH v8 18/38] x86/efi: Update EFI pagetable creation to work with SME

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 include the encryption mask so that the PGD table can be read

[PATCH v8 07/38] x86/mm: Remove phys_to_virt() usage in ioremap()

Currently there is a check if the address being mapped is in the ISA range (is_ISA_range()), and if it is, then phys_to_virt() is used to perform the mapping. When SME is active, the default is to add pagetable mappings with the encryption bit set unless specifically overridden. The resulting

[PATCH v8 19/38] x86/mm: Add support to access boot related data in the clear

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 arch specific routine to modify the pagetable protection

[PATCH v8 10/38] x86/mm: Provide general kernel support for memory encryption

Changes to the existing page table macros will allow the SME support to be enabled in a simple fashion with minimal changes to files that use these macros. Since the memory encryption mask will now be part of the regular pagetable macros, we introduce two new macros (_PAGE_TABLE_NOENC and

[PATCH v8 11/38] x86/mm: Add SME support for read_cr3_pa()

The cr3 register entry can contain the SME encryption mask that indicates the PGD is encrypted. The encryption mask should not be used when creating a virtual address from the cr3 register, so remove the SME encryption mask in the read_cr3_pa() function. During early boot SME will need to use a

[PATCH v8 15/38] x86/boot/e820: Add support to determine the E820 type of an address

Add a function that will return the E820 type associated with an address range. Reviewed-by: Borislav Petkov Signed-off-by: Tom Lendacky --- arch/x86/include/asm/e820/api.h |2 ++ arch/x86/kernel/e820.c | 26 +++--- 2

[PATCH v8 12/38] x86/mm: Extend early_memremap() support with additional attrs

Add early_memremap() support to be able to specify encrypted and decrypted mappings with and without write-protection. The use of write-protection is necessary when encrypting data "in place". The write-protect attribute is considered cacheable for loads, but not stores. This implies that the

[PATCH v8 00/38] x86: Secure Memory Encryption (AMD)

This patch series provides support for AMD's new Secure Memory Encryption (SME) feature. SME can be used to mark individual pages of memory as encrypted through the page tables. A page of memory that is marked encrypted will be automatically decrypted when read from DRAM and will be automatically

[PATCH v8 13/38] x86/mm: Add support for early encrypt/decrypt of memory

Add support to be able to either encrypt or decrypt data in place during the early stages of booting the kernel. This does not change the memory encryption attribute - it is used for ensuring that data present in either an encrypted or decrypted memory area is in the proper state (for example the

[PATCH v8 05/38] x86/CPU/AMD: Handle SME reduction in physical address size

When System Memory Encryption (SME) is enabled, the physical address space is reduced. Adjust the x86_phys_bits value to reflect this reduction. Reviewed-by: Borislav Petkov Signed-off-by: Tom Lendacky --- arch/x86/kernel/cpu/amd.c | 10 +++--- 1

[PATCH v8 14/38] x86/mm: Insure that boot memory areas are mapped properly

The boot data and command line data are present in memory in a decrypted state and are copied early in the boot process. The early page fault support will map these areas as encrypted, so before attempting to copy them, add decrypted mappings so the data is accessed properly when copied. For the

[PATCH v8 09/38] x86/mm: Simplify p[g4um]d_page() macros

Create a pgd_pfn() macro similar to the p[4um]d_pfn() macros and then use the p[g4um]d_pfn() macros in the p[g4um]d_page() macros instead of duplicating the code. Reviewed-by: Borislav Petkov Signed-off-by: Tom Lendacky --- arch/x86/include/asm/pgtable.h

[PATCH v8 08/38] x86/mm: Add support to enable SME in early boot processing

Add support to the early boot code to use Secure Memory Encryption (SME). Since the kernel has been loaded into memory in a decrypted state, encrypt the kernel in place and update the early pagetables with the memory encryption mask so that new pagetable entries will use memory encryption. The

[PATCH v8 06/38] x86/mm: Add Secure Memory Encryption (SME) support

Add support for Secure Memory Encryption (SME). This initial support provides a Kconfig entry to build the SME support into the kernel and defines the memory encryption mask that will be used in subsequent patches to mark pages as encrypted. Reviewed-by: Borislav Petkov

[PATCH v8 02/38] x86/mm/pat: Set write-protect cache mode for full PAT support

For processors that support PAT, set the write-protect cache mode (_PAGE_CACHE_MODE_WP) entry to the actual write-protect value (x05). Acked-by: Borislav Petkov Signed-off-by: Tom Lendacky --- arch/x86/mm/pat.c |6 +++--- 1 file changed, 3

[PATCH v8 04/38] x86/CPU/AMD: Add the Secure Memory Encryption CPU feature

Update the CPU features to include identifying and reporting on the Secure Memory Encryption (SME) feature. SME is identified by CPUID 0x801f, but requires BIOS support to enable it (set bit 23 of MSR_K8_SYSCFG). Only show the SME feature as available if reported by CPUID and enabled by

[PATCH v8 01/38] x86: Document AMD Secure Memory Encryption (SME)

Create a Documentation entry to describe the AMD Secure Memory Encryption (SME) feature and add documentation for the mem_encrypt= kernel parameter. Reviewed-by: Borislav Petkov Signed-off-by: Tom Lendacky ---

[PATCH v8 03/38] x86, mpparse, x86/acpi, x86/PCI, x86/dmi, SFI: Use memremap for RAM mappings

The ioremap() function is intended for mapping MMIO. For RAM, the memremap() function should be used. Convert calls from ioremap() to memremap() when re-mapping RAM. This will be used later by SME to control how the encryption mask is applied to memory mappings, with certain memory locations

Re: [PATCH 2/2] x86/idle: use dynamic halt poll

On 27/06/2017 16:22, Radim Krčmář wrote: > vcpu_is_preempted() on current cpu cannot return true, AFAIK. Of course. I must have been thinking of an older version of the vcpu_is_preempted patch (at some point the guest was the one that set preempted to 0). Paolo -- To unsubscribe from this

Re: [PATCH 2/2] x86/idle: use dynamic halt poll

2017-06-27 15:56+0200, Paolo Bonzini: > On 27/06/2017 15:40, Radim Krčmář wrote: >>> ... which is not necessarily _wrong_. It's just a different heuristic. >> Right, it's just harder to use than host's single_task_running() -- the >> VCPU calling vcpu_is_preempted() is never preempted, so we have

Re: [PATCH 0/2] x86/idle: add halt poll support

2017-06-23 14:49+0800, Yang Zhang: > On 2017/6/23 12:35, Wanpeng Li wrote: > > 2017-06-23 12:08 GMT+08:00 Yang Zhang : > > > On 2017/6/22 19:50, Wanpeng Li wrote: > > > > > > > > 2017-06-22 19:22 GMT+08:00 root : > > > > > > > > > > From: Yang

Re: [PATCH 2/2] x86/idle: use dynamic halt poll

On 27/06/2017 15:40, Radim Krčmář wrote: >> ... which is not necessarily _wrong_. It's just a different heuristic. > Right, it's just harder to use than host's single_task_running() -- the > VCPU calling vcpu_is_preempted() is never preempted, so we have to look > at other VCPUs that are not

Re: [PATCH 2/2] x86/idle: use dynamic halt poll

2017-06-27 14:28+0200, Paolo Bonzini: > On 27/06/2017 14:23, Wanpeng Li wrote: > I have considered single_task_running() before. But since there is no > such paravirtual interface currently and i am not sure whether it is a > information leak from host if introducing such interface, so

Re: [PATCH 2/2] x86/idle: use dynamic halt poll

On 27/06/2017 14:23, Wanpeng Li wrote: I have considered single_task_running() before. But since there is no such paravirtual interface currently and i am not sure whether it is a information leak from host if introducing such interface, so i didn't do it. Do you mean

Re: [PATCH 2/2] x86/idle: use dynamic halt poll

2017-06-27 20:07 GMT+08:00 Paolo Bonzini : > > > On 27/06/2017 13:22, Yang Zhang wrote: Regarding the good/bad idea part, KVM's polling is made much more acceptable by single_task_running(). At least you need to integrate it with paravirtualization. If

Re: [PATCH v4 2/3] arm64: kvm: route synchronous external abort exceptions to el2

correct the commit message: In the firmware-first RAS solution, OS receives an synchronous external abort, then trapped to EL3 by SCR_EL3.EA. Firmware inspects the HCR_EL2.TEA and chooses the target to send APEI's SEA notification. If the SCR_EL3.EA is set, delegates the error exception to

Re: [PATCH 2/2] x86/idle: use dynamic halt poll

On 27/06/2017 13:22, Yang Zhang wrote: >>> >>> Regarding the good/bad idea part, KVM's polling is made much more >>> acceptable by single_task_running(). At least you need to integrate it >>> with paravirtualization. If the VM is scheduled out, you shrink the >>> polling period. There is

Re: [RFC v4 02/17] mm: ability to disable execute permission on a key at creation

On Tue, 2017-06-27 at 03:11 -0700, Ram Pai wrote: > Currently sys_pkey_create() provides the ability to disable read > and write permission on the key, at creation. powerpc has the > hardware support to disable execute on a pkey as well.This patch > enhances the interface to let disable execute

Re: [RFC v4 03/17] x86: key creation with PKEY_DISABLE_EXECUTE disallowed

On Tue, 2017-06-27 at 03:11 -0700, Ram Pai wrote: > x86 does not support disabling execute permissions on a pkey. > > Signed-off-by: Ram Pai > --- > arch/x86/kernel/fpu/xstate.c | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/arch/x86/kernel/fpu/xstate.c

Re: [PATCH 2/2] x86/idle: use dynamic halt poll

On 2017/6/23 11:58, Yang Zhang wrote: On 2017/6/22 19:51, Paolo Bonzini wrote: On 22/06/2017 13:22, root wrote: == +poll_grow: (X86 only) + +This parameter is multiplied in the grow_poll_ns() to increase the poll time. +By

Re: [RFC v4 01/17] mm: introduce an additional vma bit for powerpc pkey

On Tue, 2017-06-27 at 03:11 -0700, Ram Pai wrote: > Currently there are only 4bits in the vma flags to support 16 keys > on x86. powerpc supports 32 keys, which needs 5bits. This patch > introduces an addition bit in the vma flags. > > Signed-off-by: Ram Pai > --- >

Re: [RFC v4 00/17] powerpc: Memory Protection Keys

On Tue, 2017-06-27 at 03:11 -0700, Ram Pai wrote: > Memory protection keys enable applications to protect its > address space from inadvertent access or corruption from > itself. > > The overall idea: > > A process allocates a key and associates it with > a address range withinits

[RFC v4 01/17] mm: introduce an additional vma bit for powerpc pkey

Currently there are only 4bits in the vma flags to support 16 keys on x86. powerpc supports 32 keys, which needs 5bits. This patch introduces an addition bit in the vma flags. Signed-off-by: Ram Pai --- fs/proc/task_mmu.c | 6 +- include/linux/mm.h | 18

[RFC v4 04/17] powerpc: Implement sys_pkey_alloc and sys_pkey_free system call

Sys_pkey_alloc() allocates and returns available pkey Sys_pkey_free() frees up the pkey. Total 32 keys are supported on powerpc. However pkey 0,1 and 31 are reserved. So effectively we have 29 pkeys. Each key can be initialized to disable read, write and execute permissions. On powerpc a

[RFC v4 07/17] powerpc: make the hash functions protection-key aware

Prepare the hash functions to be aware of protection keys. This key will later be used to program the HPTE. Signed-off-by: Ram Pai --- arch/powerpc/include/asm/book3s/64/hash.h | 2 +- arch/powerpc/include/asm/book3s/64/mmu-hash.h | 14 ++-

[RFC v4 06/17] powerpc: Implementation for sys_mprotect_pkey() system call

This system call, associates the pkey with vma corresponding to the given address range. Signed-off-by: Ram Pai --- arch/powerpc/include/asm/mman.h| 8 ++- arch/powerpc/include/asm/pkeys.h | 17 ++- arch/powerpc/include/asm/systbl.h | 1 +

[RFC v4 09/17] powerpc: call the hash functions with the correct pkey value

Pass the correct protection key value to the hash functions on page fault. Signed-off-by: Ram Pai --- arch/powerpc/include/asm/pkeys.h | 11 +++ arch/powerpc/mm/hash_utils_64.c | 4 arch/powerpc/mm/mem.c| 6 ++ 3 files changed, 21

[RFC v4 05/17] powerpc: store and restore the pkey state across context switches

Store and restore the AMR, IAMR and UMOR register state of the task before scheduling out and after scheduling in, respectively. Signed-off-by: Ram Pai --- arch/powerpc/include/asm/processor.h | 5 + arch/powerpc/kernel/process.c| 18 ++ 2 files

[RFC v4 08/17] powerpc: Program HPTE key protection bits

Map the PTE protection key bits to the HPTE key protection bits, while creating HPTE entries. Signed-off-by: Ram Pai --- Makefile | 2 +- arch/powerpc/include/asm/book3s/64/mmu-hash.h | 5 + arch/powerpc/include/asm/pkeys.h

[RFC v4 10/17] powerpc: Macro the mask used for checking DSI exception

Replace the magic number used to check for DSI exception with a meaningful value. Signed-off-by: Ram Pai --- arch/powerpc/include/asm/reg.h | 7 ++- arch/powerpc/kernel/exceptions-64s.S | 2 +- 2 files changed, 7 insertions(+), 2 deletions(-) diff --git

[RFC v4 12/17] powerpc: Deliver SEGV signal on pkey violation

The value of the AMR register at the time of exception is made available in gp_regs[PT_AMR] of the siginfo. The value of the pkey, whose protection got violated, is made available in si_pkey field of the siginfo structure. Signed-off-by: Ram Pai ---

[RFC v4 11/17] powerpc: Handle exceptions caused by pkey violation

Handle Data and Instruction exceptions caused by memory protection-key. Signed-off-by: Ram Pai --- arch/powerpc/include/asm/mmu_context.h | 12 ++ arch/powerpc/include/asm/reg.h | 2 +- arch/powerpc/mm/fault.c| 20 +

[RFC v4 15/17] Documentation: Move protecton key documentation to arch neutral directory

Since PowerPC and Intel both support memory protection keys, moving the documenation to arch-neutral directory. Signed-off-by: Ram Pai --- Documentation/vm/protection-keys.txt | 85 +++ Documentation/x86/protection-keys.txt | 85

[RFC v4 14/17] selftest: PowerPC specific test updates to memory protection keys

Abstracted out the arch specific code into the header file, and added powerpc specific changes. a) added 4k-backed hpte, memory allocator, powerpc specific. b) added three test case where the key is associated after the page is accessed/allocated/mapped. c) cleaned up the code to make

[RFC v4 13/17] selftest: Move protecton key selftest to arch neutral directory

Signed-off-by: Ram Pai --- tools/testing/selftests/vm/Makefile |1 + tools/testing/selftests/vm/pkey-helpers.h | 219 tools/testing/selftests/vm/protection_keys.c | 1395 + tools/testing/selftests/x86/Makefile |2

  1   2   >