Linux cryptographic layer development
 help / color / mirror / Atom feed
* Re: [PATCH v2 0/8] Conversion crypto API documentation to Sphinx
From: Herbert Xu @ 2016-10-25  2:35 UTC (permalink / raw)
  To: Stephan Mueller; +Cc: Jonathan Corbet, linux-crypto, linux-doc
In-Reply-To: <1645861.DSRXbPG5tl@positron.chronox.de>

On Sun, Oct 23, 2016 at 06:46:12PM +0200, Stephan Mueller wrote:
> Am Sonntag, 23. Oktober 2016, 10:32:38 CEST schrieb Jonathan Corbet:
> 
> Hi Jonathan,
> 
> > On Fri, 21 Oct 2016 04:53:45 +0200
> > 
> > Stephan Mueller <smueller@chronox.de> wrote:
> > > the attached patch set converts the existing crypto API documentation
> > > from DocBook to Sphinx.
> > 
> > This looks generally good to me - thanks for doing it!
> > 
> > Is there any chance of running the Documentation/ parts through the docs
> > tree?  Documentation/index.rst has become a bit of a conflict point
> > otherwise...
> 
> Unless Herbert objects, I would not see any reason why we should not push it 
> through the docs tree.

No objections from me.

> Yet we should wait for Herbert's ack as I have added also new information in 
> the patch set (the KPP API documentation and the change in the AEAD 
> documentation).

Looks good to me.

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: Move RSA+MPI constructs into an #include file
From: Herbert Xu @ 2016-10-25  2:48 UTC (permalink / raw)
  To: Gary R Hook; +Cc: linux-crypto, thomas.lendacky, davem
In-Reply-To: <20161014193559.4342.74036.stgit@taos>

On Fri, Oct 14, 2016 at 02:36:00PM -0500, Gary R Hook wrote:
> Move RSA support of general use into internal/rsa.h.
> This allows reuse of, e.g. RSA MPI keys and support
> functions.
> 
> Signed-off-by: Gary R Hook <gary.hook@amd.com>

Please fold this patch into the series that makes use of it.

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] padata: Remove unused but set variables
From: Herbert Xu @ 2016-10-25  3:38 UTC (permalink / raw)
  To: Steffen Klassert; +Cc: tklauser, linux-crypto, linux-kernel
In-Reply-To: <20161021090047.GO19080@gauss.secunet.com>

Steffen Klassert <steffen.klassert@secunet.com> wrote:
> On Mon, Oct 17, 2016 at 12:16:08PM +0200, Tobias Klauser wrote:
>> Remove the unused but set variable pinst in padata_parallel_worker to
>> fix the following warning when building with 'W=1':
>> 
>>   kernel/padata.c: In function ‘padata_parallel_worker’:
>>   kernel/padata.c:68:26: warning: variable ‘pinst’ set but not used [-Wunused-but-set-variable]
>> 
>> Also remove the now unused variable pd which is only used to set pinst.
>> 
>> Signed-off-by: Tobias Klauser <tklauser@distanz.ch>
> 
> Acked-by: Steffen Klassert <steffen.klassert@secunet.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: [RESEND][PATCH] crypto: caam: add support for iMX6UL
From: Herbert Xu @ 2016-10-25  3:39 UTC (permalink / raw)
  To: Marcus Folkesson
  Cc: David S . Miller, Rob Herring, Mark Rutland, Horia Geanta,
	Arnd Bergmann, Alex Porosanu, Srinivas Kandagatla, Baoyou Xie,
	Russell King, linux-crypto-u79uwXL29TY76Z2rM5mHXA,
	devicetree-u79uwXL29TY76Z2rM5mHXA,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1476703680-22676-1-git-send-email-marcus.folkesson-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>

On Mon, Oct 17, 2016 at 01:28:00PM +0200, Marcus Folkesson wrote:
> i.MX6UL does only require three clocks to enable CAAM module.
> 
> Signed-off-by: Marcus Folkesson <marcus.folkesson-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
> Reviewed-by: Horia Geantă <horia.geanta-3arQi8VN3Tc@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
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply

* Re: [PATCH -next] crypto: ccp - Fix non static symbol warning
From: Herbert Xu @ 2016-10-25  3:39 UTC (permalink / raw)
  To: Wei Yongjun; +Cc: Tom Lendacky, Gary Hook, Wei Yongjun, linux-crypto
In-Reply-To: <1476716930-9831-1-git-send-email-weiyj.lk@gmail.com>

On Mon, Oct 17, 2016 at 03:08:50PM +0000, Wei Yongjun wrote:
> From: Wei Yongjun <weiyongjun1@huawei.com>
> 
> Fixes the following sparse warning:
> 
> drivers/crypto/ccp/ccp-dev.c:44:6: warning:
>  symbol 'ccp_error_codes' was not declared. Should it be static?
> 
> Signed-off-by: Wei Yongjun <weiyongjun1@huawei.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: gcm - Fix error return code in crypto_gcm_create_common()
From: Herbert Xu @ 2016-10-25  3:39 UTC (permalink / raw)
  To: Wei Yongjun; +Cc: Wei Yongjun, linux-crypto
In-Reply-To: <1476717006-10086-1-git-send-email-weiyj.lk@gmail.com>

On Mon, Oct 17, 2016 at 03:10:06PM +0000, Wei Yongjun wrote:
> From: Wei Yongjun <weiyongjun1@huawei.com>
> 
> Fix to return error code -EINVAL from the invalid alg ivsize error
> handling case instead of 0, as done elsewhere in this function.
> 
> Signed-off-by: Wei Yongjun <weiyongjun1@huawei.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: ccp - change bitfield type to unsigned ints
From: Herbert Xu @ 2016-10-25  3:40 UTC (permalink / raw)
  To: Gary R Hook; +Cc: linux-crypto, thomas.lendacky, davem
In-Reply-To: <147682971521.8147.5364792807816963275.stgit@taos.amd.com>

On Tue, Oct 18, 2016 at 05:28:35PM -0500, Gary R Hook wrote:
> Bit fields are not sensitive to endianness, so use
> a transparent standard data type
> 
> Signed-off-by: Gary R Hook <gary.hook@amd.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] hwrng: meson: Fix module autoload for OF registration
From: Herbert Xu @ 2016-10-25  3:40 UTC (permalink / raw)
  To: Javier Martinez Canillas
  Cc: linux-kernel, Jason Gunthorpe, Kevin Hilman, Neil Armstrong,
	PrasannaKumar Muralidharan, Carlo Caione, linux-amlogic,
	Matt Mackall, linux-arm-kernel, linux-crypto
In-Reply-To: <1476733877-20275-1-git-send-email-javier@osg.samsung.com>

On Mon, Oct 17, 2016 at 04:51:17PM -0300, Javier Martinez Canillas wrote:
> If the driver is built as a module, autoload won't work because the module
> alias information is not filled. So user-space can't match the registered
> device with the corresponding module.
> 
> Export the module alias information using the MODULE_DEVICE_TABLE() macro.
> 
> Before this patch:
> 
> $ modinfo drivers/char/hw_random/meson-rng.ko | grep alias
> alias:          platform:meson-rng
> 
> After this patch:
> 
> $ modinfo drivers/char/hw_random/meson-rng.ko | grep alias
> alias:          platform:meson-rng
> alias:          of:N*T*Camlogic,meson-rngC*
> alias:          of:N*T*Camlogic,meson-rng
> 
> Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.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: ccp - remove unneeded code
From: Herbert Xu @ 2016-10-25  3:42 UTC (permalink / raw)
  To: Gary R Hook; +Cc: linux-crypto, thomas.lendacky, davem
In-Reply-To: <147682972966.8169.12625496646634682202.stgit@taos.amd.com>

On Tue, Oct 18, 2016 at 05:28:49PM -0500, Gary R Hook wrote:
> Clean up patch for an unneeded structure member.
> 
> Signed-off-by: Gary R Hook <gary.hook@amd.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: ccp - Clean up the LSB slot allocation code
From: Herbert Xu @ 2016-10-25  3:43 UTC (permalink / raw)
  To: Gary R Hook; +Cc: linux-crypto, thomas.lendacky, davem
In-Reply-To: <147683001790.8273.9550490485955104780.stgit@taos.amd.com>

On Tue, Oct 18, 2016 at 05:33:37PM -0500, Gary R Hook wrote:
> Fix a few problems revealed by testing: verify consistent
> units, especially in public slot allocation. Percolate
> some common initialization code up to a common routine.
> Add some comments.
> 
> Signed-off-by: Gary R Hook <gary.hook@amd.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: engine - Handle the kthread worker using the new API
From: Herbert Xu @ 2016-10-25  3:43 UTC (permalink / raw)
  To: Petr Mladek; +Cc: David S. Miller, linux-crypto, Tejun Heo, linux-kernel
In-Reply-To: <1476878070-12024-1-git-send-email-pmladek@suse.com>

On Wed, Oct 19, 2016 at 01:54:30PM +0200, Petr Mladek wrote:
> Use the new API to create and destroy the crypto engine kthread
> worker. The API hides some implementation details.
> 
> In particular, kthread_create_worker() allocates and initializes
> struct kthread_worker. It runs the kthread the right way
> and stores task_struct into the worker structure.
> 
> kthread_destroy_worker() flushes all pending works, stops
> the kthread and frees the structure.
> 
> This patch does not change the existing behavior except for
> dynamically allocating struct kthread_worker and storing
> only the pointer of this structure.
> 
> It is compile tested only because I did not find an easy
> way how to run the code. Well, it should be pretty safe
> given the nature of the change.
> 
> Signed-off-by: Petr Mladek <pmladek@suse.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] hwrng: meson: Remove unneeded platform MODULE_ALIAS
From: Herbert Xu @ 2016-10-25  3:43 UTC (permalink / raw)
  To: Javier Martinez Canillas
  Cc: linux-kernel, Kevin Hilman, Neil Armstrong,
	PrasannaKumar Muralidharan, Carlo Caione, linux-amlogic,
	Matt Mackall, linux-arm-kernel, linux-crypto
In-Reply-To: <1476906618-14455-1-git-send-email-javier@osg.samsung.com>

On Wed, Oct 19, 2016 at 04:50:18PM -0300, Javier Martinez Canillas wrote:
> The Amlogic Meson is a DT-only platform, which means the devices are
> registered via OF and not using the legacy platform devices support.
> 
> So there's no need to have a MODULE_ALIAS("platform:meson-rng") since
> the reported uevent MODALIAS to user-space will always be the OF one.
> 
> Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.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][TRIVIAL] crypto: ccp - fix typo "CPP"
From: Herbert Xu @ 2016-10-25  3:46 UTC (permalink / raw)
  To: Paul Bolle
  Cc: trivial, thomas.lendacky, gary.hook, linux-crypto, linux-kernel
In-Reply-To: <1476991259-4061-1-git-send-email-pebolle@tiscali.nl>

Paul Bolle <pebolle@tiscali.nl> wrote:
> The abbreviation for Cryptographic Coprocessor is "CCP".
> 
> Signed-off-by: Paul Bolle <pebolle@tiscali.nl>

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 v10 0/8] crypto: asynchronous compression api
From: Herbert Xu @ 2016-10-25  3:47 UTC (permalink / raw)
  To: Giovanni Cabiddu; +Cc: linux-crypto
In-Reply-To: <1477052394-19826-1-git-send-email-giovanni.cabiddu@intel.com>

On Fri, Oct 21, 2016 at 01:19:46PM +0100, Giovanni Cabiddu wrote:
> The following patch set introduces acomp, a generic asynchronous
> (de)compression api with support for SG lists.
> We propose a new crypto type called crypto_acomp_type, a new struct acomp_alg
> and struct crypto_acomp, together with number of helper functions to register
> acomp type algorithms and allocate tfm instances.
> This interface will allow the following operations:
> 
>     int (*compress)(struct acomp_req *req);
>     int (*decompress)(struct acomp_req *req);
> 
> Together with acomp we propose a new driver-side interface, scomp, which
> handles compression implementations which use linear buffers. We converted all
> compression algorithms available in LKCF to use this interface so that those
> algorithms will be accessible through the acomp api.
> 
> Changes in v10:
>     - fixed build issues for configurations where CONFIG_CRYPTO_USER is defined

All applied.  Thanks a lot Giovanni!
-- 
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] nvmem: sunxi-sid: SID content is not a valid source of randomness
From: LABBE Corentin @ 2016-10-25  5:38 UTC (permalink / raw)
  To: Maxime Ripard
  Cc: srinivas.kandagatla, wens, linux-kernel, linux-arm-kernel,
	linux-crypto
In-Reply-To: <20161024201020.h6akyqad2o42xkhq@lukather>

On Mon, Oct 24, 2016 at 10:10:20PM +0200, Maxime Ripard wrote:
> On Sat, Oct 22, 2016 at 03:53:28PM +0200, Corentin Labbe wrote:
> > Since SID's content is constant over reboot,
> 
> That's not true, at least not across all the Allwinner SoCs, and
> especially not on the A10 and A20 that this driver supports.
> 

On my cubieboard2 (A20)
hexdump -C /sys/devices/platform/soc\@01c00000/1c23800.eeprom/sunxi-sid0/nvmem 
00000000  16 51 66 83 80 48 50 72  56 54 48 48 03 c2 75 72  |.Qf..HPrVTHH..ur|
00000010  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00000100  16 51 66 83 80 48 50 72  56 54 48 48 03 c2 75 72  |.Qf..HPrVTHH..ur|
00000110  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00000200
cubiedev ~ # reboot
cubiedev ~ # hexdump -C /sys/devices/platform/soc\@01c00000/1c23800.eeprom/sunxi-sid0/nvmem 
00000000  16 51 66 83 80 48 50 72  56 54 48 48 03 c2 75 72  |.Qf..HPrVTHH..ur|
00000010  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00000100  16 51 66 83 80 48 50 72  56 54 48 48 03 c2 75 72  |.Qf..HPrVTHH..ur|
00000110  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00000200

So clearly for me its constant.

> > it must not be used as source of randomness.
> 
> And I don't think that's true either. A constant entropy provider will
> not add any entropy, but will not remove any, would it?

I cced linux-crypto at the begining for confirmation on that.
But the problem is increased as a part of the content is predicatable over same type of device (at least the thirst bytes and all the zeros).

^ permalink raw reply

* Re: [PATCH] nvmem: sunxi-sid: SID content is not a valid source of randomness
From: Jean-Francois Moine @ 2016-10-25  7:06 UTC (permalink / raw)
  To: LABBE Corentin
  Cc: Maxime Ripard, wens, srinivas.kandagatla, linux-kernel,
	linux-arm-kernel, linux-crypto
In-Reply-To: <20161025053855.GA901@Red>

On Tue, 25 Oct 2016 07:38:55 +0200
LABBE Corentin <clabbe.montjoie@gmail.com> wrote:

> > On Sat, Oct 22, 2016 at 03:53:28PM +0200, Corentin Labbe wrote:
> > > Since SID's content is constant over reboot,
> > 
> > That's not true, at least not across all the Allwinner SoCs, and
> > especially not on the A10 and A20 that this driver supports.
> > 
> 
> On my cubieboard2 (A20)
> hexdump -C /sys/devices/platform/soc\@01c00000/1c23800.eeprom/sunxi-sid0/nvmem 
> 00000000  16 51 66 83 80 48 50 72  56 54 48 48 03 c2 75 72  |.Qf..HPrVTHH..ur|
> 00000010  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
> *
> 00000100  16 51 66 83 80 48 50 72  56 54 48 48 03 c2 75 72  |.Qf..HPrVTHH..ur|
> 00000110  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
> *
> 00000200
> cubiedev ~ # reboot
> cubiedev ~ # hexdump -C /sys/devices/platform/soc\@01c00000/1c23800.eeprom/sunxi-sid0/nvmem 
> 00000000  16 51 66 83 80 48 50 72  56 54 48 48 03 c2 75 72  |.Qf..HPrVTHH..ur|
> 00000010  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
> *
> 00000100  16 51 66 83 80 48 50 72  56 54 48 48 03 c2 75 72  |.Qf..HPrVTHH..ur|
> 00000110  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
> *
> 00000200
> 
> So clearly for me its constant.

Even after power off/power on?

-- 
Ken ar c'hentañ	|	      ** Breizh ha Linux atav! **
Jef		|		http://moinejf.free.fr/

^ permalink raw reply

* Re: [PATCH v2] char: hw_random: atmel-rng: disable TRNG during suspend
From: Nicolas Ferre @ 2016-10-25  8:49 UTC (permalink / raw)
  To: Wenyou Yang, Herbert Xu, Matt Mackall
  Cc: linux-crypto, Wenyou Yang, linux-arm-kernel
In-Reply-To: <1477356993-27778-1-git-send-email-wenyou.yang@atmel.com>

Le 25/10/2016 à 02:56, Wenyou Yang a écrit :
> To fix the over consumption on the VDDCore due to the TRNG enabled,
> disable the TRNG during suspend, not only disable the user interface
> clock (which is controlled by PMC). Because the user interface clock
> is independent from any clock that may be used in the entropy source
> logic circuitry.
> 
> Signed-off-by: Wenyou Yang <wenyou.yang@atmel.com>

Acked-by: Nicolas Ferre <nicolas.ferre@atmel.com>

Thanks

> ---
> 
> Changes in v2:
>  - Enable the user interface first, then enable the internal clock
>    when resume.
> 
>  drivers/char/hw_random/atmel-rng.c | 24 +++++++++++++++++++++---
>  1 file changed, 21 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/char/hw_random/atmel-rng.c b/drivers/char/hw_random/atmel-rng.c
> index 0fcc9e6..ae7cae5 100644
> --- a/drivers/char/hw_random/atmel-rng.c
> +++ b/drivers/char/hw_random/atmel-rng.c
> @@ -48,6 +48,16 @@ static int atmel_trng_read(struct hwrng *rng, void *buf, size_t max,
>  		return 0;
>  }
>  
> +static void atmel_trng_enable(struct atmel_trng *trng)
> +{
> +	writel(TRNG_KEY | 1, trng->base + TRNG_CR);
> +}
> +
> +static void atmel_trng_disable(struct atmel_trng *trng)
> +{
> +	writel(TRNG_KEY, trng->base + TRNG_CR);
> +}
> +
>  static int atmel_trng_probe(struct platform_device *pdev)
>  {
>  	struct atmel_trng *trng;
> @@ -71,7 +81,7 @@ static int atmel_trng_probe(struct platform_device *pdev)
>  	if (ret)
>  		return ret;
>  
> -	writel(TRNG_KEY | 1, trng->base + TRNG_CR);
> +	atmel_trng_enable(trng);
>  	trng->rng.name = pdev->name;
>  	trng->rng.read = atmel_trng_read;
>  
> @@ -94,7 +104,7 @@ static int atmel_trng_remove(struct platform_device *pdev)
>  
>  	hwrng_unregister(&trng->rng);
>  
> -	writel(TRNG_KEY, trng->base + TRNG_CR);
> +	atmel_trng_disable(trng);
>  	clk_disable_unprepare(trng->clk);
>  
>  	return 0;
> @@ -105,6 +115,7 @@ static int atmel_trng_suspend(struct device *dev)
>  {
>  	struct atmel_trng *trng = dev_get_drvdata(dev);
>  
> +	atmel_trng_disable(trng);
>  	clk_disable_unprepare(trng->clk);
>  
>  	return 0;
> @@ -113,8 +124,15 @@ static int atmel_trng_suspend(struct device *dev)
>  static int atmel_trng_resume(struct device *dev)
>  {
>  	struct atmel_trng *trng = dev_get_drvdata(dev);
> +	int ret;
> +
> +	ret = clk_prepare_enable(trng->clk);
> +	if (ret)
> +		return ret;
>  
> -	return clk_prepare_enable(trng->clk);
> +	atmel_trng_enable(trng);
> +
> +	return 0;
>  }
>  
>  static const struct dev_pm_ops atmel_trng_pm_ops = {
> 


-- 
Nicolas Ferre

^ permalink raw reply

* [PATCH] crypto: sahara: fix typo "Decidated" -> "Dedicated"
From: Colin King @ 2016-10-25 11:07 UTC (permalink / raw)
  To: Herbert Xu, linux-crypto; +Cc: David S . Miller, linux-kernel

From: Colin Ian King <colin.king@canonical.com>

Trivial fix to typo in dev_dbg message

Signed-off-by: Colin Ian King <colin.king@canonical.com>
---
 drivers/crypto/sahara.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/crypto/sahara.c b/drivers/crypto/sahara.c
index 0c49956..7ba0eae 100644
--- a/drivers/crypto/sahara.c
+++ b/drivers/crypto/sahara.c
@@ -390,7 +390,7 @@ static void sahara_decode_status(struct sahara_dev *dev, unsigned int status)
 	if (status & SAHARA_STATUS_MODE_BATCH)
 		dev_dbg(dev->device, "	- Batch Mode.\n");
 	else if (status & SAHARA_STATUS_MODE_DEDICATED)
-		dev_dbg(dev->device, "	- Decidated Mode.\n");
+		dev_dbg(dev->device, "	- Dedicated Mode.\n");
 	else if (status & SAHARA_STATUS_MODE_DEBUG)
 		dev_dbg(dev->device, "	- Debug Mode.\n");
 
-- 
2.9.3

^ permalink raw reply related

* Re: [PATCH] nvmem: sunxi-sid: SID content is not a valid source of randomness
From: Maxime Ripard @ 2016-10-25 13:26 UTC (permalink / raw)
  To: LABBE Corentin
  Cc: wens, srinivas.kandagatla, linux-kernel, linux-arm-kernel,
	linux-crypto
In-Reply-To: <20161025053855.GA901@Red>


[-- Attachment #1.1: Type: text/plain, Size: 1646 bytes --]

On Tue, Oct 25, 2016 at 07:38:55AM +0200, LABBE Corentin wrote:
> On Mon, Oct 24, 2016 at 10:10:20PM +0200, Maxime Ripard wrote:
> > On Sat, Oct 22, 2016 at 03:53:28PM +0200, Corentin Labbe wrote:
> > > Since SID's content is constant over reboot,
> > 
> > That's not true, at least not across all the Allwinner SoCs, and
> > especially not on the A10 and A20 that this driver supports.
> > 
> 
> On my cubieboard2 (A20)
> hexdump -C /sys/devices/platform/soc\@01c00000/1c23800.eeprom/sunxi-sid0/nvmem 
> 00000000  16 51 66 83 80 48 50 72  56 54 48 48 03 c2 75 72  |.Qf..HPrVTHH..ur|
> 00000010  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
> *
> 00000100  16 51 66 83 80 48 50 72  56 54 48 48 03 c2 75 72  |.Qf..HPrVTHH..ur|
> 00000110  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
> *
> 00000200
> cubiedev ~ # reboot
> cubiedev ~ # hexdump -C /sys/devices/platform/soc\@01c00000/1c23800.eeprom/sunxi-sid0/nvmem 
> 00000000  16 51 66 83 80 48 50 72  56 54 48 48 03 c2 75 72  |.Qf..HPrVTHH..ur|
> 00000010  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
> *
> 00000100  16 51 66 83 80 48 50 72  56 54 48 48 03 c2 75 72  |.Qf..HPrVTHH..ur|
> 00000110  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
> *
> 00000200
> 
> So clearly for me its constant.

It's constant across reboots, but not across devices. Each device have
a different SID content, therefore it's a relevant source of entropy
in the system.

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

[-- Attachment #2: Type: text/plain, Size: 176 bytes --]

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply

* [PATCH] sunrpc: don't pass on-stack memory to sg_set_buf
From: J. Bruce Fields @ 2016-10-25 18:45 UTC (permalink / raw)
  To: linux-nfs-u79uwXL29TY76Z2rM5mHXA
  Cc: Rusty Russell, Christoph Hellwig,
	linux-crypto-u79uwXL29TY76Z2rM5mHXA

From: "J. Bruce Fields" <bfields-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>

As of ac4e97abce9b "scatterlist: sg_set_buf() argument must be in linear
mapping", sg_set_buf hits a BUG when make_checksum_v2->xdr_process_buf,
among other callers, passes it memory on the stack.

We only need a scatterlist to pass this to the crypto code, and it seems
like overkill to require kmalloc'd memory just to encrypt a few bytes,
but for now this seems the best fix.

Note many of these callers are in the NFS write paths, so we shouldn't
really be allocating GFP_KERNEL.  But we already have other allocations
in these code paths.  A larger redesign may be necessary to allow
allocations to be done earlier.

Cc: Rusty Russell <rusty-8n+1lVoiYb80n/F98K4Iww@public.gmane.org>
Signed-off-by: J. Bruce Fields <bfields-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
---
 net/sunrpc/auth_gss/auth_gss.c        | 13 ++++--
 net/sunrpc/auth_gss/gss_krb5_crypto.c | 82 ++++++++++++++++++++---------------
 net/sunrpc/auth_gss/svcauth_gss.c     | 21 ++++++---
 3 files changed, 71 insertions(+), 45 deletions(-)

diff --git a/net/sunrpc/auth_gss/auth_gss.c b/net/sunrpc/auth_gss/auth_gss.c
index d8bd97a5a7c9..6ecc30058f95 100644
--- a/net/sunrpc/auth_gss/auth_gss.c
+++ b/net/sunrpc/auth_gss/auth_gss.c
@@ -1616,7 +1616,7 @@ gss_validate(struct rpc_task *task, __be32 *p)
 {
 	struct rpc_cred *cred = task->tk_rqstp->rq_cred;
 	struct gss_cl_ctx *ctx = gss_cred_get_ctx(cred);
-	__be32		seq;
+	__be32		*seq = NULL;
 	struct kvec	iov;
 	struct xdr_buf	verf_buf;
 	struct xdr_netobj mic;
@@ -1631,9 +1631,12 @@ gss_validate(struct rpc_task *task, __be32 *p)
 		goto out_bad;
 	if (flav != RPC_AUTH_GSS)
 		goto out_bad;
-	seq = htonl(task->tk_rqstp->rq_seqno);
-	iov.iov_base = &seq;
-	iov.iov_len = sizeof(seq);
+	seq = kmalloc(4, GFP_KERNEL);
+	if (!seq)
+		goto out_bad;
+	*seq = htonl(task->tk_rqstp->rq_seqno);
+	iov.iov_base = seq;
+	iov.iov_len = 4;
 	xdr_buf_from_iov(&iov, &verf_buf);
 	mic.data = (u8 *)p;
 	mic.len = len;
@@ -1653,11 +1656,13 @@ gss_validate(struct rpc_task *task, __be32 *p)
 	gss_put_ctx(ctx);
 	dprintk("RPC: %5u %s: gss_verify_mic succeeded.\n",
 			task->tk_pid, __func__);
+	kfree(seq);
 	return p + XDR_QUADLEN(len);
 out_bad:
 	gss_put_ctx(ctx);
 	dprintk("RPC: %5u %s failed ret %ld.\n", task->tk_pid, __func__,
 		PTR_ERR(ret));
+	kfree(seq);
 	return ret;
 }
 
diff --git a/net/sunrpc/auth_gss/gss_krb5_crypto.c b/net/sunrpc/auth_gss/gss_krb5_crypto.c
index 244245bcbbd2..8a280a810439 100644
--- a/net/sunrpc/auth_gss/gss_krb5_crypto.c
+++ b/net/sunrpc/auth_gss/gss_krb5_crypto.c
@@ -166,8 +166,8 @@ make_checksum_hmac_md5(struct krb5_ctx *kctx, char *header, int hdrlen,
 		       unsigned int usage, struct xdr_netobj *cksumout)
 {
 	struct scatterlist              sg[1];
-	int err;
-	u8 checksumdata[GSS_KRB5_MAX_CKSUM_LEN];
+	int err = -1;
+	u8 *checksumdata;
 	u8 rc4salt[4];
 	struct crypto_ahash *md5;
 	struct crypto_ahash *hmac_md5;
@@ -187,23 +187,22 @@ make_checksum_hmac_md5(struct krb5_ctx *kctx, char *header, int hdrlen,
 		return GSS_S_FAILURE;
 	}
 
+	checksumdata = kmalloc(GSS_KRB5_MAX_CKSUM_LEN, GFP_KERNEL);
+	if (!checksumdata)
+		return GSS_S_FAILURE;
+
 	md5 = crypto_alloc_ahash("md5", 0, CRYPTO_ALG_ASYNC);
 	if (IS_ERR(md5))
-		return GSS_S_FAILURE;
+		goto out_free_cksum;
 
 	hmac_md5 = crypto_alloc_ahash(kctx->gk5e->cksum_name, 0,
 				      CRYPTO_ALG_ASYNC);
-	if (IS_ERR(hmac_md5)) {
-		crypto_free_ahash(md5);
-		return GSS_S_FAILURE;
-	}
+	if (IS_ERR(hmac_md5))
+		goto out_free_md5;
 
 	req = ahash_request_alloc(md5, GFP_KERNEL);
-	if (!req) {
-		crypto_free_ahash(hmac_md5);
-		crypto_free_ahash(md5);
-		return GSS_S_FAILURE;
-	}
+	if (!req)
+		goto out_free_hmac_md5;
 
 	ahash_request_set_callback(req, CRYPTO_TFM_REQ_MAY_SLEEP, NULL, NULL);
 
@@ -232,11 +231,8 @@ make_checksum_hmac_md5(struct krb5_ctx *kctx, char *header, int hdrlen,
 
 	ahash_request_free(req);
 	req = ahash_request_alloc(hmac_md5, GFP_KERNEL);
-	if (!req) {
-		crypto_free_ahash(hmac_md5);
-		crypto_free_ahash(md5);
-		return GSS_S_FAILURE;
-	}
+	if (!req)
+		goto out_free_hmac_md5;
 
 	ahash_request_set_callback(req, CRYPTO_TFM_REQ_MAY_SLEEP, NULL, NULL);
 
@@ -258,8 +254,12 @@ make_checksum_hmac_md5(struct krb5_ctx *kctx, char *header, int hdrlen,
 	cksumout->len = kctx->gk5e->cksumlength;
 out:
 	ahash_request_free(req);
-	crypto_free_ahash(md5);
+out_free_hmac_md5:
 	crypto_free_ahash(hmac_md5);
+out_free_md5:
+	crypto_free_ahash(md5);
+out_free_cksum:
+	kfree(checksumdata);
 	return err ? GSS_S_FAILURE : 0;
 }
 
@@ -276,8 +276,8 @@ make_checksum(struct krb5_ctx *kctx, char *header, int hdrlen,
 	struct crypto_ahash *tfm;
 	struct ahash_request *req;
 	struct scatterlist              sg[1];
-	int err;
-	u8 checksumdata[GSS_KRB5_MAX_CKSUM_LEN];
+	int err = -1;
+	u8 *checksumdata;
 	unsigned int checksumlen;
 
 	if (kctx->gk5e->ctype == CKSUMTYPE_HMAC_MD5_ARCFOUR)
@@ -291,15 +291,17 @@ make_checksum(struct krb5_ctx *kctx, char *header, int hdrlen,
 		return GSS_S_FAILURE;
 	}
 
+	checksumdata = kmalloc(GSS_KRB5_MAX_CKSUM_LEN, GFP_KERNEL);
+	if (checksumdata == NULL)
+		return GSS_S_FAILURE;
+
 	tfm = crypto_alloc_ahash(kctx->gk5e->cksum_name, 0, CRYPTO_ALG_ASYNC);
 	if (IS_ERR(tfm))
-		return GSS_S_FAILURE;
+		goto out_free_cksum;
 
 	req = ahash_request_alloc(tfm, GFP_KERNEL);
-	if (!req) {
-		crypto_free_ahash(tfm);
-		return GSS_S_FAILURE;
-	}
+	if (!req)
+		goto out_free_ahash;
 
 	ahash_request_set_callback(req, CRYPTO_TFM_REQ_MAY_SLEEP, NULL, NULL);
 
@@ -349,7 +351,10 @@ make_checksum(struct krb5_ctx *kctx, char *header, int hdrlen,
 	cksumout->len = kctx->gk5e->cksumlength;
 out:
 	ahash_request_free(req);
+out_free_ahash:
 	crypto_free_ahash(tfm);
+out_free_cksum:
+	kfree(checksumdata);
 	return err ? GSS_S_FAILURE : 0;
 }
 
@@ -368,8 +373,8 @@ make_checksum_v2(struct krb5_ctx *kctx, char *header, int hdrlen,
 	struct crypto_ahash *tfm;
 	struct ahash_request *req;
 	struct scatterlist sg[1];
-	int err;
-	u8 checksumdata[GSS_KRB5_MAX_CKSUM_LEN];
+	int err = -1;
+	u8 *checksumdata;
 	unsigned int checksumlen;
 
 	if (kctx->gk5e->keyed_cksum == 0) {
@@ -383,16 +388,18 @@ make_checksum_v2(struct krb5_ctx *kctx, char *header, int hdrlen,
 		return GSS_S_FAILURE;
 	}
 
+	checksumdata = kmalloc(GSS_KRB5_MAX_CKSUM_LEN, GFP_KERNEL);
+	if (!checksumdata)
+		return GSS_S_FAILURE;
+
 	tfm = crypto_alloc_ahash(kctx->gk5e->cksum_name, 0, CRYPTO_ALG_ASYNC);
 	if (IS_ERR(tfm))
-		return GSS_S_FAILURE;
+		goto out_free_cksum;
 	checksumlen = crypto_ahash_digestsize(tfm);
 
 	req = ahash_request_alloc(tfm, GFP_KERNEL);
-	if (!req) {
-		crypto_free_ahash(tfm);
-		return GSS_S_FAILURE;
-	}
+	if (!req)
+		goto out_free_ahash;
 
 	ahash_request_set_callback(req, CRYPTO_TFM_REQ_MAY_SLEEP, NULL, NULL);
 
@@ -433,7 +440,10 @@ make_checksum_v2(struct krb5_ctx *kctx, char *header, int hdrlen,
 	}
 out:
 	ahash_request_free(req);
+out_free_ahash:
 	crypto_free_ahash(tfm);
+out_free_cksum:
+	kfree(checksumdata);
 	return err ? GSS_S_FAILURE : 0;
 }
 
@@ -666,14 +676,17 @@ gss_krb5_cts_crypt(struct crypto_skcipher *cipher, struct xdr_buf *buf,
 	u32 ret;
 	struct scatterlist sg[1];
 	SKCIPHER_REQUEST_ON_STACK(req, cipher);
-	u8 data[GSS_KRB5_MAX_BLOCKSIZE * 2];
+	u8 *data;
 	struct page **save_pages;
 	u32 len = buf->len - offset;
 
-	if (len > ARRAY_SIZE(data)) {
+	if (len > GSS_KRB5_MAX_BLOCKSIZE * 2) {
 		WARN_ON(0);
 		return -ENOMEM;
 	}
+	data = kmalloc(GSS_KRB5_MAX_BLOCKSIZE * 2, GFP_KERNEL);
+	if (!data)
+		return -ENOMEM;
 
 	/*
 	 * For encryption, we want to read from the cleartext
@@ -708,6 +721,7 @@ gss_krb5_cts_crypt(struct crypto_skcipher *cipher, struct xdr_buf *buf,
 	ret = write_bytes_to_xdr_buf(buf, offset, data, len);
 
 out:
+	kfree(data);
 	return ret;
 }
 
diff --git a/net/sunrpc/auth_gss/svcauth_gss.c b/net/sunrpc/auth_gss/svcauth_gss.c
index d67f7e1bc82d..45662d7f0943 100644
--- a/net/sunrpc/auth_gss/svcauth_gss.c
+++ b/net/sunrpc/auth_gss/svcauth_gss.c
@@ -718,30 +718,37 @@ gss_write_null_verf(struct svc_rqst *rqstp)
 static int
 gss_write_verf(struct svc_rqst *rqstp, struct gss_ctx *ctx_id, u32 seq)
 {
-	__be32			xdr_seq;
+	__be32			*xdr_seq;
 	u32			maj_stat;
 	struct xdr_buf		verf_data;
 	struct xdr_netobj	mic;
 	__be32			*p;
 	struct kvec		iov;
+	int err = -1;
 
 	svc_putnl(rqstp->rq_res.head, RPC_AUTH_GSS);
-	xdr_seq = htonl(seq);
+	xdr_seq = kmalloc(4, GFP_KERNEL);
+	if (!xdr_seq)
+		return -1;
+	*xdr_seq = htonl(seq);
 
-	iov.iov_base = &xdr_seq;
-	iov.iov_len = sizeof(xdr_seq);
+	iov.iov_base = xdr_seq;
+	iov.iov_len = 4;
 	xdr_buf_from_iov(&iov, &verf_data);
 	p = rqstp->rq_res.head->iov_base + rqstp->rq_res.head->iov_len;
 	mic.data = (u8 *)(p + 1);
 	maj_stat = gss_get_mic(ctx_id, &verf_data, &mic);
 	if (maj_stat != GSS_S_COMPLETE)
-		return -1;
+		goto out;
 	*p++ = htonl(mic.len);
 	memset((u8 *)p + mic.len, 0, round_up_to_quad(mic.len) - mic.len);
 	p += XDR_QUADLEN(mic.len);
 	if (!xdr_ressize_check(rqstp, p))
-		return -1;
-	return 0;
+		goto out;
+	err = 0;
+out:
+	kfree(xdr_seq);
+	return err;
 }
 
 struct gss_domain {
-- 
2.7.4

--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply related

* Re: [PATCH] sunrpc: don't pass on-stack memory to sg_set_buf
From: Trond Myklebust @ 2016-10-25 19:34 UTC (permalink / raw)
  To: Fields Bruce James
  Cc: List Linux NFS Mailing, Rusty Russell, Christoph Hellwig,
	linux-crypto-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <20161025184538.GA4612-uC3wQj2KruNg9hUCZPvPmw@public.gmane.org>


> On Oct 25, 2016, at 14:45, J. Bruce Fields <bfields@fieldses.org> wrote:
> 
> From: "J. Bruce Fields" <bfields@redhat.com>
> 
> As of ac4e97abce9b "scatterlist: sg_set_buf() argument must be in linear
> mapping", sg_set_buf hits a BUG when make_checksum_v2->xdr_process_buf,
> among other callers, passes it memory on the stack.
> 
> We only need a scatterlist to pass this to the crypto code, and it seems
> like overkill to require kmalloc'd memory just to encrypt a few bytes,
> but for now this seems the best fix.
> 
> Note many of these callers are in the NFS write paths, so we shouldn't
> really be allocating GFP_KERNEL.  But we already have other allocations
> in these code paths.  A larger redesign may be necessary to allow
> allocations to be done earlier.

NACK…  I agree that there may already be borkage in RPCSEC_GSS-land, but that’s not a reason to be adding to the pile of things that need to be fixed… The allocations that lie in the RPC client’s encode/decode path do need to be GFP_NOFS….


^ permalink raw reply

* Re: [PATCH] sunrpc: don't pass on-stack memory to sg_set_buf
From: Fields Bruce James @ 2016-10-25 19:59 UTC (permalink / raw)
  To: Trond Myklebust
  Cc: List Linux NFS Mailing, Rusty Russell, Christoph Hellwig,
	linux-crypto@vger.kernel.org
In-Reply-To: <A4086E5B-B808-4828-A25D-4AAB2504EC57@primarydata.com>

On Tue, Oct 25, 2016 at 07:34:43PM +0000, Trond Myklebust wrote:
> 
> > On Oct 25, 2016, at 14:45, J. Bruce Fields <bfields@fieldses.org> wrote:
> > 
> > From: "J. Bruce Fields" <bfields@redhat.com>
> > 
> > As of ac4e97abce9b "scatterlist: sg_set_buf() argument must be in linear
> > mapping", sg_set_buf hits a BUG when make_checksum_v2->xdr_process_buf,
> > among other callers, passes it memory on the stack.
> > 
> > We only need a scatterlist to pass this to the crypto code, and it seems
> > like overkill to require kmalloc'd memory just to encrypt a few bytes,
> > but for now this seems the best fix.
> > 
> > Note many of these callers are in the NFS write paths, so we shouldn't
> > really be allocating GFP_KERNEL.  But we already have other allocations
> > in these code paths.  A larger redesign may be necessary to allow
> > allocations to be done earlier.
> 
> NACK…  I agree that there may already be borkage in RPCSEC_GSS-land, but that’s not a reason to be adding to the pile of things that need to be fixed… The allocations that lie in the RPC client’s encode/decode path do need to be GFP_NOFS….

OK.  Any disadvantage to keeping this patch with just GFP_NOFS
allocations everywhere that might be in the write path?

--b.

^ permalink raw reply

* [PATCH] crypto: caam: fix type mismatch warning
From: Arnd Bergmann @ 2016-10-25 21:29 UTC (permalink / raw)
  To: Herbert Xu
  Cc: Arnd Bergmann, David S. Miller, Horia Geantă, Catalin Vasile,
	linux-crypto, linux-kernel

Building the caam driver on arm64 produces a harmless warning:

drivers/crypto/caam/caamalg.c:140:139: warning: comparison of distinct pointer types lacks a cast

We can use min_t to tell the compiler which type we want it to use
here.

Fixes: 5ecf8ef9103c ("crypto: caam - fix sg dump")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
This is currently the only warning reported by kernelci.org for
linux-4.9 on arm, arm64 and x86.
---
 drivers/crypto/caam/caamalg.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/crypto/caam/caamalg.c b/drivers/crypto/caam/caamalg.c
index 156aad167cd6..8de85dfb1b04 100644
--- a/drivers/crypto/caam/caamalg.c
+++ b/drivers/crypto/caam/caamalg.c
@@ -137,7 +137,7 @@ static void dbg_dump_sg(const char *level, const char *prefix_str,
 		}
 
 		buf = it_page + it->offset;
-		len = min(tlen, it->length);
+		len = min_t(size_t, tlen, it->length);
 		print_hex_dump(level, prefix_str, prefix_type, rowsize,
 			       groupsize, buf, len, ascii);
 		tlen -= len;
-- 
2.9.0

^ permalink raw reply related

* Re: [PATCH] sunrpc: don't pass on-stack memory to sg_set_buf
From: Trond Myklebust @ 2016-10-25 21:47 UTC (permalink / raw)
  To: Fields Bruce James
  Cc: List Linux NFS Mailing, Rusty Russell, Christoph Hellwig,
	linux-crypto-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <20161025195930.GB5129-uC3wQj2KruNg9hUCZPvPmw@public.gmane.org>


> On Oct 25, 2016, at 15:59, Fields Bruce James <bfields@fieldses.org> wrote:
> 
> On Tue, Oct 25, 2016 at 07:34:43PM +0000, Trond Myklebust wrote:
>> 
>>> On Oct 25, 2016, at 14:45, J. Bruce Fields <bfields@fieldses.org> wrote:
>>> 
>>> From: "J. Bruce Fields" <bfields@redhat.com>
>>> 
>>> As of ac4e97abce9b "scatterlist: sg_set_buf() argument must be in linear
>>> mapping", sg_set_buf hits a BUG when make_checksum_v2->xdr_process_buf,
>>> among other callers, passes it memory on the stack.
>>> 
>>> We only need a scatterlist to pass this to the crypto code, and it seems
>>> like overkill to require kmalloc'd memory just to encrypt a few bytes,
>>> but for now this seems the best fix.
>>> 
>>> Note many of these callers are in the NFS write paths, so we shouldn't
>>> really be allocating GFP_KERNEL.  But we already have other allocations
>>> in these code paths.  A larger redesign may be necessary to allow
>>> allocations to be done earlier.
>> 
>> NACK…  I agree that there may already be borkage in RPCSEC_GSS-land, but that’s not a reason to be adding to the pile of things that need to be fixed… The allocations that lie in the RPC client’s encode/decode path do need to be GFP_NOFS….
> 
> OK.  Any disadvantage to keeping this patch with just GFP_NOFS
> allocations everywhere that might be in the write path?

It’s what we have to do everywhere else in the RPC client, so I can’t see why it should be a problem.


^ permalink raw reply

* [cryptodev:master 41/47] ERROR: "crypto_acomp_scomp_free_ctx" [crypto/acompress.ko] undefined!
From: kbuild test robot @ 2016-10-26  0:47 UTC (permalink / raw)
  To: Giovanni Cabiddu; +Cc: kbuild-all, linux-crypto, Herbert Xu

[-- Attachment #1: Type: text/plain, Size: 927 bytes --]

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/herbert/cryptodev-2.6.git master
head:   d7db7a882debaffc78f91aabedee973aa1f73390
commit: 1ab53a77b772bf7369464a0e4fa6fd6499acf8f1 [41/47] crypto: acomp - add driver-side scomp interface
config: x86_64-randconfig-s4-10260656 (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
        git checkout 1ab53a77b772bf7369464a0e4fa6fd6499acf8f1
        # save the attached .config to linux build tree
        make ARCH=x86_64 

All errors (new ones prefixed by >>):

>> ERROR: "crypto_acomp_scomp_free_ctx" [crypto/acompress.ko] undefined!
>> ERROR: "crypto_acomp_scomp_alloc_ctx" [crypto/acompress.ko] undefined!
>> ERROR: "crypto_init_scomp_ops_async" [crypto/acompress.ko] undefined!

---
0-DAY kernel test infrastructure                Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all                   Intel Corporation

[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 19304 bytes --]

^ 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