crypto_exit_cipher_ops() and crypto_exit_compress_ops() are no-ops and
have been for a long time, so remove them.
Signed-off-by: Eric Biggers
---
crypto/api.c | 20 ++--
crypto/cipher.c | 4
crypto/compress.c | 4
crypto/internal.h | 3 ---
4 files changed, 2
The definition of crypto_lookup_skcipher() was already removed in
commit 3a01d0ee2b99 ("crypto: skcipher - Remove top-level givcipher
interface"). So the declaration should be removed too.
Signed-off-by: Eric Biggers
---
include/crypto/internal/skcipher.h | 2 --
1 file changed, 2
unctions.
Signed-off-by: Eric Biggers
---
crypto/cmac.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/crypto/cmac.c b/crypto/cmac.c
index 7a8bfbd..b6c4059 100644
--- a/crypto/cmac.c
+++ b/crypto/cmac.c
@@ -243,6 +243,7 @@ static int cmac_create(struct crypto_template *tmpl, struct
rta
The per-transform 'consts' array is accessed as __be64 in
crypto_cmac_digest_setkey() but was only guaranteed to be aligned to
__alignof__(long). Fix this by aligning it to __alignof__(__be64).
Signed-off-by: Eric Biggers
---
crypto/cmac.c | 13 +
1 file changed, 9 insert
On Mon, Oct 10, 2016 at 10:29:55AM -0700, Joe Perches wrote:
> On Mon, 2016-10-10 at 10:15 -0700, Eric Biggers wrote:
> > The per-transform 'consts' array is accessed as __be64 in
> > crypto_cmac_digest_setkey() but was only guaranteed to be aligned to
> > __alignof
On Mon, Oct 10, 2016 at 10:51:14AM -0700, Joe Perches wrote:
>
> Hey Eric.
>
> I don't see any PTR_ALIGN uses in crypto/ or drivers/crypto/ that
> use a bitwise or, just mask + 1, but I believe the effect is the
> same. Anyway, your choice, but I think using min is clearer.
>
> cheers, Joe
Usu
Since commit 3a01d0ee2b99 ("crypto: skcipher - Remove top-level
givcipher interface"), crypto_spawn_skcipher2() and
crypto_spawn_skcipher() are equivalent. So switch callers of
crypto_spawn_skcipher2() to crypto_spawn_skcipher() and remove it.
Signed-off-by: Eric Biggers
---
crypto
Since commit 3a01d0ee2b99 ("crypto: skcipher - Remove top-level
givcipher interface"), crypto_grab_skcipher2() and
crypto_grab_skcipher() are equivalent. So switch callers of
crypto_grab_skcipher2() to crypto_grab_skcipher() and remove it.
Signed-off-by: Eric Biggers
---
crypto
Hi,
I'm having trouble understanding how alignment of shash input buffers is
supposed to work. If you pass crypto_shash_update() a buffer that is not
aligned to the shash algorithm's alignmask, it will call the underlying
->update() function twice, once with a temporary aligned buffer and once wi
Hi Herbert, just a few preliminary comments. I haven't made it through
everything yet.
On Wed, Nov 02, 2016 at 07:19:02AM +0800, Herbert Xu wrote:
> +static int skcipher_walk_first(struct skcipher_walk *walk)
> +{
> + if (WARN_ON_ONCE(in_irq()))
> + return -EDEADLK;
> +
> + wa
Hello,
I hit the BUG_ON() in arch/x86/mm/physaddr.c:26 while testing some crypto code
in an x86_64 kernel with CONFIG_DEBUG_VIRTUAL=y and CONFIG_VMAP_STACK=y:
/* carry flag will be set if starting x was >= PAGE_OFFSET */
VIRTUAL_BUG_ON((x > y) || !phys_addr_valid(x));
The problem
On Thu, Nov 03, 2016 at 01:30:49PM -0700, Andy Lutomirski wrote:
>
> Also, Herbert, it seems like the considerable majority of the crypto
> code is acting on kernel virtual memory addresses and does software
> processing. Would it perhaps make sense to add a kvec-based or
> iov_iter-based interfa
padded filename. Fix it by encrypting the
filename in-place in the output buffer, thereby making the temporary
buffer unnecessary.
This bug could most easily be observed in a CONFIG_DEBUG_SG kernel
because this allowed the BUG in sg_set_buf() to be triggered.
Signed-off-by: Eric Biggers
---
fs
operation used to derive the per-file key.
Fix it by using a heap buffer.
This bug could most easily be observed in a CONFIG_DEBUG_SG kernel
because this allowed the BUG in sg_set_buf() to be triggered.
Signed-off-by: Eric Biggers
---
fs/crypto/keyinfo.c | 16 +---
1 file changed, 13
On Thu, Nov 03, 2016 at 02:12:07PM -0700, Eric Biggers wrote:
> On Thu, Nov 03, 2016 at 01:30:49PM -0700, Andy Lutomirski wrote:
> >
> > Also, Herbert, it seems like the considerable majority of the crypto
> > code is acting on kernel virtual memory addresses and does so
On Thu, Nov 03, 2016 at 08:57:49PM -0700, Andy Lutomirski wrote:
>
> The crypto request objects can live on the stack just fine. It's the
> request buffers that need to live elsewhere (or the alternative
> interfaces can be used, or the crypto core code can start using
> something other than scat
On Thu, Nov 03, 2016 at 11:20:08PM +0100, Jason A. Donenfeld wrote:
> Hi David,
>
> On Thu, Nov 3, 2016 at 6:08 PM, David Miller wrote:
> > In any event no piece of code should be doing 32-bit word reads from
> > addresses like "x + 3" without, at a very minimum, going through the
> > kernel unal
On Mon, Nov 07, 2016 at 07:08:22PM +0100, Jason A. Donenfeld wrote:
> Hmm... The general data flow that strikes me as most pertinent is
> something like:
>
> struct sk_buff *skb = get_it_from_somewhere();
> skb = skb_share_check(skb, GFP_ATOMIC);
> num_frags = skb_cow_data(skb, ..., ...);
> struct
On Mon, Nov 07, 2016 at 08:02:35PM +0100, Jason A. Donenfeld wrote:
> On Mon, Nov 7, 2016 at 7:26 PM, Eric Biggers wrote:
> >
> > I was not referring to any users in particular, only what users could do.
> > As an
> > example, if you did crypto_shash_update() with
on A. Donenfeld
> ---
Reviewed-by: Eric Biggers
Nit: the subject line is a little unclear about what was changed.
"make generic C faster on chips with slow unaligned access" would be better.
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto&qu
On Tue, Nov 08, 2016 at 08:52:39AM +0100, Martin Willi wrote:
>
>
> Not sure what the exact alignment rules for key/iv are, but maybe we
> want to replace the same function in chacha20_generic.c as well?
>
> Martin
chacha20-generic provides a blkcipher API and sets an alignmask of sizeof(u32)
-
Hi Herbert,
On Sun, Nov 13, 2016 at 07:45:32PM +0800, Herbert Xu wrote:
> +int skcipher_walk_done(struct skcipher_walk *walk, int err)
> +{
> + unsigned int nbytes = 0;
> + unsigned int n = 0;
> +
> + if (likely(err >= 0)) {
> + n = walk->nbytes - err;
> + nbyte
On Sun, Nov 13, 2016 at 07:45:37PM +0800, Herbert Xu wrote:
> +static void cryptd_skcipher_encrypt(struct crypto_async_request *base,
> + int err)
> +{
> + struct skcipher_request *req = skcipher_request_cast(base);
> + struct cryptd_skcipher_request_ctx *rct
On Sun, Nov 13, 2016 at 07:45:35PM +0800, Herbert Xu wrote:
> +static int do_encrypt(struct skcipher_request *req, int err)
> +{
> + struct rctx *rctx = skcipher_request_ctx(req);
> + struct skcipher_request *subreq;
> +
> + subreq = &rctx->subreq;
> +
> + while (!err && rctx->left)
On Sun, Nov 13, 2016 at 07:45:38PM +0800, Herbert Xu wrote:
> This patch adds the simd skcipher helper which is meant to be
> a replacement for ablk helper. It replaces the underlying blkcipher
> interface with skcipher, and also presents the top-level algorithm
> as an skcipher.
I assume this me
On Tue, Nov 15, 2016 at 11:47:04AM -0500, Theodore Ts'o wrote:
> On Thu, Nov 03, 2016 at 03:03:02PM -0700, Eric Biggers wrote:
> > With the new (in 4.9) option to use a virtually-mapped stack
> > (CONFIG_VMAP_STACK), stack buffers cannot be used as input/output for
> >
quest data. As this check is now triggering BUG checks
> due to the vmalloced stack code, I'm removing it.
>
> Reported-by: Eric Biggers
> Signed-off-by: Herbert Xu
>
> diff --git a/crypto/scatterwalk.c b/crypto/scatterwalk.c
> index 52ce17a..c16c94f8 100644
&g
b ("crypto: acomp - update testmgr with support for acomp")
Signed-off-by: Eric Biggers
---
crypto/testmgr.c | 11 ---
1 file changed, 8 insertions(+), 3 deletions(-)
diff --git a/crypto/testmgr.c b/crypto/testmgr.c
index ded50b6..aca1b7b 100644
--- a/crypto/testmgr.c
++
On Thu, Dec 01, 2016 at 05:47:02PM -0800, Tim Chen wrote:
> On Thu, 2016-12-01 at 19:00 -0500, Mikulas Patocka wrote:
> > Hi
> >
> > There is a bug in mcryptd initialization.
> >
> > This is a test module that tries various hash algorithms. When you load
> > the module with "insmod test.ko 'alg=
On Mon, Dec 05, 2016 at 06:42:23PM +, Ard Biesheuvel wrote:
> The IDXn offsets are chosen such that tap values (which may go up to
> 255) end up overlapping in the xbuf allocation. In particular, IDX1
> and IDX3 are too close together, so update IDX3 to avoid this issue.
>
Hi Ard,
This patch
On Wed, Dec 07, 2016 at 07:53:51PM +, Ard Biesheuvel wrote:
> Does this help at all?
>
> diff --git a/crypto/testmgr.c b/crypto/testmgr.c
> index 670893bcf361..59e67f5b544b 100644
> --- a/crypto/testmgr.c
> +++ b/crypto/testmgr.c
> @@ -63,7 +63,7 @@ int alg_test(const char *driver, const char
In the 4.9 kernel, virtually-mapped stacks will be supported and enabled by
default on x86_64. This has been exposing a number of problems in which
on-stack buffers are being passed into the crypto API, which to support crypto
accelerators operates on 'struct page' rather than on virtual memory.
On Fri, Dec 09, 2016 at 09:25:38PM -0800, Andy Lutomirski wrote:
> > The following crypto drivers initialize a scatterlist to point into an
> > ahash_request, which may have been allocated on the stack with
> > AHASH_REQUEST_ON_STACK():
> >
> > drivers/crypto/bfin_crc.c:351
> > driv
On Sat, Dec 10, 2016 at 01:32:08PM +0800, Herbert Xu wrote:
> On Fri, Dec 09, 2016 at 09:25:38PM -0800, Andy Lutomirski wrote:
> >
> > > The following crypto drivers initialize a scatterlist to point into an
> > > ablkcipher_request, which may have been allocated on the stack with
> > > SKCIPHER_RE
On Sat, Dec 10, 2016 at 01:37:12PM +0800, Herbert Xu wrote:
> On Fri, Dec 09, 2016 at 09:25:38PM -0800, Andy Lutomirski wrote:
> >
> > Herbert, how hard would it be to teach the crypto code to use a more
> > sensible data structure than scatterlist and to use coccinelle fix
> > this stuff for real?
On Sat, Dec 10, 2016 at 04:16:43PM +0800, Herbert Xu wrote:
> Why did you drop me from the CC list when you were replying to
> my email?
>
Sorry --- this thread is Cc'ed to the kernel-hardening mailing list (which was
somewhat recently revived), and I replied to the email that reached me from
the
On Sun, Dec 11, 2016 at 11:13:55AM -0800, Andy Lutomirski wrote:
> On Fri, Dec 9, 2016 at 3:08 PM, Eric Biggers wrote:
> > In the 4.9 kernel, virtually-mapped stacks will be supported and enabled by
> > default on x86_64. This has been exposing a number of problems in which
>
On Mon, Dec 12, 2016 at 04:48:17AM +0100, Jason A. Donenfeld wrote:
>
> diff --git a/lib/Makefile b/lib/Makefile
> index 50144a3aeebd..71d398b04a74 100644
> --- a/lib/Makefile
> +++ b/lib/Makefile
> @@ -22,7 +22,8 @@ lib-y := ctype.o string.o vsprintf.o cmdline.o \
>sha1.o chacha20.o md5.o
On Mon, Dec 12, 2016 at 12:55:55PM -0800, Andy Lutomirski wrote:
> +int orinoco_mic(struct crypto_shash *tfm_michael, u8 *key,
> u8 *da, u8 *sa, u8 priority,
> u8 *data, size_t data_len, u8 *mic)
> {
> - AHASH_REQUEST_ON_STACK(req, tfm_michael);
> - struct scatt
On Mon, Dec 12, 2016 at 11:18:32PM +0100, Jason A. Donenfeld wrote:
> + for (; data != end; data += sizeof(u64)) {
> + m = get_unaligned_le64(data);
> + v3 ^= m;
> + SIPROUND;
> + SIPROUND;
> + v0 ^= m;
> + }
> +#if defined(CONFIG_
On Wed, Dec 14, 2016 at 01:04:04PM +0800, Herbert Xu wrote:
> On Tue, Dec 13, 2016 at 06:53:03PM -0800, Andy Lutomirski wrote:
> > On Tue, Dec 13, 2016 at 6:48 PM, Andy Lutomirski wrote:
> > > The driver put a constant buffer of all zeros on the stack and
> > > pointed a scatterlist entry at it in
From: Eric Biggers
It's recommended to use kmemdup instead of kmalloc followed by memcpy.
Signed-off-by: Eric Biggers
---
crypto/testmgr.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/crypto/testmgr.c b/crypto/testmgr.c
index 44e888b0b041..881176ebd8a8 1
On Thu, Jan 12, 2017 at 01:59:57PM +0100, Ondrej Mosnacek wrote:
> This patch implements bulk request handling in the AES-NI crypto drivers.
> The major advantage of this is that with bulk requests, the kernel_fpu_*
> functions (which are usually quite slow) are now called only once for the
> whol
On Thu, Jan 26, 2017 at 08:57:30AM +0100, Sven Schmidt wrote:
>
> This patchset is for updating the LZ4 compression module to a version based
> on LZ4 v1.7.3 allowing to use the fast compression algorithm aka LZ4 fast
> which provides an "acceleration" parameter as a tradeoff between
> high compre
On Sun, Jan 29, 2017 at 10:31:59PM +0100, Arkadiusz Miskiewicz wrote:
> Hi.
>
> [arekm@xps ~]$ modinfo --set-version 4.9.6 aesni-intel | grep depends
> depends:glue_helper,aes-x86_64,lrw,cryptd,ablk_helper
>
> [arekm@xps ~]$ modinfo --set-version 4.10.0-rc5-00161-gfd694aaa46c7 aesni-
> i
On Sun, Jan 29, 2017 at 09:39:20AM +0200, Gilad Ben-Yossef wrote:
> Hi Odrej,
>
> On Thu, Jan 26, 2017 at 1:34 PM, Ondrej Mosnáček
> wrote:
> > Hi Gilad,
> >
> > 2017-01-24 15:38 GMT+01:00 Gilad Ben-Yossef :
> >> - v->tfm = crypto_alloc_shash(v->alg_name, 0, 0);
> >> + v->tfm = crypto
On Mon, Jan 30, 2017 at 02:11:29PM +, Ard Biesheuvel wrote:
> Instead of unconditionally forcing 4 byte alignment for all generic
> chaining modes that rely on crypto_xor() or crypto_inc() (which may
> result in unnecessary copying of data when the underlying hardware
> can perform unaligned ac
Hi Ard,
On Sat, Jan 28, 2017 at 11:33:33PM +, Ard Biesheuvel wrote:
>
> Note that this only implements AES encryption, which is all we need
> for CTR and CBC-MAC. AES decryption can easily be implemented in a
> similar way, but is significantly more costly.
Is the expectation of decryption b
Hi Ard,
On Thu, Feb 02, 2017 at 03:56:28PM +, Ard Biesheuvel wrote:
> + const int size = sizeof(unsigned long);
> + int delta = ((unsigned long)dst ^ (unsigned long)src) & (size - 1);
> + int misalign = 0;
> +
> + if (!IS_ENABLED(CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS) && delta
On Sat, Feb 04, 2017 at 01:20:38PM -0800, Eric Biggers wrote:
> Unfortunately this is still broken, for two different reasons. First, if the
> pointers have the same relative misalignment, then 'delta' and 'misalign' will
> be set to 0 and long accesses will be used,
On Sun, Feb 05, 2017 at 12:10:53AM +0100, Jason A. Donenfeld wrote:
> Another thing that might be helpful is that you can let gcc decide on
> the alignment, and then optimize appropriately. Check out what we do
> with siphash:
>
> https://git.kernel.org/cgit/linux/kernel/git/davem/net-next.git/tre
On Thu, Feb 09, 2017 at 08:31:21AM +0900, Minchan Kim wrote:
>
> Today, I did zram-lz4 performance test with fio in current mmotm and
> found it makes regression about 20%.
>
This may or may not be the cause of the specific regression you're observing,
but I just noticed that the proposed patch
Also I noticed another bug, this time in LZ4_count():
> #if defined(CONFIG_64BIT)
> #define LZ4_ARCH64 1
> #else
> #define LZ4_ARCH64 0
> #endif
...
> #ifdef LZ4_ARCH64
>if ((pIn < (pInLimit-3))
>&& (LZ4_read32(pMatch) == LZ4_read32(pIn))) {
>pIn += 4; pMatc
On Thu, Feb 09, 2017 at 12:05:40PM +0100, Sven Schmidt wrote:
> > Because of how LZ4_ARCH64 is defined, it needs to be '#if LZ4_ARCH64'.
> >
> > But I also think the way upstream LZ4 does 64-bit detection could have just
> > been
> > left as-is; it has a function which gets inlined:
> >
> >
On Thu, Feb 09, 2017 at 12:02:11PM +0100, Sven Schmidt wrote:
> >
> > [Also, for some reason linux-crypto is apparently still not receiving patch
> > 1/5
> > in the series. It's missing from the linux-crypto archive at
> > http://www.spinics.net/lists/linux-crypto/, so it's not just me.]
> >
>
Hi Sven,
On Sun, Feb 12, 2017 at 12:16:18PM +0100, Sven Schmidt wrote:
> /*-
> * Reading and writing into memory
> **/
> +typedef union {
> + U16 u16;
> + U32 u32;
> + size_t uArch;
> +} __packed unalign;
>
ication.
Therefore, rename the tables to "le" and "be" and update the comment to
explain this.
Cc: Alex Cope
Signed-off-by: Eric Biggers
---
crypto/gf128mul.c | 49 -
1 file changed, 32 insertions(+), 17 deletions(-)
diff -
This patchset makes a few cleanups to the generic GF(2^128) multiplication code
to make it slightly easier to understand and modify. No functional changes are
intended.
Eric Biggers (4):
crypto: gf128mul - fix some comments
crypto: gf128mul - remove xx() macro
crypto: gf128mul - rename the
Constify the multiplication tables passed to the 4k and 64k
multiplication functions, as they are not modified by these functions.
Cc: Alex Cope
Signed-off-by: Eric Biggers
---
crypto/gf128mul.c | 6 +++---
include/crypto/gf128mul.h | 6 +++---
2 files changed, 6 insertions(+), 6
The xx() macro serves no purpose and can be removed.
Cc: Alex Cope
Signed-off-by: Eric Biggers
---
crypto/gf128mul.c | 18 --
1 file changed, 8 insertions(+), 10 deletions(-)
diff --git a/crypto/gf128mul.c b/crypto/gf128mul.c
index d9e3eecc218a..c050cf6f5aa9 100644
--- a
Fix incorrect references to GF(128) instead of GF(2^128), as these are
two entirely different fields, and fix a few other incorrect comments.
Cc: Alex Cope
Signed-off-by: Eric Biggers
---
crypto/gf128mul.c | 13 +++--
include/crypto/gf128mul.h | 26 ++
2
From: Eric Biggers
These two patches mark all the cryptographic test vectors as 'const'.
This has several potential advantages and moves a large amount of data
from .data to .rodata when the tests are enabled. The second patch does
the real work; the first just prepares for it by
From: Eric Biggers
Constify the buffer passed to crypto_kpp_set_secret() and
kpp_alg.set_secret, since it is never modified.
Signed-off-by: Eric Biggers
---
crypto/dh.c | 3 ++-
crypto/ecdh.c | 3 ++-
drivers/crypto/qat
From: Eric Biggers
Cryptographic test vectors should never be modified, so constify them to
enforce this at both compile-time and run-time. This moves a significant
amount of data from .data to .rodata when the crypto tests are enabled.
Signed-off-by: Eric Biggers
---
crypto/testmgr.c | 71
On Mon, Jul 24, 2017 at 07:59:43AM +0100, Ard Biesheuvel wrote:
> On 18 July 2017 at 13:06, Ard Biesheuvel wrote:
> > The generic AES driver uses 16 lookup tables of 1 KB each, and has
> > encryption and decryption routines that are fully unrolled. Given how
> > the dependencies between this code
From: Eric Biggers
Currently, the fscrypt_context (i.e. the encryption xattr) does not
contain a cryptographically secure identifier for the master key's
payload. Therefore it's not possible to verify that the correct key was
supplied, which is problematic in multi-user scenarios. To
From: Eric Biggers
This patch series solves two major problems which filesystem-level
encryption has currently. First, the user-supplied master keys are not
verified, which means a malicious user can provide the wrong key for
another user's file and cause a DOS attack or worse. This fla
From: Eric Biggers
Currently, while a fscrypt master key is required to have a certain
description in the keyring, its payload is never verified to be correct.
While sufficient for well-behaved userspace, this is insecure in a
multi-user system where a user has been given only read-only access
From: Eric Biggers
Since v2 encryption policies are opt-in, take the opportunity to also
drop support for the legacy filesystem-specific key description prefixes
"ext4:", "f2fs:", and "ubifs:", instead requiring the generic prefix
"fscrypt:". The generi
From: Eric Biggers
Now that we have a key_hash field which securely identifies a master key
payload, introduce a cache of the HMAC transforms for the master keys
currently in use for inodes using v2+ encryption policies. The entries
in this cache are called 'struct fscrypt_master_key
From: Eric Biggers
By design, the keys which userspace provides in the keyring are not used
to encrypt data directly. Instead, a KDF (Key Derivation Function) is
used to derive a unique encryption key for each inode, given a "master"
key and a nonce. The current KDF encrypts the
From: Eric Biggers
For FS_IOC_SET_ENCRYPTION_POLICY, currently the encryption modes and
flags are only validated when a new encryption policy is being set, not
when an existing policy is being compared to the one specified.
However, we're going to start needing to compute the key_hash in
From: Eric Biggers
In struct fscrypt_info, ->ci_master_key is the master key descriptor,
not the master key itself. In preparation for introducing a struct
fscrypt_master_key and making ->ci_master_key point to it, rename the
existing ->ci_master_key to ->ci_master_key_descripto
On Wed, Aug 09, 2017 at 07:35:53PM -0700, Nick Terrell wrote:
>
> It can compress at speeds approaching lz4, and quality approaching lzma.
Well, for a very loose definition of "approaching", and certainly not at the
same time. I doubt there's a use case for using the highest compression levels
in
On Thu, Aug 10, 2017 at 07:32:18AM -0400, Austin S. Hemmelgarn wrote:
> On 2017-08-10 04:30, Eric Biggers wrote:
> >On Wed, Aug 09, 2017 at 07:35:53PM -0700, Nick Terrell wrote:
> >>
> >>It can compress at speeds approaching lz4, and quality approaching lzma.
&g
On Thu, Aug 10, 2017 at 10:57:01AM -0400, Austin S. Hemmelgarn wrote:
> Also didn't think to mention this, but I could see the max level
> being very popular for use with SquashFS root filesystems used in
> LiveCD's. Currently, they have to decide between read performance
> and image size, while zs
On Thu, Aug 10, 2017 at 01:41:21PM -0400, Chris Mason wrote:
> On 08/10/2017 04:30 AM, Eric Biggers wrote:
> >On Wed, Aug 09, 2017 at 07:35:53PM -0700, Nick Terrell wrote:
>
> >>The memory reported is the amount of memory the compressor requests.
> >>
> >>|
Hi Josh,
On Tue, Aug 29, 2017 at 01:05:33PM -0500, Josh Poimboeuf wrote:
> Many of the x86 crypto functions use RBP as a temporary register. This
> breaks frame pointer convention, and breaks stack traces when unwinding
> from an interrupt in the crypto code.
>
> Convert most* of them to leave R
On Thu, Sep 07, 2017 at 09:15:34AM +0200, Ingo Molnar wrote:
>
> * Eric Biggers wrote:
>
> > Thanks for fixing these! I don't have time to review these in detail, but
> > I ran
> > the crypto self-tests on the affected algorithms, and they all pass. I also
On Thu, Sep 07, 2017 at 11:26:47PM +0200, Ingo Molnar wrote:
>
> * Eric Biggers wrote:
>
> > On Thu, Sep 07, 2017 at 09:15:34AM +0200, Ingo Molnar wrote:
> > >
> > > * Eric Biggers wrote:
> > >
> > > > Thanks for fixing these! I don
Hi Josh,
On Wed, Sep 13, 2017 at 05:33:03PM -0500, Josh Poimboeuf wrote:
> And here's v2 of the sha512-avx2 patch. It should hopefully gain back
> most of the performance lost by v1.
>
> From: Josh Poimboeuf
> Subject: [PATCH] x86/crypto: Fix RBP usage in sha512-avx2-asm.S
>
> Using RBP as a t
On Fri, Sep 15, 2017 at 07:34:31AM +0200, Ingo Molnar wrote:
>
> * Eric Biggers wrote:
>
> > Hi Josh,
> >
> > On Wed, Sep 13, 2017 at 05:33:03PM -0500, Josh Poimboeuf wrote:
> > > And here's v2 of the sha512-avx2 patch. It should hopefully gain back
On Thu, Sep 28, 2017 at 09:14:58AM +1000, James Morris wrote:
> On Wed, 27 Sep 2017, David Howells wrote:
>
> > (2) Fixing big_key to use safe crypto from Jason A. Donenfeld.
> >
>
> I'm concerned about the lack of crypto review mentioned by Jason -- I
> wonder if we can get this rewrite any m
From: Eric Biggers
When setting the secret with the "qat-dh" Diffie-Hellman implementation,
if allocating 'g' failed, then 'p' was freed twice: once immediately,
and once later when the crypto_kpp tfm was destroyed. Fix it by using
qat_dh_clear_ctx() in the
From: Eric Biggers
The "qat-dh" DH implementation assumes that 'key' and 'g' can be copied
into a buffer with size 'p_size'. However it was never checked that
that was actually the case, which allowed users to cause a buffer
underflow via
From: Eric Biggers
If 'p' is 0 for the software Diffie-Hellman implementation, then
dh_max_size() returns 0. In the case of KEYCTL_DH_COMPUTE, this causes
ZERO_SIZE_POINTER to be passed to sg_init_one(), which with
CONFIG_DEBUG_SG=y triggers the 'BUG_ON(!virt_addr_valid(buf));
From: Eric Biggers
When setting the secret with the software Diffie-Hellman implementation,
if allocating 'g' failed (e.g. if it was longer than
MAX_EXTERN_MPI_BITS), then 'p' was freed twice: once immediately, and
once later when the crypto_kpp tfm was destroyed. Fix it
From: Eric Biggers
This series fixes several corner cases in the Diffie-Hellman key
exchange implementations:
- With CONFIG_DEBUG_SG=y and the software DH implementation, setting 'p'
to 0 caused a BUG_ON().
- Both the software and QAT DH implementations had a double-free bug in
On Mon, Oct 23, 2017 at 07:01:32PM +0300, SviMik wrote:
> Hi!
>
> Got the following kernel panic:
>
> invalid opcode: [#1] SMP
> CPU: 0 PID: 1449 Comm: openvpn Not tainted 4.8.13-1.el6.elrepo.x86_64 #1
> cut
> Call Trace:
>
> [] ? enqueue_entity+0x45e/0x6f0
> [] ? aesni_gcm_enc_avx+
Hi Tudor,
On Thu, Nov 02, 2017 at 12:55:56PM +0200, Tudor Ambarus wrote:
> Hi, Eric,
>
> On 11/02/2017 12:25 AM, Eric Biggers wrote:
> >When setting the secret with the software Diffie-Hellman implementation,
> >if allocating 'g' failed (e.g. if it was longer tha
On Thu, Nov 02, 2017 at 01:40:51PM +0200, Tudor Ambarus wrote:
> Hi, Eric,
>
> On 11/02/2017 12:25 AM, Eric Biggers wrote:
> >If 'p' is 0 for the software Diffie-Hellman implementation, then
> >dh_max_size() returns 0.
>
> dh_set_secret()
On Wed, Nov 01, 2017 at 03:25:16PM -0700, Eric Biggers wrote:
> From: Eric Biggers
>
> When setting the secret with the "qat-dh" Diffie-Hellman implementation,
> if allocating 'g' failed, then 'p' was freed twice: once immediately,
> and once later w
From: Eric Biggers
Neither 'p' nor 'g' can be NULL, as they were unpacked using
crypto_dh_decode_key(). And it makes no sense for them to be optional.
So remove the NULL checks that were copy-and-pasted into both modules.
Signed-off-by: Eric Bigge
UG_ON().
3. With the QAT DH implementation, setting 'key' or 'g' larger than 'p'
caused a buffer underflow.
Note that in kernels configured with CONFIG_KEY_DH_OPERATIONS=y, these
bugs are reachable by unprivileged users via KEYCTL_DH_COMPUTE.
Patches 4 and 5 are c
From: Eric Biggers
Update the error handling in qat_dh_set_secret() to mirror
dh_set_secret(). The new version is less error-prone because freeing
memory and setting the pointers to NULL is now only done in one place.
Signed-off-by: Eric Biggers
---
drivers/crypto/qat/qat_common
From: Eric Biggers
The "qat-dh" DH implementation assumes that 'key' and 'g' can be copied
into a buffer with size 'p_size'. However it was never checked that
that was actually the case, which most likely allowed users to cause a
buffer underflow via
From: Eric Biggers
If 'p' is 0 for the software Diffie-Hellman implementation, then
dh_max_size() returns 0. In the case of KEYCTL_DH_COMPUTE, this causes
ZERO_SIZE_PTR to be passed to sg_init_one(), which with
CONFIG_DEBUG_SG=y triggers the 'BUG_ON(!virt_addr_valid(buf));
From: Eric Biggers
When setting the secret with the software Diffie-Hellman implementation,
if allocating 'g' failed (e.g. if it was longer than
MAX_EXTERN_MPI_BITS), then 'p' was freed twice: once immediately, and
once later when the crypto_kpp tfm was destroyed.
Fix it
On Mon, Nov 06, 2017 at 10:36:00AM -0800, syzbot wrote:
> kasan: GPF could be caused by NULL-ptr deref or user memory access
> general protection fault: [#1] SMP KASAN
> Dumping ftrace buffer:
>(ftrace buffer empty)
> Modules linked in:
> CPU: 3 PID: 2984 Comm: syzkaller229187 Not tainted
ngth check later in the function. How about
this:
commit 8bbe85872c660c891eb978a037f590198319e3b2
Author: Eric Biggers
Date: Mon Nov 6 10:06:32 2017 -0800
KEYS: fix NULL pointer dereference during ASN.1 parsing
syzkaller reported a NULL pointer dereference in asn1_ber_decoder(). I
1 - 100 of 1650 matches
Mail list logo
