On Thu, Feb 16, 2017 at 2:25 PM, Pavel Machek wrote:
> Hi!
>
>>
>> -config DEBUG_RODATA
>> +config STRICT_KERNEL_RWX
>> bool "Make kernel text and rodata read-only" if
>> ARCH_OPTIONAL_KERNEL_RWX
>> depends on ARCH_HAS_STRICT_KERNEL_RWX
>> default !ARCH_OPTIONAL_KERNEL_RWX ||
>
Hi Thomas,
[auto build test ERROR on next-20170216]
[also build test ERROR on v4.10-rc8]
[cannot apply to tip/x86/core kvm/linux-next tip/auto-latest v4.9-rc8 v4.9-rc7
v4.9-rc6]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https
Hi Thomas,
[auto build test ERROR on next-20170216]
[also build test ERROR on v4.10-rc8]
[cannot apply to tip/x86/core kvm/linux-next tip/auto-latest v4.9-rc8 v4.9-rc7
v4.9-rc6]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https
Hi!
>
> -config DEBUG_RODATA
> +config STRICT_KERNEL_RWX
> bool "Make kernel text and rodata read-only" if ARCH_OPTIONAL_KERNEL_RWX
> depends on ARCH_HAS_STRICT_KERNEL_RWX
> default !ARCH_OPTIONAL_KERNEL_RWX ||
Debug features are expected to have runtime cost, so kconfig help
Each processor holds a GDT in its per-cpu structure. The sgdt
instruction gives the base address of the current GDT. This address can
be used to bypass KASLR memory randomization. With another bug, an
attacker could target other per-cpu structures or deduce the base of
the main memory section (PAGE
This patch aligns MODULES_END to the beginning of the Fixmap section.
It optimizes the space available for both sections. The address is
pre-computed based on the number of pages required by the Fixmap
section.
It will allow GDT remapping in the Fixmap section. The current
MODULES_END static addre
This patch makes the GDT remapped pages read-only to prevent corruption.
This change is done only on 64-bit.
The native_load_tr_desc function was adapted to correctly handle a
read-only GDT. The LTR instruction always writes to the GDT TSS entry.
This generates a page fault if the GDT is read-only
The KVM segment_base function is confusing. This patch replaces integers
with appropriate flags, simplify constructs and add comments.
Signed-off-by: Thomas Garnier
---
Based on next-20170213
---
arch/x86/kvm/vmx.c | 30 --
1 file changed, 20 insertions(+), 10 deletio
On Thu, Feb 16, 2017 at 01:42:13PM -0600, Tom Lendacky wrote:
> I realize it's a bit more code and expands the changes but I thought it
> would be a bit clearer as to what was going on this way. And then the
> follow on patch for the physical address reduction goes in nicely, too.
Well, the code f
On 02/16/2017 11:56 AM, Borislav Petkov wrote:
> Ok, this time detailed review :-)
>
> On Thu, Feb 16, 2017 at 09:42:11AM -0600, Tom Lendacky wrote:
>> This patch adds a Documenation entry to decribe the AMD Secure Memory
>> Encryption (SME) feature.
>
> Please introduce a spellchecker into your
On 02/16/2017 12:13 PM, Borislav Petkov wrote:
> On Thu, Feb 16, 2017 at 09:42:36AM -0600, Tom Lendacky wrote:
>> 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 en
One argument was incorrect, two functions weren't showing the
brief description, and the docs for strncpy_from_unsafe() had a
colon attached to it. Fix it up.
Cc:
Signed-off-by: Stephen Boyd
---
mm/maccess.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/mm/maccess.
On Thu, Feb 16, 2017 at 09:42:36AM -0600, Tom Lendacky wrote:
> 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
> SYS_CFG MSR). Only show th
Ok, this time detailed review :-)
On Thu, Feb 16, 2017 at 09:42:11AM -0600, Tom Lendacky wrote:
> This patch adds a Documenation entry to decribe the AMD Secure Memory
> Encryption (SME) feature.
Please introduce a spellchecker into your patch creation workflow. I see
two typos in one line.
Also
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 w
This patch adds a Documenation entry to decribe the AMD Secure Memory
Encryption (SME) feature.
Signed-off-by: Tom Lendacky
---
Documentation/admin-guide/kernel-parameters.txt | 11
Documentation/x86/amd-memory-encryption.txt | 57 +++
2 files changed, 68 inserti
When System Memory Encryption (SME) is enabled, the physical address
space is reduced. Adjust the x86_phys_bits value to reflect this
reduction.
Signed-off-by: Tom Lendacky
---
arch/x86/kernel/cpu/common.c | 10 +++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/arch/x86/
Add to the 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
Adding general kernel support for memory encryption includes:
- Modify and create some page table macros to include the Secure Memory
Encryption (SME) memory encryption mask
- Modify and create some macros for calculating physical and virtual
memory addresses
- Provide an SME initialization rou
This patch adds support to the early boot code to use Secure Memory
Encryption (SME). Support is added to update the early pagetables with
the memory encryption mask and to encrypt the kernel in place.
The routines to set the encryption mask and perform the encryption are
stub routines for now wi
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
SYS_CFG MSR). Only show the SME feature as available if reported by
CPUID and enabled by BIOS.
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.
Signed-off-by: Tom Lendacky
---
arch/x86/Kconfig
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 i
Update the efi_mem_type() to return EFI_RESERVED_TYPE instead of a
hardcoded 0.
Signed-off-by: Tom Lendacky
---
arch/x86/platform/efi/efi.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/x86/platform/efi/efi.c b/arch/x86/platform/efi/efi.c
index a15cf81..6407103
This patch adds support that will determine if a supplied physical address
matches the address of an EFI table.
Signed-off-by: Tom Lendacky
---
drivers/firmware/efi/efi.c | 33 +
include/linux/efi.h|7 +++
2 files changed, 40 insertions(+)
diff
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
Boot data (such as EFI related data) is not encrypted when the system is
booted and needs to be mapped decrypted. 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
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.
Signed-off-b
For now, disable the AMD IOMMU if memory encryption is active. A future
patch will re-enable the function with full memory encryption support.
Signed-off-by: Tom Lendacky
---
drivers/iommu/amd_iommu_init.c |7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/iommu/amd_iommu_init
This patch adds the 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 plac
Since video memory needs to be accessed decrypted, be sure that the
memory encryption mask is not set for the video ranges.
Signed-off-by: Tom Lendacky
---
arch/x86/include/asm/vga.h | 13 +
drivers/gpu/drm/drm_gem.c|2 ++
drivers/gpu/drm/drm_vm.c |4 +
This RFC 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 automatica
This patch adds 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 encyrpted
by copying the kernel through a temporary buffer.
Signed-off-by: Tom Lendacky
---
arch/x86
Use memremap() to map the setup data. This will make the appropriate
decision as to whether a RAM remapping can be done or if a fallback to
ioremap_cache() is needed (similar to the setup data debugfs support).
Signed-off-by: Tom Lendacky
---
arch/x86/kernel/ksysfs.c | 27 ++--
Use memremap() to map the setup data. This simplifies the code and will
make the appropriate decision as to whether a RAM remapping can be done
or if a fallback to ioremap_cache() is needed (which includes checking
PageHighMem).
Signed-off-by: Tom Lendacky
---
arch/x86/kernel/kdebugfs.c | 30
Update the KVM support to include the memory encryption mask when creating
and using nested page tables.
Signed-off-by: Tom Lendacky
---
arch/x86/include/asm/kvm_host.h |3 ++-
arch/x86/kvm/mmu.c |8 ++--
arch/x86/kvm/vmx.c |3 ++-
arch/x86/kvm/x86.c
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 SYS_CFG MSR bit to enable
memory encryption on that AP and allow the AP to continue start up.
Sign
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.
Signed-off-by: Tom Lendacky
---
arch/x86/include/
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.
Signed-off-by: Tom Lendacky
---
arch/x86/realmo
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.
Add support for changing the memory encryption attribute for one or more
memory pages.
Signed-off-by: Tom Lendacky
---
arch/x86/include/asm/cacheflush.h |3 ++
arch/x86/mm/pageattr.c| 66 +
2 files changed, 69 insertions(+)
diff --git a/arch
This patch adds support to return the E820 type associated with an address
range.
Signed-off-by: Tom Lendacky
---
arch/x86/include/asm/e820/api.h |2 ++
arch/x86/include/asm/e820/types.h |2 ++
arch/x86/kernel/e820.c| 26 +++---
3 files changed, 27 ins
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 insertions(+), 3 deletions(-)
diff --git a/arch/x8
> On Feb 12, 2017, at 4:07 PM, Andrew Pinski wrote:
>
> On Mon, Jan 9, 2017 at 3:29 AM, Yury Norov wrote:
>> This series enables aarch64 with ilp32 mode.
>>
...
>
> For folks concerned about performance, here is what we get for SPEC
> CPU 2006 on ThunderX 2 CN99xx.
> Positive means ILP32 is fa
Hi Tony,
On Saturday 21 January 2017 12:00 AM, Tony Lindgren wrote:
> * Kishon Vijay Abraham I [170112 02:34]:
>> Add pcie1 dt node in order for the controller to operate in
>> endpoint mode. However since none of the dra7 based boards have
>> slots configured to operate in endpoint mode, keep EP
Hi,
On Thursday 19 January 2017 03:16 AM, Rob Herring wrote:
> On Thu, Jan 12, 2017 at 03:56:19PM +0530, Kishon Vijay Abraham I wrote:
>> Update device tree binding documentation of TI's dra7xx PCI
>> controller to include property for enabling legacy mode.
>>
>> Signed-off-by: Kishon Vijay Abraha
46 matches
Mail list logo
