commit 720419f01832 ("crypto: ccp - Introduce the AMD Secure Processor device")
moved the module registeration from ccp-dev.c to sp-dev.c but patch missed
removing the module version and author entry from ccp-dev.c.
It causes the below warning during boot when CONFIG_CRYPTO_DEV_SP_CCP=y
and CONFIG
,"Paul E . McKenney" ,Andrew
Morton ,Christopher Li ,Dou
Liyang ,Masahiro Yamada
,Daniel Borkmann ,Markus
Trippelsdorf ,Peter Foley ,Steven
Rostedt ,Tim Chen ,Ard
Biesheuvel ,Catalin Marinas
,Matthew Wilcox ,Michal Hocko
,Rob Landley ,Jiri Kosina
,"H . J . Lu" ,Paul Bolle
,Baoquan He ,Dan
,Chris Metcalf ,"Paul E .
McKenney" ,Andrew Morton
,Christopher Li ,Dou Liyang
,Masahiro Yamada
,Daniel Borkmann ,Markus
Trippelsdorf ,Peter Foley ,Steven
Rostedt ,Tim Chen ,Catalin
Marinas ,Matthew Wilcox
,Michal Hocko ,Rob Landley
,Jiri Kosina ,"H . J . Lu"
,Paul Bolle ,Baoquan He
,Dan
In commit 0f987e25cb8a, the source processing has been moved in front of
the destination processing, but the error handling path has not been
modified accordingly.
Free resources in the correct order to avoid some leaks.
Fixes: 0f987e25cb8a ("crypto: ixp4xx - Fix false lastlen uninitialised warnin
Hi PrasannaKumar,
thanks for taking the time to review my submission.
Thus wrote PrasannaKumar Muralidharan (prasannatsmku...@gmail.com):
> Please combine above 2 comments.
ok, I'll do this.
> > +
> > +/*
> > + * Hardware driver for the Intel/AMD/VIA Random Number Generators (RNG)
> > [...]
>
On Wed, Jul 19, 2017 at 04:53:21PM +, Horia Geantă wrote:
> On 7/19/2017 7:32 PM, Oleksij Rempel wrote:
> > On Wed, Jul 19, 2017 at 12:49:47PM +, Horia Geantă wrote:
> >> On 7/19/2017 10:45 AM, Oleksij Rempel wrote:
> >>> According documentation, it is NIST certified TRNG.
> >>> So, set hig
On Mon, Jul 17, 2017 at 10:45:51AM -0700, Michael Halcrow wrote:
> > +/*
> > + * Get the fscrypt_master_key identified by the specified v2+ encryption
> > + * context, or create it if not found.
> > + *
> > + * Returns the fscrypt_master_key with a reference taken, or an ERR_PTR().
> > + */
> > +st
On Fri, Jul 14, 2017 at 09:24:40AM -0700, Michael Halcrow wrote:
> > +static int hkdf_expand(struct crypto_shash *hmac, u8 context,
> > + const u8 *info, unsigned int infolen,
> > + u8 *okm, unsigned int okmlen)
> > +{
> > + SHASH_DESC_ON_STACK(desc, hmac);
> > +
On Wed, Jul 19, 2017 at 08:22:18AM +0200, Stephan Müller wrote:
> In the email [1] I have expressed the core concerns I see -- none of them
> address the need to keep the Jitter RNG as one noise source. To address
> those,
> a very deep dive into random.c needs to be made.
That's simply not tru
On 7/19/2017 7:32 PM, Oleksij Rempel wrote:
> On Wed, Jul 19, 2017 at 12:49:47PM +, Horia Geantă wrote:
>> On 7/19/2017 10:45 AM, Oleksij Rempel wrote:
>>> According documentation, it is NIST certified TRNG.
>>> So, set high quality to let the HWRNG framework automatically use it.
>>>
>>> Signe
Remove xts(aes) speed tests with 2 x 192-bit keys, since implementations
adhering strictly to IEEE 1619-2007 standard cannot cope with key sizes
other than 2 x 128, 2 x 256 bits - i.e. AES-XTS-{128,256}:
[...]
tcrypt: test 5 (384 bit key, 16 byte blocks):
caam_jr 802.jr: key size mismatch
tcryp
On Wed, Jul 19, 2017 at 12:49:47PM +, Horia Geantă wrote:
> On 7/19/2017 10:45 AM, Oleksij Rempel wrote:
> > According documentation, it is NIST certified TRNG.
> > So, set high quality to let the HWRNG framework automatically use it.
> >
> > Signed-off-by: Oleksij Rempel
> > ---
> > drivers
On 18/07/17 11:57 PM, Michael Ellerman wrote:
> Seems fair enough, have you tested it at all?
It's only been compile tested and the kbuild robot has beat up on it a bit.
Thanks,
Logan
Commit a53e35db70d1 ("reset: Ensure drivers are explicit when requesting
reset lines") started to transition the reset control request API calls
to explicitly state whether the driver needs exclusive or shared reset
control behavior. Convert all drivers requesting exclusive resets to the
explicit A
Commit a53e35db70d1 ("reset: Ensure drivers are explicit when requesting
reset lines") started to transition the reset control request API calls
to explicitly state whether the driver needs exclusive or shared reset
control behavior. Convert all drivers requesting exclusive resets to the
explicit A
On 7/19/2017 10:45 AM, Oleksij Rempel wrote:
> According documentation, it is NIST certified TRNG.
> So, set high quality to let the HWRNG framework automatically use it.
>
> Signed-off-by: Oleksij Rempel
> ---
> drivers/crypto/caam/caamrng.c | 6 ++
> 1 file changed, 6 insertions(+)
>
> di
From: Colin Ian King
Functions atmel_ecc_i2c_client_alloc and atmel_ecc_i2c_client_free are
local to the source and no not need to be in the global scope. Make
them static.
Cleans up sparse warnings:
symbol 'atmel_ecc_i2c_client_alloc' was not declared. Should it be static?
symbol 'atmel_ecc_i2c
Am Mittwoch, 19. Juli 2017, 10:20:07 CEST schrieb Horia Geantă:
Hi Horia,
> Hi,
>
> AFAICS, IEEE 1619-2007 standard mentions only XTS-AES-128 and
> XTS-AES-256, meaning that the keys should be either 256 or 512 bits.
>
> Further, NIST SP800-38E mentions that an implementation may restrict
> sup
A check is performed on the ipad/opad in the safexcel_hmac_sha1_setkey
function, but the index used by the loop doing it is wrong. It is
currently the size of the state array while it should be the size of a
sha1 state. This patch fixes it.
Fixes: 1b44c5a60c13 ("crypto: inside-secure - add SafeXce
The safexcel_hmac_sha1_setkey function checks if an invalidation command
should be issued, i.e. when the context ipad/opad change. This checks is
done after filling the ipad/opad which and it can't be true. The patch
fixes this by moving the check before the ipad/opad memcpy operations.
Fixes: 1b4
Hi,
AFAICS, IEEE 1619-2007 standard mentions only XTS-AES-128 and
XTS-AES-256, meaning that the keys should be either 256 or 512 bits.
Further, NIST SP800-38E mentions that an implementation may restrict
support to only one of XTS-AES-{128,256}, but does not explicitly allow
other cipher suites.
According documentation, it is NIST certified TRNG.
So, set high quality to let the HWRNG framework automatically use it.
Signed-off-by: Oleksij Rempel
---
drivers/crypto/caam/caamrng.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/crypto/caam/caamrng.c b/drivers/crypto/caam/
On Tue, Jul 18, 2017 at 03:52:19PM +0300, Tudor Ambarus wrote:
>
> I'm replacing a per-tfm shared secret with a per-request dynamically
> allocated shared secret. The same for the public key, I'm replacing
> a per-tfm public key with a per-request dynamically allocated public
> key. No shared memor
On Tue, Jul 18, 2017 at 06:18:59PM -0700, Megha Dey wrote:
>
> > >> +/*
> > >> + * CRYPTO_ALG_ASYNC flag is passed to indicate we have an ablk
> > >> + * scatter-gather walk.
> > >> + */
> > >> +static struct skcipher_alg aes_cbc_mb_alg = {
> > >> +.base = {
> > >> +.cra_nam
24 matches
Mail list logo
