Le 11/06/2019 à 18:30, Horia Geanta a écrit :
On 6/11/2019 6:40 PM, Christophe Leroy wrote:
Le 11/06/2019 à 17:37, Horia Geanta a écrit :
On 6/11/2019 5:39 PM, Christophe Leroy wrote:
This series is the last set of fixes for the Talitos driver.
We now get a fully clean boot on both SEC1
Below commit came with a typo in the CONFIG_ symbol, leading
to a permanently reduced max key size regarless of the driver
capabilities.
Reported-by: Horia Geantă
Fixes: b8fbdc2bc4e7 ("crypto: talitos - reduce max key size for SEC1")
Signed-off-by: Christophe Leroy
---
drivers/crypto/talitos.c
On Tue, 2019-06-11 at 16:53 -0600, Rob Herring wrote:
> On Mon, Jun 10, 2019 at 06:36:23PM +0800, Neal Liu wrote:
> > Document the binding used by the MediaTek ARMv8 SoCs random
> > number generator with TrustZone enabled.
> >
> > Signed-off-by: Neal Liu
> > ---
> > Documentation/devicetree/bind
On Tue, Jun 11, 2019 at 2:56 AM Horia Geanta wrote:
>
> On 6/7/2019 11:03 PM, Andrey Smirnov wrote:
> > From: Chris Spencer
> >
> > There are no clocks that the CAAM driver needs to initialise on the
> > i.MX8.
> >
> RM lists 5 clocks for CAAM module (instance.clock): caam.aclk, caam.ipg_clk,
> c
The MPPE code uses the sync skcipher to invoke the ecb(arc4) skcipher,
of which only a single generic C code implementation exists. This means
that going through all the trouble of using scatterlists etc buys us
very little, and we're better off just invoking the arc4 library directly.
Note that t
There are no remaining users of the cipher implementation, and there
are no meaningful ways in which the arc4 cipher can be combined with
templates other than ECB (and the way we do provide that combination
is highly dubious to begin with).
So let's drop the arc4 cipher altogether, and only keep t
The crypto API abstraction is not very useful for invoking ciphers
directly, especially in the case of arc4, which only has a generic
implementation in C. So let's invoke the library code directly.
Signed-off-by: Ard Biesheuvel
---
net/wireless/lib80211_crypt_tkip.c | 48 +++-
1
The crypto API abstraction is not very useful for invoking ciphers
directly, especially in the case of arc4, which only has a generic
implementation in C. So let's invoke the library code directly.
Signed-off-by: Ard Biesheuvel
---
net/wireless/Kconfig | 1 +
net/wireless/lib80211_
The CIFS code uses the sync skcipher API to invoke the ecb(arc4) skcipher,
of which only a single generic C code implementation exists. This means
that going through all the trouble of using scatterlists etc buys us
very little, and we're better off just invoking the arc4 library directly.
This al
The WEP code in the mac80211 subsystem currently uses the crypto
API to access the arc4 (RC4) cipher, which is overly complicated,
and doesn't really have an upside in this particular case, since
ciphers are always synchronous and therefore always implemented in
software. Given that we have no acce
This is a follow-up to, and supersedes [0], which moved some WEP code from
the cipher to the skcipher interface, in order to reduce the use of the bare
cipher interface in non-crypto subsystem code.
Since using the skcipher interface to invoke the generic C implementation of
an algorithm that is k
Refactor the core rc4 handling so we can move most users to a library
interface, permitting us to drop the cipher interface entirely in a
future patch. This is part of an effort to simplify the crypto API
and improve its robustness against incorrect use.
Signed-off-by: Ard Biesheuvel
---
MAINTAI
On Mon, Jun 10, 2019 at 06:36:23PM +0800, Neal Liu wrote:
> Document the binding used by the MediaTek ARMv8 SoCs random
> number generator with TrustZone enabled.
>
> Signed-off-by: Neal Liu
> ---
> Documentation/devicetree/bindings/rng/mtk-rng.txt | 15 ---
> 1 file changed, 12 in
On Tue, Jun 11, 2019 at 03:47:50PM +0200, Ard Biesheuvel wrote:
> The CIFS code uses the sync skcipher API to invoke the ecb(arc4) skcipher,
> of which only a single generic C code implementation exists. This means
> that going through all the trouble of using scatterlists etc buys us
> very little
On Tue, Jun 11, 2019 at 03:47:49PM +0200, Ard Biesheuvel wrote:
> @@ -728,8 +660,7 @@ static struct compressor ppp_mppe = {
> static int __init ppp_mppe_init(void)
> {
> int answer;
> - if (!(crypto_has_skcipher("ecb(arc4)", 0, CRYPTO_ALG_ASYNC) &&
> - crypto_has_ahash("sha1",
On Tue, Jun 11, 2019 at 03:47:46PM +0200, Ard Biesheuvel wrote:
> The crypto API abstraction is not very useful for invoking ciphers
> directly, especially in the case of arc4, which only has a generic
> implementation in C. So let's invoke the library code directly.
>
> Signed-off-by: Ard Biesheu
On Tue, Jun 11, 2019 at 03:47:45PM +0200, Ard Biesheuvel wrote:
>
> -void ieee80211_wep_free(struct ieee80211_local *local)
> -{
> - if (!IS_ERR(local->wep_tx_tfm))
> - crypto_free_cipher(local->wep_tx_tfm);
> - if (!IS_ERR(local->wep_rx_tfm))
> - crypto_free_ciphe
On Tue, Jun 11, 2019 at 03:47:48PM +0200, Ard Biesheuvel wrote:
> There are no remaining users of the cipher implementation, and there
> are no meaningful ways in which the arc4 cipher can be combined with
> templates other than ECB (and the way we do provide that combination
> is highly dubious to
Le 11/06/2019 à 18:30, Horia Geanta a écrit :
On 6/11/2019 6:40 PM, Christophe Leroy wrote:
Le 11/06/2019 à 17:37, Horia Geanta a écrit :
On 6/11/2019 5:39 PM, Christophe Leroy wrote:
This series is the last set of fixes for the Talitos driver.
We now get a fully clean boot on both SEC1
On 6/11/2019 6:40 PM, Christophe Leroy wrote:
>
>
> Le 11/06/2019 à 17:37, Horia Geanta a écrit :
>> On 6/11/2019 5:39 PM, Christophe Leroy wrote:
>>> This series is the last set of fixes for the Talitos driver.
>>>
>>> We now get a fully clean boot on both SEC1 (SEC1.2 on mpc885) and
>>> SEC2 (S
Le 11/06/2019 à 17:37, Horia Geanta a écrit :
On 6/11/2019 5:39 PM, Christophe Leroy wrote:
This series is the last set of fixes for the Talitos driver.
We now get a fully clean boot on both SEC1 (SEC1.2 on mpc885) and
SEC2 (SEC2.2 on mpc8321E) with CONFIG_CRYPTO_MANAGER_EXTRA_TESTS:
I am
On 6/11/2019 5:39 PM, Christophe Leroy wrote:
> This series is the last set of fixes for the Talitos driver.
>
> We now get a fully clean boot on both SEC1 (SEC1.2 on mpc885) and
> SEC2 (SEC2.2 on mpc8321E) with CONFIG_CRYPTO_MANAGER_EXTRA_TESTS:
>
I am getting below failures on a sec 3.3.2 (p102
On SEC1, hash provides wrong result when performing hashing in several
steps with input data SG list has more than one element. This was
detected with CONFIG_CRYPTO_MANAGER_EXTRA_TESTS:
[ 44.185947] alg: hash: md5-talitos test failed (wrong result) on test vector
6, cfg="random: may_sleep use_f
Next patch will require struct talitos_edesc to be defined
earlier in talitos.c
This patch moves it into talitos.h so that it can be used
from any place in talitos.c
Fixes: 37b5e8897eb5 ("crypto: talitos - chain in buffered data for ahash on
SEC1")
Cc: sta...@vger.kernel.org
Signed-off-by: Chris
icv_ool is not used anymore, drop it.
Fixes: 9cc87bc3613b ("crypto: talitos - fix AEAD processing")
Signed-off-by: Christophe Leroy
---
drivers/crypto/talitos.c | 3 ---
drivers/crypto/talitos.h | 2 --
2 files changed, 5 deletions(-)
diff --git a/drivers/crypto/talitos.c b/drivers/crypto/talit
When building for SEC1 only, talitos2_done functions are unneeded
and should go away.
For this, use has_ftr_sec1() which will always return true when only
SEC1 support is being built, allowing GCC to drop TALITOS2 functions.
Signed-off-by: Christophe Leroy
---
drivers/crypto/talitos.c | 2 +-
1
This series is the last set of fixes for the Talitos driver.
We now get a fully clean boot on both SEC1 (SEC1.2 on mpc885) and
SEC2 (SEC2.2 on mpc8321E) with CONFIG_CRYPTO_MANAGER_EXTRA_TESTS:
[3.385197] bus: 'platform': really_probe: probing driver talitos with
device ff02.crypto
[3
Le 11/06/2019 à 13:52, Horia Geanta a écrit :
On 6/6/2019 2:31 PM, Christophe Leroy wrote:
commit d84cc9c9524e ("crypto: talitos - fix ECB algs ivsize")
wrongly modified CBC algs ivsize instead of ECB aggs ivsize.
This restore the CBC algs original ivsize of removes ECB's ones.
Signed-off-b
On Tue, 2019-06-11 at 15:56 +0200, Ard Biesheuvel wrote:
>
> > > +++ b/net/mac80211/cfg.c
> > > @@ -402,9 +402,6 @@ static int ieee80211_add_key(struct wiphy *wiphy,
> > > struct net_device *dev,
> > > case WLAN_CIPHER_SUITE_WEP40:
> > > case WLAN_CIPHER_SUITE_TKIP:
> > > case WLAN_CIPHER_SU
On Tue, 11 Jun 2019 at 15:55, Johannes Berg wrote:
>
> On Tue, 2019-06-11 at 15:53 +0200, Ard Biesheuvel wrote:
> > On Tue, 11 Jun 2019 at 15:52, Johannes Berg
> > wrote:
> > >
> > > On Tue, 2019-06-11 at 15:47 +0200, Ard Biesheuvel wrote:
> > > >
> > > > +++ b/net/mac80211/mlme.c
> > > > @@ -50
On Tue, 2019-06-11 at 15:53 +0200, Ard Biesheuvel wrote:
> On Tue, 11 Jun 2019 at 15:52, Johannes Berg wrote:
> >
> > On Tue, 2019-06-11 at 15:47 +0200, Ard Biesheuvel wrote:
> > >
> > > +++ b/net/mac80211/mlme.c
> > > @@ -5038,8 +5038,6 @@ int ieee80211_mgd_auth(struct ieee80211_sub_if_data
>
On Tue, 11 Jun 2019 at 15:52, Johannes Berg wrote:
>
> On Tue, 2019-06-11 at 15:47 +0200, Ard Biesheuvel wrote:
> >
> > +++ b/net/mac80211/mlme.c
> > @@ -5038,8 +5038,6 @@ int ieee80211_mgd_auth(struct ieee80211_sub_if_data
> > *sdata,
> > auth_alg = WLAN_AUTH_OPEN;
> >
On Tue, 2019-06-11 at 15:47 +0200, Ard Biesheuvel wrote:
>
> +++ b/net/mac80211/mlme.c
> @@ -5038,8 +5038,6 @@ int ieee80211_mgd_auth(struct ieee80211_sub_if_data
> *sdata,
> auth_alg = WLAN_AUTH_OPEN;
> break;
> case NL80211_AUTHTYPE_SHARED_KEY:
> -
This is a follow-up to, and supersedes [0], which moved some WEP code from
the cipher to the skcipher interface, in order to reduce the use of the bare
cipher interface in non-crypto subsystem code.
Since using the skcipher interface to invoke the generic C implementation of
an algorithm that is k
The crypto API abstraction is not very useful for invoking ciphers
directly, especially in the case of arc4, which only has a generic
implementation in C. So let's invoke the library code directly.
Signed-off-by: Ard Biesheuvel
---
net/wireless/Kconfig | 1 +
net/wireless/lib80211_
Refactor the core rc4 handling so we can move most users to a library
interface, permitting us to drop the cipher interface entirely in a
future patch. This is part of an effort to simplify the crypto API
and improve its robustness against incorrect use.
Signed-off-by: Ard Biesheuvel
---
MAINTAI
The WEP code in the mac80211 subsystem currently uses the crypto
API to access the arc4 (RC4) cipher, which is overly complicated,
and doesn't really have an upside in this particular case, since
ciphers are always synchronous and therefore always implemented in
software. Given that we have no acce
The CIFS code uses the sync skcipher API to invoke the ecb(arc4) skcipher,
of which only a single generic C code implementation exists. This means
that going through all the trouble of using scatterlists etc buys us
very little, and we're better off just invoking the arc4 library directly.
Cc: lin
The crypto API abstraction is not very useful for invoking ciphers
directly, especially in the case of arc4, which only has a generic
implementation in C. So let's invoke the library code directly.
Signed-off-by: Ard Biesheuvel
---
net/wireless/lib80211_crypt_tkip.c | 46 +++-
1
The MPPE code uses the sync skcipher to invoke the ecb(arc4) skcipher,
of which only a single generic C code implementation exists. This means
that going through all the trouble of using scatterlists etc buys us
very little, and we're better off just invoking the arc4 library directly.
Note that t
There are no remaining users of the cipher implementation, and there
are no meaningful ways in which the arc4 cipher can be combined with
templates other than ECB (and the way we do provide that combination
is highly dubious to begin with).
So let's drop the arc4 cipher altogether, and only keep t
On 6/11/2019 3:38 PM, Christophe Leroy wrote:
>
>
> Le 11/06/2019 à 13:57, Horia Geanta a écrit :
>> On 6/6/2019 2:31 PM, Christophe Leroy wrote:
>>> Next patch will require struct talitos_edesc to be defined
>>> earlier in talitos.c
>>>
>>> This patch moves it into talitos.h so that it can be us
Le 11/06/2019 à 13:57, Horia Geanta a écrit :
On 6/6/2019 2:31 PM, Christophe Leroy wrote:
Next patch will require struct talitos_edesc to be defined
earlier in talitos.c
This patch moves it into talitos.h so that it can be used
from any place in talitos.c
Fixes: 37b5e8897eb5 ("crypto: tali
On 6/6/2019 2:31 PM, Christophe Leroy wrote:
> This series is the last set of fixes for the Talitos driver.
>
> We now get a fully clean boot on both SEC1 (SEC1.2 on mpc885) and
> SEC2 (SEC2.2 on mpc8321E) with CONFIG_CRYPTO_MANAGER_EXTRA_TESTS:
>
I get failures, probably due to patch 1/5:
alg:
On 6/6/2019 2:31 PM, Christophe Leroy wrote:
> Next patch will require struct talitos_edesc to be defined
> earlier in talitos.c
>
> This patch moves it into talitos.h so that it can be used
> from any place in talitos.c
>
> Fixes: 37b5e8897eb5 ("crypto: talitos - chain in buffered data for ahash
On 6/6/2019 2:31 PM, Christophe Leroy wrote:
> commit d84cc9c9524e ("crypto: talitos - fix ECB algs ivsize")
> wrongly modified CBC algs ivsize instead of ECB aggs ivsize.
>
> This restore the CBC algs original ivsize of removes ECB's ones.
>
> Signed-off-by: Christophe Leroy
> Fixes: d84cc9c952
On 6/7/2019 11:03 PM, Andrey Smirnov wrote:
> From: Chris Spencer
>
> There are no clocks that the CAAM driver needs to initialise on the
> i.MX8.
>
RM lists 5 clocks for CAAM module (instance.clock): caam.aclk, caam.ipg_clk,
caam.ipg_clk_s, caam_exsc.aclk_exsc, caam_mem.clk
47 matches
Mail list logo
