Hello,
This version has only a small change in the last patch as requested by
Christoph and Halil, and collects Reviewed-by's.
These patches are applied on top of v5.3-rc2.
I don't have a way to test SME, SEV, nor s390's PEF so the patches have only
been build tested.
Changelog
Since v3:
- Patch "s390/mm: Remove sev_active() function"
- Preserve comment from sev_active() in force_dma_unencrypted().
Suggested by Christoph Hellwig.
Since v2:
- Patch "x86,s390: Move ARCH_HAS_MEM_ENCRYPT definition to arch/Kconfig"
- Added "select ARCH_HAS_MEM_ENCRYPT" to config S390. Suggested by Janani.
- Patch "DMA mapping: Move SME handling to x86-specific files"
- Split up into 3 new patches. Suggested by Christoph Hellwig.
- Patch "swiotlb: Remove call to sme_active()"
- New patch.
- Patch "dma-mapping: Remove dma_check_mask()"
- New patch.
- Patch "x86,s390/mm: Move sme_active() and sme_me_mask to x86-specific header"
- New patch.
- Removed export of sme_active symbol. Suggested by Christoph Hellwig.
- Patch "fs/core/vmcore: Move sev_active() reference to x86 arch code"
- Removed export of sev_active symbol. Suggested by Christoph Hellwig.
- Patch "s390/mm: Remove sev_active() function"
- New patch.
Since v1:
- Patch "x86,s390: Move ARCH_HAS_MEM_ENCRYPT definition to arch/Kconfig"
- Remove definition of ARCH_HAS_MEM_ENCRYPT from s390/Kconfig as well.
- Reworded patch title and message a little bit.
- Patch "DMA mapping: Move SME handling to x86-specific files"
- Adapt s390's <asm/mem_encrypt.h> as well.
- Remove dma_check_mask() from kernel/dma/mapping.c. Suggested by
Christoph Hellwig.
Thiago Jung Bauermann (6):
x86,s390: Move ARCH_HAS_MEM_ENCRYPT definition to arch/Kconfig
swiotlb: Remove call to sme_active()
dma-mapping: Remove dma_check_mask()
x86,s390/mm: Move sme_active() and sme_me_mask to x86-specific header
fs/core/vmcore: Move sev_active() reference to x86 arch code
s390/mm: Remove sev_active() function
arch/Kconfig | 3 +++
arch/s390/Kconfig | 4 +---
arch/s390/include/asm/mem_encrypt.h | 5 +----
arch/s390/mm/init.c | 7 +------
arch/x86/Kconfig | 4 +---
arch/x86/include/asm/mem_encrypt.h | 10 ++++++++++
arch/x86/kernel/crash_dump_64.c | 5 +++++
arch/x86/mm/mem_encrypt.c | 2 --
fs/proc/vmcore.c | 8 ++++----
include/linux/crash_dump.h | 14 ++++++++++++++
include/linux/mem_encrypt.h | 15 +--------------
kernel/dma/mapping.c | 8 --------
kernel/dma/swiotlb.c | 3 +--
13 files changed, 42 insertions(+), 46 deletions(-)
powerpc is also going to use this feature, so put it in a generic location.
Signed-off-by: Thiago Jung Bauermann <[email protected]>
Reviewed-by: Thomas Gleixner <[email protected]>
Reviewed-by: Christoph Hellwig <[email protected]>
---
arch/Kconfig | 3 +++
arch/s390/Kconfig | 4 +---
arch/x86/Kconfig | 4 +---
3 files changed, 5 insertions(+), 6 deletions(-)
diff --git a/arch/Kconfig b/arch/Kconfig
index a7b57dd42c26..89e2e3f64f79 100644
--- a/arch/Kconfig
+++ b/arch/Kconfig
@@ -925,6 +925,9 @@ config LOCK_EVENT_COUNTS
the chance of application behavior change because of timing
differences. The counts are reported via debugfs.
+config ARCH_HAS_MEM_ENCRYPT
+ bool
+
source "kernel/gcov/Kconfig"
source "scripts/gcc-plugins/Kconfig"
diff --git a/arch/s390/Kconfig b/arch/s390/Kconfig
index a4ad2733eedf..f43319c44454 100644
--- a/arch/s390/Kconfig
+++ b/arch/s390/Kconfig
@@ -1,7 +1,4 @@
# SPDX-License-Identifier: GPL-2.0
-config ARCH_HAS_MEM_ENCRYPT
- def_bool y
-
config MMU
def_bool y
@@ -68,6 +65,7 @@ config S390
select ARCH_HAS_GCOV_PROFILE_ALL
select ARCH_HAS_GIGANTIC_PAGE
select ARCH_HAS_KCOV
+ select ARCH_HAS_MEM_ENCRYPT
select ARCH_HAS_PTE_SPECIAL
select ARCH_HAS_SET_MEMORY
select ARCH_HAS_STRICT_KERNEL_RWX
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 222855cc0158..06027809c599 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -68,6 +68,7 @@ config X86
select ARCH_HAS_FORTIFY_SOURCE
select ARCH_HAS_GCOV_PROFILE_ALL
select ARCH_HAS_KCOV if X86_64
+ select ARCH_HAS_MEM_ENCRYPT
select ARCH_HAS_MEMBARRIER_SYNC_CORE
select ARCH_HAS_PMEM_API if X86_64
select ARCH_HAS_PTE_DEVMAP if X86_64
@@ -1518,9 +1519,6 @@ config X86_CPA_STATISTICS
helps to determine the effectiveness of preserving large and huge
page mappings when mapping protections are changed.
-config ARCH_HAS_MEM_ENCRYPT
- def_bool y
-
config AMD_MEM_ENCRYPT
bool "AMD Secure Memory Encryption (SME) support"
depends on X86_64 && CPU_SUP_AMD
Secure Encrypted Virtualization is an x86-specific feature, so it shouldn't
appear in generic kernel code because it forces non-x86 architectures to
define the sev_active() function, which doesn't make a lot of sense.
To solve this problem, add an x86 elfcorehdr_read() function to override
the generic weak implementation. To do that, it's necessary to make
read_from_oldmem() public so that it can be used outside of vmcore.c.
Also, remove the export for sev_active() since it's only used in files that
won't be built as modules.
Signed-off-by: Thiago Jung Bauermann <[email protected]>
Reviewed-by: Christoph Hellwig <[email protected]>
Reviewed-by: Lianbo Jiang <[email protected]>
---
arch/x86/kernel/crash_dump_64.c | 5 +++++
arch/x86/mm/mem_encrypt.c | 1 -
fs/proc/vmcore.c | 8 ++++----
include/linux/crash_dump.h | 14 ++++++++++++++
include/linux/mem_encrypt.h | 1 -
5 files changed, 23 insertions(+), 6 deletions(-)
diff --git a/arch/x86/kernel/crash_dump_64.c b/arch/x86/kernel/crash_dump_64.c
index 22369dd5de3b..045e82e8945b 100644
--- a/arch/x86/kernel/crash_dump_64.c
+++ b/arch/x86/kernel/crash_dump_64.c
@@ -70,3 +70,8 @@ ssize_t copy_oldmem_page_encrypted(unsigned long pfn, char *buf, size_t csize,
{
return __copy_oldmem_page(pfn, buf, csize, offset, userbuf, true);
}
+
+ssize_t elfcorehdr_read(char *buf, size_t count, u64 *ppos)
+{
+ return read_from_oldmem(buf, count, ppos, 0, sev_active());
+}
diff --git a/arch/x86/mm/mem_encrypt.c b/arch/x86/mm/mem_encrypt.c
index 94da5a88abe6..9268c12458c8 100644
--- a/arch/x86/mm/mem_encrypt.c
+++ b/arch/x86/mm/mem_encrypt.c
@@ -349,7 +349,6 @@ bool sev_active(void)
{
return sme_me_mask && sev_enabled;
}
-EXPORT_SYMBOL(sev_active);
/* Override for DMA direct allocation check - ARCH_HAS_FORCE_DMA_UNENCRYPTED */
bool force_dma_unencrypted(struct device *dev)
diff --git a/fs/proc/vmcore.c b/fs/proc/vmcore.c
index 7bcc92add72c..7b13988796e1 100644
--- a/fs/proc/vmcore.c
+++ b/fs/proc/vmcore.c
@@ -104,9 +104,9 @@ static int pfn_is_ram(unsigned long pfn)
}
/* Reads a page from the oldmem device from given offset. */
-static ssize_t read_from_oldmem(char *buf, size_t count,
- u64 *ppos, int userbuf,
- bool encrypted)
+ssize_t read_from_oldmem(char *buf, size_t count,
+ u64 *ppos, int userbuf,
+ bool encrypted)
{
unsigned long pfn, offset;
size_t nr_bytes;
@@ -170,7 +170,7 @@ void __weak elfcorehdr_free(unsigned long long addr)
*/
ssize_t __weak elfcorehdr_read(char *buf, size_t count, u64 *ppos)
{
- return read_from_oldmem(buf, count, ppos, 0, sev_active());
+ return read_from_oldmem(buf, count, ppos, 0, false);
}
/*
diff --git a/include/linux/crash_dump.h b/include/linux/crash_dump.h
index f774c5eb9e3c..4664fc1871de 100644
--- a/include/linux/crash_dump.h
+++ b/include/linux/crash_dump.h
@@ -115,4 +115,18 @@ static inline int vmcore_add_device_dump(struct vmcoredd_data *data)
return -EOPNOTSUPP;
}
#endif /* CONFIG_PROC_VMCORE_DEVICE_DUMP */
+
+#ifdef CONFIG_PROC_VMCORE
+ssize_t read_from_oldmem(char *buf, size_t count,
+ u64 *ppos, int userbuf,
+ bool encrypted);
+#else
+static inline ssize_t read_from_oldmem(char *buf, size_t count,
+ u64 *ppos, int userbuf,
+ bool encrypted)
+{
+ return -EOPNOTSUPP;
+}
+#endif /* CONFIG_PROC_VMCORE */
+
#endif /* LINUX_CRASHDUMP_H */
diff --git a/include/linux/mem_encrypt.h b/include/linux/mem_encrypt.h
index 0c5b0ff9eb29..5c4a18a91f89 100644
--- a/include/linux/mem_encrypt.h
+++ b/include/linux/mem_encrypt.h
@@ -19,7 +19,6 @@
#else /* !CONFIG_ARCH_HAS_MEM_ENCRYPT */
static inline bool mem_encrypt_active(void) { return false; }
-static inline bool sev_active(void) { return false; }
#endif /* CONFIG_ARCH_HAS_MEM_ENCRYPT */
Thiago Jung Bauermann <[email protected]> writes:
> Hello,
>
> This version has only a small change in the last patch as requested by
> Christoph and Halil, and collects Reviewed-by's.
>
> These patches are applied on top of v5.3-rc2.
>
> I don't have a way to test SME, SEV, nor s390's PEF so the patches have only
> been build tested.
I need to take this series via the powerpc tree because there is another
fairly large powerpc specific series dependent on it.
I think this series already has pretty much all the acks it needs, which
almost never happens, amazing work!
I'll put the series in a topic branch, just in case there's any bad
conflicts and other folks want to merge it later on. I'll then merge the
topic branch into my next, and so this series will be tested in
linux-next that way.
cheers
> Changelog
>
> Since v3:
>
> - Patch "s390/mm: Remove sev_active() function"
> - Preserve comment from sev_active() in force_dma_unencrypted().
> Suggested by Christoph Hellwig.
>
> Since v2:
>
> - Patch "x86,s390: Move ARCH_HAS_MEM_ENCRYPT definition to arch/Kconfig"
> - Added "select ARCH_HAS_MEM_ENCRYPT" to config S390. Suggested by Janani.
>
> - Patch "DMA mapping: Move SME handling to x86-specific files"
> - Split up into 3 new patches. Suggested by Christoph Hellwig.
>
> - Patch "swiotlb: Remove call to sme_active()"
> - New patch.
>
> - Patch "dma-mapping: Remove dma_check_mask()"
> - New patch.
>
> - Patch "x86,s390/mm: Move sme_active() and sme_me_mask to x86-specific header"
> - New patch.
> - Removed export of sme_active symbol. Suggested by Christoph Hellwig.
>
> - Patch "fs/core/vmcore: Move sev_active() reference to x86 arch code"
> - Removed export of sev_active symbol. Suggested by Christoph Hellwig.
>
> - Patch "s390/mm: Remove sev_active() function"
> - New patch.
>
> Since v1:
>
> - Patch "x86,s390: Move ARCH_HAS_MEM_ENCRYPT definition to arch/Kconfig"
> - Remove definition of ARCH_HAS_MEM_ENCRYPT from s390/Kconfig as well.
> - Reworded patch title and message a little bit.
>
> - Patch "DMA mapping: Move SME handling to x86-specific files"
> - Adapt s390's <asm/mem_encrypt.h> as well.
> - Remove dma_check_mask() from kernel/dma/mapping.c. Suggested by
> Christoph Hellwig.
>
> Thiago Jung Bauermann (6):
> x86,s390: Move ARCH_HAS_MEM_ENCRYPT definition to arch/Kconfig
> swiotlb: Remove call to sme_active()
> dma-mapping: Remove dma_check_mask()
> x86,s390/mm: Move sme_active() and sme_me_mask to x86-specific header
> fs/core/vmcore: Move sev_active() reference to x86 arch code
> s390/mm: Remove sev_active() function
>
> arch/Kconfig | 3 +++
> arch/s390/Kconfig | 4 +---
> arch/s390/include/asm/mem_encrypt.h | 5 +----
> arch/s390/mm/init.c | 7 +------
> arch/x86/Kconfig | 4 +---
> arch/x86/include/asm/mem_encrypt.h | 10 ++++++++++
> arch/x86/kernel/crash_dump_64.c | 5 +++++
> arch/x86/mm/mem_encrypt.c | 2 --
> fs/proc/vmcore.c | 8 ++++----
> include/linux/crash_dump.h | 14 ++++++++++++++
> include/linux/mem_encrypt.h | 15 +--------------
> kernel/dma/mapping.c | 8 --------
> kernel/dma/swiotlb.c | 3 +--
> 13 files changed, 42 insertions(+), 46 deletions(-)
[email protected] writes:
> Thiago Jung Bauermann <[email protected]> writes:
>> Hello,
>>
>> This version has only a small change in the last patch as requested by
>> Christoph and Halil, and collects Reviewed-by's.
>>
>> These patches are applied on top of v5.3-rc2.
>>
>> I don't have a way to test SME, SEV, nor s390's PEF so the patches have only
>> been build tested.
>
> I need to take this series via the powerpc tree because there is another
> fairly large powerpc specific series dependent on it.
>
> I think this series already has pretty much all the acks it needs, which
> almost never happens, amazing work!
Yes, thank you very much to everyone who reviewed the patches!
> I'll put the series in a topic branch, just in case there's any bad
> conflicts and other folks want to merge it later on. I'll then merge the
> topic branch into my next, and so this series will be tested in
> linux-next that way.
That's awesome. Thank you very much!
--
Thiago Jung Bauermann
IBM Linux Technology Center
On Fri, Aug 09, 2019 at 10:51:41PM +1000, [email protected] wrote:
> I need to take this series via the powerpc tree because there is another
> fairly large powerpc specific series dependent on it.
>
> I think this series already has pretty much all the acks it needs, which
> almost never happens, amazing work!
>
> I'll put the series in a topic branch, just in case there's any bad
> conflicts and other folks want to merge it later on. I'll then merge the
> topic branch into my next, and so this series will be tested in
> linux-next that way.
Sounds good to me, I don't expect conflicts from the dma-mapping tree.
On Tue, 2019-08-06 at 04:49:14 UTC, Thiago Jung Bauermann wrote:
> powerpc is also going to use this feature, so put it in a generic location.
>
> Signed-off-by: Thiago Jung Bauermann <[email protected]>
> Reviewed-by: Thomas Gleixner <[email protected]>
> Reviewed-by: Christoph Hellwig <[email protected]>
Series applied to powerpc topic/mem-encrypt, thanks.
https://git.kernel.org/powerpc/c/0c9c1d56397518eb823d458b00b06bcccd956794
cheers
Michael Ellerman <[email protected]> writes:
> On Tue, 2019-08-06 at 04:49:14 UTC, Thiago Jung Bauermann wrote:
>> powerpc is also going to use this feature, so put it in a generic location.
>>
>> Signed-off-by: Thiago Jung Bauermann <[email protected]>
>> Reviewed-by: Thomas Gleixner <[email protected]>
>> Reviewed-by: Christoph Hellwig <[email protected]>
>
> Series applied to powerpc topic/mem-encrypt, thanks.
>
> https://git.kernel.org/powerpc/c/0c9c1d56397518eb823d458b00b06bcccd956794
Thank you!
--
Thiago Jung Bauermann
IBM Linux Technology Center