From: Eric Biggers
Date: Fri, 12 Jul 2019 16:39:31 -0700
> From: Eric Biggers
>
> Commit 0e5a610b5ca5 ("ppp: mppe: switch to RC4 library interface"),
> which was merged through the crypto tree for v5.3, changed ppp_mppe.c to
> use the new arc4_crypt() library function rather than access RC4 thr
On Fri, Jul 12, 2019 at 12:07:37PM -0400, Daniel Jordan wrote:
>
> modprobe (CPU2) kworker/21:1-293 (CPU21)
> kworker/5:2-276 (CPU5)
> --
> --
>
> ...
>
From: Eric Biggers
Commit 0e5a610b5ca5 ("ppp: mppe: switch to RC4 library interface"),
which was merged through the crypto tree for v5.3, changed ppp_mppe.c to
use the new arc4_crypt() library function rather than access RC4 through
the dynamic crypto_skcipher API.
Meanwhile commit aad1dcc4f011
SEV_VERSION_GREATER_OR_EQUAL() will fail if upgrading from 2.2 to 3.1, for
example, because the minor version is not equal to or greater than the
major.
Fix this and move to a static inline function for appropriate type
checking.
Fixes: edd303ff0e9e ("crypto: ccp - Add DOWNLOAD_FIRMWARE SEV comma
Am Freitag, 12. Juli 2019, 19:55:07 CEST schrieb Bhat, Jayalakshmi Manjunath:
Hi Jayalakshmi,
> Hi Stephan,
>
> Thank you very much for the suggestions, I have another question, is it
> possible to implement MMT and MCT using kernel crypto API's.
Yes, for sure - I have successfully implemented
On Fri, Jul 12, 2019 at 05:55:07PM +, Bhat, Jayalakshmi Manjunath wrote:
> Hi Stephan,
>
> Thank you very much for the suggestions, I have another question, is it
> possible to implement MMT and MCT using kernel crypto API's. Also FCC and
> FCC functions.
>
> Regards,
> Jaya
>
Please sto
Hi Stephan,
Thank you very much for the suggestions, I have another question, is it
possible to implement MMT and MCT using kernel crypto API's. Also FCC and FCC
functions.
Regards,
Jaya
-Original Message-
From: Stephan Mueller
Sent: Thursday, July 11, 2019 9:04 PM
To: Bhat, Jayalak
On Fri, Jul 12, 2019 at 12:10:12PM +0200, Steffen Klassert wrote:
> On Fri, Jul 12, 2019 at 06:06:36PM +0800, Herbert Xu wrote:
> > Daniel Jordan wrote:
> > >
> > > CPU0 CPU1
> > >
> > > padata_reorder padata_do_serial
> > > LOAD reorder_objec
On Thu, 11 Jul 2019 14:23:01 +0200, Maxime Ripard wrote:
> The older Allwinner SoCs have a crypto engine that is supported in Linux,
> with a matching Device Tree binding.
>
> Now that we have the DT validation in place, let's convert the device tree
> bindings for that controller over to a YAML s
On Wed, Jul 10, 2019 at 12:09:22AM +, Hook, Gary wrote:
> The AES GCM function reuses an 'op' data structure, which members
> contain values that must be cleared for each (re)use.
>
> This fix resolves a crypto self-test failure:
> alg: aead: gcm-aes-ccp encryption test failed (wrong result) o
On Mon, Jul 08, 2019 at 02:19:03PM +0800, Wen Yang wrote:
> There is a possible double free issue in ppc4xx_trng_probe():
>
> 85: dev->trng_base = of_iomap(trng, 0);
> 86: of_node_put(trng); ---> released here
> 87: if (!dev->trng_base)
> 88: goto err_out;
> ...
> 110: ie
On Fri, Jul 12, 2019 at 06:06:36PM +0800, Herbert Xu wrote:
> Daniel Jordan wrote:
> >
> > CPU0 CPU1
> >
> > padata_reorder padata_do_serial
> > LOAD reorder_objects // 0
> > INC reorder_objects // 1
>
Daniel Jordan wrote:
>
> CPU0 CPU1
>
> padata_reorder padata_do_serial
> LOAD reorder_objects // 0
> INC reorder_objects // 1
> padata_reorder
>
Each of the operations in ccp_run_cmd() needs several hundred
bytes of kernel stack. Depending on the inlining, these may
need separate stack slots that add up to more than the warning
limit, as shown in this clang based build:
drivers/crypto/ccp/ccp-ops.c:871:12: error: stack frame size of 1164 b
14 matches
Mail list logo
