On Mon, 11 Jan 2021 at 22:31, Ard Biesheuvel wrote:
>
> On Mon, 11 Jan 2021 at 22:05, Eric Biggers wrote:
> >
> > On Mon, Jan 11, 2021 at 05:52:30PM +0100, Ard Biesheuvel wrote:
> > > CRC-T10DIF is a very poor match for the crypto API:
> > > - every user in the kernel calls it via a library wrapp
This (sub)set is intended to go through the keyrings tree or is it all going
through the crypto tree now?
David
On Thu, 28 Jan 2021 at 06:04, Herbert Xu wrote:
>
> On Fri, Jan 22, 2021 at 03:09:52PM +0800, Meng Yu wrote:
> > 1. Add ecc curves(P224, P384, P521) for ECDH;
>
> OK I think this is getting unwieldy.
>
> In light of the fact that we already have hardware that supports
> a specific subset of curves
On Wed, Dec 16, 2020 at 6:47 PM Chang S. Bae wrote:
>
> When the system state switches to these sleep states, the internal key gets
> reset. Since this system transition is transparent to userspace, the
> internal key needs to be restored properly.
>
> Key Locker provides a mechanism to back up th
On Thu, Jan 28, 2021 at 11:30:23AM +0100, Ard Biesheuvel wrote:
>
> But this also begs the question which ecdh-nist-pXXX implementations
> we actually need? Why are we exposing these curves in the first place?
Once they're distinct algorithms, we can then make sure that only
the ones that are used
Add a macro cond_yield that branches to a specified label when called if
the TIF_NEED_RESCHED flag is set and decreasing the preempt count would
make the task preemptible again, resulting in a schedule to occur. This
can be used by kernel mode SIMD code that keeps a lot of state in SIMD
registers,
Given how kernel mode NEON code disables preemption (to ensure that the
FP/SIMD register state is protected without having to context switch it),
we need to take care not to let those algorithms operate on unbounded
input data, or we may end up with excessive scheduling blackouts on
CONFIG_PREEMPT
Instead of calling into kernel_neon_end() and kernel_neon_begin() (and
potentially into schedule()) from the assembler code when running in
task mode and a reschedule is pending, perform only the preempt count
check in assembler, but simply return early in this case, and let the C
code deal with th
Instead of calling into kernel_neon_end() and kernel_neon_begin() (and
potentially into schedule()) from the assembler code when running in
task mode and a reschedule is pending, perform only the preempt count
check in assembler, but simply return early in this case, and let the C
code deal with th
The users of the conditional NEON yield macros have all been switched to
the simplified cond_yield macro, and so the NEON specific ones can be
removed.
Signed-off-by: Ard Biesheuvel
---
arch/arm64/include/asm/assembler.h | 70
1 file changed, 70 deletions(-)
diff --git a/ar
There is no need for elaborate yield handling in the bit-sliced NEON
implementation of AES, given that skciphers are naturally bounded by the
size of the chunks returned by the skcipher_walk API. So remove the
yield calls from the asm code.
Signed-off-by: Ard Biesheuvel
---
arch/arm64/crypto/aes
Instead of yielding from the bowels of the asm routine if a reschedule
is needed, divide up the input into 4 KB chunks in the C glue. This
simplifies the code substantially, and avoids scheduling out the task
with the asm routine on the call stack, which is undesirable from a
CFI/instrumentation po
Instead of calling into kernel_neon_end() and kernel_neon_begin() (and
potentially into schedule()) from the assembler code when running in
task mode and a reschedule is pending, perform only the preempt count
check in assembler, but simply return early in this case, and let the C
code deal with th
Signed-off-by: Ard Biesheuvel
---
arch/arm64/crypto/aes-glue.c | 21 +---
arch/arm64/crypto/aes-modes.S | 52 +++-
2 files changed, 33 insertions(+), 40 deletions(-)
diff --git a/arch/arm64/crypto/aes-glue.c b/arch/arm64/crypto/aes-glue.c
index e7f116d833b9..17e735931a0c 100
Instead of calling into kernel_neon_end() and kernel_neon_begin() (and
potentially into schedule()) from the assembler code when running in
task mode and a reschedule is pending, perform only the preempt count
check in assembler, but simply return early in this case, and let the C
code deal with th
On 1/28/21 4:19 AM, David Howells wrote:
This (sub)set is intended to go through the keyrings tree or is it all going
through the crypto tree now?
Patch 1/3 should go through 'crypto', the other ones through 'keyrings'.
Stefan
David
Stefan Berger wrote:
> > This (sub)set is intended to go through the keyrings tree or is it all going
> > through the crypto tree now?
>
>
> Patch 1/3 should go through 'crypto', the other ones through 'keyrings'.
Do 2 & 3 depend on 1?
David
On 1/28/21 8:54 AM, David Howells wrote:
Stefan Berger wrote:
This (sub)set is intended to go through the keyrings tree or is it all going
through the crypto tree now?
Patch 1/3 should go through 'crypto', the other ones through 'keyrings'.
Do 2 & 3 depend on 1?
Functionality-wise, yes,
On Jan 28, 2021, at 02:34, Rafael J. Wysocki wrote:
> On Wed, Dec 16, 2020 at 6:47 PM Chang S. Bae wrote:
>>
>> + keybackup_status = read_keylocker_backup_status();
>> + if (!(keybackup_status & BIT(0))) {
>> + pr_err("x86/keylocker: internal key restoration failed with
Hi Mickaël,
I could pull your patches (unless Jarkko wants to), but can you please drop
the patches that are also in my keys-misc branch lest one or other (or both)
of our branches get dropped in the next merge window due to conflicts?
Ideally, can you base your branch on my keys-misc branch?
On 28/01/2021 17:52, David Howells wrote:
>
> Hi Mickaël,
Hi David,
>
> I could pull your patches (unless Jarkko wants to), but can you please drop
> the patches that are also in my keys-misc branch lest one or other (or both)
> of our branches get dropped in the next merge window due to conf
I noticed that commits in your branch are not up to date with latest
Jarkoo reviews on my patches (see changes since v2). There is no
conflict if you replace conflicting patches from your branch by patches
from this series. Could you replace your duplicate commits with this
patch series?
On 28/01
On Sun, Jan 24, 2021 at 03:03:28PM +0100, Stephan Müller wrote:
> RFC5869 specifies an extract and expand two-step key derivation
> function. The HKDF implementation is provided as a service function that
> operates on a caller-provided HMAC handle. The caller has to allocate
> the HMAC shash handl
Hello Sukadev,
On 1/28/21 8:07 PM, Sukadev Bhattiprolu wrote:
Slightly off-topic, should ndo_stop() also return a void? Its return value
seems to be mostly ignored and [...]
I don't know enough about the network stack to tell. Probably it's a
good idea to start a separate thread for this and
Please prefix the commit subject with "fscrypt: " rather than "fs: ".
On Sun, Jan 24, 2021 at 03:04:31PM +0100, Stephan Müller wrote:
> diff --git a/fs/crypto/hkdf.c b/fs/crypto/hkdf.c
> index e0ec21055505..ae236b42b1f0 100644
> --- a/fs/crypto/hkdf.c
> +++ b/fs/crypto/hkdf.c
> @@ -9,7 +9,7 @@
>
On Sun, Jan 24, 2021 at 03:04:31PM +0100, Stephan Müller wrote:
> @@ -74,16 +57,14 @@ int fscrypt_init_hkdf(struct fscrypt_hkdf *hkdf, const u8
> *master_key,
> return PTR_ERR(hmac_tfm);
> }
>
> - if (WARN_ON(crypto_shash_digestsize(hmac_tfm) != sizeof(prk))) {
> + if
On Sun, Jan 24, 2021 at 03:04:50PM +0100, Stephan Müller wrote:
> The clearing of the OKM memory buffer in case of an error is already
> performed by the HKDF implementation crypto_hkdf_expand. Thus, the
> code clearing is not needed any more in the file system code base.
>
> Signed-off-by: Stepha
On Thu, Jan 28, 2021 at 02:06:17PM +0100, Ard Biesheuvel wrote:
> Add a macro cond_yield that branches to a specified label when called if
> the TIF_NEED_RESCHED flag is set and decreasing the preempt count would
> make the task preemptible again, resulting in a schedule to occur. This
> can be use
On Thu, Jan 28, 2021 at 08:24:01PM +, Will Deacon wrote:
> On Thu, Jan 28, 2021 at 02:06:17PM +0100, Ard Biesheuvel wrote:
> > Add a macro cond_yield that branches to a specified label when called if
> > the TIF_NEED_RESCHED flag is set and decreasing the preempt count would
> > make the task p
On Thu, 28 Jan 2021 at 21:25, Will Deacon wrote:
>
> On Thu, Jan 28, 2021 at 08:24:01PM +, Will Deacon wrote:
> > On Thu, Jan 28, 2021 at 02:06:17PM +0100, Ard Biesheuvel wrote:
> > > Add a macro cond_yield that branches to a specified label when called if
> > > the TIF_NEED_RESCHED flag is se
On Wed, Jan 27, 2021 at 07:14:10PM -0500, Stefan Berger wrote:
> From: Stefan Berger
>
> Add support for parsing the parameters of a NIST P256 or NIST P192 key.
> Enable signature verification using these keys.
>
> Signed-off-by: Stefan Berger
> Cc: Herbert Xu
> Cc: "David S. Miller"
> Cc: li
On 1/28/21 5:30 AM, Ard Biesheuvel wrote:
On Thu, 28 Jan 2021 at 06:04, Herbert Xu wrote:
On Fri, Jan 22, 2021 at 03:09:52PM +0800, Meng Yu wrote:
1. Add ecc curves(P224, P384, P521) for ECDH;
OK I think this is getting unwieldy.
In light of the fact that we already have hardware that suppor
On Thu, Jan 28, 2021 at 09:49:41PM -0500, Stefan Berger wrote:
>
> In my patch series I initially had registered the akciphers under the names
> ecc-nist-p192 and ecc-nist-p256 but now, in V4, joined them together as
> 'ecdsa'. This may be too generic for a name. Maybe it should be called
> ecsda-n
On Thu, Jan 21, 2021 at 10:11:08AM +0530, Allen Pais wrote:
> From: Allen Pais
>
> In preparation for unconditionally passing the
> struct tasklet_struct pointer to all tasklet
> callbacks, switch to using the new tasklet_setup()
> and from_tasklet() to pass the tasklet pointer explicitly.
>
> S
On Mon, Jan 18, 2021 at 04:18:19PM +0800, Hui Tang wrote:
> Uacce SysFS support more algorithms inqury such as
> 'ecdh/ecdsa/sm2/x25519/x448'
>
> Signed-off-by: Hui Tang
> Reviewed-by: Zaibo Xu
> ---
> drivers/crypto/hisilicon/hpre/hpre_main.c | 5 -
> 1 file changed, 4 insertions(+), 1 del
On Mon, Jan 18, 2021 at 04:17:25PM +0800, Hui Tang wrote:
> 1.One CE error is detecting timeout of generating a random number.
> 2.Another is detecting timeout of SVA prefetching address.
>
> Signed-off-by: Hui Tang
> Reviewed-by: Zaibo Xu
> ---
> drivers/crypto/hisilicon/hpre/hpre_main.c | 8 +
On Wed, Jan 20, 2021 at 06:57:24PM +, Christophe Leroy wrote:
> Talitos Security Engine AESU considers any input
> data size that is not a multiple of 16 bytes to be an error.
> This is not a problem in general, except for Counter mode
> that is a stream cipher and can have an input of any size
On Thu, Jan 21, 2021 at 02:07:28PM +0100, Ard Biesheuvel wrote:
> Remove a set of algorithms that are never used in the kernel, and are
> highly unlikely to be depended upon by user space either.
>
> Cc: Eric Biggers
> Cc: Herbert Xu
>
> Ard Biesheuvel (5):
> crypto: remove RIPE-MD 128 hash a
On Mon, Jan 18, 2021 at 04:15:40PM +0800, Hui Tang wrote:
> Delete 'HPRE_RAS_ECC1BIT_TH' register setting of hpre,
> since register 'QM_RAS_CE_THRESHOLD' of qm has done this work.
>
> Signed-off-by: Hui Tang
> Reviewed-by: Zaibo Xu
> ---
> drivers/crypto/hisilicon/hpre/hpre_main.c | 2 --
> 1 f
On Mon, Jan 25, 2021 at 09:41:12AM -0800, Randy Dunlap wrote:
> on x86_64:
>
> ld: drivers/crypto/marvell/octeontx2/otx2_cptpf_main.o: in function
> `cptpf_flr_wq_handler':
> otx2_cptpf_main.c:(.text+0x2b): undefined reference to
> `otx2_mbox_alloc_msg_rsp'
Thanks for the report. The issue is
On 1/28/21 9:48 PM, Herbert Xu wrote:
> On Mon, Jan 25, 2021 at 09:41:12AM -0800, Randy Dunlap wrote:
>> on x86_64:
>>
>> ld: drivers/crypto/marvell/octeontx2/otx2_cptpf_main.o: in function
>> `cptpf_flr_wq_handler':
>> otx2_cptpf_main.c:(.text+0x2b): undefined reference to
>> `otx2_mbox_alloc_ms
41 matches
Mail list logo
