ug where user space is able to cause one cipher to be
> > registered multiple times potentially exhausting kernel memory.
> >
> > Reported-by: syzbot
> > Cc:
> > Signed-off-by: Stephan Mueller
>
> The syzkaller reproducer triggered a crash in crypto_remov
Am Freitag, 8. Dezember 2017, 12:39:06 CET schrieb Jonathan Cameron:
Hi Jonathan,
>
> As a heads up, the other nasties we've found so far are around hitting
> limits on the various socket buffers. When you run into those you can end
> up with parts of the data to be encrypted going through with
Am Freitag, 8. Dezember 2017, 11:06:31 CET schrieb Ard Biesheuvel:
Hi Ard,
>
> Given how it is not uncommon for counters to be used as IV, this is a
> fundamental flaw that could rear its head in other places as well, so
> I propose we fix this one way (fix the current code) or the other
> (depr
Am Donnerstag, 7. Dezember 2017, 16:08:04 CET schrieb Atul Gupta:
Hi Atul,
> > As far as I see, the key is part of the skb (via kctx). This skb is
> > released after being processed. The release calls kfree_skb which does
> > not zeroize the key. Wouldn't it make sense to clear the memory of the
Am Donnerstag, 7. Dezember 2017, 15:21:03 CET schrieb Atul Gupta:
Hi Atul,
>
> memzero_explicit(key)?
> [Atul] may not be required as entire info of size keylen and AEAD_H_SIZE is
> copied onto kctx->key. Key data is received from user, while ghash is
> memset and locally generated
Sure, but wo
riority before
> software implementations, but allow them to be selected in FIPS-mode
> (fips=1 in the kernel command line).
>
> Signed-off-by: Łukasz Stelmach
Reviewed-by: Stephan Mueller
Ciao
Stephan
Am Dienstag, 5. Dezember 2017, 13:35:57 CET schrieb Łukasz Stelmach:
Hi Łukasz,
> Use memcpy_fromio() instead of custom exynos_rng_copy_random() function
> to retrieve generated numbers from the registers of PRNG.
>
> Remove unnecessary invocation of cpu_relax().
>
> Signed-off-by: Łukasz Stelm
second?!
Another suggestion: maybe you want to add a comment to the reseed function to
indicate it is for enhanced backtracking resistance. Otherwise a lot of folks
would scratch their head why such code exists in the first place. :-)
Other than that:
Reviewed-by: Stephan Mueller
Ciao
Stephan
Am Dienstag, 5. Dezember 2017, 13:42:14 CET schrieb Łukasz Stelmach:
Hi Łukasz,
> exynos-rng is one of many implementations of stdrng. With priority as
> low as 100 it isn't selected, if software implementations (DRBG) are
> available.
What about using 300? The reason is the following: in the no
Am Dienstag, 5. Dezember 2017, 12:40:29 CET schrieb Atul Gupta:
Hi Atul,
> program the tx and rx key on chip.
>
> Signed-off-by: Atul Gupta
> ---
> drivers/crypto/chelsio/chtls/chtls_hw.c | 394
> 1 file changed, 394 insertions(+)
> create mode 100644 drivers/c
Am Mittwoch, 29. November 2017, 11:22:34 CET schrieb Herbert Xu:
Hi Herbert,
> On Wed, Nov 29, 2017 at 11:17:26AM +0100, Stephan Müller wrote:
> > @@ -111,6 +111,12 @@ static int _aead_recvmsg(struct socket *sock, struct
> > msghdr *msg,>
> > size_t usedpages = 0; /* [in] RX bufs
Am Mittwoch, 29. November 2017, 08:10:49 CET schrieb Herbert Xu:
Hi Herbert,
>
> But anyway this isn't suitable for stable where we should just fix
> it by making it not crash.
I will send a patch right away moving the wait out.
Later on I will elaborate on your suggestion to move the context-
Am Mittwoch, 29. November 2017, 00:02:40 CET schrieb Herbert Xu:
Hi Herbert,
> > --- a/crypto/algif_aead.c
> > +++ b/crypto/algif_aead.c
> > @@ -110,6 +110,7 @@ static int _aead_recvmsg(struct socket *sock, struct
> > msghdr *msg,>
> > size_t outlen = 0; /* [out] RX bufs produce
; + }
>
> - if (areq->tsgl && areq->tsgl_entries)
Why do you want to remove the check for areq->tsgl_entries? I know in the
current code that cannot happen. But it should be caught in case of a
programming error.
Thus, should we add a BUG_ON(!areq->tsgl_entries)?
Otherwise:
Reviewed-by: Stephan Mueller
Ciao
Stephan
.13: this code is not affected by this
issue because the sleep happens before any member of the context is
dereferenced.
Eric, may I ask you to check the attached patch? Note, I did not yet test that
patch myself. Thanks a lot.
---8<---
>From a06f26e1baaf6acb855ab8fb55a220a176aa0b9f Mon Se
Am Dienstag, 28. November 2017, 08:53:07 CET schrieb Eric Biggers:
Hi Eric,
> On Mon, Nov 27, 2017 at 09:37:38PM -0800, Eric Biggers wrote:
> > On Mon, Nov 27, 2017 at 10:56:47AM -0800, syzbot wrote:
> > > Hello,
> > >
> > > syzkaller hit the following crash on
> > > 1ea8d039f9edcfefb20d8ddfe136
, absolutely -- the null cipher is allocated together with the AEAD cipher
and should be freed together with the AEAD cipher.
Thanks a lot.
Reviewed-by: Stephan Mueller
Ciao
Stephan
Am Montag, 27. November 2017, 23:43:08 CET schrieb Eric Biggers:
Hi Eric,
> No, that doesn't help. I tested v4.15-rc1 with all the extra commits from
> crypto-2.6.git/master applied:
>
> crypto: algif_aead - skip SGL entries with NULL page
> crypto: af_alg - remove locking in async
Am Freitag, 24. November 2017, 17:25:55 CET schrieb Dmitry Vyukov:
Hi Dmitry,
> Eric also pointed me to grep. But I can't say the code is intuitive.
> I've spent way more time than I expected to just get a list of all
> algorithms with their types. Say, in some cases algorithm descriptions
> do n
Am Freitag, 24. November 2017, 17:18:08 CET schrieb Dmitry Vyukov:
Hi Dmitry,
>
> > {"rfc7539esp", []int{ALG_BLKCIPHER, ALG_HASH}},
> > {"rfc7539", []int{ALG_BLKCIPHER, ALG_HASH}},
> > {"rfc4543", []int{ALG_AEAD}},
> > {"rfc4106", []
Am Freitag, 24. November 2017, 17:10:59 CET schrieb Dmitry Vyukov:
Hi Dmitry,
> That's more-or-less what I did. Here:
>
> var allAlgs = map[int][]algDesc{
> ALG_AEAD: []algDesc{
> // templates:
> {"authencesn", []int{ALG_HASH, ALG_BLKCIPHER}},
> {"gcm", []int{ALG_CIPHER}},
>
> ALG
L page. Thus, the code needs to advance the start
> > pointer into the SGL to the first non-NULL entry.
> >
> > This fixes a crash visible on Intel x86 32 bit using the libkcapi test
> > suite.
> >
> > Fixes: 72548b093ee38 ("crypto: algif_aead - copy AAD from src to dst")
> > Signed-off-by: Stephan Mueller
>
> Patch applied. Thanks.
Would it make sense to feed it to stable?
Ciao
Stephan
Am Freitag, 24. November 2017, 16:53:26 CET schrieb Dmitry Vyukov:
Hi Dmitry,
> > You cannot talk to the inner ciphers. You only talk to one cipher that you
> > referred to with the name. Remember, the name is ONLY used to tell the
> > kernel which parts to put together during allocation. After t
ces for a crypto operation is moved into a
> > common function of af_alg_free_resources.
> >
> > Fixes: e870456d8e7c8 ("crypto: algif_skcipher - overhaul memory
> > management") Fixes: d887c52d6ae43 ("crypto: algif_aead - overhaul memory
> > management") Repo
Am Freitag, 24. November 2017, 15:55:59 CET schrieb Dmitry Vyukov:
Hi Dmitry,
> On Fri, Nov 24, 2017 at 3:36 PM, Stephan Mueller
wrote:
> > Am Freitag, 24. November 2017, 14:49:49 CET schrieb Dmitry Vyukov:
> >
> > Hi Dmitry,
> >
> >> On Thu, Nov
Am Freitag, 24. November 2017, 14:49:49 CET schrieb Dmitry Vyukov:
Hi Dmitry,
> I've cooked syzkaller change that teaches it to generate more
> algorithm names. Probably not idea, but much better than was before:
> https://github.com/google/syzkaller/blob/ddf7b3e0655cf6dfeacfe509e477c1486d2
> cc7
Am Freitag, 24. November 2017, 14:49:49 CET schrieb Dmitry Vyukov:
Hi Dmitry,
> On Thu, Nov 23, 2017 at 1:35 PM, Stephan Mueller
wrote:
> > Am Donnerstag, 23. November 2017, 12:34:54 CET schrieb Dmitry Vyukov:
> >
> > Hi Dmitry,
> >
> >> Btw, I've sta
Am Donnerstag, 23. November 2017, 12:34:54 CET schrieb Dmitry Vyukov:
Hi Dmitry,
> Btw, I've started doing some minimal improvements, did not yet sorted
> out alg types/names, and fuzzer started scratching surface:
>
> WARNING: kernel stack regs has bad 'bp' value 77 Nov 23 2017 12:29:36 CET
> g
Am Donnerstag, 23. November 2017, 12:27:30 CET schrieb Dmitry Vyukov:
Hi Dmitry,
> Hi Stephan,
>
> Thanks for the explanation! I am starting to digesting it.
>
> You say that:
> > static const struct crypto_type crypto_skcipher_type2 = {
> >
> > .type = CRYPTO_ALG_TYPE_SKCIPHER,
>
> w
Am Donnerstag, 23. November 2017, 10:37:35 CET schrieb Dmitry Vyukov:
Hi Dmitry,
> >> I've read the links and starring at the code, but still can't get it.
> >> The question is about textual type names in sockaddr.
> >> .cra_flags does not specify textual names.
> >> [3] again talks about int fla
Am Mittwoch, 22. November 2017, 18:03:14 CET schrieb Dmitry Vyukov:
Hi Dmitry,
> On Wed, Nov 22, 2017 at 5:54 PM, Stephan Mueller
wrote:
> > Am Dienstag, 21. November 2017, 21:46:28 CET schrieb Eric Biggers:
> >
> > Hi Eric,
> >
> >> (There is probably mo
Am Mittwoch, 22. November 2017, 11:44:51 CET schrieb Dmitry Vyukov:
Hi Dmitry,
>
> Thanks! I think we can incorporate this into syzkaller.
>
> One question: what's the relation between alg names and type ("aead",
> "hash", "rng", "skcipher")?
If you refer to AF_ALG, then the following applies:
Am Dienstag, 21. November 2017, 21:46:28 CET schrieb Eric Biggers:
Hi Eric,
>
> (There is probably more to improve for AF_ALG besides the algorithm names;
> this is just what I happened to notice for now.)
Just grepping may not cover all possibilities. Attached is a script that I use
to invoke
o/keywrap.c: In function ‘crypto_kw_encrypt’:
> crypto/keywrap.c:224: warning: integer constant is too large for ‘long’
> type
>
> Fixes: 9e49451d7a15365d ("crypto: keywrap - simplify code")
> Signed-off-by: Geert Uytterhoeven
Thank you
Reviewed-by: Stephan Mueller
Ciao
Stephan
Am Freitag, 3. November 2017, 14:20:16 CET schrieb Herbert Xu:
Hi Herbert,
> >
> > The code paths protected by the socket-lock do not use or modify the
> > socket in a non-atomic fashion. The actions pertaining the socket do not
> > even need to be handled as an atomic operation. Thus, the socke
Am Freitag, 3. November 2017, 14:20:16 CET schrieb Herbert Xu:
Hi Herbert,
> On Sun, Oct 29, 2017 at 09:39:30PM +0100, Stephan Müller wrote:
> > Am Mittwoch, 25. Oktober 2017, 17:26:31 CET schrieb Romain Izard:
> >
> > Hi Romain,
> >
> > the patch below should cover the issue you see. Would you
Am Mittwoch, 25. Oktober 2017, 17:26:31 CEST schrieb Romain Izard:
Hi Romain, Herbert,
> Hello,
>
> While running the kcapi test suite on a SAMA5D2 Xplained board with a
> v4.14-rc6 kernel, I encountered the following error:
Thank you for the report.
>
> # kcapi -x 9 -e -c "cbc(aes)" -i 0
Am Donnerstag, 19. Oktober 2017, 22:45:06 CEST schrieb Jason A. Donenfeld:
Hi Jason,
> We now structure things in a way that assumes the seeding function is
> always eventually called.
>
> Signed-off-by: Jason A. Donenfeld
> ---
> crypto/drbg.c | 20 +---
> 1 file changed, 5 in
Am Samstag, 21. Oktober 2017, 19:53:54 CEST schrieb SF Markus Elfring:
Hi Markus,
> From: Markus Elfring
> Date: Sat, 21 Oct 2017 19:29:11 +0200
>
> Adjust jump targets so that a bit of exception handling can be better
> reused at the end of this function.
>
> This issue was detected by using
Am Dienstag, 17. Oktober 2017, 09:58:31 CEST schrieb Christophe LEROY:
Hi Christophe,
>
> > If you tamper with the code shown above from libkcapi and set
> > alg_max_pages to a low value, the library reverts to sendmsg after the
> > given number of pages.
> Couldn't we get the libkcapi to splice
Am Dienstag, 17. Oktober 2017, 10:51:06 CEST schrieb Christophe LEROY:
Hi Christophe,
>
> I've now tried a test with 1.0.0, and there seems to be another big
> issue: the error returned by sendmsg() is not taken into account anymore:
It seems that this bug was there before. Can you please check
Am Montag, 16. Oktober 2017, 08:53:00 CEST schrieb Christophe LEROY:
Hi Christophe,
> Hi Stephan,
>
> I get an issue with md5sum of a big file with kernel 4.9. It don't get
> that issue with kernel 4.13.
The key to the difference in libkcapi is the following code:
static void _kcapi_handle_fla
kernels
and was therefore not marked for stable.
Fixes: 8ff590903d5fc ("crypto: algif_skcipher - User-space interface
for skcipher operations")
CC:
CC: Herbert Xu
Signed-off-by: Stephan Mueller
---
crypto/algif_skcipher.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
di
Am Mittwoch, 20. September 2017, 19:31:33 CEST schrieb Greg KH:
Hi Herbert,
> On Wed, Sep 20, 2017 at 03:47:46PM +0200, Stephan Mueller wrote:
> > Am Mittwoch, 20. September 2017, 10:32:09 CEST schrieb Herbert Xu:
> >
> > Hi Herbert,
> >
> > > Hmm, this patc
Am Mittwoch, 20. September 2017, 10:32:09 CEST schrieb Herbert Xu:
Hi Herbert,
>
> Hmm, this patch does not apply against the current tree. Is this
> a stable-only patch?
This would be a stable-only patch. With the overhauling of the AF_ALG memory
handling, this is a no-issue any more.
Thank
Am Dienstag, 12. September 2017, 11:07:26 CEST schrieb Christophe LEROY:
Hi Christophe,
> Hi again
>
> Le 12/09/2017 à 09:22, Stephan Mueller a écrit :
> > Am Dienstag, 12. September 2017, 09:20:41 CEST schrieb Stephan Mueller:
> >> I am thinking now to add AC_PREREQ
Am Dienstag, 12. September 2017, 09:20:41 CEST schrieb Stephan Mueller:
> I am thinking now to add AC_PREREQ([2.60]) to configure.ac.
I meant 2.69, of course? :-)
Ciao
Stephan
Am Dienstag, 12. September 2017, 09:01:08 CEST schrieb Christophe LEROY:
Hi Christophe,
> Hi Stephan
>
> Le 11/09/2017 à 21:17, Stephan Müller a écrit :
> > Am Montag, 11. September 2017, 19:07:31 CEST schrieb christophe leroy:
> >
> > Hi christophe,
> >
> >> Hello Stephan,
> >>
> >> I'm tryi
Am Freitag, 8. September 2017, 12:47:54 CEST schrieb Harsh Jain:
Hi Harsh,
> Hi,
>
> XTS template does not seems updating the IV after request completion. Same
> output if we run belwo command in loop
>
> [root@heptagon test]# ./kcapi -x 1 -d 4 -s -e -c "xts(aes)" -i
> 7fbc02ebf5b93322329df9bf
Am Donnerstag, 7. September 2017, 08:01:08 CEST schrieb Herbert Xu:
Hi Herbert,
> On Thu, Sep 07, 2017 at 07:48:53AM +0200, Stephan Müller wrote:
> > There is already such check:
> >
> > static inline int crypto_aead_decrypt(struct aead_request *req)
> > {
> >
> > struct crypto_aead *ae
Am Dienstag, 5. September 2017, 15:54:02 CEST schrieb Peter Huewe:
Hi Peter,
> Hi,
>
> while reading through the analysis of the Linux RNG by the BSI [1][2],
> I was suprised by the lack of reflecting on the usage of HWRNGs except
> RDRAND/RDSEED.
Sure, the study is about assessing entropy. How
Am Dienstag, 22. August 2017, 08:33:15 CEST schrieb Herbert Xu:
Hi Herbert,
> On Thu, Aug 10, 2017 at 08:06:18AM +0200, Stephan Müller wrote:
> > Hi Herbert,
> >
> > I found that issue while playing around with edge conditions in my
> > algif_akcipher implementation. This issue only manifests in
Am Mittwoch, 23. August 2017, 12:47:36 CEST schrieb Gilad Ben-Yossef:
Hi Gilad,
>
> Thank you for your persistence. It is appreciated :-)
>
> If I understood correctly what you are referring to than the buffer is not
> allocated in this code path (unless I've missed something):
Ah, that is what
d with cts(cbc(aes)) mode in tcrypt tests.
>
> Fixes: 302ef8ebb4b2 ("Add CryptoCell skcipher support")
> Signed-off-by: Gilad Ben-Yossef
> ---
>
> Changes from v1:
> - Free memory on error path, as pointed out by Stephan Mueller.
>
> drivers/staging/ccree/ssi_c
Am Mittwoch, 23. August 2017, 09:41:11 CEST schrieb Gilad Ben-Yossef:
Hi Gilad,
>
> if (areq) {
> + /*
> + * The crypto API expects us to set the req->info to the last
> + * ciphertext block. For encrypt, simply copy from the result.
> + *
Am Montag, 21. August 2017, 11:23:55 CEST schrieb Tudor Ambarus:
Hi Tudor,
>
> Oops, I missed the negation. When crypto_akcipher_set_priv_key succeeds
> you return the akcipher_maxsize. Not a bad idea, you save few cpu
> cycles.
I was hoping to save some context switches.
>
> > crypto akcipher
Am Donnerstag, 17. August 2017, 20:25:17 CEST schrieb PrasannaKumar
Muralidharan:
Hi PrasannaKumar,
> +
> +static int jz4780_rng_generate(struct crypto_rng *tfm,
> +const u8 *src, unsigned int slen,
> +u8 *dst, unsigned int dlen)
> +{
> +
Am Dienstag, 15. August 2017, 17:12:24 CEST schrieb Theodore Ts'o:
Hi Theodore, Jeffrey,
>
> Stephan, if you have any comments on the proposal made by David
> Fontaine and Olivier Vivolo, I'd appreciate hearing them!
(from Jefferey):
> This may be helpful, too. I use it to look up minimal weigh
Am Dienstag, 15. August 2017, 17:12:24 CEST schrieb Theodore Ts'o:
Hi Theodore,
>
> Stephan, if you have any comments on the proposal made by David
> Fontaine and Olivier Vivolo, I'd appreciate hearing them!
I think I have some news: The magma code I used for GF(2^32) testing was not
correct.
Am Mittwoch, 16. August 2017, 13:19:48 CEST schrieb Ryder Lee:
Hi Ryder,
> Currently, empty messages are not supported in GCM mode, hence add
> a check to prevent producing incorrect results.
In case the caller would provide empty messages, would there be just wrong
data or a real problem? Note
Am Mittwoch, 16. August 2017, 11:37:31 CEST schrieb Herbert Xu:
Hi Herbert,
> On Wed, Aug 16, 2017 at 10:39:43AM +0200, Stephan Mueller wrote:
> > Are you feeding that patch to the Linus 4.13-rc tree via your crypto-2.6
> > tree?
> Good point. Why don't you repost that
Am Mittwoch, 16. August 2017, 10:29:18 CEST schrieb Herbert Xu:
Hi Herbert,
> On Thu, Aug 10, 2017 at 10:25:58AM +0200, Stephan Mueller wrote:
> > I think there is such patch already, see [1].
> >
> > Your comment to that patch triggered my rewrite of the memory managment
Am Dienstag, 15. August 2017, 00:21:05 CEST schrieb Theodore Ts'o:
Hi Theodore,
> Have you looked at section 3.1.1 of the above cited paper?
>
> http://eprint.iacr.org/2012/251.pdf
Thanks for the hint, but that does not seem to solve the mystery either.
When I use magma with GF(2^32), I
Am Montag, 14. August 2017, 14:25:49 CEST schrieb Plauth, Max:
Hi Max,
> Dear linux-crypto community,
>
> I think I might have run into a bug in crypto/scatterwalk.c:
> - at the end of scatterwalk_pagedone, sg_next(walk->sg) is fed as an
> argument to scatterwalk_start(...) - sg_next (lib/scatte
Hi Ted,
drivers/char/random.c contains the following comment:
"""
* Our mixing functions were analyzed by Lacharme, Roeck, Strubel, and
* Videau in their paper, "The Linux Pseudorandom Number Generator
* Revisited" (see: http://eprint.iacr.org/2012/251.pdf). In their
* paper, they point out
Am Montag, 14. August 2017, 08:26:22 CEST schrieb Marcel Holtmann:
Hi Marcel,
> > The first part is clearly where AF_ALG fits and keyctl does not. This is
> > provided with the current patch set. As the keyctl API only handles, well,
> > keys, access to the raw ciphers may not be possible through
Am Freitag, 11. August 2017, 18:02:55 CEST schrieb Marcel Holtmann:
Hi Marcel,
> > Thanks for the reminder. I have looked at that but I am unsure about
> > whether this one covers asym crypto appropriately, too.
> >
> > The issue is that some hardware may only offer accelerators without a full
>
Am Freitag, 11. August 2017, 21:43:15 CEST schrieb Mat Martineau:
Hi Mat,
>
> I also would like to have more of those algorithms exposed to userspace,
> and I'd like to make sure the API is a good fit. There was extensive
> discussion of AF_ALG akcipher last year. v8 of the patch set updates the
Am Sonntag, 13. August 2017, 10:52:00 CEST schrieb Gilad Ben-Yossef:
Hi Gilad,
> While I don't have anything to contribute to the choice between
> keyctl() vs ALG_IF as interfaces for asymmetric cryptography, I would
> like to point out that there is both interest and HW support for
> private sy
Am Freitag, 11. August 2017, 14:56:18 CEST schrieb Tudor Ambarus:
Hi Tudor,
> Any reason why you keep this patch separately?
> I think you can squash this patch with patch 3/4.
There is no real reason. If you think it makes sense to add it to patch 3, I
will do that.
Thanks.
Ciao
Stephan
Am Freitag, 11. August 2017, 02:48:37 CEST schrieb Mat Martineau:
Hi Mat,
>
> AF_ALG is best suited for crypto use cases where a socket is set up once
> and there are lots of reads and writes to justify the setup cost. With
> asymmetric crypto, the setup cost is high when you might only use the
Am Donnerstag, 10. August 2017, 14:49:39 CEST schrieb Tudor Ambarus:
Hi Tudor,
thanks for reviewing
> >
> > - err = ctx->enc ? crypto_aead_encrypt(&areq->cra_u.aead_req) :
> > -crypto_aead_decrypt(&areq->cra_u.aead_req);
> > - } else {
> > + } else
>
>
Am Donnerstag, 10. August 2017, 10:21:53 CEST schrieb Herbert Xu:
Hi Herbert,
> On Thu, Aug 10, 2017 at 10:16:48AM +0200, Stephan Mueller wrote:
> > As now the AIO code path is updated, the bug that I was reporting last
> > September allowing to crash the kernel via AF_ALG is fix
Am Mittwoch, 9. August 2017, 15:57:34 CEST schrieb Herbert Xu:
Hi Herbert,
>
> Patch applied. Thanks.
Thanks.
As now the AIO code path is updated, the bug that I was reporting last
September allowing to crash the kernel via AF_ALG is fixed.
As the patch is very invasive, I am not sure that p
is 32
since the tag is not returned any more.
Reported-by: Mat Martineau
Signed-off-by: Stephan Mueller
---
crypto/algif_aead.c | 57 +
1 file changed, 36 insertions(+), 21 deletions(-)
diff --git a/crypto/algif_aead.c b/crypto/algif_aead.c
in
16 bytes CT and 16 bytes tag, the AF_ALG AEAD interface
before showed a recv return code of 48 (bytes) whereas after this patch,
the return code is 32 since the tag is not returned any more.
Reported-by: Mat Martineau
Signed-off-by: Stephan Mueller
---
crypto/algif_aead.c |
and no AAD is provided and the caller only
requests the generation of the tag value.
Signed-off-by: Stephan Mueller
---
crypto/algif_aead.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/crypto/algif_aead.c b/crypto/algif_aead.c
index 80a0f1a..6e95137 100644
--- a/cry
content of the
scratch buffer to the caller's buffer.
The scratch buffer is allocated during allocation time of the CTR DRBG
as its access is protected with the DRBG mutex.
Signed-off-by: Stephan Mueller
---
crypto/drbg.c | 29 -
include/crypto/drbg.h | 2
time of the CTR DRBG
as its access is protected with the DRBG mutex.
Signed-off-by: Stephan Mueller
---
crypto/drbg.c | 35 +++
include/crypto/drbg.h | 2 ++
2 files changed, 33 insertions(+), 4 deletions(-)
diff --git a/crypto/drbg.c b/crypto/drbg.c
index
in case the
caller-provided buffer is deemed not suitable for use in an SG. The
crypto operation of the CTR DRBG produces its output with that scratch
buffer.
The scratch buffer is allocated during allocation time of the CTR DRBG
as its access is protected with the DRBG mutex.
Signed-off-by: Step
Am Freitag, 18. November 2016, 12:31:10 CET schrieb Stephan Mueller:
Hi Herbert,
> Hi Herbert,
>
> Once in a while I seem to trigger a bug in the blkcipher_walk code which I
> cannot track down. This bug happens sporadically where I assume that it has
> something to do
Am Mittwoch, 16. November 2016, 17:04:46 CET schrieb Herbert Xu:
Hi Herbert,
> On Wed, Nov 16, 2016 at 10:02:59AM +0100, Stephan Mueller wrote:
> > One thing occurred to me: The copying of the AD would only be done of src
> > != dst. For the AF_ALG interface, I thing we always
the output buffer again. This implies that only the
first 128 bytes of the output buffer would ever be filled.
The patch adds the advancement of the buffer pointer to fill the entire
buffer.
Signed-off-by: Stephan Mueller
---
crypto/drbg.c | 1 +
1 file changed, 1 insertion(+)
diff --git a
Hi Herbert,
Once in a while I seem to trigger a bug in the blkcipher_walk code which I
cannot track down. This bug happens sporadically where I assume that it has
something to do with the memory management in the slow path of blkcipher_walk.
I am using the CTR DRBG code that in turn uses the ct
Am Donnerstag, 17. November 2016, 09:07:48 CET schrieb Corentin Labbe:
Hi Corentin,
>
> Seed again, or just do not seed (and so return -EAGAIN for read() function)
> until ready_callback ?
This is your choice. But for the start sequence, you should not simply rely on
get_random_bytes.
For the
Am Mittwoch, 16. November 2016, 16:57:42 CET schrieb Herbert Xu:
Hi Herbert,
> On Tue, Nov 15, 2016 at 08:06:47PM +0100, Stephan Mueller wrote:
> > Shall the fix be rolled into the patch together with the fix for the tag
> > value as well as the crash fix? Or can we have a st
Am Samstag, 12. November 2016, 10:13:02 CET schrieb Herbert Xu:
Hi Herbert,
> On Sat, Nov 12, 2016 at 03:03:36AM +0100, Stephan Mueller wrote:
> > When you have separate buffers, the kernel does not seem to copy the AD
> > over to the target buffer.
>
> OK we should defini
Am Samstag, 12. November 2016, 09:55:19 CET schrieb Herbert Xu:
Hi Herbert,
> On Thu, Nov 10, 2016 at 04:32:03AM +0100, Stephan Mueller wrote:
> > The kernel crypto API AEAD cipher operation generates output such that
> > space for the AAD is reserved in the output buffe
Am Freitag, 11. November 2016, 16:26:12 CET schrieb Mat Martineau:
Hi Mat,
> >
> > With this solution, the caller must not use sendpage with the exact same
> > buffers for input and output. The following rationale applies: When
> > the caller sends the same buffer for input/output to the sendpage
Am Dienstag, 13. September 2016, 13:27:34 CET schrieb Stephan Mueller:
Hi Herbert,
> Am Dienstag, 13. September 2016, 18:08:16 CEST schrieb Herbert Xu:
>
> Hi Herbert,
>
> > This patch appears to be papering over a real bug.
> >
> > The async path should be exa
Am Dienstag, 13. September 2016, 18:12:46 CET schrieb Herbert Xu:
Hi Herbert,
> On Sun, Sep 11, 2016 at 04:59:19AM +0200, Stephan Mueller wrote:
> > Hi Herbert,
> >
> > The AIO support for algif_aead is broken when submitting more than one
> > iocb.>
> > The
Handle the case when the caller provided a zero buffer to
sendmsg/sendpage. Such scenario is legal for AEAD ciphers when no
plaintext / ciphertext and no AAD is provided and the caller only
requests the generation of the tag value.
Signed-off-by: Stephan Mueller
---
crypto/algif_aead.c | 5
return code is 32 since the tag is not returned any more.
Reported-by: Mat Martineau
Signed-off-by: Stephan Mueller
---
crypto/algif_aead.c | 77 ++---
1 file changed, 55 insertions(+), 22 deletions(-)
diff --git a/crypto/algif_aead.c b/crypto
this fixes a kernel crash that
is present in current kernel versions.
The patch set can be tested with the HEAD branch of libkcapi found at [1].
If the patch set is accepted, the development branch will be released as
0.13.0.
[1] https://github.com/smuellerDD/libkcapi
Stephan Mueller (3):
crypto
has already replaced the AAD with the ciphertext,
the tag calculation will take the ciphertext as AAD and thus calculate
a wrong tag.
Reported-by: Mat Martineau
Signed-off-by: Stephan Mueller
---
crypto/algif_aead.c | 143 +---
1 file changed, 113
Am Montag, 31. Oktober 2016, 16:18:32 CET schrieb Mat Martineau:
Hi Mat,
>
> My main concern is getting the semantics correct and consistent in a
> single patch series. It would be a big problem to explain that AF_ALG AEAD
> read and write works one way in 4.x, another way in 4.y, and some
> diff
Am Dienstag, 8. November 2016, 17:16:38 CET schrieb Harsh Jain:
Hi Harsh,
> On 08-11-2016 16:45, Stephan Mueller wrote:
> > Am Donnerstag, 27. Oktober 2016, 15:36:08 CET schrieb Harsh Jain:
> >
> > Hi Harsh,
> >
> >>>> +static void chcr_verify_ta
Am Donnerstag, 27. Oktober 2016, 15:36:08 CET schrieb Harsh Jain:
Hi Harsh,
> >> +static void chcr_verify_tag(struct aead_request *req, u8 *input, int
> >> *err)
> >> +{
> >> + u8 temp[SHA512_DIGEST_SIZE];
> >> + struct crypto_aead *tfm = crypto_aead_reqtfm(req);
> >> + int authsize = crypto_a
Am Montag, 31. Oktober 2016, 16:18:32 CET schrieb Mat Martineau:
Hi Mat,
> My main concern is getting the semantics correct and consistent in a
> single patch series. It would be a big problem to explain that AF_ALG AEAD
> read and write works one way in 4.x, another way in 4.y, and some
> differ
Am Freitag, 28. Oktober 2016, 15:21:19 CET schrieb Mat Martineau:
Hi Mat,
> >
> > Please check the current patch (the one I sent to you as a pre-release did
> > not contain the fix for the decryption part -- the patch sent to the list
> > and what we discuss here contains the appropriate handling
201 - 300 of 1554 matches
Mail list logo
