On Mon, Oct 26, 2020 at 8:26 PM Eric Biggers wrote:
>
> Here's the version of eboiv_create() I recommend (untested):
>
> static int eboiv_create(struct crypto_template *tmpl, struct rtattr **tb)
> {
> struct skcipher_instance *inst;
> struct eboiv_instance_ctx *ictx;
> str
--
Hello,
Greetings and hope this email meets you well?
I am Dr. Hamza Kabore, the chief Medical consultant at a reputable
clinic here in Ouagadougou, Burkina Faso and I have a Patient who
hails from the Republic of philippines but unfortunately is in coma
right now due to complications from a
On Mon, Oct 26, 2020 at 06:10:59PM -0500, Gustavo A. R. Silva wrote:
> On Mon, Oct 26, 2020 at 04:21:48PM -0500, Gustavo A. R. Silva wrote:
> > > +/*
> > > + * Linux v4.12 and later removed the 64-byte limit on salg_name[]; it's
> > > now an
> > > + * arbitrary-length field. We had to keep the or
(+ Andy)
On Tue, 27 Oct 2020 at 00:04, Ard Biesheuvel wrote:
>
> On Tue, 27 Oct 2020 at 00:03, Eric Biggers wrote:
> >
> > On Tue, Oct 27, 2020 at 12:00:27AM +0100, Ard Biesheuvel wrote:
> > > PAC pointer authentication signs the return address against the value
> > > of the stack pointer, to pr
On Mon, Oct 26, 2020 at 04:21:48PM -0500, Gustavo A. R. Silva wrote:
> > +/*
> > + * Linux v4.12 and later removed the 64-byte limit on salg_name[]; it's
> > now an
> > + * arbitrary-length field. We had to keep the original struct above for
> > source
> > + * compatibility with existing userspa
On Tue, 27 Oct 2020 at 00:03, Eric Biggers wrote:
>
> On Tue, Oct 27, 2020 at 12:00:27AM +0100, Ard Biesheuvel wrote:
> > PAC pointer authentication signs the return address against the value
> > of the stack pointer, to prevent stack overrun exploits from corrupting
> > the control flow. However,
On Tue, Oct 27, 2020 at 12:00:27AM +0100, Ard Biesheuvel wrote:
> PAC pointer authentication signs the return address against the value
> of the stack pointer, to prevent stack overrun exploits from corrupting
> the control flow. However, this requires that the AUTIASP is issued with
> SP holding t
PAC pointer authentication signs the return address against the value
of the stack pointer, to prevent stack overrun exploits from corrupting
the control flow. However, this requires that the AUTIASP is issued with
SP holding the same value as it held when the PAC value was generated.
The Poly1305
On Mon, Oct 26, 2020 at 10:23:35PM +0100, 'Jann Horn' via syzkaller-bugs wrote:
> On Mon, Oct 26, 2020 at 9:08 PM Eric Biggers wrote:
> > Commit 3f69cc60768b ("crypto: af_alg - Allow arbitrarily long algorithm
> > names") made the kernel start accepting arbitrarily long algorithm names
> > in sock
Hi Gilad,
I love your patch! Perhaps something to improve:
[auto build test WARNING on cryptodev/master]
[also build test WARNING on crypto/master]
[cannot apply to dm/for-next v5.10-rc1 next-20201026]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting
On 10/26/2020 9:06 PM, Iuliana Prodan wrote:
> Use the new crypto_engine_alloc_init_and_set() function to
> initialize crypto-engine and enable retry mechanism.
>
> Set the maximum size for crypto-engine software queue based on
> Job Ring size (JOBR_DEPTH) and a threshold (reserved for the
> non-c
Hi,
On Mon, Oct 26, 2020 at 01:07:15PM -0700, Eric Biggers wrote:
> From: Eric Biggers
>
> Commit 3f69cc60768b ("crypto: af_alg - Allow arbitrarily long algorithm
> names") made the kernel start accepting arbitrarily long algorithm names
> in sockaddr_alg. However, the actual length of the salg
Hi,
On 26/10/2020 21:48:07+0800, Zhang Qilong wrote:
> The 'break' is unnecessary because of previous
> 'return', discard it.
>
This is a duplicate of
https://lore.kernel.org/linux-crypto/20201019193653.13757-1-t...@redhat.com/T/#u
> Signed-off-by: Zhang Qilong
> ---
> drivers/crypto/atmel-s
On 19/10/2020 12:36:53-0700, t...@redhat.com wrote:
> From: Tom Rix
>
> A break is not needed if it is preceded by a return
>
> Signed-off-by: Tom Rix
Reviewed-by: Alexandre Belloni
> ---
> drivers/crypto/atmel-sha.c | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/drivers/crypto/atm
From: Eric Biggers
Commit 3f69cc60768b ("crypto: af_alg - Allow arbitrarily long algorithm
names") made the kernel start accepting arbitrarily long algorithm names
in sockaddr_alg. However, the actual length of the salg_name field
stayed at the original 64 bytes.
This is broken because the kern
On 26/10/2020 19:39, Eric Biggers wrote:
> On Mon, Oct 26, 2020 at 07:29:57PM +0100, Milan Broz wrote:
>> On 26/10/2020 18:52, Eric Biggers wrote:
>>> On Mon, Oct 26, 2020 at 03:04:46PM +0200, Gilad Ben-Yossef wrote:
Replace the explicit EBOIV handling in the dm-crypt driver with calls
Use the new crypto_engine_alloc_init_and_set() function to
initialize crypto-engine and enable retry mechanism.
Set the maximum size for crypto-engine software queue based on
Job Ring size (JOBR_DEPTH) and a threshold (reserved for the
non-crypto-API requests that are not passed through crypto-eng
On Tue, Oct 27, 2020 at 05:41:55AM +1100, Herbert Xu wrote:
>
> The point is that people rebuilding their kernel can end up with a
> broken system. Just set a default on EBOIV if dm-crypt is on.
That's not enough as it's an existing option. So we need to
add a new Kconfig option with a default
On Mon, Oct 26, 2020 at 11:39:36AM -0700, Eric Biggers wrote:
>
> CONFIG_DM_CRYPT can either select every weird combination of algorithms anyone
> can ever be using, or it can select some defaults and require any other needed
> algorithms to be explicitly selected.
>
> In reality, dm-crypt has ne
On Mon, Oct 26, 2020 at 07:29:57PM +0100, Milan Broz wrote:
> On 26/10/2020 18:52, Eric Biggers wrote:
> > On Mon, Oct 26, 2020 at 03:04:46PM +0200, Gilad Ben-Yossef wrote:
> >> Replace the explicit EBOIV handling in the dm-crypt driver with calls
> >> into the crypto API, which now possesses the c
On 26/10/2020 18:52, Eric Biggers wrote:
> On Mon, Oct 26, 2020 at 03:04:46PM +0200, Gilad Ben-Yossef wrote:
>> Replace the explicit EBOIV handling in the dm-crypt driver with calls
>> into the crypto API, which now possesses the capability to perform
>> this processing within the crypto subsystem.
On Mon, Oct 26, 2020 at 11:24:50AM -0700, Eric Biggers wrote:
> > +static int eboiv_create(struct crypto_template *tmpl, struct rtattr **tb)
> > +{
> > + struct crypto_attr_type *algt;
> > + const char *inner_cipher_name;
> > + struct skcipher_instance *skcipher_inst = NULL;
> > + struct cr
On Mon, Oct 26, 2020 at 03:04:44PM +0200, Gilad Ben-Yossef wrote:
> diff --git a/crypto/eboiv.c b/crypto/eboiv.c
> new file mode 100644
> index ..467833e89139
> --- /dev/null
> +++ b/crypto/eboiv.c
> @@ -0,0 +1,295 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * EBOIV skcipher tem
Hi Gilad,
I love your patch! Perhaps something to improve:
[auto build test WARNING on cryptodev/master]
[also build test WARNING on crypto/master]
[cannot apply to dm/for-next v5.10-rc1 next-20201026]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting
On 10/26/2020 7:11 PM, Iuliana Prodan wrote:
> On 10/26/2020 5:36 PM, Horia Geantă wrote:
>> On 10/21/2020 11:07 PM, Iuliana Prodan wrote:
[...]
>>> +#define CRYPTO_ENGINE_MAX_QLEN (2 * (JOBR_DEPTH - THRESHOLD))
>>> +
>> What's the logic behind multiplying by 2?
>
> I added the 2 as the number of
On Mon, Oct 26, 2020 at 03:04:46PM +0200, Gilad Ben-Yossef wrote:
> Replace the explicit EBOIV handling in the dm-crypt driver with calls
> into the crypto API, which now possesses the capability to perform
> this processing within the crypto subsystem.
>
> Signed-off-by: Gilad Ben-Yossef
>
> --
The pull request you sent on Mon, 26 Oct 2020 12:11:59 +1100:
> git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6.git linus
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/41ba50b0572e90ed3d24fe4def54567e9050bc47
Thank you!
--
Deet-doot-dot, I am a bot
On 10/26/2020 5:36 PM, Horia Geantă wrote:
On 10/21/2020 11:07 PM, Iuliana Prodan wrote:
Use the new crypto_engine_alloc_init_and_set() function to
initialize crypto-engine and enable retry mechanism.
Set the maximum size for crypto-engine software queue based on
Job Ring size (JOBR_DEPTH) and
On Tue, Oct 06, 2020 at 08:51:45PM -0700, Eric Biggers wrote:
> On Fri, Sep 18, 2020 at 02:57:05PM -0700, Eric Biggers wrote:
> > On Fri, Sep 18, 2020 at 04:42:07PM -0400, Theodore Y. Ts'o wrote:
>
> Ted, any further feedback on this? Are you planning to apply this patch?
>
> - Eric
Ping.
On Tue, Oct 06, 2020 at 08:50:21PM -0700, Eric Biggers wrote:
> On Tue, Sep 15, 2020 at 09:19:08PM -0700, Eric Biggers wrote:
> > From: Eric Biggers
> >
> > The RNDRESEEDCRNG ioctl reseeds the primary_crng from itself, which
> > doesn't make sense. Reseed it from the input_pool instead.
> >
> >
On Tue, Oct 06, 2020 at 08:50:58PM -0700, Eric Biggers wrote:
> On Tue, Sep 15, 2020 at 09:36:52PM -0700, Eric Biggers wrote:
> > From: Eric Biggers
> >
> > Remove some dead code that was left over following commit 90ea1c6436d2
> > ("random: remove the blocking pool").
> >
> > Signed-off-by: Eri
From: Eric Biggers
Currently, by default crypto self-test failures only result in a
pr_warn() message and an "unknown" status in /proc/crypto. Both of
these are easy to miss. There is also an option to panic the kernel
when a test fails, but that can't be the default behavior.
A crypto self-te
From: Eric Biggers
Add crypto_aead_driver_name(), which is analogous to
crypto_skcipher_driver_name().
Signed-off-by: Eric Biggers
---
include/crypto/aead.h | 5 +
1 file changed, 5 insertions(+)
diff --git a/include/crypto/aead.h b/include/crypto/aead.h
index c32a6f5664e9a..fcc12c593ef8b
From: Eric Biggers
When alg_test() is called from tcrypt.ko rather than from the algorithm
registration code, "driver" is actually the algorithm name, not the
driver name. So it shouldn't be used in places where a driver name is
wanted, e.g. when reporting a test failure or when checking whether
From: Eric Biggers
When alg_test() is called from tcrypt.ko rather than from the algorithm
registration code, "driver" is actually the algorithm name, not the
driver name. So it shouldn't be used in places where a driver name is
wanted, e.g. when reporting a test failure or when checking whether
When alg_test() is called from tcrypt.ko rather than from the algorithm
registration code, "driver" is actually the algorithm name, not the
driver name. So it shouldn't be used in places where a driver name is
wanted, e.g. when reporting a test failure or when checking whether the
driver is the ge
From: Eric Biggers
When alg_test() is called from tcrypt.ko rather than from the algorithm
registration code, "driver" is actually the algorithm name, not the
driver name. So it shouldn't be used in places where a driver name is
wanted, e.g. when reporting a test failure or when checking whether
On 10/21/2020 11:07 PM, Iuliana Prodan wrote:
> Use the new crypto_engine_alloc_init_and_set() function to
> initialize crypto-engine and enable retry mechanism.
>
> Set the maximum size for crypto-engine software queue based on
> Job Ring size (JOBR_DEPTH) and a threshold (reserved for the
> non-
The 'break' is unnecessary because of previous
'return', discard it.
Signed-off-by: Zhang Qilong
---
drivers/crypto/atmel-sha.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/crypto/atmel-sha.c b/drivers/crypto/atmel-sha.c
index 75ccf41a7cb9..0eb6f54e3b66 100644
--- a/drivers/crypto/
On Fri, Oct 16, 2020 at 06:27:57PM +0100, Daniele Alessandrelli wrote:
> From: Declan Murphy
>
> Add device-tree bindings for the Intel Keem Bay Offload Crypto Subsystem
> (OCS) Hashing Control Unit (HCU) crypto driver.
>
> Signed-off-by: Declan Murphy
> Signed-off-by: Daniele Alessandrelli
>
BitLocker eboiv support, which was removed in
commit 1d8b41ff6991 ("crypto: ccree - remove bitlocker cipher")
is reintroduced based on the crypto API new support for
eboiv.
Signed-off-by: Gilad Ben-Yossef
Fixes: 1d8b41ff6991 ("crypto: ccree - remove bitlocker cipher")
---
drivers/crypto/ccree/cc
Replace the explicit EBOIV handling in the dm-crypt driver with calls
into the crypto API, which now possesses the capability to perform
this processing within the crypto subsystem.
Signed-off-by: Gilad Ben-Yossef
---
drivers/md/Kconfig| 1 +
drivers/md/dm-crypt.c | 61 ++--
Add test vectors for the use of the EBOIV template with cbc(aes)
modes as it is being used by dm-crypt for BitLocker support.
Vectors taken from dm-crypt test suite images.
Signed-off-by: Gilad Ben-Yossef
---
crypto/tcrypt.c | 9 ++
crypto/testmgr.c | 6 +
crypto/testmgr.h | 279 ++
This series creates an EBOIV template that produces a skcipher
transform which passes through all operations to the skcipher, while
using the same skcipher and key to encrypt the input IV, which is
assumed to be a sector offset, although this is not enforced.
This matches dm-crypt use of EBOIV to
Encrypted byte-offset initialization vector (EBOIV) is an IV
generation method that is used in some cases by dm-crypt for
supporting the BitLocker volume encryption used by Windows 8
and onwards as a backwards compatible version in lieu of XTS
support. Support for eboiv was added to dm-crypt in 5.6
From: Arvind Sankar
> Sent: 25 October 2020 23:54
...
> > That's odd, the BLEND loop is about 20 instructions.
> > I wouldn't expect unrolling to help - unless you manage
> > to use 16 registers for the active W[] values.
> >
>
> I am not sure about what's going on inside the hardware, but even wi
On Sun, 25 Oct 2020 at 15:31, Arvind Sankar wrote:
>
> Unrolling the LOAD and BLEND loops improves performance by ~8% on x86_64
> (tested on Broadwell Xeon) while not increasing code size too much.
>
> Signed-off-by: Arvind Sankar
> Reviewed-by: Eric Biggers
Acked-by: Ard Biesheuvel
> ---
>
On Sun, 25 Oct 2020 at 15:31, Arvind Sankar wrote:
>
> This reduces code size substantially (on x86_64 with gcc-10 the size of
> sha256_update() goes from 7593 bytes to 1952 bytes including the new
> SHA256_K array), and on x86 is slightly faster than the full unroll
> (tested on Broadwell Xeon).
On Sun, 25 Oct 2020 at 15:31, Arvind Sankar wrote:
>
> The temporary W[] array is currently zeroed out once every call to
> sha256_transform(), i.e. once every 64 bytes of input data. Moving it to
> sha256_update() instead so that it is cleared only once per update can
> save about 2-3% of the tot
On Sun, 25 Oct 2020 at 15:31, Arvind Sankar wrote:
>
> The assignments to clear a through h and t1/t2 are optimized out by the
> compiler because they are unused after the assignments.
>
> Clearing individual scalar variables is unlikely to be useful, as they
> may have been assigned to registers,
On Sun, 25 Oct 2020 at 15:31, Arvind Sankar wrote:
>
> Without the barrier_data() inside memzero_explicit(), the compiler may
> optimize away the state-clearing if it can tell that the state is not
> used afterwards. At least in lib/crypto/sha256.c:__sha256_final(), the
> function can get inlined
On Sun, 25 Oct 2020 at 15:31, Arvind Sankar wrote:
>
> Without the barrier_data() inside memzero_explicit(), the compiler may
> optimize away the state-clearing if it can tell that the state is not
> used afterwards.
>
> Signed-off-by: Arvind Sankar
Acked-by: Ard Biesheuvel
I agree with Eric t
52 matches
Mail list logo
