* Re: [PATCH -next v2] crypto: sun4i-ss - fix missing unlock on error in sun4i_hash()
From: Herbert Xu @ 2016-08-24 13:14 UTC (permalink / raw)
To: Wei Yongjun
Cc: Corentin Labbe, David S. Miller, Maxime Ripard, Chen-Yu Tsai,
linux-crypto, linux-arm-kernel
In-Reply-To: <1471690133-24396-1-git-send-email-weiyj.lk@gmail.com>
On Sat, Aug 20, 2016 at 10:48:53AM +0000, Wei Yongjun wrote:
> Add the missing unlock before return from function sun4i_hash()
> in the error handling case.
>
> Fixes: 477d9b2e591b ("crypto: sun4i-ss - unify update/final function")
> Signed-off-by: Wei Yongjun <weiyj.lk@gmail.com>
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: qat - fix aes-xts key sizes
From: Herbert Xu @ 2016-08-24 13:13 UTC (permalink / raw)
To: Giovanni Cabiddu; +Cc: linux-crypto
In-Reply-To: <1471546416-7164-1-git-send-email-giovanni.cabiddu@intel.com>
On Thu, Aug 18, 2016 at 07:53:36PM +0100, Giovanni Cabiddu wrote:
> Increase value of supported key sizes for qat_aes_xts.
> aes-xts keys consists of keys of equal size concatenated.
>
> Reported-by: Wenqian Yu <wenqian.yu@intel.com>
> Signed-off-by: Giovanni Cabiddu <giovanni.cabiddu@intel.com>
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 V2 linux-next] hwrng: update Freescale i.MX RNGA Random Number Generator
From: Herbert Xu @ 2016-08-24 13:13 UTC (permalink / raw)
To: Fabian Frederick; +Cc: Matt Mackall, linux-crypto, Arnd Bergmann, linux-kernel
In-Reply-To: <1471376985-7791-1-git-send-email-fabf@skynet.be>
On Tue, Aug 16, 2016 at 09:49:45PM +0200, Fabian Frederick wrote:
> We can directly depend on SOC_IMX31 since commit c9ee94965dce
> ("ARM: imx: deconstruct mxc_rnga initialization")
>
> Since that commit, CONFIG_HW_RANDOM_MXC_RNGA could not be switched on
> with unknown symbol ARCH_HAS_RNGA and mxc-rnga.o can't be generated with
> ARCH=arm make M=drivers/char/hw_random
> Previously, HW_RANDOM_MXC_RNGA required ARCH_HAS_RNGA
> which was based on IMX_HAVE_PLATFORM_MXC_RNGA && ARCH_MXC.
> IMX_HAVE_PLATFORM_MXC_RNGA was based on SOC_IMX31.
>
> Fixes: c9ee94965dce ("ARM: imx: deconstruct mxc_rnga initialization")
> Signed-off-by: Fabian Frederick <fabf@skynet.be>
> ---
> -Cc to linux-crypto (suggested by Herbert Xu)
> -Adding "Fixes:" (suggested by Arnd Bergmann)
> -This patch appeared in 4.8-rc1 (not in stable yet)
> -Improving patch description
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] hw_random: Improve description of the ->read() interface
From: Herbert Xu @ 2016-08-24 13:13 UTC (permalink / raw)
To: Daniel Thompson
Cc: Matt Mackall, linux-crypto, linux-kernel, patches, linaro-kernel,
LABBE Corentin, PrasannaKumar Muralidharan
In-Reply-To: <1471523841-30469-1-git-send-email-daniel.thompson@linaro.org>
On Thu, Aug 18, 2016 at 01:37:21PM +0100, Daniel Thompson wrote:
> Currently, very few RNG drivers support single byte reads using the
> ->read() interface. Of the 14 drivers in drivers/char/hw_random that
> support this interface only three of these actually support max == 1.
> The other behaviours vary between return 0, return 2, return 4 and return
> -EIO).
>
> This is not a problem in practice because the core hw_random code never
> performs a read shorter than 16 bytes. The documentation for this function
> already contrains the alignment of the buffer pointer, so let's also
> guarantee that the buffer is at least as large as its alignment.
>
> This constraint is intended to be the weakest guarantee neccessary to
> allow driver writers to safely simplify their code.
>
> Signed-off-by: Daniel Thompson <daniel.thompson@linaro.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: [RFC PATCH v1 18/28] crypto: add AMD Platform Security Processor driver
From: Tom Lendacky @ 2016-08-24 12:02 UTC (permalink / raw)
To: Herbert Xu, Brijesh Singh
Cc: simon.guinot, linux-efi, kvm, rkrcmar, matt, linus.walleij,
linux-mm, paul.gortmaker, hpa, dan.j.williams, aarcange, sfr,
andriy.shevchenko, bhe, xemul, joro, x86, mingo, msalter,
ross.zwisler, bp, dyoung, jroedel, keescook, toshi.kani,
mathieu.desnoyers, devel, tglx, mchehab, iamjoonsoo.kim, labbott,
tony.luck, alexandre.bounine, kuleshovmail, linux-kernel, mcgrof
In-Reply-To: <20160823071458.GC392@gondor.apana.org.au>
On 08/23/2016 02:14 AM, Herbert Xu wrote:
> On Mon, Aug 22, 2016 at 07:27:22PM -0400, Brijesh Singh wrote:
>> The driver to communicate with Secure Encrypted Virtualization (SEV)
>> firmware running within the AMD secure processor providing a secure key
>> management interface for SEV guests.
>>
>> Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
>> Signed-off-by: Brijesh Singh <brijesh.singh@amd.com>
>
> This driver doesn't seem to hook into the Crypto API at all, is
> there any reason why it should be in drivers/crypto?
Yes, this needs to be cleaned up. The PSP and the CCP share the same
PCI id, so this has to be integrated with the CCP. It could either
be moved into the drivers/crypto/ccp directory or both the psp and
ccp device specific support can be moved somewhere else leaving just
the ccp crypto API related files in drivers/crypto/ccp.
Thanks,
Tom
>
> Thanks,
>
--
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 3/5] hwrng: amd: Be consitent with the driver name
From: Herbert Xu @ 2016-08-24 10:58 UTC (permalink / raw)
To: LABBE Corentin; +Cc: mpm, linux-crypto, linux-kernel
In-Reply-To: <1471614177-12380-3-git-send-email-clabbe.montjoie@gmail.com>
On Fri, Aug 19, 2016 at 03:42:55PM +0200, LABBE Corentin wrote:
> The driver name is displayed each time differently.
> This patch make use of the same name everywhere.
>
> Signed-off-by: LABBE Corentin <clabbe.montjoie@gmail.com>
> ---
> drivers/char/hw_random/amd-rng.c | 13 ++++++-------
> 1 file changed, 6 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/char/hw_random/amd-rng.c b/drivers/char/hw_random/amd-rng.c
> index d0042f5..d0a806a 100644
> --- a/drivers/char/hw_random/amd-rng.c
> +++ b/drivers/char/hw_random/amd-rng.c
> @@ -31,7 +31,7 @@
> #include <linux/delay.h>
> #include <asm/io.h>
>
> -#define PFX KBUILD_MODNAME ": "
> +#define DRV_NAME "AMD768-HWRNG"
>
> /*
> * Data for PCI driver interface
> @@ -98,7 +98,7 @@ static void amd_rng_cleanup(struct hwrng *rng)
> }
>
> static struct hwrng amd_rng = {
> - .name = "amd",
> + .name = DRV_NAME,
Hmm, this changes a sysfs-exported name which has the potential
to break user-space. So I think you'd need to a stronger argument
to do it other than just cleaning it up.
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
* [PATCH] crypto: vmx - fix null dereference in p8_aes_xts_crypt
From: Li Zhong @ 2016-08-24 7:34 UTC (permalink / raw)
To: linux-crypto; +Cc: leosilva, pfsmorigo, herbert
walk.iv is not assigned a value in blkcipher_walk_init. It makes iv uninitialized.
It is possibly a null value(as shown below), which is then used by aes_p8_encrypt.
This patch moves iv = walk.iv after blkcipher_walk_virt, in which walk.iv is set.
[17856.268050] Unable to handle kernel paging request for data at address 0x00000000
[17856.268212] Faulting instruction address: 0xd000000002ff04bc
7:mon> t
[link register ] d000000002ff47b8 p8_aes_xts_crypt+0x168/0x2a0 [vmx_crypto] (938)
[c000000013b77960] d000000002ff4794 p8_aes_xts_crypt+0x144/0x2a0 [vmx_crypto] (unreliable)
[c000000013b77a70] c000000000544d64 skcipher_decrypt_blkcipher+0x64/0x80
[c000000013b77ac0] d000000003c0175c crypt_convert+0x53c/0x620 [dm_crypt]
[c000000013b77ba0] d000000003c043fc kcryptd_crypt+0x3cc/0x440 [dm_crypt]
[c000000013b77c50] c0000000000f3070 process_one_work+0x1e0/0x590
[c000000013b77ce0] c0000000000f34c8 worker_thread+0xa8/0x660
[c000000013b77d80] c0000000000fc0b0 kthread+0x110/0x130
[c000000013b77e30] c0000000000098f0 ret_from_kernel_thread+0x5c/0x6c
Signed-off-by: Li Zhong <zhong@linux.vnet.ibm.com>
---
drivers/crypto/vmx/aes_xts.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/crypto/vmx/aes_xts.c b/drivers/crypto/vmx/aes_xts.c
index cfb2541..24353ec3 100644
--- a/drivers/crypto/vmx/aes_xts.c
+++ b/drivers/crypto/vmx/aes_xts.c
@@ -129,8 +129,8 @@ static int p8_aes_xts_crypt(struct blkcipher_desc *desc,
blkcipher_walk_init(&walk, dst, src, nbytes);
- iv = (u8 *)walk.iv;
ret = blkcipher_walk_virt(desc, &walk);
+ iv = walk.iv;
memset(tweak, 0, AES_BLOCK_SIZE);
aes_p8_encrypt(iv, tweak, &ctx->tweak_key);
^ permalink raw reply related
* Re: [PATCH v2 2/2] HWRNG: thunderx: Add Cavium HWRNG driver for ThunderX SoC.
From: Corentin LABBE @ 2016-08-24 5:46 UTC (permalink / raw)
To: Omer Khaliq, linux-kernel, linux-pci, linux-crypto,
linux-arm-kernel, bhelgaas, mpm, herbert, Ananth.Jasty,
David.Daney
In-Reply-To: <1471994835-2423-3-git-send-email-okhaliq@caviumnetworks.com>
Hello
> +/* Read data from the RNG unit */
> +static int cavium_rng_read(struct hwrng *rng, void *dat, size_t max, bool wait)
> +{
> + struct cavium_rng *p = container_of(rng, struct cavium_rng, ops);
> + unsigned int size = max;
> +
> + while (size >= 8) {
> + *((u64 *)dat) = readq(p->result);
> + size -= 8;
> + dat += 8;
> + }
I think you could use readsq()
This will increase throughput
Regards
LABBE Corentin
^ permalink raw reply
* [PATCH v2 2/2] HWRNG: thunderx: Add Cavium HWRNG driver for ThunderX SoC.
From: Omer Khaliq @ 2016-08-23 23:27 UTC (permalink / raw)
To: linux-kernel, linux-pci, linux-crypto, linux-arm-kernel, bhelgaas,
mpm, herbert, Ananth.Jasty, David.Daney, clabbe.montjoie
Cc: Omer Khaliq
In-Reply-To: <1471994835-2423-1-git-send-email-okhaliq@caviumnetworks.com>
The Cavium ThunderX SoC has a hardware random number generator.
This driver provides support using the HWRNG framework.
Signed-off-by: Omer Khaliq <okhaliq@caviumnetworks.com>
Signed-off-by: Ananth Jasty <Ananth.Jasty@cavium.com>
Acked-by: David Daney <david.daney@cavium.com>
---
drivers/char/hw_random/Kconfig | 13 +++++
drivers/char/hw_random/Makefile | 1 +
drivers/char/hw_random/cavium-rng-vf.c | 99 ++++++++++++++++++++++++++++++++++
drivers/char/hw_random/cavium-rng.c | 94 ++++++++++++++++++++++++++++++++
4 files changed, 207 insertions(+)
create mode 100644 drivers/char/hw_random/cavium-rng-vf.c
create mode 100644 drivers/char/hw_random/cavium-rng.c
diff --git a/drivers/char/hw_random/Kconfig b/drivers/char/hw_random/Kconfig
index 56ad5a5..fb9c7ad 100644
--- a/drivers/char/hw_random/Kconfig
+++ b/drivers/char/hw_random/Kconfig
@@ -410,6 +410,19 @@ config HW_RANDOM_MESON
If unsure, say Y.
+config HW_RANDOM_CAVIUM
+ tristate "Cavium ThunderX Random Number Generator support"
+ depends on HW_RANDOM && PCI && (ARM64 || (COMPILE_TEST && 64BIT))
+ default HW_RANDOM
+ ---help---
+ This driver provides kernel-side support for the Random Number
+ Generator hardware found on Cavium SoCs.
+
+ To compile this driver as a module, choose M here: the
+ module will be called cavium_rng.
+
+ If unsure, say Y.
+
endif # HW_RANDOM
config UML_RANDOM
diff --git a/drivers/char/hw_random/Makefile b/drivers/char/hw_random/Makefile
index 04bb0b0..5f52b1e 100644
--- a/drivers/char/hw_random/Makefile
+++ b/drivers/char/hw_random/Makefile
@@ -35,3 +35,4 @@ obj-$(CONFIG_HW_RANDOM_XGENE) += xgene-rng.o
obj-$(CONFIG_HW_RANDOM_STM32) += stm32-rng.o
obj-$(CONFIG_HW_RANDOM_PIC32) += pic32-rng.o
obj-$(CONFIG_HW_RANDOM_MESON) += meson-rng.o
+obj-$(CONFIG_HW_RANDOM_CAVIUM) += cavium-rng.o cavium-rng-vf.o
diff --git a/drivers/char/hw_random/cavium-rng-vf.c b/drivers/char/hw_random/cavium-rng-vf.c
new file mode 100644
index 0000000..066ae0e
--- /dev/null
+++ b/drivers/char/hw_random/cavium-rng-vf.c
@@ -0,0 +1,99 @@
+/*
+ * Hardware Random Number Generator support for Cavium, Inc.
+ * Thunder processor family.
+ *
+ * This file is subject to the terms and conditions of the GNU General Public
+ * License. See the file "COPYING" in the main directory of this archive
+ * for more details.
+ *
+ * Copyright (C) 2016 Cavium, Inc.
+ */
+
+#include <linux/hw_random.h>
+#include <linux/io.h>
+#include <linux/module.h>
+#include <linux/pci.h>
+#include <linux/pci_ids.h>
+
+struct cavium_rng {
+ struct hwrng ops;
+ void __iomem *result;
+};
+
+/* Read data from the RNG unit */
+static int cavium_rng_read(struct hwrng *rng, void *dat, size_t max, bool wait)
+{
+ struct cavium_rng *p = container_of(rng, struct cavium_rng, ops);
+ unsigned int size = max;
+
+ while (size >= 8) {
+ *((u64 *)dat) = readq(p->result);
+ size -= 8;
+ dat += 8;
+ }
+ while (size > 0) {
+ *((u8 *)dat) = readb(p->result);
+ size--;
+ dat++;
+ }
+ return max;
+}
+
+/* Map Cavium RNG to an HWRNG object */
+static int cavium_rng_probe_vf(struct pci_dev *pdev,
+ const struct pci_device_id *id)
+{
+ struct cavium_rng *rng;
+ int ret;
+
+ rng = devm_kzalloc(&pdev->dev, sizeof(*rng), GFP_KERNEL);
+ if (!rng)
+ return -ENOMEM;
+
+ /* Map the RNG result */
+ rng->result = pcim_iomap(pdev, 0, 0);
+ if (!rng->result) {
+ dev_err(&pdev->dev, "Error iomap failed retrieving result.\n");
+ return -ENOMEM;
+ }
+
+ rng->ops.name = "cavium rng";
+ rng->ops.read = cavium_rng_read;
+ rng->ops.quality = 1000;
+
+ pci_set_drvdata(pdev, rng);
+
+ ret = hwrng_register(&rng->ops);
+ if (ret) {
+ dev_err(&pdev->dev, "Error registering device as HWRNG.\n");
+ return ret;
+ }
+
+ return 0;
+}
+
+/* Remove the VF */
+void cavium_rng_remove_vf(struct pci_dev *pdev)
+{
+ struct cavium_rng *rng;
+
+ rng = pci_get_drvdata(pdev);
+ hwrng_unregister(&rng->ops);
+}
+
+static const struct pci_device_id cavium_rng_vf_id_table[] = {
+ { PCI_DEVICE(PCI_VENDOR_ID_CAVIUM, 0xa033), 0, 0, 0},
+ {0,},
+};
+MODULE_DEVICE_TABLE(pci, cavium_rng_vf_id_table);
+
+static struct pci_driver cavium_rng_vf_driver = {
+ .name = "cavium_rng_vf",
+ .id_table = cavium_rng_vf_id_table,
+ .probe = cavium_rng_probe_vf,
+ .remove = cavium_rng_remove_vf,
+};
+module_pci_driver(cavium_rng_vf_driver);
+
+MODULE_AUTHOR("Omer Khaliq <okhaliq@caviumnetworks.com>");
+MODULE_LICENSE("GPL");
diff --git a/drivers/char/hw_random/cavium-rng.c b/drivers/char/hw_random/cavium-rng.c
new file mode 100644
index 0000000..a944e0a
--- /dev/null
+++ b/drivers/char/hw_random/cavium-rng.c
@@ -0,0 +1,94 @@
+/*
+ * Hardware Random Number Generator support for Cavium Inc.
+ * Thunder processor family.
+ *
+ * This file is subject to the terms and conditions of the GNU General Public
+ * License. See the file "COPYING" in the main directory of this archive
+ * for more details.
+ *
+ * Copyright (C) 2016 Cavium, Inc.
+ */
+
+#include <linux/hw_random.h>
+#include <linux/io.h>
+#include <linux/module.h>
+#include <linux/pci.h>
+#include <linux/pci_ids.h>
+
+#define THUNDERX_RNM_ENT_EN 0x1
+#define THUNDERX_RNM_RNG_EN 0x2
+
+struct cavium_rng_pf {
+ void __iomem *control_status;
+};
+
+/* Enable the RNG hardware and activate the VF */
+static int cavium_rng_probe(struct pci_dev *pdev,
+ const struct pci_device_id *id)
+{
+ struct cavium_rng_pf *rng;
+ int iov_err;
+
+ rng = devm_kzalloc(&pdev->dev, sizeof(*rng), GFP_KERNEL);
+ if (!rng)
+ return -ENOMEM;
+
+ /*Map the RNG control */
+ rng->control_status = pcim_iomap(pdev, 0, 0);
+ if (!rng->control_status) {
+ dev_err(&pdev->dev,
+ "Error iomap failed retrieving control_status.\n");
+ return -ENOMEM;
+ }
+
+ /* Enable the RNG hardware and entropy source */
+ writeq(THUNDERX_RNM_RNG_EN | THUNDERX_RNM_ENT_EN,
+ rng->control_status);
+
+ pci_set_drvdata(pdev, rng);
+
+ /* Enable the Cavium RNG as a VF */
+ iov_err = pci_enable_sriov(pdev, 1);
+ if (iov_err != 0) {
+ /* Disable the RNG hardware and entropy source */
+ writeq(0, rng->control_status);
+ dev_err(&pdev->dev,
+ "Error initializing RNG virtual function,(%i).\n",
+ iov_err);
+ return iov_err;
+ }
+
+ return 0;
+}
+
+/* Disable VF and RNG Hardware */
+void cavium_rng_remove(struct pci_dev *pdev)
+{
+ struct cavium_rng_pf *rng;
+
+ rng = pci_get_drvdata(pdev);
+
+ /* Remove the VF */
+ pci_disable_sriov(pdev);
+
+ /* Disable the RNG hardware and entropy source */
+ writeq(0, rng->control_status);
+}
+
+static const struct pci_device_id cavium_rng_pf_id_table[] = {
+ { PCI_DEVICE(PCI_VENDOR_ID_CAVIUM, 0xa018), 0, 0, 0}, /* Thunder RNM */
+ {0,},
+};
+
+MODULE_DEVICE_TABLE(pci, cavium_rng_pf_id_table);
+
+static struct pci_driver cavium_rng_pf_driver = {
+ .name = "cavium_rng_pf",
+ .id_table = cavium_rng_pf_id_table,
+ .probe = cavium_rng_probe,
+ .remove = cavium_rng_remove,
+};
+
+module_pci_driver(cavium_rng_pf_driver);
+MODULE_AUTHOR("Omer Khaliq <okhaliq@caviumnetworks.com>");
+MODULE_LICENSE("GPL");
--
1.9.1
^ permalink raw reply related
* [PATCH v2 1/2] PCI: quirk fixup for cavium invalid sriov link value.
From: Omer Khaliq @ 2016-08-23 23:27 UTC (permalink / raw)
To: linux-kernel, linux-pci, linux-crypto, linux-arm-kernel, bhelgaas,
mpm, herbert, Ananth.Jasty, David.Daney, clabbe.montjoie
Cc: Omer Khaliq
In-Reply-To: <1471994835-2423-1-git-send-email-okhaliq@caviumnetworks.com>
From: Ananth Jasty <Ananth.Jasty@cavium.com>
Cavium cn88xx hardware presents an incorrect SR-IOV Function
Dependency Link, add a fixup quirk for the affected devices.
Acked-by: David Daney <david.daney@cavium.com>
Signed-off-by: Ananth Jasty <Ananth.Jasty@cavium.com>
Signed-off-by: Omer Khaliq <okhaliq@caviumnetworks.com>
---
drivers/pci/quirks.c | 11 +++++++++++
1 file changed, 11 insertions(+)
diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c
index 37ff015..5980aae 100644
--- a/drivers/pci/quirks.c
+++ b/drivers/pci/quirks.c
@@ -834,6 +834,17 @@ static void quirk_amd_ioapic(struct pci_dev *dev)
DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_AMD, PCI_DEVICE_ID_AMD_VIPER_7410, quirk_amd_ioapic);
#endif /* CONFIG_X86_IO_APIC */
+#ifdef CONFIG_ARM64
+
+static void quirk_cavium_sriov_rnm_link(struct pci_dev *dev)
+{
+ /* Fix for improper SRIOV configuration on Cavium cn88xx RNM device */
+ if (dev->subsystem_device == 0xa118)
+ dev->sriov->link = dev->devfn;
+}
+DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_CAVIUM, 0xa018, quirk_cavium_sriov_rnm_link);
+#endif
+
/*
* Some settings of MMRBC can lead to data corruption so block changes.
* See AMD 8131 HyperTransport PCI-X Tunnel Revision Guide
--
1.9.1
^ permalink raw reply related
* [PATCH v2 0/2] HWRNG/PCI: Add driver for Cavium Thunder RNG
From: Omer Khaliq @ 2016-08-23 23:27 UTC (permalink / raw)
To: linux-kernel, linux-pci, linux-crypto, linux-arm-kernel, bhelgaas,
mpm, herbert, Ananth.Jasty, David.Daney, clabbe.montjoie
Cc: Omer Khaliq
There is a hardware error rendering the FDL field incorrect for the some
Thunder RNG devices. The first patch adds a PCI quirk to fix the problem.
The second patch adds the driver.
Changes from v1:
Use PCI quirks as advised.
Removed unecessary headers
Format changes as advised
Ananth Jasty (1):
PCI: quirk fixup for cavium invalid sriov link value.
Omer Khaliq (1):
HWRNG: thunderx: Add Cavium HWRNG driver for ThunderX SoC.
drivers/char/hw_random/Kconfig | 13 +++++
drivers/char/hw_random/Makefile | 1 +
drivers/char/hw_random/cavium-rng-vf.c | 99 ++++++++++++++++++++++++++++++++++
drivers/char/hw_random/cavium-rng.c | 94 ++++++++++++++++++++++++++++++++
drivers/pci/quirks.c | 11 ++++
5 files changed, 218 insertions(+)
create mode 100644 drivers/char/hw_random/cavium-rng-vf.c
create mode 100644 drivers/char/hw_random/cavium-rng.c
--
1.9.1
^ permalink raw reply
* Problems with cbc(aes) and do_alg0test()
From: Michael McKay @ 2016-08-23 22:44 UTC (permalink / raw)
To: linux-crypto@vger.kernel.org
We are writing a device driver with kernel v3.14, and trying to encrypt some data using the Linux kernel algorithm “cbc(aes)”. Our /proc/crypto shows the following is loaded: driver “cbc-aes-aesni”, module “aesni_intel”, and type “ablkcipher”. But crypto_has_alg() gives us an error indicating the algo is not loaded. So knowing we have the algo string correct, most likely the problem is with the two other input variables: mask or type.
Since AESNI is in use, we have a decent guess at the types by looking at the .cra_flags field in aensi-Intel_glue.c (which has “CRYPTO_ALG_TYPE_ABLKCIPHER | CRYPTO_ALG_ASYNC”). That leaves just a few mask fields to guess at, but CRYPTO_ALG_TYPE_BLKCIPHER_MASK and CRYPTO_ALG_TYPE_MASK don’t work (not does OR’ing them together).
What are the correct mask and type values for AESNI, and can you point me to any documentation? What else might we be doing wrong? Is /proc/crypto giving us relevant information? Thanks,
Michael McKay
mmckay@vmware.com
^ permalink raw reply
* crypto: mxs-dcp: do not call blocking ops when !TASK_RUNNING; state=1
From: Stefan Wahren @ 2016-08-23 20:38 UTC (permalink / raw)
To: Herbert Xu; +Cc: linux-crypto, Fabio Estevam
Hi,
i'm using a iMX233-OLinuXino board and i get the following warning during boot
with 4.8.0-rc2-next-20160819:
[ 2.450000] ------------[ cut here ]------------
[ 2.450000] WARNING: CPU: 0 PID: 42 at kernel/sched/core.c:7602
__might_sleep+0x8c/0xa0
[ 2.470000] do not call blocking ops when !TASK_RUNNING; state=1 set at
[<c048f730>] dcp_chan_thread_aes+0x24/0x664
[ 2.480000] Modules linked in:
[ 2.480000] CPU: 0 PID: 42 Comm: mxs_dcp_chan/ae Not tainted
4.8.0-rc2-next-20160819-dirty #2
[ 2.490000] mxs-dcp 80028000.dcp: Failed to register sha1 hash!
[ 2.500000] Hardware name: Freescale MXS (Device Tree)
[ 2.510000] [<c00100a4>] (unwind_backtrace) from [<c000e088>]
(show_stack+0x10/0x14)
[ 2.520000] [<c000e088>] (show_stack) from [<c001ce8c>] (__warn+0xd8/0x100)
[ 2.530000] [<c001ce8c>] (__warn) from [<c001cf5c>]
(warn_slowpath_fmt+0x38/0x48)
[ 2.540000] [<c001cf5c>] (warn_slowpath_fmt) from [<c00479dc>]
(__might_sleep+0x8c/0xa0)
[ 2.540000] [<c00479dc>] (__might_sleep) from [<c05dd24c>]
(mutex_lock_nested+0x24/0x39c)
[ 2.550000] [<c05dd24c>] (mutex_lock_nested) from [<c048f760>]
(dcp_chan_thread_aes+0x54/0x664)
[ 2.560000] [<c048f760>] (dcp_chan_thread_aes) from [<c0040574>]
(kthread+0xd0/0xf0)
[ 2.580000] [<c0040574>] (kthread) from [<c000a36c>]
(ret_from_fork+0x14/0x28)
[ 2.590000] ---[ end trace e2182161e464af25 ]---
What would be the right fix for this issue?
Regards
Stefan
^ permalink raw reply
* Re: [PATCH] crypto: rockchip - use devm_add_action_or_reset()
From: Heiko Stübner @ 2016-08-23 15:34 UTC (permalink / raw)
To: Sudip Mukherjee
Cc: Herbert Xu, linux-kernel, linux-rockchip, linux-crypto,
David S. Miller, linux-arm-kernel
In-Reply-To: <1471964334-27060-1-git-send-email-sudipm.mukherjee@gmail.com>
Am Dienstag, 23. August 2016, 20:28:54 schrieb Sudip Mukherjee:
> If devm_add_action() fails we are explicitly calling the cleanup to free
> the resources allocated. Lets use the helper devm_add_action_or_reset()
> and return directly in case of error, as we know that the cleanup function
> has been already called by the helper if there was any error.
>
> Signed-off-by: Sudip Mukherjee <sudip.mukherjee@codethink.co.uk>
nice little cleanup
Reviewed-by: Heiko Stuebner <heiko@sntech.de>
^ permalink raw reply
* [PATCH] crypto: rockchip - use devm_add_action_or_reset()
From: Sudip Mukherjee @ 2016-08-23 14:58 UTC (permalink / raw)
To: Herbert Xu, David S. Miller, Heiko Stuebner
Cc: linux-rockchip-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Sudip Mukherjee,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-crypto-u79uwXL29TY76Z2rM5mHXA
If devm_add_action() fails we are explicitly calling the cleanup to free
the resources allocated. Lets use the helper devm_add_action_or_reset()
and return directly in case of error, as we know that the cleanup function
has been already called by the helper if there was any error.
Signed-off-by: Sudip Mukherjee <sudip.mukherjee-4yDnlxn2s6sWdaTGBSpHTA@public.gmane.org>
---
drivers/crypto/rockchip/rk3288_crypto.c | 6 ++----
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/crypto/rockchip/rk3288_crypto.c b/drivers/crypto/rockchip/rk3288_crypto.c
index af50825..d0f80c6 100644
--- a/drivers/crypto/rockchip/rk3288_crypto.c
+++ b/drivers/crypto/rockchip/rk3288_crypto.c
@@ -304,11 +304,9 @@ static int rk_crypto_probe(struct platform_device *pdev)
usleep_range(10, 20);
reset_control_deassert(crypto_info->rst);
- err = devm_add_action(dev, rk_crypto_action, crypto_info);
- if (err) {
- reset_control_assert(crypto_info->rst);
+ err = devm_add_action_or_reset(dev, rk_crypto_action, crypto_info);
+ if (err)
goto err_crypto;
- }
spin_lock_init(&crypto_info->lock);
--
1.9.1
^ permalink raw reply related
* Re: [PATCH -next v2] crypto: sun4i-ss - fix missing unlock on error in sun4i_hash()
From: Corentin LABBE @ 2016-08-23 13:54 UTC (permalink / raw)
To: Wei Yongjun, Herbert Xu, David S. Miller, Maxime Ripard,
Chen-Yu Tsai
Cc: linux-crypto, linux-arm-kernel
In-Reply-To: <1471690133-24396-1-git-send-email-weiyj.lk@gmail.com>
On 20/08/2016 12:48, Wei Yongjun wrote:
> Add the missing unlock before return from function sun4i_hash()
> in the error handling case.
>
> Fixes: 477d9b2e591b ("crypto: sun4i-ss - unify update/final function")
> Signed-off-by: Wei Yongjun <weiyj.lk@gmail.com>
> ---
> v1 -> v2: goto release_ss as LABBE Corentin's suggestion
> ---
> drivers/crypto/sunxi-ss/sun4i-ss-hash.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/crypto/sunxi-ss/sun4i-ss-hash.c b/drivers/crypto/sunxi-ss/sun4i-ss-hash.c
> index 2ee3b59..1afeb8e 100644
> --- a/drivers/crypto/sunxi-ss/sun4i-ss-hash.c
> +++ b/drivers/crypto/sunxi-ss/sun4i-ss-hash.c
> @@ -245,7 +245,8 @@ int sun4i_hash(struct ahash_request *areq)
> if (end > areq->nbytes || areq->nbytes - end > 63) {
> dev_err(ss->dev, "ERROR: Bound error %u %u\n",
> end, areq->nbytes);
> - return -EINVAL;
> + err = -EINVAL;
> + goto release_ss;
> }
> } else {
> /* Since we have the flag final, we can go up to modulo 4 */
>
Acked-by: Corentin LABBE <clabbe.montjoie@gmail.com>
Thanks
^ permalink raw reply
* Re: [PATCH V2 linux-next] hwrng: update Freescale i.MX RNGA Random Number Generator
From: Arnd Bergmann @ 2016-08-23 12:27 UTC (permalink / raw)
To: Fabian Frederick; +Cc: Matt Mackall, Herbert Xu, linux-crypto, linux-kernel
In-Reply-To: <1471376985-7791-1-git-send-email-fabf@skynet.be>
On Tuesday, August 16, 2016 9:49:45 PM CEST Fabian Frederick wrote:
> We can directly depend on SOC_IMX31 since commit c9ee94965dce
> ("ARM: imx: deconstruct mxc_rnga initialization")
>
> Since that commit, CONFIG_HW_RANDOM_MXC_RNGA could not be switched on
> with unknown symbol ARCH_HAS_RNGA and mxc-rnga.o can't be generated with
> ARCH=arm make M=drivers/char/hw_random
> Previously, HW_RANDOM_MXC_RNGA required ARCH_HAS_RNGA
> which was based on IMX_HAVE_PLATFORM_MXC_RNGA && ARCH_MXC.
> IMX_HAVE_PLATFORM_MXC_RNGA was based on SOC_IMX31.
>
> Fixes: c9ee94965dce ("ARM: imx: deconstruct mxc_rnga initialization")
> Signed-off-by: Fabian Frederick <fabf@skynet.be>
> ---
> -Cc to linux-crypto (suggested by Herbert Xu)
> -Adding "Fixes:" (suggested by Arnd Bergmann)
> -This patch appeared in 4.8-rc1 (not in stable yet)
> -Improving patch description
>
Thanks for fixing my mistake!
Acked-by: Arnd Bergmann <arnd@arndb.de>
^ permalink raw reply
* Crypto Fixes for 4.8
From: Herbert Xu @ 2016-08-23 9:51 UTC (permalink / raw)
To: Linus Torvalds, David S. Miller, Linux Kernel Mailing List,
Linux Crypto Mailing List
In-Reply-To: <20160801095821.GA1260@gondor.apana.org.au>
Hi Linus:
This push fixes a number of memory corruption bugs in the newly
added sha256-mb/sha256-mb code.
Please pull from
git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6.git linus
Xiaodong Liu (2):
crypto: sha256-mb - fix ctx pointer and digest copy
crypto: sha512-mb - fix ctx pointer
arch/x86/crypto/sha256-mb/sha256_mb.c | 4 ++--
arch/x86/crypto/sha256-mb/sha256_mb_mgr_flush_avx2.S | 7 ++++---
arch/x86/crypto/sha512-mb/sha512_mb.c | 4 ++--
3 files changed, 8 insertions(+), 7 deletions(-)
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 v2] crypto: XTS - remove test that will fail in FIPS mode
From: Herbert Xu @ 2016-08-23 9:47 UTC (permalink / raw)
To: Stephan Mueller; +Cc: Tapas Sarangi, linux-crypto@vger.kernel.org
In-Reply-To: <16370043.OYgDIDmMpM@tauon.atsec.com>
On Tue, Aug 16, 2016 at 11:38:00AM +0200, Stephan Mueller wrote:
> Hi Tapas,
>
> I was able to reproduce the issue now.
>
> I tested the patch below and it works for me now. Yet, I see that dracut-fips seems to need some fixes too as it cannot find cmac when compiled as module and has some issues with the authenc() ciphers too.
>
>
> ---8<---
>
> In FIPS mode, setting XTS keys where the AES key is identical to the
> tweak key is forbidden. Thus, the self test with such property will fail
> in FIPS mode.
>
> As we have other tests available for XTS, this patch simply removes the
> offending test vectors.
>
> Reported-by: Tapas Sarangi <TSarangi@trustwave.com>
> Signed-off-by: Stephan Mueller <stephan.mueller@atsec.com>
We should fix this without removing tests. Perhaps add a field
in the vector to indicate that it should be skipped when in FIPS
mode, just like we do for expected weak keys.
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
* [PATCH] crypto: FIPS - allow RSA keys >= 2048 bits
From: Stephan Mueller @ 2016-08-23 8:09 UTC (permalink / raw)
To: herbert; +Cc: linux-crypto
With a public notification, NIST now allows the use of RSA keys with a
modulus >= 2048 bits. The new rule allows any modulus size >= 2048 bits
provided that either 2048 or 3072 bits are supported at least so that
the entire RSA implementation can be CAVS tested.
This patch fixes the inability to boot the kernel in FIPS mode, because
certs/x509.genkey defines a 4096 bit RSA key per default. This key causes
the RSA signature verification to fail in FIPS mode without the patch
below.
Signed-off-by: Stephan Mueller <smueller@chronox.de>
---
crypto/rsa_helper.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/crypto/rsa_helper.c b/crypto/rsa_helper.c
index 4df6451..0b66dc8 100644
--- a/crypto/rsa_helper.c
+++ b/crypto/rsa_helper.c
@@ -35,8 +35,8 @@ int rsa_get_n(void *context, size_t hdrlen, unsigned char tag,
n_sz--;
}
- /* In FIPS mode only allow key size 2K & 3K */
- if (n_sz != 256 && n_sz != 384) {
+ /* In FIPS mode only allow key size 2K and higher */
+ if (n_sz < 256) {
pr_err("RSA: key size not allowed in FIPS mode\n");
return -EINVAL;
}
--
2.7.4
^ permalink raw reply related
* Re: [RFC PATCH v1 18/28] crypto: add AMD Platform Security Processor driver
From: Herbert Xu @ 2016-08-23 7:14 UTC (permalink / raw)
To: Brijesh Singh
Cc: simon.guinot, linux-efi, kvm, rkrcmar, matt, linus.walleij,
linux-mm, paul.gortmaker, hpa, dan.j.williams, aarcange, sfr,
andriy.shevchenko, bhe, xemul, joro, x86, mingo, msalter,
ross.zwisler, bp, dyoung, thomas.lendacky, jroedel, keescook,
toshi.kani, mathieu.desnoyers, devel, tglx, mchehab,
iamjoonsoo.kim, labbott, tony.luck, alexandre.bounine,
kuleshovmail, linux-kernel, mcgrof, linux-crypto, pbonzin
In-Reply-To: <147190844204.9523.14931918358168729826.stgit@brijesh-build-machine>
On Mon, Aug 22, 2016 at 07:27:22PM -0400, Brijesh Singh wrote:
> The driver to communicate with Secure Encrypted Virtualization (SEV)
> firmware running within the AMD secure processor providing a secure key
> management interface for SEV guests.
>
> Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
> Signed-off-by: Brijesh Singh <brijesh.singh@amd.com>
This driver doesn't seem to hook into the Crypto API at all, is
there any reason why it should be in drivers/crypto?
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
--
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
* [RFC PATCH v1 05/28] KVM: SVM: prepare for new bit definition in nested_ctl
From: Brijesh Singh @ 2016-08-22 23:24 UTC (permalink / raw)
To: simon.guinot, linux-efi, brijesh.singh, kvm, rkrcmar, matt,
linus.walleij, linux-mm, paul.gortmaker, hpa, dan.j.williams,
aarcange, sfr, andriy.shevchenko, herbert, bhe, xemul, joro, x86,
mingo, msalter, ross.zwisler, bp, dyoung, thomas.lendacky,
jroedel, keescook, toshi.kani, mathieu.desnoyers, devel, tglx,
mchehab
In-Reply-To: <147190820782.9523.4967724730957229273.stgit@brijesh-build-machine>
From: Tom Lendacky <thomas.lendacky@amd.com>
Currently the nested_ctl variable in the vmcb_control_area structure is
used to indicate nested paging support. The nested paging support field
is actually defined as bit 0 of the this field. In order to support a new
feature flag the usage of the nested_ctl and nested paging support must
be converted to operate on a single bit.
Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
---
arch/x86/include/asm/svm.h | 2 ++
arch/x86/kvm/svm.c | 7 ++++---
2 files changed, 6 insertions(+), 3 deletions(-)
diff --git a/arch/x86/include/asm/svm.h b/arch/x86/include/asm/svm.h
index 14824fc..2aca535 100644
--- a/arch/x86/include/asm/svm.h
+++ b/arch/x86/include/asm/svm.h
@@ -136,6 +136,8 @@ struct __attribute__ ((__packed__)) vmcb_control_area {
#define SVM_VM_CR_SVM_LOCK_MASK 0x0008ULL
#define SVM_VM_CR_SVM_DIS_MASK 0x0010ULL
+#define SVM_NESTED_CTL_NP_ENABLE BIT(0)
+
struct __attribute__ ((__packed__)) vmcb_seg {
u16 selector;
u16 attrib;
diff --git a/arch/x86/kvm/svm.c b/arch/x86/kvm/svm.c
index 9b2de7c..9b59260 100644
--- a/arch/x86/kvm/svm.c
+++ b/arch/x86/kvm/svm.c
@@ -1177,7 +1177,7 @@ static void init_vmcb(struct vcpu_svm *svm)
if (npt_enabled) {
/* Setup VMCB for Nested Paging */
- control->nested_ctl = 1;
+ control->nested_ctl |= SVM_NESTED_CTL_NP_ENABLE;
clr_intercept(svm, INTERCEPT_INVLPG);
clr_exception_intercept(svm, PF_VECTOR);
clr_cr_intercept(svm, INTERCEPT_CR3_READ);
@@ -2701,7 +2701,8 @@ static bool nested_vmcb_checks(struct vmcb *vmcb)
if (vmcb->control.asid == 0)
return false;
- if (vmcb->control.nested_ctl && !npt_enabled)
+ if ((vmcb->control.nested_ctl & SVM_NESTED_CTL_NP_ENABLE) &&
+ !npt_enabled)
return false;
return true;
@@ -2776,7 +2777,7 @@ static bool nested_svm_vmrun(struct vcpu_svm *svm)
else
svm->vcpu.arch.hflags &= ~HF_HIF_MASK;
- if (nested_vmcb->control.nested_ctl) {
+ if (nested_vmcb->control.nested_ctl & SVM_NESTED_CTL_NP_ENABLE) {
kvm_mmu_unload(&svm->vcpu);
svm->nested.nested_cr3 = nested_vmcb->control.nested_cr3;
nested_svm_init_mmu_context(&svm->vcpu);
^ permalink raw reply related
* [RFC PATCH v1 26/28] KVM: SVM: add KVM_SEV_DEBUG_DECRYPT command
From: Brijesh Singh @ 2016-08-22 23:29 UTC (permalink / raw)
To: simon.guinot, linux-efi, brijesh.singh, kvm, rkrcmar, matt,
linus.walleij, linux-mm, paul.gortmaker, hpa, dan.j.williams,
aarcange, sfr, andriy.shevchenko, herbert, bhe, xemul, joro, x86,
mingo, msalter, ross.zwisler, bp, dyoung, thomas.lendacky,
jroedel, keescook, toshi.kani, mathieu.desnoyers, devel, tglx,
mchehab
In-Reply-To: <147190820782.9523.4967724730957229273.stgit@brijesh-build-machine>
The command decrypts a page of guest memory for debugging purposes.
For more information see [1], section 7.1
[1] http://support.amd.com/TechDocs/55766_SEV-KM%20API_Spec.pdf
Signed-off-by: Brijesh Singh <brijesh.singh@amd.com>
---
arch/x86/kvm/svm.c | 83 ++++++++++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 83 insertions(+)
diff --git a/arch/x86/kvm/svm.c b/arch/x86/kvm/svm.c
index 63e7d15..b383bc7 100644
--- a/arch/x86/kvm/svm.c
+++ b/arch/x86/kvm/svm.c
@@ -5606,6 +5606,84 @@ err_1:
return ret;
}
+static int __sev_dbg_decrypt_page(struct kvm *kvm, unsigned long src,
+ void *dst, int *psp_ret)
+{
+ int ret, pinned;
+ struct page **inpages;
+ struct psp_data_dbg *decrypt;
+
+ decrypt = kzalloc(sizeof(*decrypt), GFP_KERNEL);
+ if (!decrypt)
+ return -ENOMEM;
+
+ ret = -ENOMEM;
+ inpages = kzalloc(1 * sizeof(struct page *), GFP_KERNEL);
+ if (!inpages)
+ goto err_1;
+
+ /* pin the user virtual address */
+ ret = -EFAULT;
+ down_read(¤t->mm->mmap_sem);
+ pinned = get_user_pages(src, 1, 1, 0, inpages, NULL);
+ up_read(¤t->mm->mmap_sem);
+ if (pinned < 0)
+ goto err_2;
+
+ decrypt->hdr.buffer_len = sizeof(*decrypt);
+ decrypt->handle = kvm_sev_handle();
+ decrypt->dst_addr = __pa(dst) | sme_me_mask;
+ decrypt->src_addr = __sev_page_pa(inpages[0]);
+ decrypt->length = PAGE_SIZE;
+
+ ret = psp_dbg_decrypt(decrypt, psp_ret);
+ if (ret)
+ printk(KERN_ERR "SEV: DEBUG_DECRYPT %d (%#010x)\n",
+ ret, *psp_ret);
+ release_pages(inpages, 1, 0);
+err_2:
+ kfree(inpages);
+err_1:
+ kfree(decrypt);
+ return ret;
+}
+
+static int sev_dbg_decrypt(struct kvm *kvm,
+ struct kvm_sev_dbg_decrypt __user *argp,
+ int *psp_ret)
+{
+ void *data;
+ int ret, offset, len;
+ struct kvm_sev_dbg_decrypt debug;
+
+ if (!kvm_sev_guest())
+ return -ENOTTY;
+
+ if (copy_from_user(&debug, argp, sizeof(*argp)))
+ return -EFAULT;
+
+ if (debug.length > PAGE_SIZE)
+ return -EINVAL;
+
+ data = (void *) get_zeroed_page(GFP_KERNEL);
+ if (!data)
+ return -ENOMEM;
+
+ /* decrypt one page */
+ ret = __sev_dbg_decrypt_page(kvm, debug.src_addr, data, psp_ret);
+ if (ret)
+ goto err_1;
+
+ /* we have decrypted full page but copy request length */
+ offset = debug.src_addr & (PAGE_SIZE - 1);
+ len = min_t(size_t, (PAGE_SIZE - offset), debug.length);
+ if (copy_to_user((uint8_t *)debug.dst_addr, data + offset, len))
+ ret = -EFAULT;
+err_1:
+ free_page((unsigned long)data);
+ return ret;
+}
+
static int amd_sev_issue_cmd(struct kvm *kvm,
struct kvm_sev_issue_cmd __user *user_data)
{
@@ -5636,6 +5714,11 @@ static int amd_sev_issue_cmd(struct kvm *kvm,
&arg.ret_code);
break;
}
+ case KVM_SEV_DBG_DECRYPT: {
+ r = sev_dbg_decrypt(kvm, (void *)arg.opaque,
+ &arg.ret_code);
+ break;
+ }
default:
break;
}
^ permalink raw reply related
* [RFC PATCH v1 19/28] KVM: SVM: prepare to reserve asid for SEV guest
From: Brijesh Singh @ 2016-08-22 23:27 UTC (permalink / raw)
To: simon.guinot, linux-efi, brijesh.singh, kvm, rkrcmar, matt,
linus.walleij, linux-mm, paul.gortmaker, hpa, dan.j.williams,
aarcange, sfr, andriy.shevchenko, herbert, bhe, xemul, joro, x86,
mingo, msalter, ross.zwisler, bp, dyoung, thomas.lendacky,
jroedel, keescook, toshi.kani, mathieu.desnoyers, devel, tglx,
mchehab
In-Reply-To: <147190820782.9523.4967724730957229273.stgit@brijesh-build-machine>
In current implementation, asid allocation starts from 1, this patch
adds a min_asid variable in svm_vcpu structure to allow starting asid
from something other than 1.
Signed-off-by: Brijesh Singh <brijesh.singh@amd.com>
---
arch/x86/kvm/svm.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/arch/x86/kvm/svm.c b/arch/x86/kvm/svm.c
index 211be94..f010b23 100644
--- a/arch/x86/kvm/svm.c
+++ b/arch/x86/kvm/svm.c
@@ -470,6 +470,7 @@ struct svm_cpu_data {
u64 asid_generation;
u32 max_asid;
u32 next_asid;
+ u32 min_asid;
struct kvm_ldttss_desc *tss_desc;
struct page *save_area;
@@ -726,6 +727,7 @@ static int svm_hardware_enable(void)
sd->asid_generation = 1;
sd->max_asid = cpuid_ebx(SVM_CPUID_FUNC) - 1;
sd->next_asid = sd->max_asid + 1;
+ sd->min_asid = 1;
native_store_gdt(&gdt_descr);
gdt = (struct desc_struct *)gdt_descr.address;
@@ -1887,7 +1889,7 @@ static void new_asid(struct vcpu_svm *svm, struct svm_cpu_data *sd)
{
if (sd->next_asid > sd->max_asid) {
++sd->asid_generation;
- sd->next_asid = 1;
+ sd->next_asid = sd->min_asid;
svm->vmcb->control.tlb_ctl = TLB_CONTROL_FLUSH_ALL_ASID;
}
^ permalink raw reply related
* [RFC PATCH v1 20/28] KVM: SVM: prepare for SEV guest management API support
From: Brijesh Singh @ 2016-08-22 23:28 UTC (permalink / raw)
To: simon.guinot, linux-efi, brijesh.singh, kvm, rkrcmar, matt,
linus.walleij, linux-mm, paul.gortmaker, hpa, dan.j.williams,
aarcange, sfr, andriy.shevchenko, herbert, bhe, xemul, joro, x86,
mingo, msalter, ross.zwisler, bp, dyoung, thomas.lendacky,
jroedel, keescook, toshi.kani, mathieu.desnoyers, devel, tglx,
mchehab
In-Reply-To: <147190820782.9523.4967724730957229273.stgit@brijesh-build-machine>
The patch adds initial support required for Secure Encrypted
Virtualization (SEV) guest management API's.
ASID management:
- Reserve asid range for SEV guest, SEV asid range is obtained
through CPUID Fn8000_001f[ECX]. A non-SEV guest can use any
asid outside the SEV asid range.
- SEV guest must have asid value within asid range obtained
through CPUID.
- SEV guest must have the same asid for all vcpu's. A TLB flush
is required if different vcpu for the same ASID is to be run
on the same host CPU.
- save SEV private structure in kvm_arch.
- If SEV is available then initialize PSP firmware during hardware probe
Signed-off-by: Brijesh Singh <brijesh.singh@amd.com>
---
arch/x86/include/asm/kvm_host.h | 9 ++
arch/x86/kvm/svm.c | 213 +++++++++++++++++++++++++++++++++++++++
2 files changed, 221 insertions(+), 1 deletion(-)
diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_host.h
index b1dd673..9b885fc 100644
--- a/arch/x86/include/asm/kvm_host.h
+++ b/arch/x86/include/asm/kvm_host.h
@@ -715,6 +715,12 @@ struct kvm_hv {
u64 hv_crash_ctl;
};
+struct kvm_sev_info {
+ unsigned int asid; /* asid for this guest */
+ unsigned int handle; /* firmware handle */
+ unsigned int ref_count; /* number of active vcpus */
+};
+
struct kvm_arch {
unsigned int n_used_mmu_pages;
unsigned int n_requested_mmu_pages;
@@ -799,6 +805,9 @@ struct kvm_arch {
bool x2apic_format;
bool x2apic_broadcast_quirk_disabled;
+
+ /* struct for SEV guest */
+ struct kvm_sev_info sev_info;
};
struct kvm_vm_stat {
diff --git a/arch/x86/kvm/svm.c b/arch/x86/kvm/svm.c
index f010b23..dcee635 100644
--- a/arch/x86/kvm/svm.c
+++ b/arch/x86/kvm/svm.c
@@ -34,6 +34,7 @@
#include <linux/sched.h>
#include <linux/trace_events.h>
#include <linux/slab.h>
+#include <linux/ccp-psp.h>
#include <asm/apic.h>
#include <asm/perf_event.h>
@@ -186,6 +187,9 @@ struct vcpu_svm {
struct page *avic_backing_page;
u64 *avic_physical_id_cache;
bool avic_is_running;
+
+ /* which host cpu was used for running this vcpu */
+ bool last_cpuid;
};
#define AVIC_LOGICAL_ID_ENTRY_GUEST_PHYSICAL_ID_MASK (0xFF)
@@ -243,6 +247,25 @@ static int avic;
module_param(avic, int, S_IRUGO);
#endif
+/* Secure Encrypted Virtualization */
+static bool sev_enabled;
+static unsigned long max_sev_asid;
+static unsigned long *sev_asid_bitmap;
+
+#define kvm_sev_guest() (kvm->arch.sev_info.handle)
+#define kvm_sev_handle() (kvm->arch.sev_info.handle)
+#define kvm_sev_ref() (kvm->arch.sev_info.ref_count++)
+#define kvm_sev_unref() (kvm->arch.sev_info.ref_count--)
+#define svm_sev_handle() (svm->vcpu.kvm->arch.sev_info.handle)
+#define svm_sev_asid() (svm->vcpu.kvm->arch.sev_info.asid)
+#define svm_sev_ref() (svm->vcpu.kvm->arch.sev_info.ref_count++)
+#define svm_sev_unref() (svm->vcpu.kvm->arch.sev_info.ref_count--)
+#define svm_sev_guest() (svm->vcpu.kvm->arch.sev_info.handle)
+#define svm_sev_ref_count() (svm->vcpu.kvm->arch.sev_info.ref_count)
+
+static int sev_asid_new(void);
+static void sev_asid_free(int asid);
+
static void svm_set_cr0(struct kvm_vcpu *vcpu, unsigned long cr0);
static void svm_flush_tlb(struct kvm_vcpu *vcpu);
static void svm_complete_interrupts(struct vcpu_svm *svm);
@@ -474,6 +497,8 @@ struct svm_cpu_data {
struct kvm_ldttss_desc *tss_desc;
struct page *save_area;
+
+ void **sev_vmcb; /* index = sev_asid, value = vmcb pointer */
};
static DEFINE_PER_CPU(struct svm_cpu_data *, svm_data);
@@ -727,7 +752,10 @@ static int svm_hardware_enable(void)
sd->asid_generation = 1;
sd->max_asid = cpuid_ebx(SVM_CPUID_FUNC) - 1;
sd->next_asid = sd->max_asid + 1;
- sd->min_asid = 1;
+ sd->min_asid = max_sev_asid + 1;
+
+ if (sev_enabled)
+ memset(sd->sev_vmcb, 0, (max_sev_asid + 1) * sizeof(void *));
native_store_gdt(&gdt_descr);
gdt = (struct desc_struct *)gdt_descr.address;
@@ -788,6 +816,7 @@ static void svm_cpu_uninit(int cpu)
per_cpu(svm_data, raw_smp_processor_id()) = NULL;
__free_page(sd->save_area);
+ kfree(sd->sev_vmcb);
kfree(sd);
}
@@ -805,6 +834,14 @@ static int svm_cpu_init(int cpu)
if (!sd->save_area)
goto err_1;
+ if (sev_enabled) {
+ sd->sev_vmcb = kmalloc((max_sev_asid + 1) * sizeof(void *),
+ GFP_KERNEL);
+ r = -ENOMEM;
+ if (!sd->sev_vmcb)
+ goto err_1;
+ }
+
per_cpu(svm_data, cpu) = sd;
return 0;
@@ -931,6 +968,74 @@ static void svm_disable_lbrv(struct vcpu_svm *svm)
set_msr_interception(msrpm, MSR_IA32_LASTINTTOIP, 0, 0);
}
+static __init void sev_hardware_setup(void)
+{
+ int ret, psp_ret;
+ struct psp_data_init *init;
+ struct psp_data_status *status;
+
+ /*
+ * Check SEV Feature Support: Fn8001_001F[EAX]
+ * Bit 1: Secure Memory Virtualization supported
+ */
+ if (!(cpuid_eax(0x8000001F) & 0x2))
+ return;
+
+ /*
+ * Get maximum number of encrypted guest supported: Fn8001_001F[ECX]
+ * Bit 31:0: Number of supported guest
+ */
+ max_sev_asid = cpuid_ecx(0x8000001F);
+ if (!max_sev_asid)
+ return;
+
+ init = kzalloc(sizeof(*init), GFP_KERNEL);
+ if (!init)
+ return;
+
+ status = kzalloc(sizeof(*status), GFP_KERNEL);
+ if (!status)
+ goto err_1;
+
+ /* Initialize PSP firmware */
+ init->hdr.buffer_len = sizeof(*init);
+ init->flags = 0;
+ ret = psp_platform_init(init, &psp_ret);
+ if (ret) {
+ printk(KERN_ERR "SEV: PSP_INIT ret=%d (%#x)\n", ret, psp_ret);
+ goto err_2;
+ }
+
+ /* Initialize SEV ASID bitmap */
+ sev_asid_bitmap = kmalloc(max(sizeof(unsigned long),
+ max_sev_asid/8 + 1), GFP_KERNEL);
+ if (IS_ERR(sev_asid_bitmap)) {
+ psp_platform_shutdown(&psp_ret);
+ goto err_2;
+ }
+ bitmap_zero(sev_asid_bitmap, max_sev_asid);
+ set_bit(0, sev_asid_bitmap); /* mark ASID 0 as used */
+
+ sev_enabled = 1;
+ printk(KERN_INFO "kvm: SEV enabled\n");
+
+ /* Query the platform status and print API version */
+ status->hdr.buffer_len = sizeof(*status);
+ ret = psp_platform_status(status, &psp_ret);
+ if (ret) {
+ printk(KERN_ERR "SEV: PLATFORM_STATUS ret=%#x\n", psp_ret);
+ goto err_2;
+ }
+
+ printk(KERN_INFO "SEV API: %d.%d\n",
+ status->api_major, status->api_minor);
+err_2:
+ kfree(status);
+err_1:
+ kfree(init);
+ return;
+}
+
static __init int svm_hardware_setup(void)
{
int cpu;
@@ -966,6 +1071,8 @@ static __init int svm_hardware_setup(void)
kvm_enable_efer_bits(EFER_SVME | EFER_LMSLE);
}
+ sev_hardware_setup();
+
for_each_possible_cpu(cpu) {
r = svm_cpu_init(cpu);
if (r)
@@ -1003,10 +1110,25 @@ err:
return r;
}
+static __exit void sev_hardware_unsetup(void)
+{
+ int ret, psp_ret;
+
+ ret = psp_platform_shutdown(&psp_ret);
+ if (ret)
+ printk(KERN_ERR "failed to shutdown PSP rc=%d (%#0x10x)\n",
+ ret, psp_ret);
+
+ kfree(sev_asid_bitmap);
+}
+
static __exit void svm_hardware_unsetup(void)
{
int cpu;
+ if (sev_enabled)
+ sev_hardware_unsetup();
+
for_each_possible_cpu(cpu)
svm_cpu_uninit(cpu);
@@ -1088,6 +1210,11 @@ static void avic_init_vmcb(struct vcpu_svm *svm)
svm->vcpu.arch.apicv_active = true;
}
+static void sev_init_vmcb(struct vcpu_svm *svm)
+{
+ svm->vmcb->control.nested_ctl |= SVM_NESTED_CTL_SEV_ENABLE;
+}
+
static void init_vmcb(struct vcpu_svm *svm)
{
struct vmcb_control_area *control = &svm->vmcb->control;
@@ -1202,6 +1329,10 @@ static void init_vmcb(struct vcpu_svm *svm)
if (avic)
avic_init_vmcb(svm);
+ if (svm_sev_guest())
+ sev_init_vmcb(svm);
+
+
mark_all_dirty(svm->vmcb);
enable_gif(svm);
@@ -1413,6 +1544,14 @@ static void svm_vcpu_reset(struct kvm_vcpu *vcpu, bool init_event)
avic_update_vapic_bar(svm, APIC_DEFAULT_PHYS_BASE);
}
+static void sev_init_vcpu(struct vcpu_svm *svm)
+{
+ if (!svm_sev_guest())
+ return;
+
+ svm_sev_ref();
+}
+
static struct kvm_vcpu *svm_create_vcpu(struct kvm *kvm, unsigned int id)
{
struct vcpu_svm *svm;
@@ -1475,6 +1614,7 @@ static struct kvm_vcpu *svm_create_vcpu(struct kvm *kvm, unsigned int id)
init_vmcb(svm);
svm_init_osvw(&svm->vcpu);
+ sev_init_vcpu(svm);
return &svm->vcpu;
@@ -1494,6 +1634,23 @@ out:
return ERR_PTR(err);
}
+static void sev_uninit_vcpu(struct vcpu_svm *svm)
+{
+ int cpu;
+ int asid = svm_sev_asid();
+ struct svm_cpu_data *sd;
+
+ if (!svm_sev_guest())
+ return;
+
+ svm_sev_unref();
+
+ for_each_possible_cpu(cpu) {
+ sd = per_cpu(svm_data, cpu);
+ sd->sev_vmcb[asid] = NULL;
+ }
+}
+
static void svm_free_vcpu(struct kvm_vcpu *vcpu)
{
struct vcpu_svm *svm = to_svm(vcpu);
@@ -1502,6 +1659,7 @@ static void svm_free_vcpu(struct kvm_vcpu *vcpu)
__free_pages(virt_to_page(svm->msrpm), MSRPM_ALLOC_ORDER);
__free_page(virt_to_page(svm->nested.hsave));
__free_pages(virt_to_page(svm->nested.msrpm), MSRPM_ALLOC_ORDER);
+ sev_uninit_vcpu(svm);
kvm_vcpu_uninit(vcpu);
kmem_cache_free(kvm_vcpu_cache, svm);
}
@@ -1945,6 +2103,11 @@ static int pf_interception(struct vcpu_svm *svm)
default:
error_code = svm->vmcb->control.exit_info_1;
+ /* In SEV mode, the guest physical address will have C-bit
+ * set. C-bit must be cleared before handling the fault.
+ */
+ if (svm_sev_guest())
+ fault_address &= ~sme_me_mask;
trace_kvm_page_fault(fault_address, error_code);
if (!npt_enabled && kvm_event_needs_reinjection(&svm->vcpu))
kvm_mmu_unprotect_page_virt(&svm->vcpu, fault_address);
@@ -4131,12 +4294,40 @@ static void reload_tss(struct kvm_vcpu *vcpu)
load_TR_desc();
}
+static void pre_sev_run(struct vcpu_svm *svm)
+{
+ int asid = svm_sev_asid();
+ int cpu = raw_smp_processor_id();
+ struct svm_cpu_data *sd = per_cpu(svm_data, cpu);
+
+ /* Assign the asid allocated for this SEV guest */
+ svm->vmcb->control.asid = svm_sev_asid();
+
+ /* Flush guest TLB:
+ * - when different VMCB for the same ASID is to be run on the
+ * same host CPU
+ * or
+ * - this VMCB was executed on different host cpu in previous VMRUNs.
+ */
+ if (sd->sev_vmcb[asid] != (void *)svm->vmcb ||
+ svm->last_cpuid != cpu)
+ svm->vmcb->control.tlb_ctl = TLB_CONTROL_FLUSH_ALL_ASID;
+
+ svm->last_cpuid = cpu;
+ sd->sev_vmcb[asid] = (void *)svm->vmcb;
+
+ mark_dirty(svm->vmcb, VMCB_ASID);
+}
+
static void pre_svm_run(struct vcpu_svm *svm)
{
int cpu = raw_smp_processor_id();
struct svm_cpu_data *sd = per_cpu(svm_data, cpu);
+ if (svm_sev_guest())
+ return pre_sev_run(svm);
+
/* FIXME: handle wraparound of asid_generation */
if (svm->asid_generation != sd->asid_generation)
new_asid(svm, sd);
@@ -4985,6 +5176,26 @@ static inline void avic_post_state_restore(struct kvm_vcpu *vcpu)
avic_handle_ldr_update(vcpu);
}
+static int sev_asid_new(void)
+{
+ int pos;
+
+ if (!sev_enabled)
+ return -ENOTTY;
+
+ pos = find_first_zero_bit(sev_asid_bitmap, max_sev_asid);
+ if (pos >= max_sev_asid)
+ return -EBUSY;
+
+ set_bit(pos, sev_asid_bitmap);
+ return pos;
+}
+
+static void sev_asid_free(int asid)
+{
+ clear_bit(asid, sev_asid_bitmap);
+}
+
static struct kvm_x86_ops svm_x86_ops __ro_after_init = {
.cpu_has_kvm_support = has_svm,
.disabled_by_bios = is_disabled,
^ 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