Nak. We would rather not have this in the builtin config at this time.
Thanks,
Steve
-Original Message-
From: Benjamin Marzinski
Sent: Wednesday, August 14, 2019 2:15 PM
To: Christophe Varoqui
Cc: device-mapper development ; Schremmer, Steven
Subject: [PATCH] libmultipath: builtin co
On Thu, Aug 15, 2019 at 08:15:29AM +0300, Ard Biesheuvel wrote:
>
> So what about checking that the cipher key size matches the shash
> digest size, or that the cipher block size matches the skcipher IV
> size? This all moves to the TFM init function?
I don't think you need to check those things.
From: Martin Wilck
This new configuration parameter can be used to selectively
enable foreign libraries. The value is a regular expression,
against which foreign library names such as "nvme" are matched.
By setting this to a value that matches no foreign library
(e.g. "^$" or "NONE"), foreign cod
From: Martin Wilck
Hi Christophe, hi Ben,
This is my alternative take to Ben's "multipath: add print_foreign option"
patch. I'd prefer it because it's more generic and more flexible for future
extensions.
Regards
Martin
Martin Wilck (2):
multipath.conf: add "enable_foreign" parameter
multi
From: Martin Wilck
Add documentation for foreign library support, and for the
"enable_foreign" parameter.
Signed-off-by: Martin Wilck
---
multipath/multipath.conf.5 | 40 ++
1 file changed, 40 insertions(+)
diff --git a/multipath/multipath.conf.5 b/multipat
On Thu, 15 Aug 2019 at 14:35, Herbert Xu wrote:
>
> On Thu, Aug 15, 2019 at 08:15:29AM +0300, Ard Biesheuvel wrote:
> >
> > So what about checking that the cipher key size matches the shash
> > digest size, or that the cipher block size matches the skcipher IV
> > size? This all moves to the TFM i
On Thu, 15 Aug 2019 at 20:46, Ard Biesheuvel wrote:
>
> On Thu, 15 Aug 2019 at 14:35, Herbert Xu wrote:
> >
> > On Thu, Aug 15, 2019 at 08:15:29AM +0300, Ard Biesheuvel wrote:
> > >
> > > So what about checking that the cipher key size matches the shash
> > > digest size, or that the cipher block
The plain CBC driver and the CTS one share some code that iterates over
a scatterwalk and invokes the CBC asm code to do the processing. The
upcoming ESSIV/CBC mode will clone that pattern for the third time, so
let's factor it out first.
Signed-off-by: Ard Biesheuvel
---
arch/arm64/crypto/aes-g
Implement a template that wraps a (skcipher,shash) or (aead,shash) tuple
so that we can consolidate the ESSIV handling in fscrypt and dm-crypt and
move it into the crypto API. This will result in better test coverage, and
will allow future changes to make the bare cipher interface internal to the
c
Add a test vector for the ESSIV mode that is the most widely used,
i.e., using cbc(aes) and sha256, in both skcipher and AEAD modes
(the latter is used by tcrypt to encapsulate the authenc template
or h/w instantiations of the same)
Signed-off-by: Ard Biesheuvel
---
crypto/tcrypt.c | 9 +
cry
This series creates an ESSIV template that produces a skcipher or AEAD
transform based on a tuple of the form ',' (or ','
for the AEAD case). It exposes the encapsulated sync or async skcipher/aead by
passing through all operations, while using the cipher/shash pair to transform
the input IV into a
Add an accelerated version of the 'essiv(cbc(aes),sha256)' skcipher,
which is used by fscrypt or dm-crypt on systems where CBC mode is
signficantly more performant than XTS mode (e.g., when using a h/w
accelerator which supports the former but not the latter) This avoids
a separate call into the AE
12 matches
Mail list logo