Linux cryptographic layer development
 help / color / mirror / Atom feed
* Re: [PATCH v2 2/2] HWRNG: thunderx: Add Cavium HWRNG driver for ThunderX SoC.
From: David Daney @ 2016-08-24 23:07 UTC (permalink / raw)
  To: Corentin LABBE
  Cc: Omer Khaliq, linux-kernel, linux-pci, linux-crypto,
	linux-arm-kernel, bhelgaas, mpm, herbert, Ananth.Jasty,
	David.Daney
In-Reply-To: <874d0bce-cf9b-8772-5af4-ec3844b3b255@gmail.com>

On 08/23/2016 10:46 PM, Corentin LABBE wrote:
> 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

If you look at the implementation of readsq(), you will see that it is a 
similar loop.  Since the overhead is primarily I/O latency from the RNG 
hardware, the throughput cannot really be changed with micro 
optimizations to this simple loop.

Also, on big-endian kernels, it appears that a loop of readq() and 
readsq() will give different results as readq will byte swap the result 
and readsq does not.  Since this is a RNG, the byte swapping is not 
important, but it is a difference.

Because of this, I think it should be acceptable to stick with the loop 
we currently have.

If the hwrng maintainers want to change the loop, to a readsq(), we 
might investigate this more.

Thanks,
David Daney

^ permalink raw reply

* Re: crypto: mxs-dcp: do not call blocking ops when !TASK_RUNNING; state=1
From: Fabio Estevam @ 2016-08-24 22:52 UTC (permalink / raw)
  To: Stefan Wahren; +Cc: Herbert Xu, linux-crypto, Fabio Estevam, Marek Vašut
In-Reply-To: <140047983.403523.225ddbfe-fd96-4f9b-a2b9-e0173af882ba.open-xchange@email.1und1.de>

Hi Stefan,

On Tue, Aug 23, 2016 at 5:38 PM, Stefan Wahren <stefan.wahren@i2se.com> wrote:
> 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

Did you select any debug option to observe such messages?

The kernelci boot log does not show this problem on a imx23-olinuxino
running linux-next:
https://storage.kernelci.org/next/next-20160824/arm-mxs_defconfig/lab-pengutronix/boot-imx23-olinuxino.html

We still have the errors below:

[    4.400000] mxs-dcp 80028000.dcp: Failed to register sha1 hash!
[    4.410000] mxs-dcp: probe of 80028000.dcp failed with error -22

,but that's a different issue.

Regards,

Fabio Estevam

^ permalink raw reply

* Re: [PATCH v2 1/2] PCI: quirk fixup for cavium invalid sriov link value.
From: Bjorn Helgaas @ 2016-08-24 16:47 UTC (permalink / raw)
  To: Omer Khaliq
  Cc: linux-kernel, linux-pci, linux-crypto, linux-arm-kernel, bhelgaas,
	mpm, herbert, Ananth.Jasty, David.Daney, clabbe.montjoie
In-Reply-To: <1471994835-2423-2-git-send-email-okhaliq@caviumnetworks.com>

On Tue, Aug 23, 2016 at 04:27:14PM -0700, Omer Khaliq wrote:
> 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>

Acked-by: Bjorn Helgaas <bhelgaas@google.com>

If you update this patch for any reason, please update the subject
like this:

  -PCI: quirk fixup for cavium invalid sriov link value.
  +PCI: Fix incorrect Cavium cn8xx SR-IOV Function Dependency Link

This will make "git log --oneline drivers/pci/quirks.c" show more
useful information and look more consistent.

I assume somebody else will merge this patch along with your HWRNG
driver.

> ---
>  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
> 
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply

* Re: [PATCH -next] chcr: Fix non static symbol warning
From: Wei Yongjun @ 2016-08-24 14:50 UTC (permalink / raw)
  To: Herbert Xu
  Cc: David S. Miller, Hariprasad Shenai, Atul Gupta, Wei Yongjun,
	linux-crypto
In-Reply-To: <20160824130651.GB2120@gondor.apana.org.au>

Hi Herbert,

On 08/24/2016 09:06 PM, Herbert Xu wrote:
> On Mon, Aug 22, 2016 at 04:11:18PM +0000, Wei Yongjun wrote:
>> From: Wei Yongjun <weiyongjun1@huawei.com>
>>
>> Fixes the following sparse warning:
>>
>> drivers/crypto/chelsio/chcr_algo.c:593:5: warning:
>>  symbol 'cxgb4_is_crypto_q_full' was not declared. Should it be static?
>>
>> Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com>
> Please repost this to netdev as the chelsio patches were applied
> in the net tree.

This file only exists in net-next, not in netdev.
http://git.kernel.org/cgit/linux/kernel/git/davem/net.git/tree/drivers/crypto/chelsio/chcr_algo.c
show not found.

Regards,
Wei Yongjun

^ permalink raw reply

* Re: [PATCH] crypto: FIPS - allow RSA keys >= 2048 bits
From: Herbert Xu @ 2016-08-24 13:18 UTC (permalink / raw)
  To: Stephan Mueller; +Cc: linux-crypto
In-Reply-To: <3300015.Y5nlQbUkhj@positron.chronox.de>

On Tue, Aug 23, 2016 at 10:09:32AM +0200, Stephan Mueller wrote:
> 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>

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 -next] chcr: Fix non static symbol warning
From: Herbert Xu @ 2016-08-24 13:06 UTC (permalink / raw)
  To: Wei Yongjun
  Cc: David S. Miller, Hariprasad Shenai, Atul Gupta, Wei Yongjun,
	linux-crypto
In-Reply-To: <1471882278-25777-1-git-send-email-weiyj.lk@gmail.com>

On Mon, Aug 22, 2016 at 04:11:18PM +0000, Wei Yongjun wrote:
> From: Wei Yongjun <weiyongjun1@huawei.com>
> 
> Fixes the following sparse warning:
> 
> drivers/crypto/chelsio/chcr_algo.c:593:5: warning:
>  symbol 'cxgb4_is_crypto_q_full' was not declared. Should it be static?
> 
> Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com>

Please repost this to netdev as the chelsio patches were applied
in the net tree.

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 3/5] hwrng: amd: Be consitent with the driver name
From: LABBE Corentin @ 2016-08-24 13:51 UTC (permalink / raw)
  To: Herbert Xu; +Cc: mpm, linux-crypto, linux-kernel
In-Reply-To: <20160824105811.GA2120@gondor.apana.org.au>

On Wed, Aug 24, 2016 at 06:58:11PM +0800, Herbert Xu wrote:
> 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.
> 

amd is really really too generic.

But if you still NACK that (and I understand perfectly why), I will update my series.

Regards

^ permalink raw reply

* Re: [PATCH] crypto: rockchip - use devm_add_action_or_reset()
From: Herbert Xu @ 2016-08-24 13:19 UTC (permalink / raw)
  To: Sudip Mukherjee
  Cc: Heiko Stuebner, linux-kernel-u79uwXL29TY76Z2rM5mHXA,
	linux-rockchip-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
	linux-crypto-u79uwXL29TY76Z2rM5mHXA, David S. Miller,
	linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <1471964334-27060-1-git-send-email-sudipm.mukherjee-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>

On Tue, Aug 23, 2016 at 08:28:54PM +0530, Sudip Mukherjee wrote:
> 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>

Patch applied.  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: [PATCH] crypto: mxc-scc - check clk_prepare_enable() error
From: Herbert Xu @ 2016-08-24 13:18 UTC (permalink / raw)
  To: Fabio Estevam; +Cc: s.trumtrar, linux-crypto, Fabio Estevam
In-Reply-To: <1471833447-11446-1-git-send-email-festevam@gmail.com>

On Sun, Aug 21, 2016 at 11:37:27PM -0300, Fabio Estevam wrote:
> From: Fabio Estevam <fabio.estevam@nxp.com>
> 
> clk_prepare_enable() may fail, so we should better check its return
> value and propagate it in the case of failure.
> 
> Signed-off-by: Fabio Estevam <fabio.estevam@nxp.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] hw_random: omap3-rom-rng.c: Remove obsoleted functions
From: Herbert Xu @ 2016-08-24 13:17 UTC (permalink / raw)
  To: PrasannaKumar Muralidharan; +Cc: linux-crypto, aaro.koskinen, mpm, linux-kernel
In-Reply-To: <1471708866-1423-1-git-send-email-prasannatsmkumar@gmail.com>

On Sat, Aug 20, 2016 at 09:31:06PM +0530, PrasannaKumar Muralidharan wrote:
> Remove omap3_rom_rng_data_present method as it was returning 1 always.
> Use .read callback instead of .data_read callback. This avoids use of
> obsolete callbacks.
> 
> This patch is not tested with hardware as I don't have access to it.
> 
> Signed-off-by: PrasannaKumar Muralidharan <prasannatsmkumar@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/xor: skip speed test if the xor function is selected automatically
From: Herbert Xu @ 2016-08-24 13:17 UTC (permalink / raw)
  To: Martin Schwidefsky; +Cc: davem, linux-crypto, schwidefsky
In-Reply-To: <1471609170-18816-1-git-send-email-schwidefsky@de.ibm.com>

Martin Schwidefsky <schwidefsky@de.ibm.com> wrote:
> If the architecture selected the xor function with XOR_SELECT_TEMPLATE
> the speed result of the do_xor_speed benchmark is of limited value.
> The speed measurement increases the bootup time a little, which can
> makes a difference for kernels used in container like virtual machines.
> 
> Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.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 -next] crypto: drbg - fix error return code
From: Herbert Xu @ 2016-08-24 13:15 UTC (permalink / raw)
  To: Wei Yongjun; +Cc: Stephan Mueller, linux-crypto
In-Reply-To: <1471705611-19309-1-git-send-email-weiyj.lk@gmail.com>

On Sat, Aug 20, 2016 at 03:06:51PM +0000, Wei Yongjun wrote:
> Fix to return a negative error code from the error handling
> case instead of 0.
> 
> 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 -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


This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox