On Thu, 21 Apr 2016 23:04:26 +0800
Zhigang Gao wrote:
> Chinese maintainer for help. Contact the Chinese maintainer, if this
> translation is outdated or there is problem with translation.
>
> -Chinese maintainer: Zhang Le
> +Chinese maintainer: Zhang Le
So this makes me a little uncomfo
On Mon, 25 Apr 2016 18:03:07 +0200
Arnd Bergmann wrote:
> As suggested by Nicolas Pitre, here is a resend of two patches to
> move the kernel modules from Documentation/*/ to samples/*/.
>
> With Nico's changes in place, it's no longer necessary to do this,
> but it seems like a good idea anyway
On Fri, 22 Apr 2016 21:17:23 +0200
René Nyffenegger wrote:
> This is my first patch submission. Please let me know if I have made a
> mistake anywhere.
Thank you for improving the documentation!
Unfortunately, the patch was corrupted by your mail client and does not
apply. Could I please ask
On Mon, Apr 25, 2016 at 09:47:40PM +0300, Yury Norov wrote:
> On Mon, Apr 25, 2016 at 09:19:13PM +0300, Yury Norov wrote:
> > On Mon, Apr 25, 2016 at 06:26:56PM +0100, Catalin Marinas wrote:
> > > On Wed, Apr 06, 2016 at 01:08:42AM +0300, Yury Norov wrote:
> > > > --- a/arch/arm64/kernel/entry.S
>
On 2016/4/26 17:52, Jonathan Corbet wrote:
> On Thu, 21 Apr 2016 23:04:26 +0800
> Zhigang Gao wrote:
>
>> Chinese maintainer for help. Contact the Chinese maintainer, if this
>> translation is outdated or there is problem with translation.
>>
>> -Chinese maintainer: Zhang Le
>> +Chinese mai
On 04/26/2016 11:59 AM, Jonathan Corbet wrote:
> On Mon, 25 Apr 2016 18:03:07 +0200
> Arnd Bergmann wrote:
>
>> As suggested by Nicolas Pitre, here is a resend of two patches to
>> move the kernel modules from Documentation/*/ to samples/*/.
>>
>> With Nico's changes in place, it's no longer ne
Em Tue, 26 Apr 2016 12:28:42 +0200
Hans Verkuil escreveu:
> On 04/26/2016 11:59 AM, Jonathan Corbet wrote:
> > On Mon, 25 Apr 2016 18:03:07 +0200
> > Arnd Bergmann wrote:
> >
> >> As suggested by Nicolas Pitre, here is a resend of two patches to
> >> move the kernel modules from Documentation
On Mon, 25 Apr 2016 18:05:53 +0800
Yongji Xie wrote:
> Hi Alex,
>
> Any comment?
TBH, I shuffled this to the bottom of the review pile because you're
depending on a patch series for ARM MSI mapping that's still very much
in flux. You've really got 3 or 4 separate patch series here that
should
On Wed, Apr 06, 2016 at 01:08:42AM +0300, Yury Norov wrote:
> +/* Using non-compat syscalls where necessary */
> +#define compat_sys_fadvise64_64sys_fadvise64_64
> +#define compat_sys_fallocate sys_fallocate
> +#define compat_sys_ftruncate64 sys_ftruncate
> +#define compat
Hello!
This series contains a few memory-barriers.txt updates and a locktorture
cleanup:
1. Add a disclaimer to memory-barrier.txt, courtesy of
Peter Zijlstra.
2. Explicitly state the purpose of memory-barrier.txt, courtesy
of David Howells.
3. Explicitly state th
From: Peter Zijlstra
It appears people are reading this document as a requirements list for
building hardware. This is not the intent of this document. Nor is it
particularly suited for this purpose.
The primary purpose of this document is our collective attempt to define
a set of primitives tha
From: Will Deacon
For compound atomics performing both a load and a store operation, make
it clear that _acquire and _release variants refer only to the load and
store portions of compound atomic. For example, xchg_acquire is an xchg
operation where the load takes on ACQUIRE semantics.
Cc: Paul
From: David Howells
There has been some confusion about the purpose of memory-barriers.txt,
so this commit adds a statement of purpose.
Signed-off-by: David Howells
Signed-off-by: Paul E. McKenney
---
Documentation/memory-barriers.txt | 16
1 file changed, 16 insertions(+)
d
This commit replaces a #ifdef with IS_ENABLED(), saving five lines.
Signed-off-by: Paul E. McKenney
---
kernel/locking/locktorture.c | 7 +--
1 file changed, 1 insertion(+), 6 deletions(-)
diff --git a/kernel/locking/locktorture.c b/kernel/locking/locktorture.c
index d066a50dc87e..f8c5af52a
On Mon 2016-04-25 20:34:07, Jarkko Sakkinen wrote:
> Intel(R) SGX is a set of CPU instructions that can be used by
> applications to set aside private regions of code and data. The code
> outside the enclave is disallowed to access the memory inside the
> enclave by the CPU access control.
>
> Th
On Tue, Apr 26, 2016 at 12:00 PM, Pavel Machek wrote:
> On Mon 2016-04-25 20:34:07, Jarkko Sakkinen wrote:
>> Intel(R) SGX is a set of CPU instructions that can be used by
>> applications to set aside private regions of code and data. The code
>> outside the enclave is disallowed to access the me
On Tue 2016-04-26 12:05:48, Andy Lutomirski wrote:
> On Tue, Apr 26, 2016 at 12:00 PM, Pavel Machek wrote:
> > On Mon 2016-04-25 20:34:07, Jarkko Sakkinen wrote:
> >> Intel(R) SGX is a set of CPU instructions that can be used by
> >> applications to set aside private regions of code and data. The
On Tue, Apr 26, 2016 at 12:41 PM, Pavel Machek wrote:
> On Tue 2016-04-26 12:05:48, Andy Lutomirski wrote:
>> On Tue, Apr 26, 2016 at 12:00 PM, Pavel Machek wrote:
>> > On Mon 2016-04-25 20:34:07, Jarkko Sakkinen wrote:
>> >> Intel(R) SGX is a set of CPU instructions that can be used by
>> >> app
Hi!
> >> >> The firmware uses PRMRR registers to reserve an area of physical memory
> >> >> called Enclave Page Cache (EPC). There is a hardware unit in the
> >> >> processor called Memory Encryption Engine. The MEE encrypts and decrypts
> >> >> the EPC pages as they enter and leave the processor
> Replay Protected Memory Block. It's a device that allows someone to
> write to it and confirm that the write happened and the old contents
> is no longer available. You could use it to implement an enclave that
> checks a password for your disk but only allows you to try a certain
> number of t
> > Storing your ssh private key encrypted such that even someone who
> > completely compromises your system can't get the actual private key
>
> Well, if someone gets root on my system, he can get my ssh private
> key right?
Potentially not. If you are using a TPM or other TEE (such as SGX
> But... that will mean that my ssh will need to be SGX-aware, and that
> I will not be able to switch to AMD machine in future. ... or to other
> Intel machine for that matter, right?
I'm not privy to AMD's CPU design plans.
However I think for the ssl/ssh case you'd use the same interfaces
curr
On Tue 2016-04-26 21:59:52, One Thousand Gnomes wrote:
> > But... that will mean that my ssh will need to be SGX-aware, and that
> > I will not be able to switch to AMD machine in future. ... or to other
> > Intel machine for that matter, right?
>
> I'm not privy to AMD's CPU design plans.
>
> Ho
On Apr 26, 2016 1:11 PM, "Pavel Machek" wrote:
>
> Hi!
>
> > >> >> The firmware uses PRMRR registers to reserve an area of physical
> > >> >> memory
> > >> >> called Enclave Page Cache (EPC). There is a hardware unit in the
> > >> >> processor called Memory Encryption Engine. The MEE encrypts and
On Tue, Apr 26, 2016 at 2:52 PM, Pavel Machek wrote:
> On Tue 2016-04-26 21:59:52, One Thousand Gnomes wrote:
>> > But... that will mean that my ssh will need to be SGX-aware, and that
>> > I will not be able to switch to AMD machine in future. ... or to other
>> > Intel machine for that matter, r
Encrypt memory areas in place when possible (e.g. zero page, etc.) so
that special handling isn't needed afterwards.
Signed-off-by: Tom Lendacky
---
arch/x86/kernel/head64.c | 90 +++---
arch/x86/kernel/setup.c |8
2 files changed, 93 insertion
Add to the early_memmap support to be able to specify encrypted and
un-encrypted 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
Provide support for Secure Memory Encryption (SME). This initial support
defines the memory encryption mask as a variable for quick access and an
accessor for retrieving the number of physical addressing bits lost if
SME is enabled.
Signed-off-by: Tom Lendacky
---
arch/x86/include/asm/mem_encryp
The EFI tables are not encrypted and need to be accessed as such. Be sure
to memmap them without the encryption attribute set. For EFI support that
lives outside of the arch/x86 tree, create a routine that uses the __weak
attribute so that it can be overridden by an architecture specific routine.
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
- Update kernel boot support to call an SME routine that checks for and
sets the SME capability (the SME routine will gro
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
For AMD processors that support PAT, set the write-protect cache mode
(_PAGE_CACHE_MODE_WP) entry to the actual write-protect value (x05).
Signed-off-by: Tom Lendacky
---
arch/x86/mm/pat.c | 11 +--
1 file changed, 9 insertions(+), 2 deletions(-)
diff --git a/arch/x86/mm/pat.c b/arch/
Provide support for Secure Memory Encryption (SME). This initial support
defines the memory encryption mask as a variable for quick access and an
accessor for retrieving the number of physical addressing bits lost if
SME is enabled.
Signed-off-by: Tom Lendacky
---
arch/x86/include/asm/mem_encryp
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
- Update kernel boot support to call an SME routine that checks for and
sets the SME capability (the SME routine will gro
Provide the Kconfig support to build the SME support in the kernel.
Signed-off-by: Tom Lendacky
---
arch/x86/Kconfig |9 +
1 file changed, 9 insertions(+)
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 7bb1574..13249b5 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@
Encrypt memory areas in place when possible (e.g. zero page, etc.) so
that special handling isn't needed afterwards.
Signed-off-by: Tom Lendacky
---
arch/x86/kernel/head64.c | 90 +++---
arch/x86/kernel/setup.c |8
2 files changed, 93 insertion
Add support to set the memory encryption enable flag on the APs during
realmode initialization. When an AP is started it checks this flag, and
if set, enables memory encryption on its core.
Signed-off-by: Tom Lendacky
---
arch/x86/include/asm/msr-index.h |2 ++
arch/x86/include/asm/realm
This patch adds the support to check for and enable SME when available
on the processor and when the mem_encrypt=on command line option is set.
This consists of setting the encryption mask, calculating the number of
physical bits of addressing lost and encrypting the kernel "in place."
Signed-off-
Since the VGA memory needs to be accessed unencrypted be sure that the
memory encryption mask is not set for the VGA range being mapped.
Signed-off-by: Tom Lendacky
---
arch/x86/include/asm/vga.h | 13 +
1 file changed, 13 insertions(+)
diff --git a/arch/x86/include/asm/vga.h b/ar
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
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 |2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/x86/kernel/cpu/common.c b/ar
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 |2 +-
arch/x86/kvm/mmu.c |7 +--
arch/x86/kvm/vmx.c |2 +-
arch/x86/kvm/x86.c
Add support to the AMD IOMMU driver to set the memory encryption mask if
memory encryption is enabled.
Signed-off-by: Tom Lendacky
---
arch/x86/include/asm/mem_encrypt.h |2 ++
arch/x86/mm/mem_encrypt.c |5 +
drivers/iommu/amd_iommu.c | 10 ++
3 files chan
For AMD processors that support PAT, set the write-protect cache mode
(_PAGE_CACHE_MODE_WP) entry to the actual write-protect value (x05).
Signed-off-by: Tom Lendacky
---
arch/x86/mm/pat.c | 11 +--
1 file changed, 9 insertions(+), 2 deletions(-)
diff --git a/arch/x86/mm/pat.c b/arch/
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
This adds support to be able to either encrypt or decrypt data 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 un-encrypted memory area is in the proper state
(for example the i
Add to the early_memmap support to be able to specify encrypted and
un-encrypted 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
The device tree is not encrypted and needs to be accessed as such. Be sure
to memmap it without the encryption mask set.
Signed-off-by: Tom Lendacky
---
arch/x86/kernel/devicetree.c |6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/arch/x86/kernel/devicetree.c b/arch/x
This adds support to be able to either encrypt or decrypt data 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 un-encrypted memory area is in the proper state
(for example the i
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 un-encrypted bounce buffers for use by these devices.
Signed-of
Update the cpu features to include identifying and reporting on the
Secure Memory Encryption feature.
Signed-off-by: Tom Lendacky
---
arch/x86/include/asm/cpufeature.h |1 +
arch/x86/include/asm/cpufeatures.h |5 -
arch/x86/kernel/cpu/scattered.c|1 +
3 files changed, 6 inse
Provide the Kconfig support to build the SME support in the kernel.
Signed-off-by: Tom Lendacky
---
arch/x86/Kconfig |9 +
1 file changed, 9 insertions(+)
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 7bb1574..13249b5 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@
The EFI tables are not encrypted and need to be accessed as such. Be sure
to memmap them without the encryption attribute set. For EFI support that
lives outside of the arch/x86 tree, create a routine that uses the __weak
attribute so that it can be overridden by an architecture specific routine.
Update the cpu features to include identifying and reporting on the
Secure Memory Encryption feature.
Signed-off-by: Tom Lendacky
---
arch/x86/include/asm/cpufeature.h |1 +
arch/x86/include/asm/cpufeatures.h |5 -
arch/x86/kernel/cpu/scattered.c|1 +
3 files changed, 6 inse
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 |2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/x86/kernel/cpu/common.c b/ar
This fixes several spelling mistakes in the Documentation/ tree, which
are caught by checkpatch.pl's spell checking.
Signed-off-by: Kees Cook
---
Documentation/ABI/obsolete/sysfs-driver-hid-roccat-savu | 4 ++--
Documentation/ABI/testing/sysfs-bus-event_source-devices-hv_24x7 | 2 +-
Do
On Tue, Apr 26, 2016 at 4:34 PM, Randy Dunlap wrote:
> On 04/26/16 16:28, Kees Cook wrote:
>> This fixes several spelling mistakes in the Documentation/ tree, which
>> are caught by checkpatch.pl's spell checking.
>>
>> Signed-off-by: Kees Cook
>> ---
>> Documentation/ABI/obsolete/sysfs-driver-h
On 04/26/16 16:28, Kees Cook wrote:
> This fixes several spelling mistakes in the Documentation/ tree, which
> are caught by checkpatch.pl's spell checking.
>
> Signed-off-by: Kees Cook
> ---
> Documentation/ABI/obsolete/sysfs-driver-hid-roccat-savu | 4 ++--
> Documentation/ABI/testing
This fixes several spelling mistakes in the Documentation/ tree, which
are caught by checkpatch.pl's spell checking.
Signed-off-by: Kees Cook
---
Documentation/ABI/obsolete/sysfs-driver-hid-roccat-savu | 11 ++-
.../ABI/testing/sysfs-bus-event_source-devices-hv_24x7| 2 +-
On Tue, Apr 26, 2016 at 04:28:27PM -0700, Kees Cook wrote:
> This fixes several spelling mistakes in the Documentation/ tree, which
> are caught by checkpatch.pl's spell checking.
>
> Signed-off-by: Kees Cook
Both "resizeable" and "resizable" are forms, but I suppose saving
a few characters is u
A few instances of "fimware" instead of "firmware" were found. Fix these
and add it to the spelling.txt file.
Reported-by: Randy Dunlap
Signed-off-by: Kees Cook
---
Looks like spelling.txt changes have been going in through -mm?
---
drivers/media/usb/dvb-usb/dib0700_core.c | 2 +-
drivers/
On Tue, Apr 26, 2016 at 4:44 PM, Paul E. McKenney
wrote:
> On Tue, Apr 26, 2016 at 04:28:27PM -0700, Kees Cook wrote:
>> This fixes several spelling mistakes in the Documentation/ tree, which
>> are caught by checkpatch.pl's spell checking.
>>
>> Signed-off-by: Kees Cook
>
> Both "resizeable" and
On 04/26/16 16:41, Kees Cook wrote:
> This fixes several spelling mistakes in the Documentation/ tree, which
> are caught by checkpatch.pl's spell checking.
>
> Signed-off-by: Kees Cook
Acked-by: Randy Dunlap
Thanks.
> ---
> Documentation/ABI/obsolete/sysfs-driver-hid-roccat-savu | 11
On 2016/4/27 0:40, Alex Williamson wrote:
On Mon, 25 Apr 2016 18:05:53 +0800
Yongji Xie wrote:
Hi Alex,
Any comment?
TBH, I shuffled this to the bottom of the review pile because you're
depending on a patch series for ARM MSI mapping that's still very much
in flux. You've really got 3 or 4
Hi, Kees Cook
* From: Kees Cook [mailto:keesc...@chromium.org]
> Sent: Wednesday, April 27, 2016 7:48 AM
> To: Andrew Morton
> Cc: Randy Dunlap ; Andy Whitcroft
> ; Joe Perches ; Zhao Lei
> ; linux-doc@vger.kernel.org;
> linux-ker...@vger.kernel.org
> Subject: [PATCH] scripts/spelling.txt: add "f
65 matches
Mail list logo
