er's name.
> Reviewed-by: Mike Mike Snitzer
Thanks!
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
dm-devel mailing list
dm-devel@redhat.com
https://listman.redhat.com/mailman/listinfo/dm-devel
. Fix it by adding it to
reqsize.
Fixes: e3023094dffb ("dm crypt: Avoid using MAX_CIPHER_BLOCKSIZE")
Reported-by: Tatu Heikkil�
Signed-off-by: Herbert Xu
diff --git a/drivers/md/dm-crypt.c b/drivers/md/dm-crypt.c
index f2662c21a6df..5315fd261c23 100644
--- a/drivers/md/dm-crypt.c
+
support for lskcipher algorithms")
> 8aee5d4ebd11 ("crypto: lskcipher - Add compatibility wrapper around ECB")
>
> Is this a known issue?
Thanks for the report. I'll look into this.
Cheers,
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
P
sed the fact that it was preallocating memory with
GFP_KERNEL.
So perhaps the answer is to adjust our API to allow the drivers to
pre-allocate memory. I'll look into this.
Thanks,
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubk
; Reviewed-by: Mike Snitzer
Thanks!
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
dm-devel mailing list
dm-devel@redhat.com
https://listman.redhat.com/mailman/listinfo/dm-devel
MAX_CIPHER_BLOCKSIZE is an internal implementation detail and should
not be relied on by users of the Crypto API.
Instead of storing the IV on the stack, allocate it together with
the crypto request.
Signed-off-by: Herbert Xu
---
drivers/md/dm-crypt.c | 15 +++
1 file changed
v2 adds the actual algapi conversion which went missing.
---8<---
This patch does the final flag day conversion of all completion
functions which are now all contained in the Crypto API.
Signed-off-by: Herbert Xu
---
crypto/adiantum.c |5 +---
crypto/af_alg.c|
gorithms may require fallbacks
for esoteric reasons. For example, drivers/crypto/amcc appears to
require a fallback for certain input parameters which may or may not
be possible with TLS.
To be on the safe side I would do a backport once this has been
in mainline for a little bit.
Cheers,
--
Em
nly uses aead_req to get ahold of
the tls_rec object. So we could pass that in instead of aead_req
to simplify the code.
Suggested-by: Jakub Kicinski
Signed-off-by: Herbert Xu
diff --git a/net/tls/tls_sw.c b/net/tls/tls_sw.c
index 0515cda32fe2..6dfec2e8fdfa 100644
--- a/net/tls/tls_sw.c
+++ b/net/t
On Mon, Feb 06, 2023 at 11:10:08PM -0800, Jakub Kicinski wrote:
> On Mon, 6 Feb 2023 18:21:06 +0800 Herbert Xu wrote:
> > The crypto completion function currently takes a pointer to a
> > struct crypto_async_request object. However, in reality the API
> > does not allo
This patch removes the temporary scaffolding now that the comletion
function signature has been converted.
Signed-off-by: Herbert Xu
---
net/ipv4/ah4.c |8
net/ipv4/esp4.c | 16
2 files changed, 12 insertions(+), 12 deletions(-)
diff --git a/net/ipv4/ah4.c b
This patch removes the temporary scaffolding now that the comletion
function signature has been converted.
Signed-off-by: Herbert Xu
---
include/linux/crypto.h |6 --
1 file changed, 6 deletions(-)
diff --git a/include/linux/crypto.h b/include/linux/crypto.h
index 80f6350fb588
This patch removes the temporary scaffolding now that the comletion
function signature has been converted.
Signed-off-by: Herbert Xu
---
net/tls/tls_sw.c |8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/net/tls/tls_sw.c b/net/tls/tls_sw.c
index 5b7f67a7d394
This patch removes the temporary scaffolding now that the comletion
function signature has been converted.
Signed-off-by: Herbert Xu
---
net/tipc/crypto.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/net/tipc/crypto.c b/net/tipc/crypto.c
index ab356e7a3870
This patch removes the temporary scaffolding now that the comletion
function signature has been converted.
Signed-off-by: Herbert Xu
---
net/ipv6/ah6.c |8
net/ipv6/esp6.c | 16
2 files changed, 12 insertions(+), 12 deletions(-)
diff --git a/net/ipv6/ah6.c b
This patch adds temporary scaffolding so that the Crypto API
completion function can take a void * instead of crypto_async_request.
Once affected users have been converted this can be removed.
Signed-off-by: Herbert Xu
---
net/ipv6/ah6.c |8
net/ipv6/esp6.c | 20
This patch does the final flag day conversion of all completion
functions which are now all contained in the Crypto API.
Signed-off-by: Herbert Xu
---
crypto/adiantum.c |5 +---
crypto/af_alg.c|6 ++---
crypto/ahash.c | 12 +-
crypto/api.c
This patch removes the temporary scaffolding now that the comletion
function signature has been converted.
Signed-off-by: Herbert Xu
---
drivers/net/macsec.c |8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/net/macsec.c b/drivers/net/macsec.c
index
This patch removes the temporary scaffolding now that the comletion
function signature has been converted.
Signed-off-by: Herbert Xu
---
drivers/md/dm-crypt.c |6 +++---
drivers/md/dm-integrity.c |4 ++--
2 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/md/dm
This patch replaces the custom crypto completion function with
crypto_req_done.
Signed-off-by: Herbert Xu
---
security/keys/dh.c | 30 +-
1 file changed, 5 insertions(+), 25 deletions(-)
diff --git a/security/keys/dh.c b/security/keys/dh.c
index b339760a31dd
This patch adds temporary scaffolding so that the Crypto API
completion function can take a void * instead of crypto_async_request.
Once affected users have been converted this can be removed.
Signed-off-by: Herbert Xu
---
net/tipc/crypto.c | 12 ++--
1 file changed, 6 insertions
The crypto_async_request passed to the completion is not guaranteed
to be the original request object. Only the data field can be relied
upon.
Fix this by storing the socket pointer with the AEAD request.
Signed-off-by: Herbert Xu
---
net/tls/tls.h|2 ++
net/tls/tls_sw.c | 40
This patch adds temporary scaffolding so that the Crypto API
completion function can take a void * instead of crypto_async_request.
Once affected users have been converted this can be removed.
Signed-off-by: Herbert Xu
---
net/ipv4/ah4.c |8
net/ipv4/esp4.c | 20
This patch replaces the custom crypto completion function with
crypto_req_done.
Signed-off-by: Herbert Xu
---
net/bluetooth/ecdh_helper.c | 37 ++---
1 file changed, 6 insertions(+), 31 deletions(-)
diff --git a/net/bluetooth/ecdh_helper.c b/net/bluetooth
This patch replaces the custom crypto completion function with
crypto_req_done.
Signed-off-by: Herbert Xu
---
fs/ecryptfs/crypto.c | 30 +++---
1 file changed, 3 insertions(+), 27 deletions(-)
diff --git a/fs/ecryptfs/crypto.c b/fs/ecryptfs/crypto.c
index
This patch adds temporary scaffolding so that the Crypto API
completion function can take a void * instead of crypto_async_request.
Once affected users have been converted this can be removed.
Signed-off-by: Herbert Xu
---
drivers/md/dm-crypt.c |8 +++-
drivers/md/dm-integrity.c
This patch adds temporary scaffolding so that the Crypto API
completion function can take a void * instead of crypto_async_request.
Once affected users have been converted this can be removed.
Signed-off-by: Herbert Xu
---
drivers/net/macsec.c |8
1 file changed, 4 insertions
,
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
dm-devel mailing list
dm-devel@redhat.com
https://listman.redhat.com/mailman/listinfo/dm-devel
ge in the set that fixes the problem.
>
> Did this go anywhere? I'm still not seeing it in any of the stable trees.
It's in the cryptodev tree which should hit mainline when the merge
window opens.
Thanks,
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.ap
rk too.
Thanks,
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
dm-devel mailing list
dm-devel@redhat.com
https://listman.redhat.com/mailman/listinfo/dm-devel
stable (possibly only
when DM_CRYPT is enabled/modular). The patches in question while
good may have too wide an effect for the stable kernel series.
Giovanni, could you send Greg a Kconfig patch to do that?
Thanks,
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: htt
M situations where drivers that must allocate memory on each
request may lead to dead-lock so it's not really targeted at qat.
Cheers,
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
dm-devel mailing list
dm-deve
cka
Date: Thu Jul 9 23:20:41 2020 -0700
crypto: drivers - set the flag CRYPTO_ALG_ALLOCATES_MEMORY
So this should no longer be an issue with an up-to-date kernel.
Cheers,
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.t
is now legal to call flush_dcache_page on slab pages we
no longer need to do the check in the Crypto API.
Reported-by: Ira Weiny
Signed-off-by: Herbert Xu
diff --git a/include/crypto/scatterwalk.h b/include/crypto/scatterwalk.h
index c837d0775474..7af08174a721 100644
--- a/include/crypto/scatte
el_dcache_page() needs so much logic around it
> before complicating the general kernel users.
>
> I would like to see it go away if possible.
This thread may be related:
https://lwn.net/Articles/240249/
Cheers,
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: h
has the same check. This
all goes back to
commit 4f3e797ad07d52d34983354a77b365dfcd48c1b4
Author: Herbert Xu
Date: Mon Feb 9 14:22:14 2009 +1100
crypto: scatterwalk - Avoid flush_dcache_page on slab pages
It's illegal to call flush_dcache_page on slab pages on a number
of
GFP_NOIO.
Cheers,
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel
> default to dm-crypto Kconfig option value does solves the problem, or
> have I missed something?
Oh I'm mistaken then. I thought it was an existing option. If
it's a new option then a default depending on dm-crypt should be
sufficient.
Thanks,
--
Email: Herbert Xu
Home Page: http://gondo
f dm-crypt users don't want to bloat their kernels with
> random
> legacy algorithms.
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.
Cheers,
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~he
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 memory as needed.
Thanks,
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel
d/dm-crypt.c | 17 ++-
> include/crypto/algapi.h | 25 ++--
> include/crypto/internal/geniv.h | 2 +-
> include/linux/crypto.h| 36 +-
> 62 files changed, 562 insertions(+), 405 deletions(-)
Patches 1-6 applied. Thanks.
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel
00 from working).
> Please take a look at v2. Thanks!
Looks good. Thanks!
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel
pto_algt_inherited_mask,
e.g.,
u32 mask;
int err;
err = crypto_algt_inherited_mask(tb, CRYPTO_ALG_TYPE_SHASH);
if (err < 0)
return err;
mask = err;
This could then be used to simplify other templates too, such as
gcm.
Thanks,
--
struct aead_alg *alg;
> + u32 mask;
> int err;
>
> algt = crypto_get_attr_type(tb);
> if (IS_ERR(algt))
> return PTR_ERR(algt);
Then we could remove this bit.
Cheers,
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~he
Without the backlog flag, if the hardware queue is full the request
will simply be dropped, which is appropriate in the network stack
with IPsec where congestion can be dealt with at the source.
Block layer on the other hand should always use the backlog flag
and stop sending more requests to the
reqmanager.c | 12 ++--
> drivers/crypto/cavium/cpt/request_manager.h |2 ++
> 3 files changed, 9 insertions(+), 6 deletions(-)
All applied. Thanks.
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
(CRYPTO_ALG_ASYNC |
> CRYPTO_ALG_ALLOCATES_MEMORY)
Any reason why you need to renumber NOLOAD? If not please keep
the existing values.
Thanks,
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel
es you are absolutely right. In general high-performance work
should be carried out in softirq context. That's how the networking
stack works for example.
Cheers,
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
dm-
work in IRQ handlers. All
the substantial work should be postponed to softirq context.
Why do you need to do work in hard IRQ context?
Cheers,
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
dm-devel mailing list
dm-deve
y. We could mark the
known broken ones (or the known working ones) and then dm-crypt
can allocate only those using the types/mask to crypto_alloc.
Cheers,
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
dm-devel mai
ocated within the crypto request
object. That's why we have the reqsize field to indicate how much
memory could be needed per request.
Thanks,
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
dm-devel mailing list
dm
ngine?
>
> What do you mean by the crypto-engine?
crypto-engine is the generic queueing mechanism that any crypto
driver can use to implement the queueing.
Thanks,
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
o align it with the aead one
> - add a test case for essiv(cbc(aes),aes,sha256)
> - add an accelerated implementation for arm64 that combines the IV
> derivation and the actual en/decryption in a single asm routine
>
> Code can be found here
> https://git.kernel.org/pub/scm/l
| 663
> 3 files changed, 692 insertions(+)
Acked-by: Herbert Xu
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel
upport is the offloading of encryption/decryption
over many sectors.
Cheers,
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel
On Wed, Aug 21, 2019 at 04:57:41PM +0900, boojin.kim wrote:
>
> Can you tell me which patch you mentioned? Is this?
> https://patches.linaro.org/project/linux-crypto/list/?series=22762
Yes this is the one.
Cheers,
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert
n, but then
> just implement proper crypto API module that accelerates particular cipher.
I agree. Please take a look at the recent ESSIV patches on
linux-crypto and build multi-block operations on top of them
which can then be implemented by the hardware.
Cheers,
--
Email: Herbert Xu
Home P
+ goto out_drop_skcipher;
> + }
Holding a reference to this algorithm for the life-time of the
instance is not nice. How about just doing a lookup as you were
doing before with crypto_alg_mod_lookup and getting the cra_name
from that?
Thanks,
--
Email: Herbert Xu
Home Page: http://gon
n fact we don't check any gemoetry on the fallbacks at all.
Cheers,
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
e the TFM allocation. What is the problem?
IOW the presence of the block cipher and unkeyed hash does not
affect the creation of the instance object.
Cheers,
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
dm-devel mailin
own the top-level instance when a better underlying spawn
implementation is added to the system.
For these two algorithms, we don't really care about their performance
to do such a tear-down since they only operate on small pieces of
data.
Therefore just keep things simple and allocate them in the tfm
init fu
akes sense. But we have h/w drivers that instantiate
> authenc(X,Y) in its entirety, and passing those driver names is
> something that is supported today, so we can't just remove that.
Sure, we only need to impose a restriction on the cra_name, not
on the driver name.
Thanks,
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
The fact is that this is an interface that we export to user-space
and we must NEVER break that. So if your driver is breaking this
interface then your driver is broken and needs to be fixed.
Cheers,
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
rk you need to put the new
Subject in the email headers.
Thanks,
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
ithm name essiv(X,Z).
> >
>
> Same problem. We'd need to instantiate the skcipher and parse the cra_name.
>
> Perhaps we should introduce a crypto API call that infers the cra_name
> from a cra_driver_name?
You don't need to do that. Just copy whatever gcm does in its
creatio
supported by dm-crypt.
Similary for the skcipher case, given
essiv(cbc(X),Y,Z)
is it ever possible for X != Y? If not then we should just make the
algorithm name essiv(X,Z).
Thanks,
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
ement the cipher text stealing properly, just to be able to boast
> about IEEE P1619 compliance ...)
If your hardware supports XTS properly then you wouldn't even need
to use this new template. You would directly export the xts
interface.
Cheers,
--
Email: Herbert Xu
Home Page: http://gond
act performance. This means whatever wrapper we invent around xex()
> (or whatever we call it) should go out of its way to ensure that the
> common, non-CTS case does not regress in performance, and the special
> handling is only invoked when necessary (which will be never).
Agreed.
Cheers,
--
Emai
plementation cannot do that.
You simply use the underlying xts for the first n - 2 blocks and
do the last two by hand.
Cheers,
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
om the one for CBC as implemented by the current CTS template.
The template is just a name. The implementation can do whatever it
wants for each instance. So obviously we would employ a different
implementation for xts compared to cbc.
Cheers,
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herb
.
But if you were going to volunteer to change them all in one swoop
then it wouldn't matter.
Cheers,
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
could rename the existing xts to a
new name (xek perhaps) and add xts into the cts template as
a wrapper around xek.
That way you don't have to touch the ARM code at all and it
should just work.
PS should we mark xek or whatever it's called as internal so
it isn't visible to user-space?
Cheer
via the existing cts template, and add
> support for wrapping XTS to it.
XTS without stealing should be renamed as XEX. Sure you can then
wrap it inside cts to form xts but the end result needs to be called
xts.
Cheers,
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PG
> the driver.
But the whole point of XTS is that it supports sizes that are
not multiples of the block size. So implementing it without
supporting ciphertext stealing is just wrong.
So let's fix the generic implementation rather than breaking
the caam driver.
Thanks,
--
Email: Herbert Xu
a containing
> > the little-endian byte offset and then use an IV of zero.
> >
>
> That would only work for encryption.
True. So this doesn't obviate the need to access the single-block
cipher. But the code probably should still do it that way for
encryption for performance reaso
entation itself.
AFAICS this is using the same key as the actual data. So why
don't you combine it with the actual data when encrypting/decrypting?
That is, add a block at the front of the actual data containing
the little-endian byte offset and then use an IV of zero.
Cheers,
--
Email: Herbert Xu
Home
makes sense.
Thanks,
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
s can use a
fallback.
Thanks,
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
t could
serve as an example for future implementations.
What do the dm-crypt people think? Are you ever going to need
processing in units other than 4K?
Cheers,
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
e along and fix it later.
Cheers,
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
n order to take advantage of this.
My preference would be to encode the sector size into the key.
Hardware that can only support some sector sizes can use fallbacks
as usual.
Cheers,
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
On Thu, Jun 20, 2019 at 09:13:25AM +0800, Herbert Xu wrote:
> On Wed, Jun 19, 2019 at 06:04:17PM -0700, Eric Biggers wrote:
> >
> > > +#define ESSIV_IV_SIZEsizeof(u64) // IV size of the outer
> > > algo
> > > +#define MAX_INNER_IV_SIZE
that's
presumably why 64 bits is sufficient. Do you forsee a case where
we need 128-bit block numbers?
Cheers,
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
I think as long as drivers/md
is the only user of the said code then having it in drivers/md should
be fine.
However, if we end up using/reusing the same code for others such as
fs/crypto then it might make more sense to have them in crypto.
Cheers,
--
Email: Herbert Xu
Home P
out-of bounds access on counter overflow
> crypto: testmgr - Add test for LRW counter wrap-around
> crypto: lrw - Optimize tweak computation
> crypto: lrw - Do not use auxiliary buffer
>
> crypto/lrw.c | 342 +--
> crypto/te
ed-off-by: Ondrej Mosnacek
> ---
> crypto/xts.c | 269 +--
> 1 file changed, 46 insertions(+), 223 deletions(-)
>
> Changes in v5:
> - fix dumb mistakes
Patch applied. Thanks.
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel
On Thu, Sep 13, 2018 at 01:54:39PM -0400, Mike Snitzer wrote:
>
> Acked-by: Mike Snitzer
Patch applied. Thanks.
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
dm-devel mailing list
dm-devel@redhat.com
malloc() in
> crypto API routines, but it does resolve the original reported problem
> and also makes the XTS code easier to maintain.
Nice work. Unfortunately it doesn't apply against the latest
cryptodev tree. Please rebase and resubmit.
Thanks,
--
Email: Herbert Xu
Home Page: http://gond
l.org/r/CA+55aFzCG-zNmZwX4A2FQpadafLfEzK6CC=qpxydaacu1rq...@mail.gmail.com
>
> Signed-off-by: Kees Cook
Can the dm folks please review this patch?
Thanks,
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
dm-devel mailing
struct crypto_skcipher *skcipher, unsigned int reqsize)
> {
> + BUG_ON(reqsize > SKCIPHER_MAX_REQSIZE);
Please do not add these BUG_ONs. Instead allow this function to
fail and check for the failure in the caller.
Thanks,
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herber
I'd like to get an ack from
the dm folks regarding patch 5. As to patch 9, please fix it so
it doesn't rely on the BUG_ON to catch things.
Thanks,
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel
On Fri, Aug 24, 2018 at 09:21:45PM +0800, Herbert Xu wrote:
> On Fri, Aug 24, 2018 at 09:00:00AM -0400, Mikulas Patocka wrote:
> >
> > BTW. gcmaes_crypt_by_sg also contains GFP_ATOMIC and -ENOMEM, behind a
> > pretty complex condition. Do you mean that this condition is part
allocation that can fail.
This condition does look strange. It's introduced by the commit
e845520707f85c539ce04bb73c6070e9441480be. Dave, what exactly is
it meant to do?
Thanks,
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbe
EP is not possible.
These should never trigger for dm-crypt AFAICS since it only
happens if you provide unaligned input/output.
Cheers,
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
dm-devel mailing list
dm-deve
n't think this is necessary given that this allocation
and similar ones in lrw and other places in the crypto API are just
performance enhancements and unlikely to fail except in very dire
situations.
But if new problems arise I'm certainly not opposed to this.
Thanks,
--
Email: Herbert Xu
Home Page: http://
k->src.virt.addr;
> - u8 last_iv[bsize];
> + u8 last_iv[MAX_CIPHER_BLOCKSIZE];
> +
> + BUG_ON(bsize > sizeof(last_iv));
Ugh, please don't add these BUG_ONs. Add them to the places where
the algorithm is created (if they aren't checking that already).
Thanks,
--
. We should not be adding
hardware algorithms for which there is no software equivalent.
Thanks,
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel
[0], alignmask + 1);
> int err = 0;
> - u8 key1[bs];
> + u8 key1[XCBC_BLOCKSIZE];
> +
> + if (WARN_ON(bs > sizeof(key1)))
> + return -EINVAL;
Please remove this. You already checked it in xcbc_create.
In fact, you should just make bs XCBC_BLOCKSIZE uncondi
On Sat, Jul 14, 2018 at 07:59:09PM -0700, Kees Cook wrote:
> On Sat, Jul 14, 2018 at 7:44 PM, Herbert Xu
> wrote:
> > On Fri, Jul 13, 2018 at 08:07:10PM -0700, Kees Cook wrote:
> >>
> >> On a plane today I started converting all these to shash. IIUC, it
> &
1 - 100 of 171 matches
Mail list logo
