* Re: [PATCH v3] MIPS: Fix build breakage caused by header file changes
From: Ingo Molnar @ 2017-03-07 10:34 UTC (permalink / raw)
To: James Hogan
Cc: Guenter Roeck, Ralf Baechle, Herbert Xu, linux-mips, linux-kernel,
linux-crypto, Linus Torvalds
In-Reply-To: <20170307093850.GD996@jhogan-linux.le.imgtec.org>
* James Hogan <james.hogan@imgtec.com> wrote:
> Hi Ingo,
>
> On Tue, Mar 07, 2017 at 08:38:05AM +0100, Ingo Molnar wrote:
> > Just a quick question: is your MIPS build fix going to be merged and sent to
> > Linus? I can apply it too, and send it to Linus later today, together with a few
> > other sched.h header related build fixes.
>
> One for Ralf...
Ralf, what's your preference?
> > Assuming it's all properly tested - my limited MIPS defconfig builds worked fine -
> > but MIPS has a lot of build variations.
>
> If you have a branch with other generic fixes I'm happy to push it to
> our MIPS buildbot too to double check.
So I have not applied your patch yet (can do it with ack from Ralf), but all the
other fixes that are pending can be found in:
git git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git core/urgent
It's these commits:
bb35e4515411 drivers/char/nwbutton: Fix build breakage caused by include file reshuffling
80aa1a54f054 h8300: Fix build breakage caused by header file changes
1fbdbcea8005 avr32: Fix build error caused by include file reshuffling
Thanks,
Ingo
^ permalink raw reply
* Re: [RFC PATCH v2 05/32] x86: Use encrypted access of BOOT related data with SEV
From: Borislav Petkov @ 2017-03-07 11:09 UTC (permalink / raw)
To: Brijesh Singh
Cc: simon.guinot, linux-efi, kvm, rkrcmar, matt, linux-pci,
linus.walleij, gary.hook, linux-mm, paul.gortmaker, hpa, cl,
dan.j.williams, aarcange, sfr, andriy.shevchenko, herbert, bhe,
xemul, joro, x86, peterz, piotr.luc, mingo, msalter, ross.zwisler,
dyoung, thomas.lendacky, jroedel, keescook, arnd, toshi.kani,
mathieu.desnoyers, luto, devel, bhelgaas, tglx, mchehab,
iamjoonsoo.kim, labbott
In-Reply-To: <148846757895.2349.561582698953591240.stgit@brijesh-build-machine>
On Thu, Mar 02, 2017 at 10:12:59AM -0500, Brijesh Singh wrote:
> From: Tom Lendacky <thomas.lendacky@amd.com>
>
> When Secure Encrypted Virtualization (SEV) is active, BOOT data (such as
> EFI related data, setup data) is encrypted and needs to be accessed as
> such when mapped. Update the architecture override in early_memremap to
> keep the encryption attribute when mapping this data.
This could also explain why persistent memory needs to be accessed
decrypted with SEV.
In general, what the difference in that aspect is in respect to SME. And
I'd write that in the comment over the function. And not say "E820 areas
are checked in making this determination." because that is visible but
say *why* we need to check those ranges and determine access depending
on their type.
--
Regards/Gruss,
Boris.
SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg)
--
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: [RFC PATCH v2 02/32] x86: Secure Encrypted Virtualization (SEV) support
From: Borislav Petkov @ 2017-03-07 11:19 UTC (permalink / raw)
To: Brijesh Singh
Cc: linux-efi, kvm, rkrcmar, matt, linux-pci, linus.walleij,
gary.hook, linux-mm, hpa, cl, tglx, aarcange, sfr, mchehab,
simon.guinot, bhe, xemul, joro, x86, peterz, piotr.luc, mingo,
msalter, ross.zwisler, labbott, dyoung, thomas.lendacky, jroedel,
keescook, arnd, toshi.kani, mathieu.desnoyers, luto, pbonzini,
bhelgaas, dan.j.williams, andriy.shevchenko, akpm, herbert,
tony.luck, pau
In-Reply-To: <148846754069.2349.4698319264278045964.stgit@brijesh-build-machine>
On Thu, Mar 02, 2017 at 10:12:20AM -0500, Brijesh Singh wrote:
> From: Tom Lendacky <thomas.lendacky@amd.com>
>
> Provide support for Secure Encyrpted Virtualization (SEV). This initial
> support defines a flag that is used by the kernel to determine if it is
> running with SEV active.
>
> Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
Btw,
you need to add your Signed-off-by here after Tom's to denote that
you're handing that patch forward.
--
Regards/Gruss,
Boris.
SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg)
--
_______________________________________________
devel mailing list
devel@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
^ permalink raw reply
* Re: [RFC PATCH v2 07/32] x86/efi: Access EFI data as encrypted when SEV is active
From: Borislav Petkov @ 2017-03-07 11:57 UTC (permalink / raw)
To: Brijesh Singh, Matt Fleming
Cc: simon.guinot, linux-efi, kvm, rkrcmar, matt, linux-pci,
linus.walleij, gary.hook, linux-mm, paul.gortmaker, hpa, cl,
dan.j.williams, aarcange, sfr, andriy.shevchenko, herbert, bhe,
xemul, joro, x86, peterz, piotr.luc, mingo, msalter, ross.zwisler,
dyoung, thomas.lendacky, jroedel, keescook, arnd, toshi.kani,
mathieu.desnoyers, luto, devel, bhelgaas, tglx, mchehab,
iamjoonsoo.kim, labbott
In-Reply-To: <148846760142.2349.8522516472305792434.stgit@brijesh-build-machine>
On Thu, Mar 02, 2017 at 10:13:21AM -0500, Brijesh Singh wrote:
> From: Tom Lendacky <thomas.lendacky@amd.com>
>
> EFI data is encrypted when the kernel is run under SEV. Update the
> page table references to be sure the EFI memory areas are accessed
> encrypted.
>
> Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
> Signed-off-by: Brijesh Singh <brijesh.singh@amd.com>
This SOB chain looks good.
> ---
> arch/x86/platform/efi/efi_64.c | 15 ++++++++++++++-
> 1 file changed, 14 insertions(+), 1 deletion(-)
>
> diff --git a/arch/x86/platform/efi/efi_64.c b/arch/x86/platform/efi/efi_64.c
> index 2d8674d..9a76ed8 100644
> --- a/arch/x86/platform/efi/efi_64.c
> +++ b/arch/x86/platform/efi/efi_64.c
> @@ -45,6 +45,7 @@
> #include <asm/realmode.h>
> #include <asm/time.h>
> #include <asm/pgalloc.h>
> +#include <asm/mem_encrypt.h>
>
> /*
> * We allocate runtime services regions bottom-up, starting from -4G, i.e.
> @@ -286,7 +287,10 @@ int __init efi_setup_page_tables(unsigned long pa_memmap, unsigned num_pages)
> * as trim_bios_range() will reserve the first page and isolate it away
> * from memory allocators anyway.
> */
> - if (kernel_map_pages_in_pgd(pgd, 0x0, 0x0, 1, _PAGE_RW)) {
> + pf = _PAGE_RW;
> + if (sev_active())
> + pf |= _PAGE_ENC;
> + if (kernel_map_pages_in_pgd(pgd, 0x0, 0x0, 1, pf)) {
> pr_err("Failed to create 1:1 mapping for the first page!\n");
> return 1;
> }
> @@ -329,6 +333,9 @@ static void __init __map_region(efi_memory_desc_t *md, u64 va)
> if (!(md->attribute & EFI_MEMORY_WB))
> flags |= _PAGE_PCD;
>
> + if (sev_active())
> + flags |= _PAGE_ENC;
> +
So I'm wondering if we could avoid this sprinkling of _PAGE_ENC in the
EFI code by defining something like __supported_pte_mask but called
__efi_base_page_flags or so which has _PAGE_ENC cleared in the SME case,
i.e., when baremetal and has it set in the SEV case.
Then we could simply OR in __efi_base_page_flags which the SME/SEV code
will set appropriately early enough.
Hmm.
Matt, what do you think?
--
Regards/Gruss,
Boris.
SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg)
--
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* [PATCH 4/4] hwrng: omap - move clock related code to omap_rng_probe()
From: Thomas Petazzoni @ 2017-03-07 14:14 UTC (permalink / raw)
To: Deepak Saxena, Matt Mackall, Herbert Xu
Cc: linux-crypto, romain.perier, Jason Cooper, Andrew Lunn,
Sebastian Hesselbarth, Gregory Clement, Nadav Haklai, Hanna Hawa,
Yehuda Yitschak, Thomas Petazzoni
In-Reply-To: <1488896089-17586-1-git-send-email-thomas.petazzoni@free-electrons.com>
Currently, the code that takes a reference to the clock and enables it
is located inside of_get_omap_rng_device_details(), called only when
probing through the Device Tree.
However, there is nothing that makes this clock logic dependent on the
Device Tree, so it makes more sense to have it in omap_rng_probe()
directly.
Moreover, we make sure to bail out if we can't enable the clock. Indeed,
while the clock is optional, if a clock is present, we really want to
succeed in enabling it. And we fix the error message to fit on one line,
so that it is grep-friendly.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
---
drivers/char/hw_random/omap-rng.c | 22 ++++++++++++----------
1 file changed, 12 insertions(+), 10 deletions(-)
diff --git a/drivers/char/hw_random/omap-rng.c b/drivers/char/hw_random/omap-rng.c
index b1ad125..74d11ae 100644
--- a/drivers/char/hw_random/omap-rng.c
+++ b/drivers/char/hw_random/omap-rng.c
@@ -398,16 +398,6 @@ static int of_get_omap_rng_device_details(struct omap_rng_dev *priv,
return err;
}
- priv->clk = devm_clk_get(&pdev->dev, NULL);
- if (IS_ERR(priv->clk) && PTR_ERR(priv->clk) == -EPROBE_DEFER)
- return -EPROBE_DEFER;
- if (!IS_ERR(priv->clk)) {
- err = clk_prepare_enable(priv->clk);
- if (err)
- dev_err(&pdev->dev, "unable to enable the clk, "
- "err = %d\n", err);
- }
-
/*
* On OMAP4, enabling the shutdown_oflo interrupt is
* done in the interrupt mask register. There is no
@@ -478,6 +468,18 @@ static int omap_rng_probe(struct platform_device *pdev)
goto err_ioremap;
}
+ priv->clk = devm_clk_get(&pdev->dev, NULL);
+ if (IS_ERR(priv->clk) && PTR_ERR(priv->clk) == -EPROBE_DEFER)
+ return -EPROBE_DEFER;
+ if (!IS_ERR(priv->clk)) {
+ ret = clk_prepare_enable(priv->clk);
+ if (ret) {
+ dev_err(&pdev->dev,
+ "Unable to enable the clk: %d\n", ret);
+ goto err_register;
+ }
+ }
+
ret = (dev->of_node) ? of_get_omap_rng_device_details(priv, pdev) :
get_omap_rng_device_details(priv);
if (ret)
--
2.7.4
^ permalink raw reply related
* [PATCH 0/4] hwrng: omap - fixes and improvements
From: Thomas Petazzoni @ 2017-03-07 14:14 UTC (permalink / raw)
To: Deepak Saxena, Matt Mackall, Herbert Xu
Cc: linux-crypto, romain.perier, Jason Cooper, Andrew Lunn,
Sebastian Hesselbarth, Gregory Clement, Nadav Haklai, Hanna Hawa,
Yehuda Yitschak, Thomas Petazzoni
Hello,
This small patch series brings a few fixes and improvements to the
omap_rng driver. The first fix is particularly important, as it fixes
using the driver built as a module on SoCs that require a clock for
the IP to work properly.
Thanks,
Thomas
Thomas Petazzoni (4):
hwrng: omap - write registers after enabling the clock
hwrng: omap - use devm_clk_get() instead of of_clk_get()
hwrng: omap - Do not access INTMASK_REG on EIP76
hwrng: omap - move clock related code to omap_rng_probe()
drivers/char/hw_random/omap-rng.c | 36 +++++++++++++++++++++++++-----------
1 file changed, 25 insertions(+), 11 deletions(-)
--
2.7.4
^ permalink raw reply
* [PATCH 1/4] hwrng: omap - write registers after enabling the clock
From: Thomas Petazzoni @ 2017-03-07 14:14 UTC (permalink / raw)
To: Deepak Saxena, Matt Mackall, Herbert Xu
Cc: linux-crypto, romain.perier, Jason Cooper, Andrew Lunn,
Sebastian Hesselbarth, Gregory Clement, Nadav Haklai, Hanna Hawa,
Yehuda Yitschak, Thomas Petazzoni, stable
In-Reply-To: <1488896089-17586-1-git-send-email-thomas.petazzoni@free-electrons.com>
Commit 383212425c926 ("hwrng: omap - Add device variant for SafeXcel
IP-76 found in Armada 8K") added support for the SafeXcel IP-76 variant
of the IP. This modification included getting a reference and enabling a
clock. Unfortunately, this was done *after* writing to the
RNG_INTMASK_REG register. This generally works fine when the driver is
built-in because the clock might have been left enabled by the
bootloader, but fails short when the driver is built as a module: it
causes a system hang because a register is being accessed while the
clock is not enabled.
This commit fixes that by making the register access *after* enabling
the clock.
This issue was found by the kernelci.org testing effort.
Fixes: 383212425c926 ("hwrng: omap - Add device variant for SafeXcel IP-76 found in Armada 8K")
Cc: <stable@vger.kernel.org>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
---
drivers/char/hw_random/omap-rng.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/char/hw_random/omap-rng.c b/drivers/char/hw_random/omap-rng.c
index 3ad86fd..efa3747 100644
--- a/drivers/char/hw_random/omap-rng.c
+++ b/drivers/char/hw_random/omap-rng.c
@@ -397,7 +397,6 @@ static int of_get_omap_rng_device_details(struct omap_rng_dev *priv,
irq, err);
return err;
}
- omap_rng_write(priv, RNG_INTMASK_REG, RNG_SHUTDOWN_OFLO_MASK);
priv->clk = of_clk_get(pdev->dev.of_node, 0);
if (IS_ERR(priv->clk) && PTR_ERR(priv->clk) == -EPROBE_DEFER)
@@ -408,6 +407,8 @@ static int of_get_omap_rng_device_details(struct omap_rng_dev *priv,
dev_err(&pdev->dev, "unable to enable the clk, "
"err = %d\n", err);
}
+
+ omap_rng_write(priv, RNG_INTMASK_REG, RNG_SHUTDOWN_OFLO_MASK);
}
return 0;
}
--
2.7.4
^ permalink raw reply related
* [PATCH 2/4] hwrng: omap - use devm_clk_get() instead of of_clk_get()
From: Thomas Petazzoni @ 2017-03-07 14:14 UTC (permalink / raw)
To: Deepak Saxena, Matt Mackall, Herbert Xu
Cc: linux-crypto, romain.perier, Jason Cooper, Andrew Lunn,
Sebastian Hesselbarth, Gregory Clement, Nadav Haklai, Hanna Hawa,
Yehuda Yitschak, Thomas Petazzoni, stable
In-Reply-To: <1488896089-17586-1-git-send-email-thomas.petazzoni@free-electrons.com>
The omap-rng driver currently uses of_clk_get() to get a reference to
the clock, but never releases that reference. This commit fixes that by
using devm_clk_get() instead.
Fixes: 383212425c926 ("hwrng: omap - Add device variant for SafeXcel IP-76 found in Armada 8K")
Cc: <stable@vger.kernel.org>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
---
drivers/char/hw_random/omap-rng.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/char/hw_random/omap-rng.c b/drivers/char/hw_random/omap-rng.c
index efa3747..d286628 100644
--- a/drivers/char/hw_random/omap-rng.c
+++ b/drivers/char/hw_random/omap-rng.c
@@ -398,7 +398,7 @@ static int of_get_omap_rng_device_details(struct omap_rng_dev *priv,
return err;
}
- priv->clk = of_clk_get(pdev->dev.of_node, 0);
+ priv->clk = devm_clk_get(&pdev->dev, NULL);
if (IS_ERR(priv->clk) && PTR_ERR(priv->clk) == -EPROBE_DEFER)
return -EPROBE_DEFER;
if (!IS_ERR(priv->clk)) {
--
2.7.4
^ permalink raw reply related
* [PATCH 3/4] hwrng: omap - Do not access INTMASK_REG on EIP76
From: Thomas Petazzoni @ 2017-03-07 14:14 UTC (permalink / raw)
To: Deepak Saxena, Matt Mackall, Herbert Xu
Cc: linux-crypto, romain.perier, Jason Cooper, Andrew Lunn,
Sebastian Hesselbarth, Gregory Clement, Nadav Haklai, Hanna Hawa,
Yehuda Yitschak, Thomas Petazzoni, stable
In-Reply-To: <1488896089-17586-1-git-send-email-thomas.petazzoni@free-electrons.com>
The INTMASK_REG register does not exist on EIP76. Due to this, the call:
omap_rng_write(priv, RNG_INTMASK_REG, RNG_SHUTDOWN_OFLO_MASK);
ends up, through the reg_map_eip76[] array, in accessing the register at
offset 0, which is the RNG_OUTPUT_0_REG. This by itself doesn't cause
any problem, but clearly doesn't enable the interrupt as it was
expected.
On EIP76, the register that allows to enable the interrupt is
RNG_CONTROL_REG. And just like RNG_INTMASK_REG, it's bit 1 of this
register that allows to enable the shutdown_oflo interrupt.
Fixes: 383212425c926 ("hwrng: omap - Add device variant for SafeXcel IP-76 found in Armada 8K")
Cc: <stable@vger.kernel.org>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
---
drivers/char/hw_random/omap-rng.c | 13 ++++++++++++-
1 file changed, 12 insertions(+), 1 deletion(-)
diff --git a/drivers/char/hw_random/omap-rng.c b/drivers/char/hw_random/omap-rng.c
index d286628..b1ad125 100644
--- a/drivers/char/hw_random/omap-rng.c
+++ b/drivers/char/hw_random/omap-rng.c
@@ -408,7 +408,18 @@ static int of_get_omap_rng_device_details(struct omap_rng_dev *priv,
"err = %d\n", err);
}
- omap_rng_write(priv, RNG_INTMASK_REG, RNG_SHUTDOWN_OFLO_MASK);
+ /*
+ * On OMAP4, enabling the shutdown_oflo interrupt is
+ * done in the interrupt mask register. There is no
+ * such register on EIP76, and it's enabled by the
+ * same bit in the control register
+ */
+ if (priv->pdata->regs[RNG_INTMASK_REG])
+ omap_rng_write(priv, RNG_INTMASK_REG,
+ RNG_SHUTDOWN_OFLO_MASK);
+ else
+ omap_rng_write(priv, RNG_CONTROL_REG,
+ RNG_SHUTDOWN_OFLO_MASK);
}
return 0;
}
--
2.7.4
^ permalink raw reply related
* [PATCH] dt-bindings: rng: clocks property on omap_rng is optional
From: Thomas Petazzoni @ 2017-03-07 14:18 UTC (permalink / raw)
To: devicetree, Rob Herring, Ian Campbell, Pawel Moll, Mark Rutland,
Kumar Gala, Deepak Saxena, Matt Mackall, Herbert Xu
Cc: linux-crypto, romain.perier, Jason Cooper, Andrew Lunn,
Sebastian Hesselbarth, Gregory Clement, Nadav Haklai, Hanna Hawa,
Yehuda Yitschak, Thomas Petazzoni, stable
Commit 52060836f79 ("dt-bindings: omap-rng: Document SafeXcel IP-76
device variant") update the omap_rng Device Tree binding to add support
for the IP-76 variation of the IP. As part of this change, a "clocks"
property was added, but is indicated as "Required", while it is in fact
"Optional": some SoCs do not require a clock for this IP block.
Fixes: 52060836f79 ("dt-bindings: omap-rng: Document SafeXcel IP-76 device variant")
Cc: <stable@vger.kernel.org>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
---
Documentation/devicetree/bindings/rng/omap_rng.txt | 3 +++
1 file changed, 3 insertions(+)
diff --git a/Documentation/devicetree/bindings/rng/omap_rng.txt b/Documentation/devicetree/bindings/rng/omap_rng.txt
index 4714772..20d435da 100644
--- a/Documentation/devicetree/bindings/rng/omap_rng.txt
+++ b/Documentation/devicetree/bindings/rng/omap_rng.txt
@@ -12,6 +12,9 @@ Required properties:
- reg : Offset and length of the register set for the module
- interrupts : the interrupt number for the RNG module.
Used for "ti,omap4-rng" and "inside-secure,safexcel-eip76"
+
+Optional properties:
+
- clocks: the trng clock source
Example:
--
2.7.4
^ permalink raw reply related
* Re: [RFC PATCH v2 08/32] x86: Use PAGE_KERNEL protection for ioremap of memory page
From: Borislav Petkov @ 2017-03-07 14:59 UTC (permalink / raw)
To: Brijesh Singh
Cc: simon.guinot, linux-efi, kvm, rkrcmar, matt, linux-pci,
linus.walleij, gary.hook, linux-mm, paul.gortmaker, hpa, cl,
dan.j.williams, aarcange, sfr, andriy.shevchenko, herbert, bhe,
xemul, joro, x86, peterz, piotr.luc, mingo, msalter, ross.zwisler,
dyoung, thomas.lendacky, jroedel, keescook, arnd, toshi.kani,
mathieu.desnoyers, luto, devel, bhelgaas, tglx, mchehab,
iamjoonsoo.kim, labbott
In-Reply-To: <148846761276.2349.4899767672892365544.stgit@brijesh-build-machine>
On Thu, Mar 02, 2017 at 10:13:32AM -0500, Brijesh Singh wrote:
> From: Tom Lendacky <thomas.lendacky@amd.com>
>
> In order for memory pages to be properly mapped when SEV is active, we
> need to use the PAGE_KERNEL protection attribute as the base protection.
> This will insure that memory mapping of, e.g. ACPI tables, receives the
> proper mapping attributes.
>
> Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
> ---
> diff --git a/arch/x86/mm/ioremap.c b/arch/x86/mm/ioremap.c
> index c400ab5..481c999 100644
> --- a/arch/x86/mm/ioremap.c
> +++ b/arch/x86/mm/ioremap.c
> @@ -151,7 +151,15 @@ static void __iomem *__ioremap_caller(resource_size_t phys_addr,
> pcm = new_pcm;
> }
>
> + /*
> + * If the page being mapped is in memory and SEV is active then
> + * make sure the memory encryption attribute is enabled in the
> + * resulting mapping.
> + */
> prot = PAGE_KERNEL_IO;
> + if (sev_active() && page_is_mem(pfn))
Hmm, a resource tree walk per ioremap call. This could get expensive for
ioremap-heavy workloads.
__ioremap_caller() gets called here during boot 55 times so not a whole
lot but I wouldn't be surprised if there were some nasty use cases which
ioremap a lot.
...
> diff --git a/kernel/resource.c b/kernel/resource.c
> index 9b5f044..db56ba3 100644
> --- a/kernel/resource.c
> +++ b/kernel/resource.c
> @@ -518,6 +518,46 @@ int __weak page_is_ram(unsigned long pfn)
> }
> EXPORT_SYMBOL_GPL(page_is_ram);
>
> +/*
> + * This function returns true if the target memory is marked as
> + * IORESOURCE_MEM and IORESOUCE_BUSY and described as other than
> + * IORES_DESC_NONE (e.g. IORES_DESC_ACPI_TABLES).
> + */
> +static int walk_mem_range(unsigned long start_pfn, unsigned long nr_pages)
> +{
> + struct resource res;
> + unsigned long pfn, end_pfn;
> + u64 orig_end;
> + int ret = -1;
> +
> + res.start = (u64) start_pfn << PAGE_SHIFT;
> + res.end = ((u64)(start_pfn + nr_pages) << PAGE_SHIFT) - 1;
> + res.flags = IORESOURCE_MEM | IORESOURCE_BUSY;
> + orig_end = res.end;
> + while ((res.start < res.end) &&
> + (find_next_iomem_res(&res, IORES_DESC_NONE, true) >= 0)) {
> + pfn = (res.start + PAGE_SIZE - 1) >> PAGE_SHIFT;
> + end_pfn = (res.end + 1) >> PAGE_SHIFT;
> + if (end_pfn > pfn)
> + ret = (res.desc != IORES_DESC_NONE) ? 1 : 0;
> + if (ret)
> + break;
> + res.start = res.end + 1;
> + res.end = orig_end;
> + }
> + return ret;
> +}
So the relevant difference between this one and walk_system_ram_range()
is this:
- ret = (*func)(pfn, end_pfn - pfn, arg);
+ ret = (res.desc != IORES_DESC_NONE) ? 1 : 0;
so it seems to me you can have your own *func() pointer which does that
IORES_DESC_NONE comparison. And then you can define your own workhorse
__walk_memory_range() which gets called by both walk_mem_range() and
walk_system_ram_range() instead of almost duplicating them.
And looking at walk_system_ram_res(), that one looks similar too except
the pfn computation. But AFAICT the pfn/end_pfn things are computed from
res.start and res.end so it looks to me like all those three functions
are crying for unification...
--
Regards/Gruss,
Boris.
SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg)
--
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: [PATCH 0/4] hwrng: omap - fixes and improvements
From: Jason Cooper @ 2017-03-07 15:14 UTC (permalink / raw)
To: Thomas Petazzoni
Cc: Deepak Saxena, Matt Mackall, Herbert Xu, linux-crypto,
romain.perier, Andrew Lunn, Sebastian Hesselbarth,
Gregory Clement, Nadav Haklai, Hanna Hawa, Yehuda Yitschak
In-Reply-To: <1488896089-17586-1-git-send-email-thomas.petazzoni@free-electrons.com>
Hi Thomas,
On Tue, Mar 07, 2017 at 03:14:45PM +0100, Thomas Petazzoni wrote:
> Hello,
>
> This small patch series brings a few fixes and improvements to the
> omap_rng driver. The first fix is particularly important, as it fixes
> using the driver built as a module on SoCs that require a clock for
> the IP to work properly.
>
> Thanks,
>
> Thomas
>
> Thomas Petazzoni (4):
> hwrng: omap - write registers after enabling the clock
> hwrng: omap - use devm_clk_get() instead of of_clk_get()
> hwrng: omap - Do not access INTMASK_REG on EIP76
> hwrng: omap - move clock related code to omap_rng_probe()
>
> drivers/char/hw_random/omap-rng.c | 36 +++++++++++++++++++++++++-----------
> 1 file changed, 25 insertions(+), 11 deletions(-)
For the whole series,
Acked-by: Jason Cooper <jason@lakedaemon.net>
thx,
Jason.
^ permalink raw reply
* hmac(crc32)
From: Stephan Müller @ 2017-03-08 8:20 UTC (permalink / raw)
To: herbert, linux-crypto
Hi Herbert,
hmac(crc32) is defined in testmgr.c and tcrypt.c. Yet, when using that cipher,
I get an ENOENT:
alg: hash: Failed to load transform for hmac(crc32): -2
Is there such a thing as hmac(crc32)?
Ciao
Stephan
^ permalink raw reply
* Re: [RFC PATCH v2 09/32] x86: Change early_ioremap to early_memremap for BOOT data
From: Borislav Petkov @ 2017-03-08 8:46 UTC (permalink / raw)
To: Brijesh Singh
Cc: simon.guinot, linux-efi, kvm, rkrcmar, matt, linux-pci,
linus.walleij, gary.hook, linux-mm, paul.gortmaker, hpa, cl,
dan.j.williams, aarcange, sfr, andriy.shevchenko, herbert, bhe,
xemul, joro, x86, peterz, piotr.luc, mingo, msalter, ross.zwisler,
dyoung, thomas.lendacky, jroedel, keescook, arnd, toshi.kani,
mathieu.desnoyers, luto, devel, bhelgaas, tglx, mchehab,
iamjoonsoo.kim, labbott
In-Reply-To: <148846763334.2349.9327692408737971533.stgit@brijesh-build-machine>
On Thu, Mar 02, 2017 at 10:13:53AM -0500, Brijesh Singh wrote:
> From: Tom Lendacky <thomas.lendacky@amd.com>
>
> In order to map BOOT data with the proper encryption bit, the
Btw, what does that all-caps spelling "BOOT" denote? Something I'm
missing?
> early_ioremap() function calls are changed to early_memremap() calls.
> This allows the proper access for both SME and SEV.
>
> Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
> ---
> arch/x86/kernel/acpi/boot.c | 4 ++--
> arch/x86/kernel/mpparse.c | 10 +++++-----
> drivers/sfi/sfi_core.c | 6 +++---
> 3 files changed, 10 insertions(+), 10 deletions(-)
>
> diff --git a/arch/x86/kernel/acpi/boot.c b/arch/x86/kernel/acpi/boot.c
> index 35174c6..468c25a 100644
> --- a/arch/x86/kernel/acpi/boot.c
> +++ b/arch/x86/kernel/acpi/boot.c
> @@ -124,7 +124,7 @@ char *__init __acpi_map_table(unsigned long phys, unsigned long size)
> if (!phys || !size)
> return NULL;
>
> - return early_ioremap(phys, size);
> + return early_memremap(phys, size);
Right, the question will keep popping up why we can simply replace
memremap with ioremap and the general difference wrt to SME/SEV. So it
would be a good idea to have a comment in, say, arch/x86/mm/ioremap.c,
explaining the general situation.
Thanks.
--
Regards/Gruss,
Boris.
SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg)
--
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: [PATCH] crypto: powerpc - Fix initialisation of crc32c context
From: Herbert Xu @ 2017-03-08 8:47 UTC (permalink / raw)
To: Daniel Axtens; +Cc: dja, linuxppc-dev, linux-crypto, anton
In-Reply-To: <20170303065655.7317-1-dja@axtens.net>
Daniel Axtens <dja@axtens.net> wrote:
> Turning on crypto self-tests on a POWER8 shows:
>
> alg: hash: Test 1 failed for crc32c-vpmsum
> 00000000: ff ff ff ff
>
> Comparing the code with the Intel CRC32c implementation on which
> ours is based shows that we are doing an init with 0, not ~0
> as CRC32c requires.
>
> This probably wasn't caught because btrfs does its own weird
> open-coded initialisation.
>
> Initialise our internal context to ~0 on init.
>
> This makes the self-tests pass, and btrfs continues to work.
>
> Fixes: 6dd7a82cc54e ("crypto: powerpc - Add POWER8 optimised crc32c")
> Cc: Anton Blanchard <anton@samba.org>
> Cc: stable@vger.kernel.org
> Signed-off-by: Daniel Axtens <dja@axtens.net>
Patch applied. Thanks.
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH] crypto: s5p-sss - Fix completing crypto request in IRQ handler
From: Herbert Xu @ 2017-03-08 8:47 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: David S . Miller, linux-crypto, linux-kernel, Nathan Royce
In-Reply-To: <20170305171407.839-1-krzk@kernel.org>
On Sun, Mar 05, 2017 at 07:14:07PM +0200, Krzysztof Kozlowski wrote:
> In a regular interrupt handler driver was finishing the crypt/decrypt
> request by calling complete on crypto request. This is disallowed since
> converting to skcipher in commit b286d8b1a690 ("crypto: skcipher - Add
> skcipher walk interface") and causes a warning:
> WARNING: CPU: 0 PID: 0 at crypto/skcipher.c:430 skcipher_walk_first+0x13c/0x14c
>
> The interrupt is marked shared but in fact there are no other users
> sharing it. Thus the simplest solution seems to be to just use a
> threaded interrupt handler, after converting it to oneshot.
>
> Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
Patch applied. Thanks.
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH 5/8] crypto:chcr: Change cra_flags for cipher algos
From: Harsh Jain @ 2017-03-08 9:58 UTC (permalink / raw)
Cc: Herbert Xu, linux-crypto
In-Reply-To: <19591395286ea8addca8affa595eabd951fda7ff.1485501429.git.harsh@chelsio.com>
Hi Herbert
On Fri, Jan 27, 2017 at 4:09 PM, Harsh Jain <harsh@chelsio.com> wrote:
> Change cipher algos flags to CRYPTO_ALG_TYPE_ABLKCIPHER.
>
> Signed-off-by: Harsh Jain <harsh@chelsio.com>
> ---
> drivers/crypto/chelsio/chcr_algo.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/crypto/chelsio/chcr_algo.c b/drivers/crypto/chelsio/chcr_algo.c
> index d335943..21fc04c 100644
> --- a/drivers/crypto/chelsio/chcr_algo.c
> +++ b/drivers/crypto/chelsio/chcr_algo.c
> @@ -171,7 +171,7 @@ int chcr_handle_resp(struct crypto_async_request *req, unsigned char *input,
> }
> break;
>
> - case CRYPTO_ALG_TYPE_BLKCIPHER:
> + case CRYPTO_ALG_TYPE_ABLKCIPHER:
> ctx_req.req.ablk_req = (struct ablkcipher_request *)req;
> ctx_req.ctx.ablk_ctx =
> ablkcipher_request_ctx(ctx_req.req.ablk_req);
> @@ -2492,7 +2492,7 @@ static int chcr_aead_op(struct aead_request *req,
> .cra_name = "cbc(aes)",
> .cra_driver_name = "cbc-aes-chcr",
> .cra_priority = CHCR_CRA_PRIORITY,
> - .cra_flags = CRYPTO_ALG_TYPE_BLKCIPHER |
> + .cra_flags = CRYPTO_ALG_TYPE_ABLKCIPHER |
> CRYPTO_ALG_ASYNC,
> .cra_blocksize = AES_BLOCK_SIZE,
> .cra_ctxsize = sizeof(struct chcr_context)
> @@ -2519,7 +2519,7 @@ static int chcr_aead_op(struct aead_request *req,
> .cra_name = "xts(aes)",
> .cra_driver_name = "xts-aes-chcr",
> .cra_priority = CHCR_CRA_PRIORITY,
> - .cra_flags = CRYPTO_ALG_TYPE_BLKCIPHER |
> + .cra_flags = CRYPTO_ALG_TYPE_ABLKCIPHER |
> CRYPTO_ALG_ASYNC,
> .cra_blocksize = AES_BLOCK_SIZE,
> .cra_ctxsize = sizeof(struct chcr_context) +
If I try above patch on 4.9.13 stable kernel. Kernel stops executing
tests for cbc(aes), Same is working fine on cryptodev-2.6 latest tree.
It seems below patch set has changed the behavior.
crypto: testmgr - Do not test internal algorithms
diff --git a/crypto/algboss.c b/crypto/algboss.c
index 6e39d9c..ccb85e1 100644
--- a/crypto/algboss.c
+++ b/crypto/algboss.c
@@ -247,12 +247,8 @@ static int cryptomgr_schedule_test(struct crypto_alg *alg)
memcpy(param->alg, alg->cra_name, sizeof(param->alg));
type = alg->cra_flags;
- /* This piece of crap needs to disappear into per-type test hooks. */
- if (!((type ^ CRYPTO_ALG_TYPE_BLKCIPHER) &
- CRYPTO_ALG_TYPE_BLKCIPHER_MASK) && !(type & CRYPTO_ALG_GENIV) &&
- ((alg->cra_flags & CRYPTO_ALG_TYPE_MASK) ==
- CRYPTO_ALG_TYPE_BLKCIPHER ? alg->cra_blkcipher.ivsize :
- alg->cra_ablkcipher.ivsize))
+ /* Do not test internal algorithms. */
+ if (type & CRYPTO_ALG_INTERNAL)
type |= CRYPTO_ALG_TESTED;
Its bit confusing for me. Are we supposed to declared it as
"CRYPTO_ALG_TYPE_BLKCIPHER" for older kernels.
Regards
Harsh Jain
^ permalink raw reply related
* Re: [PATCH 5/8] crypto:chcr: Change cra_flags for cipher algos
From: Herbert Xu @ 2017-03-08 10:21 UTC (permalink / raw)
To: Harsh Jain; +Cc: linux-crypto
In-Reply-To: <CAFXBA=mkKinfgLT0vRSXjyW7Lt0V-6o0ud3bdzLZjxqF1je+sg@mail.gmail.com>
On Wed, Mar 08, 2017 at 03:28:26PM +0530, Harsh Jain wrote:
>
> If I try above patch on 4.9.13 stable kernel. Kernel stops executing
> tests for cbc(aes), Same is working fine on cryptodev-2.6 latest tree.
> It seems below patch set has changed the behavior.
>
>
> crypto: testmgr - Do not test internal algorithms
On older kernels each ablkcipher gets an geniv instantiated on top
of it. Therefore the ablkcipher itself is never tested, only the
geniv is tested.
We have since got rid of the geniv and now test the ablkcipher
directly.
There was a period where we didn't generate a geniv but I forgot
to also remove the below chunk which skipped testing the ablkcipher.
> diff --git a/crypto/algboss.c b/crypto/algboss.c
> index 6e39d9c..ccb85e1 100644
> --- a/crypto/algboss.c
> +++ b/crypto/algboss.c
> @@ -247,12 +247,8 @@ static int cryptomgr_schedule_test(struct crypto_alg *alg)
> memcpy(param->alg, alg->cra_name, sizeof(param->alg));
> type = alg->cra_flags;
> - /* This piece of crap needs to disappear into per-type test hooks. */
> - if (!((type ^ CRYPTO_ALG_TYPE_BLKCIPHER) &
> - CRYPTO_ALG_TYPE_BLKCIPHER_MASK) && !(type & CRYPTO_ALG_GENIV) &&
> - ((alg->cra_flags & CRYPTO_ALG_TYPE_MASK) ==
> - CRYPTO_ALG_TYPE_BLKCIPHER ? alg->cra_blkcipher.ivsize :
> - alg->cra_ablkcipher.ivsize))
> + /* Do not test internal algorithms. */
> + if (type & CRYPTO_ALG_INTERNAL)
> type |= CRYPTO_ALG_TESTED;
>
> Its bit confusing for me. Are we supposed to declared it as
> "CRYPTO_ALG_TYPE_BLKCIPHER" for older kernels.
It should definitely be ABLKCIPHER in your case.
Even if the test is skipped your driver should still work.
Cheers,
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH 0/4] hwrng: omap - fixes and improvements
From: Romain Perier @ 2017-03-08 8:37 UTC (permalink / raw)
To: Thomas Petazzoni, Deepak Saxena, Matt Mackall, Herbert Xu
Cc: linux-crypto, Jason Cooper, Andrew Lunn, Sebastian Hesselbarth,
Gregory Clement, Nadav Haklai, Hanna Hawa, Yehuda Yitschak
In-Reply-To: <1488896089-17586-1-git-send-email-thomas.petazzoni@free-electrons.com>
Hello,
Le 07/03/2017 à 15:14, Thomas Petazzoni a écrit :
> Hello,
>
> This small patch series brings a few fixes and improvements to the
> omap_rng driver. The first fix is particularly important, as it fixes
> using the driver built as a module on SoCs that require a clock for
> the IP to work properly.
>
> Thanks,
>
> Thomas
>
> Thomas Petazzoni (4):
> hwrng: omap - write registers after enabling the clock
> hwrng: omap - use devm_clk_get() instead of of_clk_get()
> hwrng: omap - Do not access INTMASK_REG on EIP76
> hwrng: omap - move clock related code to omap_rng_probe()
>
> drivers/char/hw_random/omap-rng.c | 36 +++++++++++++++++++++++++-----------
> 1 file changed, 25 insertions(+), 11 deletions(-)
For the whole series,
Reviewed-by: Romain Perier <romain.perier@collabora.com>
^ permalink raw reply
* Re: [PATCH 9/9] crypto: mediatek - add support to OFB mode and CFB128 mode
From: Herbert Xu @ 2017-03-08 10:48 UTC (permalink / raw)
To: Ryder Lee
Cc: linux-mediatek-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-crypto-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1487582822-30393-10-git-send-email-ryder.lee-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>
On Mon, Feb 20, 2017 at 05:27:02PM +0800, Ryder Lee wrote:
> This patch adds support to OFB mode and CFB128 mode.
>
> Signed-off-by: Ryder Lee <ryder.lee-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>
In general we do not add any algorithms that
1) have no in-kernel users;
2) and/or have no software implementations.
Thanks,
--
Email: Herbert Xu <herbert-lOAM2aK0SrRLBo1qDEOMRrpzq4S04n8Q@public.gmane.org>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [RFC PATCH v2 10/32] x86: DMA support for SEV memory encryption
From: Borislav Petkov @ 2017-03-08 10:56 UTC (permalink / raw)
To: Brijesh Singh
Cc: simon.guinot, linux-efi, kvm, rkrcmar, matt, linux-pci,
linus.walleij, gary.hook, linux-mm, paul.gortmaker, hpa, cl,
dan.j.williams, aarcange, sfr, andriy.shevchenko, herbert, bhe,
xemul, joro, x86, peterz, piotr.luc, mingo, msalter, ross.zwisler,
dyoung, thomas.lendacky, jroedel, keescook, arnd, toshi.kani,
mathieu.desnoyers, luto, devel, bhelgaas, tglx, mchehab,
iamjoonsoo.kim, labbott
In-Reply-To: <148846766532.2349.4832844575566575886.stgit@brijesh-build-machine>
On Thu, Mar 02, 2017 at 10:14:25AM -0500, Brijesh Singh wrote:
> From: Tom Lendacky <thomas.lendacky@amd.com>
>
> DMA access to memory mapped as encrypted while SEV is active can not be
> encrypted during device write or decrypted during device read. In order
> for DMA to properly work when SEV is active, the swiotlb bounce buffers
> must be used.
>
> Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
> ---
> arch/x86/mm/mem_encrypt.c | 77 +++++++++++++++++++++++++++++++++++++++++++++
> 1 file changed, 77 insertions(+)
>
> diff --git a/arch/x86/mm/mem_encrypt.c b/arch/x86/mm/mem_encrypt.c
> index 090419b..7df5f4c 100644
> --- a/arch/x86/mm/mem_encrypt.c
> +++ b/arch/x86/mm/mem_encrypt.c
> @@ -197,8 +197,81 @@ void __init sme_early_init(void)
> /* Update the protection map with memory encryption mask */
> for (i = 0; i < ARRAY_SIZE(protection_map); i++)
> protection_map[i] = pgprot_encrypted(protection_map[i]);
> +
> + if (sev_active())
> + swiotlb_force = SWIOTLB_FORCE;
> +}
> +
> +static void *sme_alloc(struct device *dev, size_t size, dma_addr_t *dma_handle,
> + gfp_t gfp, unsigned long attrs)
> +{
> + unsigned long dma_mask;
> + unsigned int order;
> + struct page *page;
> + void *vaddr = NULL;
> +
> + dma_mask = dma_alloc_coherent_mask(dev, gfp);
> + order = get_order(size);
> +
> + gfp &= ~__GFP_ZERO;
Please add a comment around here that swiotlb_alloc_coherent() will
memset(, 0, ) the memory. It took me a while to figure out what the
situation is.
Also, Joerg says the __GFP_ZERO is not absolutely necessary but it has
not been fixed in the other DMA alloc* functions because of fears that
something would break. That bit could also be part of the comment.
> +
> + page = alloc_pages_node(dev_to_node(dev), gfp, order);
> + if (page) {
> + dma_addr_t addr;
> +
> + /*
> + * Since we will be clearing the encryption bit, check the
> + * mask with it already cleared.
> + */
> + addr = phys_to_dma(dev, page_to_phys(page)) & ~sme_me_mask;
> + if ((addr + size) > dma_mask) {
> + __free_pages(page, get_order(size));
> + } else {
> + vaddr = page_address(page);
> + *dma_handle = addr;
> + }
> + }
> +
> + if (!vaddr)
> + vaddr = swiotlb_alloc_coherent(dev, size, dma_handle, gfp);
> +
> + if (!vaddr)
> + return NULL;
> +
> + /* Clear the SME encryption bit for DMA use if not swiotlb area */
> + if (!is_swiotlb_buffer(dma_to_phys(dev, *dma_handle))) {
> + set_memory_decrypted((unsigned long)vaddr, 1 << order);
> + *dma_handle &= ~sme_me_mask;
> + }
> +
> + return vaddr;
> }
>
> +static void sme_free(struct device *dev, size_t size, void *vaddr,
> + dma_addr_t dma_handle, unsigned long attrs)
> +{
> + /* Set the SME encryption bit for re-use if not swiotlb area */
> + if (!is_swiotlb_buffer(dma_to_phys(dev, dma_handle)))
> + set_memory_encrypted((unsigned long)vaddr,
> + 1 << get_order(size));
> +
> + swiotlb_free_coherent(dev, size, vaddr, dma_handle);
> +}
> +
> +static struct dma_map_ops sme_dma_ops = {
WARNING: struct dma_map_ops should normally be const
#112: FILE: arch/x86/mm/mem_encrypt.c:261:
+static struct dma_map_ops sme_dma_ops = {
Please integrate scripts/checkpatch.pl in your patch creation workflow.
Some of the warnings/errors *actually* make sense.
> + .alloc = sme_alloc,
> + .free = sme_free,
> + .map_page = swiotlb_map_page,
> + .unmap_page = swiotlb_unmap_page,
> + .map_sg = swiotlb_map_sg_attrs,
> + .unmap_sg = swiotlb_unmap_sg_attrs,
> + .sync_single_for_cpu = swiotlb_sync_single_for_cpu,
> + .sync_single_for_device = swiotlb_sync_single_for_device,
> + .sync_sg_for_cpu = swiotlb_sync_sg_for_cpu,
> + .sync_sg_for_device = swiotlb_sync_sg_for_device,
> + .mapping_error = swiotlb_dma_mapping_error,
> +};
> +
> /* Architecture __weak replacement functions */
> void __init mem_encrypt_init(void)
> {
> @@ -208,6 +281,10 @@ void __init mem_encrypt_init(void)
> /* Call into SWIOTLB to update the SWIOTLB DMA buffers */
> swiotlb_update_mem_attributes();
>
> + /* Use SEV DMA operations if SEV is active */
That's obvious. The WHY is not.
> + if (sev_active())
> + dma_ops = &sme_dma_ops;
> +
> pr_info("AMD Secure Memory Encryption (SME) active\n");
> }
>
>
--
Regards/Gruss,
Boris.
SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg)
--
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: [PATCH] crypto: testmgr - don't DMA map IV from stack in test_skcipher()
From: Horia Geantă @ 2017-03-08 13:04 UTC (permalink / raw)
To: Herbert Xu; +Cc: David S. Miller, linux-crypto@vger.kernel.org
In-Reply-To: <20170113084620.GF22022@gondor.apana.org.au>
On 1/13/2017 10:46 AM, Herbert Xu wrote:
> On Fri, Jan 13, 2017 at 08:59:16AM +0200, Horia Geantă wrote:
>> Fix the "DMA-API: device driver maps memory from stack" warning
>> generated when crypto accelerators map the IV.
>>
>> Signed-off-by: Horia Geantă <horia.geanta@nxp.com>
>
> Hmm, the IV comes in as a pointer. So you should not assume that
> it can be DMAed at all.
>
That's correct, thanks for pointing it out.
> Perhaps we should change the API so that it gets passed in as an
> SG list.
>
Since changing the API and converting the users looks pretty lengthy,
would it be acceptable to fix tcrypt for now?
Indeed, I've missed updating test_skcipher_speed, I can add this in v2.
Thanks,
Horia
^ permalink raw reply
* Re: [RFC PATCH v2 02/32] x86: Secure Encrypted Virtualization (SEV) support
From: Borislav Petkov @ 2017-03-08 15:06 UTC (permalink / raw)
To: Brijesh Singh
Cc: simon.guinot, linux-efi, kvm, rkrcmar, matt, linux-pci,
linus.walleij, gary.hook, linux-mm, paul.gortmaker, hpa, cl,
dan.j.williams, aarcange, sfr, andriy.shevchenko, herbert, bhe,
xemul, joro, x86, peterz, piotr.luc, mingo, msalter, ross.zwisler,
dyoung, thomas.lendacky, jroedel, keescook, arnd, toshi.kani,
mathieu.desnoyers, luto, devel, bhelgaas, tglx, mchehab,
iamjoonsoo.kim, labbott
In-Reply-To: <148846754069.2349.4698319264278045964.stgit@brijesh-build-machine>
On Thu, Mar 02, 2017 at 10:12:20AM -0500, Brijesh Singh wrote:
> From: Tom Lendacky <thomas.lendacky@amd.com>
>
> Provide support for Secure Encyrpted Virtualization (SEV). This initial
> support defines a flag that is used by the kernel to determine if it is
> running with SEV active.
>
> Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
> ---
> arch/x86/include/asm/mem_encrypt.h | 14 +++++++++++++-
> arch/x86/mm/mem_encrypt.c | 3 +++
> include/linux/mem_encrypt.h | 6 ++++++
> 3 files changed, 22 insertions(+), 1 deletion(-)
>
> diff --git a/arch/x86/include/asm/mem_encrypt.h b/arch/x86/include/asm/mem_encrypt.h
> index 1fd5426..9799835 100644
> --- a/arch/x86/include/asm/mem_encrypt.h
> +++ b/arch/x86/include/asm/mem_encrypt.h
> @@ -20,10 +20,16 @@
> #ifdef CONFIG_AMD_MEM_ENCRYPT
>
> extern unsigned long sme_me_mask;
> +extern unsigned int sev_enabled;
So there's a function name sev_enabled() and an int sev_enabled too.
It looks to me like you want to call the function "sev_enable()" -
similar to sme_enable(), convert it to C code - i.e., I don't see what
would speak against it - and rename that sev_enc_bit to sev_enabled and
use it everywhere when testing SEV status.
> static inline bool sme_active(void)
> {
> - return (sme_me_mask) ? true : false;
> + return (sme_me_mask && !sev_enabled) ? true : false;
> +}
> +
> +static inline bool sev_active(void)
> +{
> + return (sme_me_mask && sev_enabled) ? true : false;
Then, those read strange: like SME and SEV are mutually exclusive. Why?
I might have an idea but I'd like for you to confirm it :-)
Then, you're calling sev_enabled in startup_32() but we can enter
in arch/x86/boot/compressed/head_64.S::startup_64() too, when we're
loaded by a 64-bit bootloader, which would then theoretically bypass
sev_enabled().
--
Regards/Gruss,
Boris.
SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg)
--
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: XTS Crypto Not Found In /proc/crypto Even After Compiled for 4.10.1.
From: Krzysztof Kozlowski @ 2017-03-08 17:45 UTC (permalink / raw)
To: Nathan Royce
Cc: Herbert Xu, davem, linux-crypto, linux-kernel, Marek Szyprowski
In-Reply-To: <CALaQ_hqhFjb60rJ2AgBnYgyNCPQ7fH5BdOOCeaMiankQR0VwqQ@mail.gmail.com>
On Mon, Mar 06, 2017 at 03:29:48PM -0600, Nathan Royce wrote:
> OK, I just tried 4.10.0 and the output is looking the same.
>
> I can't say my setup is all that odd. The cryptographic use is only
> with the swap partition found in my original email (seen in Herbert's
> reply).
You have quite specific/customized config and compilation flags.
I doubt that it causes the issue but at least the config is unusable on
anything other then XU3/XU4.
Anyway I reproduced some of the issues with tcrypt on Odroid U3 on v4.10
and v4.11-rc1, with regular exynos defconfig plus some more crypto
algorithms:
1. Without my patch: the original warning.
2. With my patch:
[ 95.170527] testing speed of async lrw(aes) (lrw(ecb-aes-s5p)) encryption
[ 95.173990] tcrypt: test 0 (256 bit key, 16 byte blocks): 19007 operations in 1 seconds (304112 bytes)
[ 96.175986] tcrypt: test 1 (256 bit key, 64 byte blocks): 15753 operations in 1 seconds (1008192 bytes)
[ 97.176099] tcrypt: test 2 (256 bit key, 256 byte blocks): 14293 operations in 1 seconds (3659008 bytes)
[ 98.176177] tcrypt: test 3 (256 bit key, 1024 byte blocks): 11906 operations in 1 seconds (12191744 bytes)
[ 99.176407] tcrypt: test 4 (256 bit key, 8192 byte blocks):
[ 99.177235] BUG: spinlock recursion on CPU#1, irq/84-10830000/89
[ 99.188034] lock: 0xeea99a68, .magic: dead4ead, .owner: irq/84-10830000/89, .owner_cpu: 1
[ 99.196282] CPU: 1 PID: 89 Comm: irq/84-10830000 Not tainted 4.11.0-rc1-00001-g897ca6d0800d #559
[ 99.205038] Hardware name: SAMSUNG EXYNOS (Flattened Device Tree)
[ 99.211158] [<c010e1ec>] (unwind_backtrace) from [<c010ae1c>] (show_stack+0x10/0x14)
[ 99.218863] [<c010ae1c>] (show_stack) from [<c03449c0>] (dump_stack+0x78/0x8c)
[ 99.226060] [<c03449c0>] (dump_stack) from [<c015de68>] (do_raw_spin_lock+0x11c/0x120)
[ 99.233962] [<c015de68>] (do_raw_spin_lock) from [<c0720110>] (_raw_spin_lock_irqsave+0x20/0x28)
[ 99.242733] [<c0720110>] (_raw_spin_lock_irqsave) from [<c0572ca0>] (s5p_aes_crypt+0x2c/0xb4)
[ 99.251240] [<c0572ca0>] (s5p_aes_crypt) from [<bf1d8aa4>] (do_encrypt+0x78/0xb0 [lrw])
[ 99.259230] [<bf1d8aa4>] (do_encrypt [lrw]) from [<bf1d8b00>] (encrypt_done+0x24/0x54 [lrw])
[ 99.267628] [<bf1d8b00>] (encrypt_done [lrw]) from [<c05732a0>] (s5p_aes_complete+0x60/0xcc)
[ 99.276046] [<c05732a0>] (s5p_aes_complete) from [<c0573440>] (s5p_aes_interrupt+0x134/0x1a0)
[ 99.284558] [<c0573440>] (s5p_aes_interrupt) from [<c01667c4>] (irq_thread_fn+0x1c/0x54)
[ 99.292624] [<c01667c4>] (irq_thread_fn) from [<c0166a98>] (irq_thread+0x12c/0x1e0)
[ 99.300269] [<c0166a98>] (irq_thread) from [<c0136a28>] (kthread+0x108/0x138)
[ 99.307382] [<c0136a28>] (kthread) from [<c0107778>] (ret_from_fork+0x14/0x3c)
I will take a look into this.
Thanks for the report.
Best regards,
Krzysztof
^ permalink raw reply
* [PATCH] crypto: s5p-sss - Fix spinlock recursion on LRW(AES)
From: Krzysztof Kozlowski @ 2017-03-08 21:14 UTC (permalink / raw)
To: Herbert Xu, davem, Vladimir Zapolskiy, Marek Szyprowski,
linux-crypto, linux-kernel
Cc: Nathan Royce, Krzysztof Kozlowski,
# v4 . 10 . x : 07de4bc88c crypto : s5p-sss - Fix completing
Running TCRYPT with LRW compiled causes spinlock recursion:
testing speed of async lrw(aes) (lrw(ecb-aes-s5p)) encryption
tcrypt: test 0 (256 bit key, 16 byte blocks): 19007 operations in 1 seconds (304112 bytes)
tcrypt: test 1 (256 bit key, 64 byte blocks): 15753 operations in 1 seconds (1008192 bytes)
tcrypt: test 2 (256 bit key, 256 byte blocks): 14293 operations in 1 seconds (3659008 bytes)
tcrypt: test 3 (256 bit key, 1024 byte blocks): 11906 operations in 1 seconds (12191744 bytes)
tcrypt: test 4 (256 bit key, 8192 byte blocks):
BUG: spinlock recursion on CPU#1, irq/84-10830000/89
lock: 0xeea99a68, .magic: dead4ead, .owner: irq/84-10830000/89, .owner_cpu: 1
CPU: 1 PID: 89 Comm: irq/84-10830000 Not tainted 4.11.0-rc1-00001-g897ca6d0800d #559
Hardware name: SAMSUNG EXYNOS (Flattened Device Tree)
[<c010e1ec>] (unwind_backtrace) from [<c010ae1c>] (show_stack+0x10/0x14)
[<c010ae1c>] (show_stack) from [<c03449c0>] (dump_stack+0x78/0x8c)
[<c03449c0>] (dump_stack) from [<c015de68>] (do_raw_spin_lock+0x11c/0x120)
[<c015de68>] (do_raw_spin_lock) from [<c0720110>] (_raw_spin_lock_irqsave+0x20/0x28)
[<c0720110>] (_raw_spin_lock_irqsave) from [<c0572ca0>] (s5p_aes_crypt+0x2c/0xb4)
[<c0572ca0>] (s5p_aes_crypt) from [<bf1d8aa4>] (do_encrypt+0x78/0xb0 [lrw])
[<bf1d8aa4>] (do_encrypt [lrw]) from [<bf1d8b00>] (encrypt_done+0x24/0x54 [lrw])
[<bf1d8b00>] (encrypt_done [lrw]) from [<c05732a0>] (s5p_aes_complete+0x60/0xcc)
[<c05732a0>] (s5p_aes_complete) from [<c0573440>] (s5p_aes_interrupt+0x134/0x1a0)
[<c0573440>] (s5p_aes_interrupt) from [<c01667c4>] (irq_thread_fn+0x1c/0x54)
[<c01667c4>] (irq_thread_fn) from [<c0166a98>] (irq_thread+0x12c/0x1e0)
[<c0166a98>] (irq_thread) from [<c0136a28>] (kthread+0x108/0x138)
[<c0136a28>] (kthread) from [<c0107778>] (ret_from_fork+0x14/0x3c)
Interrupt handling routine was calling req->base.complete() under
spinlock. In most cases this wasn't fatal but when combined with some
of the cipher modes (like LRW) this caused recursion - starting the new
encryption (s5p_aes_crypt()) while still holding the spinlock from
previous round (s5p_aes_complete()).
Beside that, the s5p_aes_interrupt() error handling path could execute
two completions in case of error for RX and TX blocks.
Rewrite the interrupt handling routine and the completion by:
1. Splitting the operations on scatterlist copies from
s5p_aes_complete() into separate s5p_sg_done(). This still should be
done under lock.
The s5p_aes_complete() now only calls req->base.complete() and it has
to be called outside of lock.
2. Moving the s5p_aes_complete() out of spinlock critical sections.
In interrupt service routine s5p_aes_interrupts(), it appeared in few
places, including error paths inside other functions called from ISR.
This code was not so obvious to read so simplify it by putting the
s5p_aes_complete() only within ISR level.
Reported-by: Nathan Royce <nroycea+kernel@gmail.com>
Cc: <stable@vger.kernel.org> # v4.10.x: 07de4bc88c crypto: s5p-sss - Fix completing
Cc: <stable@vger.kernel.org> # v4.10.x
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
---
I think, along with 07de4bc88c this should be backported to v4.10 as it
happens there.
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
---
drivers/crypto/s5p-sss.c | 127 ++++++++++++++++++++++++++++++-----------------
1 file changed, 82 insertions(+), 45 deletions(-)
diff --git a/drivers/crypto/s5p-sss.c b/drivers/crypto/s5p-sss.c
index a668286d62cb..1b9da3dc799b 100644
--- a/drivers/crypto/s5p-sss.c
+++ b/drivers/crypto/s5p-sss.c
@@ -270,7 +270,7 @@ static void s5p_sg_copy_buf(void *buf, struct scatterlist *sg,
scatterwalk_done(&walk, out, 0);
}
-static void s5p_aes_complete(struct s5p_aes_dev *dev, int err)
+static void s5p_sg_done(struct s5p_aes_dev *dev)
{
if (dev->sg_dst_cpy) {
dev_dbg(dev->dev,
@@ -281,8 +281,11 @@ static void s5p_aes_complete(struct s5p_aes_dev *dev, int err)
}
s5p_free_sg_cpy(dev, &dev->sg_src_cpy);
s5p_free_sg_cpy(dev, &dev->sg_dst_cpy);
+}
- /* holding a lock outside */
+/* Calls the completion. Cannot be called with dev->lock hold. */
+static void s5p_aes_complete(struct s5p_aes_dev *dev, int err)
+{
dev->req->base.complete(&dev->req->base, err);
dev->busy = false;
}
@@ -368,51 +371,44 @@ static int s5p_set_indata(struct s5p_aes_dev *dev, struct scatterlist *sg)
}
/*
- * Returns true if new transmitting (output) data is ready and its
- * address+length have to be written to device (by calling
- * s5p_set_dma_outdata()). False otherwise.
+ * Returns -ERRNO on error (mapping of new data failed).
+ * On success returns:
+ * - 0 if there is no more data,
+ * - 1 if new transmitting (output) data is ready and its address+length
+ * have to be written to device (by calling s5p_set_dma_outdata()).
*/
-static bool s5p_aes_tx(struct s5p_aes_dev *dev)
+static int s5p_aes_tx(struct s5p_aes_dev *dev)
{
- int err = 0;
- bool ret = false;
+ int ret = 0;
s5p_unset_outdata(dev);
if (!sg_is_last(dev->sg_dst)) {
- err = s5p_set_outdata(dev, sg_next(dev->sg_dst));
- if (err)
- s5p_aes_complete(dev, err);
- else
- ret = true;
- } else {
- s5p_aes_complete(dev, err);
-
- dev->busy = true;
- tasklet_schedule(&dev->tasklet);
+ ret = s5p_set_outdata(dev, sg_next(dev->sg_dst));
+ if (!ret)
+ ret = 1;
}
return ret;
}
/*
- * Returns true if new receiving (input) data is ready and its
- * address+length have to be written to device (by calling
- * s5p_set_dma_indata()). False otherwise.
+ * Returns -ERRNO on error (mapping of new data failed).
+ * On success returns:
+ * - 0 if there is no more data,
+ * - 1 if new receiving (input) data is ready and its address+length
+ * have to be written to device (by calling s5p_set_dma_indata()).
*/
-static bool s5p_aes_rx(struct s5p_aes_dev *dev)
+static int s5p_aes_rx(struct s5p_aes_dev *dev/*, bool *set_dma*/)
{
- int err;
- bool ret = false;
+ int ret = 0;
s5p_unset_indata(dev);
if (!sg_is_last(dev->sg_src)) {
- err = s5p_set_indata(dev, sg_next(dev->sg_src));
- if (err)
- s5p_aes_complete(dev, err);
- else
- ret = true;
+ ret = s5p_set_indata(dev, sg_next(dev->sg_src));
+ if (!ret)
+ ret = 1;
}
return ret;
@@ -422,33 +418,73 @@ static irqreturn_t s5p_aes_interrupt(int irq, void *dev_id)
{
struct platform_device *pdev = dev_id;
struct s5p_aes_dev *dev = platform_get_drvdata(pdev);
- bool set_dma_tx = false;
- bool set_dma_rx = false;
+ int err_dma_tx = 0;
+ int err_dma_rx = 0;
+ bool tx_end = false;
unsigned long flags;
uint32_t status;
+ int err;
spin_lock_irqsave(&dev->lock, flags);
+ /*
+ * Handle rx or tx interrupt. If there is still data (scatterlist did not
+ * reach end), then map next scatterlist entry.
+ * In case of such mapping error, s5p_aes_complete() should be called.
+ *
+ * If there is no more data in tx scatter list, call s5p_aes_complete()
+ * and schedule new tasklet.
+ */
status = SSS_READ(dev, FCINTSTAT);
if (status & SSS_FCINTSTAT_BRDMAINT)
- set_dma_rx = s5p_aes_rx(dev);
- if (status & SSS_FCINTSTAT_BTDMAINT)
- set_dma_tx = s5p_aes_tx(dev);
+ err_dma_rx = s5p_aes_rx(dev);
+
+ if (status & SSS_FCINTSTAT_BTDMAINT) {
+ if (sg_is_last(dev->sg_dst))
+ tx_end = true;
+ err_dma_tx = s5p_aes_tx(dev);
+ }
SSS_WRITE(dev, FCINTPEND, status);
- /*
- * Writing length of DMA block (either receiving or transmitting)
- * will start the operation immediately, so this should be done
- * at the end (even after clearing pending interrupts to not miss the
- * interrupt).
- */
- if (set_dma_tx)
- s5p_set_dma_outdata(dev, dev->sg_dst);
- if (set_dma_rx)
- s5p_set_dma_indata(dev, dev->sg_src);
+ if (err_dma_rx < 0) {
+ err = err_dma_rx;
+ goto error;
+ }
+ if (err_dma_tx < 0) {
+ err = err_dma_tx;
+ goto error;
+ }
+
+ if (tx_end) {
+ s5p_sg_done(dev);
+
+ spin_unlock_irqrestore(&dev->lock, flags);
+
+ s5p_aes_complete(dev, 0);
+ dev->busy = true;
+ tasklet_schedule(&dev->tasklet);
+ } else {
+ /*
+ * Writing length of DMA block (either receiving or
+ * transmitting) will start the operation immediately, so this
+ * should be done at the end (even after clearing pending
+ * interrupts to not miss the interrupt).
+ */
+ if (err_dma_tx == 1)
+ s5p_set_dma_outdata(dev, dev->sg_dst);
+ if (err_dma_rx == 1)
+ s5p_set_dma_indata(dev, dev->sg_src);
+ spin_unlock_irqrestore(&dev->lock, flags);
+ }
+
+ return IRQ_HANDLED;
+
+error:
+ s5p_sg_done(dev);
spin_unlock_irqrestore(&dev->lock, flags);
+ s5p_aes_complete(dev, err);
return IRQ_HANDLED;
}
@@ -597,8 +633,9 @@ static void s5p_aes_crypt_start(struct s5p_aes_dev *dev, unsigned long mode)
s5p_unset_indata(dev);
indata_error:
- s5p_aes_complete(dev, err);
+ s5p_sg_done(dev);
spin_unlock_irqrestore(&dev->lock, flags);
+ s5p_aes_complete(dev, err);
}
static void s5p_tasklet_cb(unsigned long data)
--
2.9.3
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox