should be 1 not 2 from
crypto_larval_add. But it's not clear to me which is sensible here.
What's the right solution here?
Thanks,
-Kees
--
Kees Cook
Chrome OS Security
--
To unsubscribe from this list: send the line unsubscribe linux-crypto in
the body of a message to majord...@vger.kernel.org
On Sat, Sep 7, 2013 at 7:39 AM, Neil Horman nhor...@tuxdriver.com wrote:
On Fri, Sep 06, 2013 at 04:20:50PM -0700, Kees Cook wrote:
Hi,
I've tracked down a race condition and ref counting problem in the
crypto API internals. We've been seeing it under Chrome OS, but it
seems it's
On Sat, Sep 7, 2013 at 6:32 PM, Herbert Xu herb...@gondor.apana.org.au wrote:
On Fri, Sep 06, 2013 at 04:20:50PM -0700, Kees Cook wrote:
In the two-thread situation, the first thread gets a larval with
refcnt 2 via crypto_larval_add. (Why 2?) The next thread finds the
larval via
On Sat, Sep 7, 2013 at 9:54 PM, Herbert Xu herb...@gondor.apana.org.au wrote:
On Sun, Sep 08, 2013 at 02:37:03PM +1000, Herbert Xu wrote:
On Sat, Sep 07, 2013 at 08:34:15PM -0700, Kees Cook wrote:
However, I noticed on the good path (even without the above patch),
I sometimes see a double
On Sat, Sep 7, 2013 at 11:01 PM, Kees Cook keesc...@chromium.org wrote:
On Sat, Sep 7, 2013 at 9:54 PM, Herbert Xu herb...@gondor.apana.org.au
wrote:
On Sun, Sep 08, 2013 at 02:37:03PM +1000, Herbert Xu wrote:
On Sat, Sep 07, 2013 at 08:34:15PM -0700, Kees Cook wrote:
However, I noticed
When bringing a new RNG source online, it seems like it would make sense
to use some of its bytes to make the system entropy pool more random,
as done with all sorts of other devices that contain per-device or
per-boot differences.
Signed-off-by: Kees Cook keesc...@chromium.org
---
Added linux
When bringing a new RNG source online, it seems like it would make sense
to use some of its bytes to make the system entropy pool more random,
as done with all sorts of other devices that contain per-device or
per-boot differences.
Signed-off-by: Kees Cook keesc...@chromium.org
---
drivers/char
On Tue, Mar 4, 2014 at 7:38 AM, Jason Cooper ja...@lakedaemon.net wrote:
Kees, Ted,
On Mon, Mar 03, 2014 at 03:51:48PM -0800, Kees Cook wrote:
When bringing a new RNG source online, it seems like it would make sense
to use some of its bytes to make the system entropy pool more random
On Tue, Mar 4, 2014 at 11:53 AM, Jason Cooper ja...@lakedaemon.net wrote:
On Tue, Mar 04, 2014 at 11:01:49AM -0800, Kees Cook wrote:
On Tue, Mar 4, 2014 at 7:38 AM, Jason Cooper ja...@lakedaemon.net wrote:
Kees, Ted,
On Mon, Mar 03, 2014 at 03:51:48PM -0800, Kees Cook wrote:
When
On Wed, Mar 5, 2014 at 1:11 PM, Jason Cooper ja...@lakedaemon.net wrote:
Matt, Kees,
On Tue, Mar 04, 2014 at 04:39:57PM -0600, Matt Mackall wrote:
On Tue, 2014-03-04 at 11:59 -0800, Kees Cook wrote:
On Tue, Mar 4, 2014 at 11:53 AM, Jason Cooper ja...@lakedaemon.net wrote:
On Tue, Mar 04
something into the pool is performance.
Excellent. So it sounds like you're okay with my original patch as-is?
-Kees
--
Kees Cook
Chrome OS Security
--
To unsubscribe from this list: send the line unsubscribe linux-crypto in
the body of a message to majord...@vger.kernel.org
More majordomo info
(-)
Signed-off-by: Marek Vasut ma...@denx.de
Cc: Herbert Xu herb...@gondor.apana.org.au
Cc: Horia Geanta horia.gea...@freescale.com
Thanks for doing this! The final result looks good to me, though I too
can't test with real hardware. Please consider the whole series:
Reviewed-by: Kees Cook keesc
This prefixes all crypto module loading with crypto- so we never run
the risk of exposing module auto-loading to userspace via a crypto API,
as demonstrated by Mathias Krause:
https://lkml.org/lkml/2013/3/4/70
Signed-off-by: Kees Cook keesc...@chromium.org
---
arch/arm/crypto/aes_glue.c
On Mon, Nov 17, 2014 at 10:38 AM, Mathias Krause mini...@googlemail.com wrote:
On 17 November 2014 16:09, Herbert Xu herb...@gondor.apana.org.au wrote:
On Fri, Nov 14, 2014 at 01:34:59PM -0800, Kees Cook wrote:
This prefixes all crypto module loading with crypto- so we never run
the risk
This prefixes all crypto module loading with crypto- so we never run
the risk of exposing module auto-loading to userspace via a crypto API,
as demonstrated by Mathias Krause:
https://lkml.org/lkml/2013/3/4/70
Signed-off-by: Kees Cook keesc...@chromium.org
---
v2:
- added missing #include
On Mon, Nov 17, 2014 at 3:20 PM, Mathias Krause mini...@googlemail.com wrote:
On 17 November 2014 21:02, Kees Cook keesc...@chromium.org wrote:
This prefixes all crypto module loading with crypto- so we never run
the risk of exposing module auto-loading to userspace via a crypto API
On Tue, Nov 18, 2014 at 3:12 PM, Mathias Krause mini...@googlemail.com wrote:
On 18 November 2014 01:45, Kees Cook keesc...@chromium.org wrote:
On Mon, Nov 17, 2014 at 3:20 PM, Mathias Krause mini...@googlemail.com
wrote:
On 17 November 2014 21:02, Kees Cook keesc...@chromium.org wrote
This prefixes all crypto module loading with crypto- so we never run
the risk of exposing module auto-loading to userspace via a crypto API,
as demonstrated by Mathias Krause:
https://lkml.org/lkml/2013/3/4/70
Signed-off-by: Kees Cook keesc...@chromium.org
---
v3:
- added unprefixed alias back
)
crypto-vfat(blowfish)-all
crypto-vfat
Reported-by: Mathias Krause mini...@googlemail.com
Signed-off-by: Kees Cook keesc...@chromium.org
---
crypto/algapi.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/crypto/algapi.c b/crypto/algapi.c
index e8d3a7dca8c4
)
crypto-vfat(blowfish)-all
crypto-vfat
Reported-by: Mathias Krause mini...@googlemail.com
Signed-off-by: Kees Cook keesc...@chromium.org
---
crypto/algapi.c | 4 ++--
crypto/authenc.c| 1 +
crypto/authencesn.c | 1 +
crypto/cbc.c| 1 +
crypto/chainiv.c| 1 +
crypto/cmac.c
)
crypto-vfat(blowfish)-all
crypto-vfat
Reported-by: Mathias Krause mini...@googlemail.com
Signed-off-by: Kees Cook keesc...@chromium.org
Acked-by: Mathias Krause mini...@googlemail.com
---
v3:
- added a few more missing aliases, minipli
v2:
- added missing aliases, minipli
---
arch/x86
rather than
having it be kernel auto-loaded?
-Kees
--
Kees Cook
Chrome OS Security
--
To unsubscribe from this list: send the line unsubscribe linux-crypto in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
autoloading with crypto-)
Cc: Kees Cook keesc...@chromium.org
Signed-off-by: Mathias Krause mini...@googlemail.com
Ah, perfect! Thanks for finding the missing ones!
Acked-by: Kees Cook keesc...@chromium.org
-Kees
---
arch/powerpc/crypto/sha1.c |1 +
arch/x86/crypto/sha-mb
for crypto-ccm and crypto-ctr if you
build them as modules.
I still haven't been able to reproduce this. :(
-Kees
--
Kees Cook
Chrome OS Security
--
To unsubscribe from this list: send the line unsubscribe linux-crypto in
the body of a message to majord...@vger.kernel.org
More majordomo info
CRYPTO_REPORT_MAXSIZE (sizeof(struct crypto_user_alg) + \
sizeof(struct crypto_report_blkcipher))
Thanks!
-Kees
--
Kees Cook
Chrome OS Security
--
To unsubscribe from this list: send the line unsubscribe linux-crypto in
the body of a message to majord...@vger.kernel.org
More
Since the API for jent_panic() does not include format string parameters,
adjust the call to panic() to use a literal string to avoid any future
callers from leaking format strings into the panic message.
Signed-off-by: Kees Cook keesc...@chromium.org
---
crypto/jitterentropy-kcapi.c | 2 +-
1
// res of less than 0 means an error occured
> return -EIO;
> + }
>
> - bytes = dest_len;
> + bytes = res;
> data = squashfs_first_page(output);
> buff = stream->output;
> while (data) {
> @@ -1
o fix. Thus, as a compromise
> between log-messages-for-all and nobody-knows, this is `default y`,
> except it is also `depends on DEBUG_KERNEL`. This will ensure that the
> curious see the messages while others don't have to.
This commit log needs updating (default DEBUG_KERNEL, not depen
useful configs. Since it doesn't strictly _depend_ on
DEBUG_KERNEL, I think it's probably a mistake to enforce a false
dependency. Using it as a hint for the default seems maybe like a good
middle ground. (And if people can't agree on that, then I guess
"default n"...)
-Kees
--
Kees Cook
Pixel Security
ocking nearly
> anything else from happening.
>
> On x86, that's only the initial canary since the per-task canaries end
> up being used, but elsewhere at least without SMP disabled or changes to
> GCC that's all there is so the entropy matters.
And just to note, building with GCC_PLUGIN_LATENT_ENTROPY, while it
(correctly) doesn't credit entropy to the pool, should at least make
the pool less deterministic between boots.
-Kees
--
Kees Cook
Pixel Security
struct module *owner = NULL;
>
> + if (!rdy->func)
> + return;
Perhaps add a note here about what a NULL func means here? (e.g.
"Already run, not in the list.")
> +
> spin_lock_irqsave(_ready_list_lock, flags);
> if (!list_empty(>list)) {
> list_del_init(>list);
> --
> 2.14.2
>
Otherwise, yeah, looks sensible.
-Kees
--
Kees Cook
Pixel Security
Yang Shi <yan...@alibaba-inc.com>
> Cc: Kees Cook <keesc...@chromium.org>
> Cc: Anton Vorontsov <an...@enomsg.org>
> Cc: Colin Cross <ccr...@android.com>
> Cc: Tony Luck <tony.l...@intel.com>
Thanks! I've applied this for -next.
-Kees
> ---
> fs/psto
Lars Persson <lars.pers...@axis.com>
Cc: Niklas Cassel <niklas.cas...@axis.com>
Cc: "David S. Miller" <da...@davemloft.net>
Cc: Jamie Iles <ja...@jamieiles.com>
Cc: linux-arm-ker...@axis.com
Cc: linux-crypto@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org
S
f-by: Kyle Spiers <ksspi...@google.com>
Reviewed-by: Kees Cook <keesc...@chromium.org>
Is this something that should go via Vinod, Dan, or direct through
Herbert's crypto tree?
Thanks!
-Kees
> ---
> Forgot to add slab.h
> ---
> crypto/async_tx/async_pq.c | 18 ++
to avoid possible races in the value changing.
[1]
https://lkml.kernel.org/r/CA+55aFzCG-zNmZwX4A2FQpadafLfEzK6CC=qpxydaacu1rq...@mail.gmail.com
Signed-off-by: Kees Cook <keesc...@chromium.org>
---
crypto/tcrypt.c | 118 +---
1 file chang
f-by: Kyle Spiers <ksspi...@google.com>
Reviewed-by: Kees Cook <keesc...@chromium.org>
Thanks for working on this one!
-Kees
> ---
> crypto/async_tx/async_pq.c | 18 ++
> crypto/async_tx/raid6test.c | 8 +++-
> 2 files changed, 21 insertions(+), 5 deletions(
On Wed, Jul 25, 2018 at 4:32 AM, Rafael J. Wysocki wrote:
> On Tue, Jul 24, 2018 at 6:49 PM, Kees Cook wrote:
>> In the quest to remove all stack VLA usage from the kernel[1], this
>> removes the discouraged use of AHASH_REQUEST_ON_STACK by switching to
>> shash di
On the quest to remove all VLAs from the kernel[1], this switches to
a pair of kmalloc regions instead of using the stack. This also moves
the get_random_bytes() after all allocations (and drops the needless
"nbytes" variable).
[1] https://lkml.org/lkml/2018/3/7/621
Signed-off-by:
On Thu, Mar 8, 2018 at 1:43 AM, Tudor Ambarus
<tudor.amba...@microchip.com> wrote:
> Hi, Kees,
>
>
> On 03/07/2018 11:56 PM, Kees Cook wrote:
>>
>> On the quest to remove all VLAs from the kernel[1], this switches to
>> a pair of kmalloc regions instead
On the quest to remove all VLAs from the kernel[1], this switches to
a pair of kmalloc regions instead of using the stack. This also moves
the get_random_bytes() after all allocations (and drops the needless
"nbytes" variable).
[1] https://lkml.org/lkml/2018/3/7/621
Signed-off-by:
7 ++-
> crypto/ctr.c | 13 +++--
> crypto/cts.c | 8 ++--
> crypto/internal.h | 8
> crypto/pcbc.c | 9 +++--
> 6 files changed, 48 insertions(+), 11 deletions(-)
These all look good to me! Thanks for the refactoring. :)
Reviewed-by: Kees Cook <keesc...@chromium.org>
-Kees
--
Kees Cook
Pixel Security
On Fri, Mar 30, 2018 at 9:55 AM, Kees Cook <keesc...@chromium.org> wrote:
> On the quest to remove all VLAs from the kernel[1], this avoids VLAs
> by just using the maximum allocation size (4 bytes) for stack arrays.
> All the VLAs in ecc were either 3 or 4 bytes (or a multiple),
does not end up larger than the arrays.
This includes a removal of the earlier attempt at this fix from
commit a963834b4742 ("crypto/ecc: Remove stack VLA usage")
[1] https://lkml.org/lkml/2018/3/7/621
Signed-off-by: Kees Cook <keesc...@chromium.org>
---
v2:
- Squash revert (herb
On Fri, Mar 16, 2018 at 8:56 AM, Herbert Xu <herb...@gondor.apana.org.au> wrote:
> On Thu, Mar 08, 2018 at 01:57:02PM -0800, Kees Cook wrote:
>> On the quest to remove all VLAs from the kernel[1], this switches to
>> a pair of kmalloc regions instead of using the s
does not end up larger than the arrays.
[1] https://lkml.org/lkml/2018/3/7/621
Signed-off-by: Kees Cook <keesc...@chromium.org>
---
This expects 14de52112ee70ca289fa77bf2d9cbc79fd2c811f to be reverted.
---
crypto/ecc.c | 47 ---
crypto/ecc.h
he conflict with Kees's
> patch in cryptodev. Otherwise, I can respin it to apply onto cryptodev
> directly. The patch was build tested only - I don't have the hardware.
I think the depth warning is minor (90 bytes over), so I don't think
it's high priority to backport the fix. I'm fine either way, of
course.
Reviewed-by: Kees Cook
-Kees
--
Kees Cook
Pixel Security
46 matches
Mail list logo
