Re: [PATCH 1/2] netdevice: add netdev_pub helper function

On Mon, Jul 10, 2017 at 10:04 AM, David Miller wrote: > I disagree. Assuming one can go from the driver private to the netdev > object trivially is a worse assumption than the other way around, and > locks us into the current implementation of how the netdev and driver >

Re: [PATCH 1/2] netdevice: add netdev_pub helper function

On Mon, Jul 10, 2017 at 10:04 AM, David Miller wrote: > I disagree. Assuming one can go from the driver private to the netdev > object trivially is a worse assumption than the other way around, and > locks us into the current implementation of how the netdev and driver > private memory is

[PATCH 2/2] ioc3-eth: use netdev_pub instead of handrolling alignment

It's safer to use the generic library function for this, rather than reinventing it here with hard-coded alignment values. Signed-off-by: Jason A. Donenfeld <ja...@zx2c4.com> --- drivers/net/ethernet/sgi/ioc3-eth.c | 11 +++ 1 file changed, 3 insertions(+), 8 deletions(-) diff

[PATCH 2/2] ioc3-eth: use netdev_pub instead of handrolling alignment

It's safer to use the generic library function for this, rather than reinventing it here with hard-coded alignment values. Signed-off-by: Jason A. Donenfeld --- drivers/net/ethernet/sgi/ioc3-eth.c | 11 +++ 1 file changed, 3 insertions(+), 8 deletions(-) diff --git a/drivers/net

[PATCH 1/2] netdevice: add netdev_pub helper function

single function, which makes everything confusing and less clear. Additionally, this enables a "correct" way of doing such a thing, instead of having drivers attempt to reinvent the wheel and screw it up. Signed-off-by: Jason A. Donenfeld <ja...@zx2c4.com> --- include/linux/

[PATCH 1/2] netdevice: add netdev_pub helper function

single function, which makes everything confusing and less clear. Additionally, this enables a "correct" way of doing such a thing, instead of having drivers attempt to reinvent the wheel and screw it up. Signed-off-by: Jason A. Donenfeld --- include/linux/netdevice.h | 11 +

Re: [PATCH] random: reorder READ_ONCE() in get_random_uXX

Seems reasonable to me. Signed-off-by: Jason A. Donenfeld <ja...@zx2c4.com>

Re: [PATCH] random: reorder READ_ONCE() in get_random_uXX

Seems reasonable to me. Signed-off-by: Jason A. Donenfeld

Re: [PATCH v2] kref: Avoid null pointer dereference after WARN

On Tue, Jun 27, 2017 at 9:22 PM, Andi Kleen wrote: > Who would actually set mman_min_addr incorrectly? Historically there have been quite a few bypasses of mmap_min_addr, actually. This is well-trodden ground.

Re: [PATCH v2] kref: Avoid null pointer dereference after WARN

On Tue, Jun 27, 2017 at 9:22 PM, Andi Kleen wrote: > Who would actually set mman_min_addr incorrectly? Historically there have been quite a few bypasses of mmap_min_addr, actually. This is well-trodden ground.

Re: [PATCH v2] kref: Avoid null pointer dereference after WARN

nline int kref_put_lock(struct kref *kref, > spinlock_t *lock) > { > if (refcount_dec_and_lock(>refcount, lock)) { > + BUG_ON(release == NULL); > release(kref); > return 1; > } > -- > 2.7.4 Looks good to me. Signed-off-by: Jason A. Donenfeld <ja...@zx2c4.com>

Re: [PATCH v2] kref: Avoid null pointer dereference after WARN

refcount, lock)) { > + BUG_ON(release == NULL); > release(kref); > return 1; > } > -- > 2.7.4 Looks good to me. Signed-off-by: Jason A. Donenfeld

Re: [PATCH] kref: Avoid null pointer dereference after WARN

On Tue, Jun 27, 2017 at 4:49 PM, Andi Kleen wrote: > Is there any data how many security holes this would have > caught? Please no hand waving. A lot of the recent > security patches seem to have gone in with just a lot of > hand waving and security theater I don't practice

Re: [PATCH] kref: Avoid null pointer dereference after WARN

On Tue, Jun 27, 2017 at 4:49 PM, Andi Kleen wrote: > Is there any data how many security holes this would have > caught? Please no hand waving. A lot of the recent > security patches seem to have gone in with just a lot of > hand waving and security theater I don't practice security theater.

Re: [PATCH] kref: Avoid null pointer dereference after WARN

function, something is really messed up and the kernel should "safely" panic instead. > > thanks, > > greg k-h -- Jason A. Donenfeld Deep Space Explorer fr: +33 6 51 90 82 66 us: +1 513 476 1200 www.jasondonenfeld.com www.zx2c4.com zx2c4.com/keys/AB9942E6D4A4CFC3412620A749FC7012A5DE03AE.asc

Re: [PATCH] kref: Avoid null pointer dereference after WARN

function, something is really messed up and the kernel should "safely" panic instead. > > thanks, > > greg k-h -- Jason A. Donenfeld Deep Space Explorer fr: +33 6 51 90 82 66 us: +1 513 476 1200 www.jasondonenfeld.com www.zx2c4.com zx2c4.com/keys/AB9942E6D4A4CFC3412620A749FC7012A5DE03AE.asc

Re: [PATCH] net/icmp: restore source address if packet is NATed

Hi David, On Sun, Jun 25, 2017 at 5:49 PM, David Miller wrote: > This violates things on so many levels. Yes, indeed. > I think this kind of thing need to be hidden inside of netfilter, > it can do the rate limiting and stuff like that in the spot > where it makes the

Re: [PATCH] net/icmp: restore source address if packet is NATed

Hi David, On Sun, Jun 25, 2017 at 5:49 PM, David Miller wrote: > This violates things on so many levels. Yes, indeed. > I think this kind of thing need to be hidden inside of netfilter, > it can do the rate limiting and stuff like that in the spot > where it makes the transformation and knows

[PATCH] net/icmp: restore source address if packet is NATed

of the subsequent processing in the icmp_send and icmpv6_send functions, so we do the lookup very early on, so that the rest of the ICMP machinery can progress as usual. In my tests, this setup works very well. Signed-off-by: Jason A. Donenfeld <ja...@zx2c4.com> --- net/ipv4/icmp.

[PATCH] net/icmp: restore source address if packet is NATed

of the subsequent processing in the icmp_send and icmpv6_send functions, so we do the lookup very early on, so that the rest of the ICMP machinery can progress as usual. In my tests, this setup works very well. Signed-off-by: Jason A. Donenfeld --- net/ipv4/icmp.c | 21 + net

Re: [kernel-hardening] [PATCH] random: warn when kernel uses unseeded randomness

l issue with that architecture > or subarchitecture. To see all uses of unseeded randomness, > developers can enable CONFIG_WARN_ALL_UNSEEDED_RANDOM. Seems fine to me. Acked-by: Jason A. Donenfeld <ja...@zx2c4.com> Jason

Re: [kernel-hardening] [PATCH] random: warn when kernel uses unseeded randomness

e with that architecture > or subarchitecture. To see all uses of unseeded randomness, > developers can enable CONFIG_WARN_ALL_UNSEEDED_RANDOM. Seems fine to me. Acked-by: Jason A. Donenfeld Jason

[PATCH] random: warn when kernel uses unseeded randomness

`. This will ensure that the curious see the messages while others don't have to. Signed-off-by: Jason A. Donenfeld <ja...@zx2c4.com> Signed-off-by: Theodore Ts'o <ty...@mit.edu> --- Hi Ted, This patch is meant to replace d06bfd1989fe97623b32d6df4ffa6e4338c99dc8, which is currently in y

[PATCH] random: warn when kernel uses unseeded randomness

`. This will ensure that the curious see the messages while others don't have to. Signed-off-by: Jason A. Donenfeld Signed-off-by: Theodore Ts'o --- Hi Ted, This patch is meant to replace d06bfd1989fe97623b32d6df4ffa6e4338c99dc8, which is currently in your dev tree. It switches from using `default y

Re: [PATCH] random: silence compiler warnings and fix race

On Wed, Jun 21, 2017 at 1:38 AM, Theodore Ts'o wrote: > The punch was in response to this statement, which I personally found > fairly infuriating: > >>> I more or less agree with you that we should just turn this on for all >>> users and they'll just have to live with the spam and

Re: [PATCH] random: silence compiler warnings and fix race

On Wed, Jun 21, 2017 at 1:38 AM, Theodore Ts'o wrote: > The punch was in response to this statement, which I personally found > fairly infuriating: > >>> I more or less agree with you that we should just turn this on for all >>> users and they'll just have to live with the spam and report odd >>>

Re: [kernel-hardening] Re: [PATCH] random: silence compiler warnings and fix race

On Tue, Jun 20, 2017 at 8:14 PM, Kees Cook wrote: > How about doing this: > >default DEBUG_KERNEL > > Most distro kernel select DEBUG_KERNEL because it unhides a bunch of > other useful configs. Since it doesn't strictly _depend_ on > DEBUG_KERNEL, I think it's probably

Re: [kernel-hardening] Re: [PATCH] random: silence compiler warnings and fix race

On Tue, Jun 20, 2017 at 8:14 PM, Kees Cook wrote: > How about doing this: > >default DEBUG_KERNEL > > Most distro kernel select DEBUG_KERNEL because it unhides a bunch of > other useful configs. Since it doesn't strictly _depend_ on > DEBUG_KERNEL, I think it's probably a mistake to enforce a

Re: [PATCH] random: silence compiler warnings and fix race

On Tue, Jun 20, 2017 at 11:36 AM, Theodore Ts'o wrote: >> But I think there's another camp that would mutiny in the face of this >> kind of hubris. > > Blocking the boot for hours and hours until we have enough entropy to > initialize the CRNG is ***not*** an acceptable way of

Re: [PATCH] random: silence compiler warnings and fix race

On Tue, Jun 20, 2017 at 11:36 AM, Theodore Ts'o wrote: >> But I think there's another camp that would mutiny in the face of this >> kind of hubris. > > Blocking the boot for hours and hours until we have enough entropy to > initialize the CRNG is ***not*** an acceptable way of making the >

Re: [PATCH] random: silence compiler warnings and fix race

On Tue, Jun 20, 2017 at 10:33 AM, Jeffrey Walton wrote: > I think it is a bad idea to suppress all messages from a security > engineering point of view. > > Many folks don't run debug kernels. Most of the users who want or need > to know of the issues won't realize its

Re: [PATCH] random: silence compiler warnings and fix race

On Tue, Jun 20, 2017 at 10:33 AM, Jeffrey Walton wrote: > I think it is a bad idea to suppress all messages from a security > engineering point of view. > > Many folks don't run debug kernels. Most of the users who want or need > to know of the issues won't realize its happening. Consider, the >

Re: [PATCH] random: silence compiler warnings and fix race

Hey Ted, On Tue, Jun 20, 2017 at 02:03:44AM -0400, Theodore Ts'o wrote: > I actually had set up an earlier version of your patch for on Saturday > while I was in Beijing. (Like Linus, I'm attending the LinuxCon China > conference Monday and Tuesday.) I had even created the signed tag, > I've

Re: [PATCH] random: silence compiler warnings and fix race

Hey Ted, On Tue, Jun 20, 2017 at 02:03:44AM -0400, Theodore Ts'o wrote: > I actually had set up an earlier version of your patch for on Saturday > while I was in Beijing. (Like Linus, I'm attending the LinuxCon China > conference Monday and Tuesday.) I had even created the signed tag, > I've

Re: [PATCH] random: silence compiler warnings and fix race

Hello Ted, With rc6 already released and rc7 coming up, I'd really appreciate you stepping in here and either ACKing the above commit, or giving your two cents about it in case I need to roll something different. Thanks, Jason On Thu, Jun 15, 2017 at 12:45 AM, Jason A. Donenfeld <ja...@zx

Re: [PATCH] random: silence compiler warnings and fix race

Hello Ted, With rc6 already released and rc7 coming up, I'd really appreciate you stepping in here and either ACKing the above commit, or giving your two cents about it in case I need to roll something different. Thanks, Jason On Thu, Jun 15, 2017 at 12:45 AM, Jason A. Donenfeld wrote: >

Re: [PATCH] random: silence compiler warnings and fix race

On Mon, Jun 19, 2017 at 9:45 AM, Sebastian Andrzej Siewior wrote: > ehm. You sure? I simply delayed the lock-dropping _after_ the state > variable was been modified. So it was basically what your patch did > except it was unlocked later… Yes, I'm sure. You moved the call

Re: [PATCH] random: silence compiler warnings and fix race

On Mon, Jun 19, 2017 at 9:45 AM, Sebastian Andrzej Siewior wrote: > ehm. You sure? I simply delayed the lock-dropping _after_ the state > variable was been modified. So it was basically what your patch did > except it was unlocked later… Yes, I'm sure. You moved the call to

Re: [kernel-hardening] Re: [PATCH v4 13/13] random: warn when kernel uses unseeded randomness

On Sun, Jun 18, 2017 at 7:55 PM, Stephan Müller wrote: > But you bring up an interesting point: if it is true you say that it is hard > for people to use differnent types of APIs regarding entropy and random > numbers right (which I would concur with), and considering that

Re: [kernel-hardening] Re: [PATCH v4 13/13] random: warn when kernel uses unseeded randomness

On Sun, Jun 18, 2017 at 7:55 PM, Stephan Müller wrote: > But you bring up an interesting point: if it is true you say that it is hard > for people to use differnent types of APIs regarding entropy and random > numbers right (which I would concur with), and considering that you imply that >

Re: [kernel-hardening] Re: [PATCH v4 13/13] random: warn when kernel uses unseeded randomness

On Sun, Jun 18, 2017 at 5:46 PM, Theodore Ts'o wrote: > You are effectively proposing that there ought to be a middle range of > security between prandom_32, get_random_u32/get_random_u64 and > get_random_bytes(). I think that's going to lead to all sorts of > complexity and bugs

Re: [kernel-hardening] Re: [PATCH v4 13/13] random: warn when kernel uses unseeded randomness

On Sun, Jun 18, 2017 at 5:46 PM, Theodore Ts'o wrote: > You are effectively proposing that there ought to be a middle range of > security between prandom_32, get_random_u32/get_random_u64 and > get_random_bytes(). I think that's going to lead to all sorts of > complexity and bugs from people not

Re: [kernel-hardening] Re: [PATCH v4 06/13] iscsi: ensure RNG is seeded before use

Hi Lee, On Fri, Jun 16, 2017 at 11:58 PM, Lee Duncan wrote: > It seems like what you are doing is basically "good", i.e. if there is > not enough random data, don't use it. But what happens in that case? The > authentication fails? How does the user know to wait and try again?

Re: [kernel-hardening] Re: [PATCH v4 06/13] iscsi: ensure RNG is seeded before use

Hi Lee, On Fri, Jun 16, 2017 at 11:58 PM, Lee Duncan wrote: > It seems like what you are doing is basically "good", i.e. if there is > not enough random data, don't use it. But what happens in that case? The > authentication fails? How does the user know to wait and try again? The process just

Re: [PATCH] random: silence compiler warnings and fix race

On Fri, Jun 16, 2017 at 4:35 PM, Sebastian Andrzej Siewior wrote: > I wouldn't just push the lock one up as is but move that write part to > crng_init to remain within the locked section. Like that: We can't quite do that, because invalidate_batched_entropy() needs to be

Re: [PATCH] random: silence compiler warnings and fix race

On Fri, Jun 16, 2017 at 4:35 PM, Sebastian Andrzej Siewior wrote: > I wouldn't just push the lock one up as is but move that write part to > crng_init to remain within the locked section. Like that: We can't quite do that, because invalidate_batched_entropy() needs to be called _before_

Re: [PATCH v5 01/13] random: invalidate batched entropy after crng init

On Fri, Jun 16, 2017 at 10:31 AM, Sebastian Andrzej Siewior wrote: > am talking about. Again: I actually figured that out myself after sending the initial email, so then I wrote a follow-up patch which I attached to this thread. You should have received it. Can you take

Re: [PATCH v5 01/13] random: invalidate batched entropy after crng init

On Fri, Jun 16, 2017 at 10:31 AM, Sebastian Andrzej Siewior wrote: > am talking about. Again: I actually figured that out myself after sending the initial email, so then I wrote a follow-up patch which I attached to this thread. You should have received it. Can you take a look?

[PATCH] random: silence compiler warnings and fix race

be called in opposite order. Moving the call to invalidate_batched_entropy to outside the lock rectifies this issue. Signed-off-by: Jason A. Donenfeld <ja...@zx2c4.com> --- Ted -- the first part of this is the fixup patch we discussed earlier. Then I added on top a fix for a potentially relate

[PATCH] random: silence compiler warnings and fix race

be called in opposite order. Moving the call to invalidate_batched_entropy to outside the lock rectifies this issue. Signed-off-by: Jason A. Donenfeld --- Ted -- the first part of this is the fixup patch we discussed earlier. Then I added on top a fix for a potentially related race. I'm not totally

Re: [PATCH v5 01/13] random: invalidate batched entropy after crng init

There's a potential race that I fixed in my v5 of that patch set, but Ted only took v4, and for whatever reason has been to busy to submit the additional patch I already posted showing the diff between v4 Hopefully he actually gets around to it and sends this for the next rc. Here it is:

Re: [PATCH v5 01/13] random: invalidate batched entropy after crng init

There's a potential race that I fixed in my v5 of that patch set, but Ted only took v4, and for whatever reason has been to busy to submit the additional patch I already posted showing the diff between v4 Hopefully he actually gets around to it and sends this for the next rc. Here it is:

Re: [PATCH 6/6] mac80211/wpa: use constant time memory comparison for MACs

On Tue, Jun 13, 2017 at 10:20 AM, Johannes Berg wrote: > I'm not really sure that this is actually true, since you don't get > much feedback on your frame that's dropped, especially if you're > attacking from remote. Basically, I don't see how you can observe the >

Re: [PATCH 6/6] mac80211/wpa: use constant time memory comparison for MACs

On Tue, Jun 13, 2017 at 10:20 AM, Johannes Berg wrote: > I'm not really sure that this is actually true, since you don't get > much feedback on your frame that's dropped, especially if you're > attacking from remote. Basically, I don't see how you can observe the > timing of this operation?

Re: [GIT PULL] random bug fixes for 4.12

Since it looks like Linus already pulled, here's the diff-commit I made from before, that you can submit on top: https://lkml.org/lkml/2017/6/8/408 It should row "Cc: sta...@vger.kernel.org" if it's not going to be rebased into the existing commit there.

Re: [GIT PULL] random bug fixes for 4.12

Since it looks like Linus already pulled, here's the diff-commit I made from before, that you can submit on top: https://lkml.org/lkml/2017/6/8/408 It should row "Cc: sta...@vger.kernel.org" if it's not going to be rebased into the existing commit there.

Re: [GIT PULL] random bug fixes for 4.12

Hi Ted, Did you forget this discussion [1][2][3], where we talked about how you accidentally pulled v4 instead of v5, and would replace that v4 patch [4] with the v5 one [5]? Jason [1] https://lkml.org/lkml/2017/6/8/1046 [2] https://lkml.org/lkml/2017/6/8/1173 [3]

Re: [GIT PULL] random bug fixes for 4.12

Hi Ted, Did you forget this discussion [1][2][3], where we talked about how you accidentally pulled v4 instead of v5, and would replace that v4 patch [4] with the v5 one [5]? Jason [1] https://lkml.org/lkml/2017/6/8/1046 [2] https://lkml.org/lkml/2017/6/8/1173 [3]

Re: [PATCH 0/6] Constant Time Memory Comparisons Are Important

Hi Stephan, On Sun, Jun 11, 2017 at 11:06 PM, Stephan Müller wrote: > Are you planning to send an update to your patch set? If yes, there is another > one which should be converted too: crypto/rsa-pkcs1pad.c. I just sent an update to this thread patching that, per your

Re: [PATCH 0/6] Constant Time Memory Comparisons Are Important

Hi Stephan, On Sun, Jun 11, 2017 at 11:06 PM, Stephan Müller wrote: > Are you planning to send an update to your patch set? If yes, there is another > one which should be converted too: crypto/rsa-pkcs1pad.c. I just sent an update to this thread patching that, per your suggestion. Since these

[PATCH] rsa-pkcs1pad: use constant time memory comparison for MACs

Otherwise, we enable all sorts of forgeries via timing attack. Signed-off-by: Jason A. Donenfeld <ja...@zx2c4.com> Suggested-by: Stephan Müller <smuel...@chronox.de> Cc: sta...@vger.kernel.org Cc: Herbert Xu <herb...@gondor.apana.org.au> Cc: linux-cry...@vger.kernel.org --- cry

[PATCH] rsa-pkcs1pad: use constant time memory comparison for MACs

Otherwise, we enable all sorts of forgeries via timing attack. Signed-off-by: Jason A. Donenfeld Suggested-by: Stephan Müller Cc: sta...@vger.kernel.org Cc: Herbert Xu Cc: linux-cry...@vger.kernel.org --- crypto/rsa-pkcs1pad.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git

Re: [PATCH 3/6] ccree: use constant time memory comparison for macs and tags

Hey Gilad, That's fine. As I mentioned, I really have no clue what this code's trying to do. If this is just part of some test that doesn't deal with actual messages that could be forged, then of course there's nothing that needs to be done and this can be NAKd. Jason

Re: [PATCH 3/6] ccree: use constant time memory comparison for macs and tags

Hey Gilad, That's fine. As I mentioned, I really have no clue what this code's trying to do. If this is just part of some test that doesn't deal with actual messages that could be forged, then of course there's nothing that needs to be done and this can be NAKd. Jason

[PATCH 0/6] Constant Time Memory Comparisons Are Important

cleaning this stuff up. The following 6 locations were found with some simple regex greps, but I'm sure more lurk below the surface. If you maintain some code or know somebody who maintains some code that deals with MACs, tell them to double check which comparison function they're using. Jason

[PATCH 0/6] Constant Time Memory Comparisons Are Important

cleaning this stuff up. The following 6 locations were found with some simple regex greps, but I'm sure more lurk below the surface. If you maintain some code or know somebody who maintains some code that deals with MACs, tell them to double check which comparison function they're using. Jason

[PATCH 2/6] net/ipv6: use constant time memory comparison for mac

Otherwise, we enable a MAC forgery via timing attack. Signed-off-by: Jason A. Donenfeld <ja...@zx2c4.com> Cc: "David S. Miller" <da...@davemloft.net> Cc: net...@vger.kernel.org Cc: sta...@vger.kernel.org --- net/ipv6/seg6_hmac.c | 3 ++- 1 file changed, 2 insertions(+), 1 d

[PATCH 2/6] net/ipv6: use constant time memory comparison for mac

Otherwise, we enable a MAC forgery via timing attack. Signed-off-by: Jason A. Donenfeld Cc: "David S. Miller" Cc: net...@vger.kernel.org Cc: sta...@vger.kernel.org --- net/ipv6/seg6_hmac.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/net/ipv6/seg6_hmac.c

[PATCH 1/6] sunrpc: use constant time memory comparison for mac

Otherwise, we enable a MAC forgery via timing attack. Signed-off-by: Jason A. Donenfeld <ja...@zx2c4.com> Cc: "J. Bruce Fields" <bfie...@fieldses.org> Cc: Jeff Layton <jlay...@poochiereds.net> Cc: Trond Myklebust <trond.mykleb...@primarydata.com> Cc: Anna Schuma

[PATCH 5/6] bluetooth/smp: use constant time memory comparison for secret values

This file is filled with complex cryptography. Thus, the comparisons of MACs and secret keys and curve points and so forth should not add timing attacks, which could either result in a direct forgery, or, given the complexity, some other type of attack. Signed-off-by: Jason A. Donenfeld <

[PATCH 1/6] sunrpc: use constant time memory comparison for mac

Otherwise, we enable a MAC forgery via timing attack. Signed-off-by: Jason A. Donenfeld Cc: "J. Bruce Fields" Cc: Jeff Layton Cc: Trond Myklebust Cc: Anna Schumaker Cc: linux-...@vger.kernel.org Cc: sta...@vger.kernel.org --- net/sunrpc/auth_gss/gss_krb5_crypto.c | 3 ++- 1 file

[PATCH 5/6] bluetooth/smp: use constant time memory comparison for secret values

This file is filled with complex cryptography. Thus, the comparisons of MACs and secret keys and curve points and so forth should not add timing attacks, which could either result in a direct forgery, or, given the complexity, some other type of attack. Signed-off-by: Jason A. Donenfeld Cc

[PATCH 6/6] mac80211/wpa: use constant time memory comparison for MACs

Otherwise, we enable all sorts of forgeries via timing attack. Signed-off-by: Jason A. Donenfeld <ja...@zx2c4.com> Cc: Johannes Berg <johan...@sipsolutions.net> Cc: linux-wirel...@vger.kernel.org Cc: sta...@vger.kernel.org --- net/mac80211/wpa.c | 9 + 1 file changed, 5 inse

[PATCH 6/6] mac80211/wpa: use constant time memory comparison for MACs

Otherwise, we enable all sorts of forgeries via timing attack. Signed-off-by: Jason A. Donenfeld Cc: Johannes Berg Cc: linux-wirel...@vger.kernel.org Cc: sta...@vger.kernel.org --- net/mac80211/wpa.c | 9 + 1 file changed, 5 insertions(+), 4 deletions(-) diff --git a/net/mac80211

[PATCH 4/6] security/keys: use constant time memory comparison for macs

Otherwise, we enable a MAC forgery via timing attack. Signed-off-by: Jason A. Donenfeld <ja...@zx2c4.com> Cc: David Safford <saff...@us.ibm.com> Cc: Mimi Zohar <zo...@linux.vnet.ibm.com> Cc: David Howells <dhowe...@redhat.com> Cc: keyri...@vger.kernel.org Cc: sta...@vger.

[PATCH 4/6] security/keys: use constant time memory comparison for macs

Otherwise, we enable a MAC forgery via timing attack. Signed-off-by: Jason A. Donenfeld Cc: David Safford Cc: Mimi Zohar Cc: David Howells Cc: keyri...@vger.kernel.org Cc: sta...@vger.kernel.org --- security/keys/trusted.c | 7 --- 1 file changed, 4 insertions(+), 3 deletions(-) diff

[PATCH 3/6] ccree: use constant time memory comparison for macs and tags

Otherwise, we enable several different forgeries via timing attack. While the C inside this file is nearly incomprehensible, I did notice a high volume of "FIPS" and "NIST", which makes this kind of bug slightly more embarrassing. Signed-off-by: Jason A. Donenfeld <ja...@z

[PATCH 3/6] ccree: use constant time memory comparison for macs and tags

Otherwise, we enable several different forgeries via timing attack. While the C inside this file is nearly incomprehensible, I did notice a high volume of "FIPS" and "NIST", which makes this kind of bug slightly more embarrassing. Signed-off-by: Jason A. Donenfeld Cc: Gilad

Re: [PATCH cleanups/resubmit 0/4] Cleanups & Resubmissions for Random-dev

Hi Ted, One other question -- you plan on pushing this to Linus for 4.12, correct? Thanks, Jason

Re: [PATCH cleanups/resubmit 0/4] Cleanups & Resubmissions for Random-dev

Hi Ted, One other question -- you plan on pushing this to Linus for 4.12, correct? Thanks, Jason

[PATCH] bluetooth: ensure RNG is properly seeded before powerup

the potential error code back through the failure setter, like the rest of the function does. Signed-off-by: Jason A. Donenfeld <ja...@zx2c4.com> Cc: Marcel Holtmann <mar...@holtmann.org> Cc: Gustavo Padovan <gust...@padovan.org> Cc: Johan Hedberg <johan.hedb...@gmail.com> --- Ted

[PATCH] bluetooth: ensure RNG is properly seeded before powerup

the potential error code back through the failure setter, like the rest of the function does. Signed-off-by: Jason A. Donenfeld Cc: Marcel Holtmann Cc: Gustavo Padovan Cc: Johan Hedberg --- Ted -- this would be instead of my other bluetooth patch. I think my other one might be a bit more robust

[PATCH] random: default the warning to be on

platforms, this commit turns it on everywhere. It's fairly non-invasive now, and it will help us get some visibility into the issue that we otherwise wouldn't have. Signed-off-by: Jason A. Donenfeld <ja...@zx2c4.com> --- lib/Kconfig.debug | 1 - 1 file changed, 1 deletion(-) diff --git a/lib/Kco

[PATCH] random: default the warning to be on

platforms, this commit turns it on everywhere. It's fairly non-invasive now, and it will help us get some visibility into the issue that we otherwise wouldn't have. Signed-off-by: Jason A. Donenfeld --- lib/Kconfig.debug | 1 - 1 file changed, 1 deletion(-) diff --git a/lib/Kconfig.debug b/lib/Kco

Re: [PATCH cleanups/resubmit 0/4] Cleanups & Resubmissions for Random-dev

Hey Ted, On Thu, Jun 8, 2017 at 11:58 PM, Theodore Ts'o wrote: >> random: squelch sh compiler warning and ensure safe optimization >> >> This was the biggie -- I had incorporated this fix into v5, but you picked >> up v4, so this commit is an additional one to bring your tree up

Re: [PATCH cleanups/resubmit 0/4] Cleanups & Resubmissions for Random-dev

Hey Ted, On Thu, Jun 8, 2017 at 11:58 PM, Theodore Ts'o wrote: >> random: squelch sh compiler warning and ensure safe optimization >> >> This was the biggie -- I had incorporated this fix into v5, but you picked >> up v4, so this commit is an additional one to bring your tree up to date, >>

Re: [PATCH v4 12/13] bluetooth/smp: ensure RNG is properly seeded before ECDH use

On Thu, Jun 8, 2017 at 7:05 PM, Marcel Holtmann wrote: > on a powered down controller, you can not do any crypto. SMP is only during a > connection and the RPAs are only generated when needed. So yes, doing this > once in hci_power_on is plenty. However we might want to

Re: [PATCH v4 12/13] bluetooth/smp: ensure RNG is properly seeded before ECDH use

On Thu, Jun 8, 2017 at 7:05 PM, Marcel Holtmann wrote: > on a powered down controller, you can not do any crypto. SMP is only during a > connection and the RPAs are only generated when needed. So yes, doing this > once in hci_power_on is plenty. However we might want to limit this to LE >

[PATCH cleanups/resubmit 3/4] bluetooth/smp: ensure RNG is properly seeded before ECDH use

the RNG initialization has been interrupted, rather than later, so we call wait_for_random_bytes() at the top, so that later on the call to get_random_bytes() is acceptable. Signed-off-by: Jason A. Donenfeld <ja...@zx2c4.com> Cc: Marcel Holtmann <mar...@holtmann.org> Cc: Gustavo P

[PATCH cleanups/resubmit 3/4] bluetooth/smp: ensure RNG is properly seeded before ECDH use

the RNG initialization has been interrupted, rather than later, so we call wait_for_random_bytes() at the top, so that later on the call to get_random_bytes() is acceptable. Signed-off-by: Jason A. Donenfeld Cc: Marcel Holtmann Cc: Gustavo Padovan Cc: Johan Hedberg --- This is the same as v4

[PATCH cleanups/resubmit 4/4] crypto/rng: ensure that the RNG is ready before using

Signed-off-by: Jason A. Donenfeld <ja...@zx2c4.com> --- This is the same as v4/v5. crypto/rng.c | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/crypto/rng.c b/crypto/rng.c index f46dac5288b9..e042437e64b4 100644 --- a/crypto/rng.c +++ b/crypto/rng.c @@ -48,12 +

[PATCH cleanups/resubmit 4/4] crypto/rng: ensure that the RNG is ready before using

Otherwise, we might be seeding the RNG using bad randomness, which is dangerous. The one use of this function from within the kernel -- not from userspace -- is being removed (keys/big_key), so that call site isn't relevant in assessing this. Cc: Herbert Xu Signed-off-by: Jason A. Donenfeld

[PATCH cleanups/resubmit 2/4] random: squelch sh compiler warning and ensure safe optimization

and v5. Signed-off-by: Jason A. Donenfeld <ja...@zx2c4.com> --- drivers/char/random.c | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/char/random.c b/drivers/char/random.c index 3bdeef13afda..cef9358ecf20 100644 --- a/drivers/char/random.c +++ b/driver

[PATCH cleanups/resubmit 1/4] security/keys: ensure RNG is seeded before use

a blocking function in key serial allocation, because this will block booting in some configurations, so here we use the more appropriate get_random_u32, which will use RDRAND if available. Signed-off-by: Jason A. Donenfeld <ja...@zx2c4.com> Cc: David Howells <dhowe...@redhat.com> Cc: Mi

[PATCH cleanups/resubmit 0/4] Cleanups & Resubmissions for Random-dev

Hi Ted, I'm not super sure what your workflow is like, but yesterday you picked up my v4 instead of my v5, and as you applied the wrong commits, I sent you several emails notifying you, along with quick fixes to various issues, which you also did not see. I assume you have complicated email

[PATCH cleanups/resubmit 2/4] random: squelch sh compiler warning and ensure safe optimization

and v5. Signed-off-by: Jason A. Donenfeld --- drivers/char/random.c | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/char/random.c b/drivers/char/random.c index 3bdeef13afda..cef9358ecf20 100644 --- a/drivers/char/random.c +++ b/drivers/char/random.c @@ -2066,8

[PATCH cleanups/resubmit 1/4] security/keys: ensure RNG is seeded before use

a blocking function in key serial allocation, because this will block booting in some configurations, so here we use the more appropriate get_random_u32, which will use RDRAND if available. Signed-off-by: Jason A. Donenfeld Cc: David Howells Cc: Mimi Zohar Cc: David Safford --- security/keys

[PATCH cleanups/resubmit 0/4] Cleanups & Resubmissions for Random-dev

Hi Ted, I'm not super sure what your workflow is like, but yesterday you picked up my v4 instead of my v5, and as you applied the wrong commits, I sent you several emails notifying you, along with quick fixes to various issues, which you also did not see. I assume you have complicated email

Re: [kernel-hardening] Re: [PATCH v4 06/13] iscsi: ensure RNG is seeded before use

t's safe to simply wait until we have enough randomness to carry out the authentication correctly. While we're at it, we clean up a small memleak during an error condition. Signed-off-by: Jason A. Donenfeld <ja...@zx2c4.com> Cc: "Nicholas A. Bellinger" <n...@linux-iscsi.org

Re: [kernel-hardening] Re: [PATCH v4 06/13] iscsi: ensure RNG is seeded before use

on about how to kick off some kind of automated > test suite ala xfstests for file systems. Only very basic testing from my end. I'm thus adding the iSCSI list to see if they'll have a look (patch reattached). Jason From 1adecf785526a2a96104767807140b9e1a9e2a27 Mon Sep 17 00:00:00 2001 From: &quo

<    1   2   3   4   5   6   7   8   9   10   >