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

Hi Ted, >> This protocol uses lots of complex cryptography that relies on securely >> generated random numbers. Thus, it's important that the RNG is actually >> seeded before use. Fortuantely, it appears we're always operating in >> process context (there are many GFP_KERNEL allocations and other

Re: [kernel-hardening] Re: [PATCH v3 04/13] crypto/rng: ensure that the RNG is ready before using

On Wed, 2017-06-07 at 18:26 +0100, Mark Rutland wrote: > On Wed, Jun 07, 2017 at 01:00:25PM -0400, Daniel Micay wrote: > > > On the better bootloaders, an initramfs segment can be loaded > > > independently (and you can have as many as required), which makes > > > an > > > early_initramfs a more

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

On Tue, Jun 06, 2017 at 07:48:03PM +0200, Jason A. Donenfeld wrote: > This protocol uses lots of complex cryptography that relies on securely > generated random numbers. Thus, it's important that the RNG is actually > seeded before use. Fortuantely, it appears we're always operating in > process

Re: [PATCH v4 11/13] net/route: use get_random_int for random counter

On Tue, Jun 06, 2017 at 07:48:02PM +0200, Jason A. Donenfeld wrote: > Using get_random_int here is faster, more fitting of the use case, and > just as cryptographically secure. It also has the benefit of providing > better randomness at early boot, which is when many of these structures > are

Re: [PATCH v4 10/13] net/neighbor: use get_random_u32 for 32-bit hash random

On Tue, Jun 06, 2017 at 07:48:01PM +0200, Jason A. Donenfeld wrote: > Using get_random_u32 here is faster, more fitting of the use case, and > just as cryptographically secure. It also has the benefit of providing > better randomness at early boot, which is when many of these structures > are

Re: [PATCH v4 09/13] rhashtable: use get_random_u32 for hash_rnd

On Tue, Jun 06, 2017 at 07:48:00PM +0200, Jason A. Donenfeld wrote: > This is much faster and just as secure. It also has the added benefit of > probably returning better randomness at early-boot on systems with > architectural RNGs. > > Signed-off-by: Jason A. Donenfeld > Cc:

Re: [kernel-hardening] [PATCH v4 07/13] ceph: ensure RNG is seeded before using

On Tue, Jun 06, 2017 at 07:47:58PM +0200, Jason A. Donenfeld wrote: > Ceph uses the RNG for various nonce generations, and it shouldn't accept > using bad randomness. So, we wait for the RNG to be properly seeded. We > do this by calling wait_for_random_bytes() in a function that is > certainly

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

On Tue, Jun 06, 2017 at 07:47:57PM +0200, Jason A. Donenfeld wrote: > It's not safe to use weak random data here, especially for the challenge > response randomness. Since we're always in process context, it's safe to > simply wait until we have enough randomness to carry out the > authentication

[PATCH v2 3/6] ima: Log the same audit cause whenever a file has no signature

If the file doesn't have an xattr, ima_appraise_measurement sets cause to "missing-hash" while if there's an xattr but it's a digest instead of a signature it sets cause to "IMA-signature-required". Fix it by setting cause to "IMA-signature-required" in both cases. Signed-off-by: Thiago Jung

[PATCH v2 4/6] integrity: Introduce struct evm_hmac_xattr

Even though struct evm_ima_xattr_data includes a fixed-size array to hold a SHA1 digest, most of the code ignores the array and uses the struct to mean "type indicator followed by data of unspecified size" and tracks the real size of what the struct represents in a separate length variable. The

[PATCH v2 6/6] ima: Support module-style appended signatures for appraisal

This patch introduces the modsig keyword to the IMA policy syntax to specify that a given hook should expect the file to have the IMA signature appended to it. Here is how it can be used in a rule: appraise func=KEXEC_KERNEL_CHECK appraise_type=modsig|imasig With this rule, IMA will accept

[PATCH v2 5/6] MODSIGN: Export module signature definitions.

IMA will use the module_signature format for append signatures, so export the relevant definitions and factor out the code which verifies that the appended signature trailer is valid. Also, add function verify_pkcs7_message_signature which takes a struct pkcs7_message for verification isntead of

[PATCH v2 2/6] ima: Simplify policy_func_show.

If the func_tokens array uses the same indices as enum ima_hooks, policy_func_show can be a lot simpler, and the func_* enum becomes unnecessary. Also, if we use the same macro trick used by kernel_read_file_id_str we can use one hooks list for both the enum and the string array, making sure they

[PATCH v2 0/6] Appended signatures support for IMA appraisal

On the OpenPOWER platform, secure boot and trusted boot are being implemented using IMA for taking measurements and verifying signatures. Since the kernel image on Power servers is an ELF binary, kernels are signed using the scripts/sign-file tool and thus use the same signature format as signed

[PATCH v2 1/6] integrity: Small code improvements

These changes are too small to warrant their own patches: The keyid and sig_size members of struct signature_v2_hdr are in BE format, so use a type that makes this assumption explicit. Also, use beXX_to_cpu instead of __beXX_to_cpu to read them. Change integrity_kernel_read to take a void *

Re: [PATCH v4 04/13] security/keys: ensure RNG is seeded before use

On Thu, Jun 8, 2017 at 2:50 AM, Jason A. Donenfeld wrote: > On Thu, Jun 8, 2017 at 2:31 AM, Theodore Ts'o wrote: >> I'm guessing you changed key_alloc_serial() to return an int back when >> you were thinking that you might use get_random_bytes_wait(), which >>

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

On Thu, Jun 8, 2017 at 1:58 AM, Theodore Ts'o wrote: > Thanks, applied. This will be on the for_stable that I will be > sending to Linus sometime during 4.12-rcX. I think you might have just missed the kbuild test robot complaining about an incorrect compiler warning, when using

Re: [PATCH v4 04/13] security/keys: ensure RNG is seeded before use

On Thu, Jun 8, 2017 at 2:31 AM, Theodore Ts'o wrote: > I'm guessing you changed key_alloc_serial() to return an int back when > you were thinking that you might use get_random_bytes_wait(), which > could return -ERESTARTSYS. > > Now that you're not doing this, but using

Re: [kernel-hardening] [PATCH v4 05/13] crypto/rng: ensure that the RNG is ready before using

On Thu, Jun 8, 2017 at 2:41 AM, Theodore Ts'o wrote: > The use in keys/big_key is _being_ removed, so this commit is > dependent on that commit landing, correct? (Order matters, because > otherwise we don't want to potentially screw up doing a kernel bisect > and causing their

Re: [kernel-hardening] [PATCH v4 05/13] crypto/rng: ensure that the RNG is ready before using

On Tue, Jun 06, 2017 at 07:47:56PM +0200, Jason A. Donenfeld wrote: > 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

Re: [kernel-hardening] [PATCH v4 08/13] cifs: use get_random_u32 for 32-bit lock random

On Thu, Jun 8, 2017 at 2:25 AM, Theodore Ts'o wrote: > There's a bigger problem here, which is that cifs_lock_secret is a > 32-bit value which is being used to obscure flock->fl_owner before it > is sent across the wire. But flock->fl_owner is a pointer to the > struct file *, so

Re: [kernel-hardening] [PATCH v4 08/13] cifs: use get_random_u32 for 32-bit lock random

On Thu, Jun 8, 2017 at 2:25 AM, Theodore Ts'o wrote: > There's a bigger problem here, which is that cifs_lock_secret is a > 32-bit value which is being used to obscure flock->fl_owner before it > is sent across the wire. But flock->fl_owner is a pointer to the > struct file *, so

Re: [PATCH v4 04/13] security/keys: ensure RNG is seeded before use

On Tue, Jun 06, 2017 at 07:47:55PM +0200, Jason A. Donenfeld wrote: > -static inline void key_alloc_serial(struct key *key) > +static inline int key_alloc_serial(struct key *key) > @@ -170,7 +168,7 @@ static inline void key_alloc_serial(struct key *key) > rb_insert_color(>serial_node,

Re: [kernel-hardening] [PATCH v4 08/13] cifs: use get_random_u32 for 32-bit lock random

On Tue, Jun 06, 2017 at 07:47:59PM +0200, Jason A. Donenfeld wrote: > Using get_random_u32 here is faster, more fitting of the use case, and > just as cryptographically secure. It also has the benefit of providing > better randomness at early boot, which is sometimes when this is used. > >

Re: [kernel-hardening] [PATCH v4 03/13] random: add get_random_{bytes,u32,u64,int,long,once}_wait family

On Tue, Jun 06, 2017 at 07:47:54PM +0200, Jason A. Donenfeld wrote: > These functions are simple convenience wrappers that call > wait_for_random_bytes before calling the respective get_random_* > function. > > Signed-off-by: Jason A. Donenfeld Thanks, applied to the dev

Re: [PATCH v4 02/13] random: add synchronous API for the urandom pool

On Tue, Jun 06, 2017 at 07:47:53PM +0200, Jason A. Donenfeld wrote: > This enables users of get_random_{bytes,u32,u64,int,long} to wait until > the pool is ready before using this function, in case they actually want > to have reliable randomness. > > Signed-off-by: Jason A. Donenfeld

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

On Tue, Jun 06, 2017 at 07:47:52PM +0200, Jason A. Donenfeld wrote: > It's possible that get_random_{u32,u64} is used before the crng has > initialized, in which case, its output might not be cryptographically > secure. For this problem, directly, this patch set is introducing the > *_wait variety

[PATCH v5 02/13] random: add synchronous API for the urandom pool

This enables users of get_random_{bytes,u32,u64,int,long} to wait until the pool is ready before using this function, in case they actually want to have reliable randomness. Signed-off-by: Jason A. Donenfeld --- drivers/char/random.c | 41

[PATCH v5 04/13] security/keys: ensure RNG is seeded before use

Otherwise, we might use bad random numbers which, particularly in the case of IV generation, could be quite bad. It makes sense to use the synchronous API here, because we're always in process context (as the code is littered with GFP_KERNEL and the like). However, we can't change to using a

[PATCH v5 00/13] Unseeded In-Kernel Randomness Fixes

It looks like critique of this has come to an end. Could somebody take this into their tree for 4.12? As discussed in [1], there is a problem with get_random_bytes being used before the RNG has actually been seeded. The solution for fixing this appears to be multi-pronged. One of those prongs

[PATCH v5 07/13] ceph: ensure RNG is seeded before using

Ceph uses the RNG for various nonce generations, and it shouldn't accept using bad randomness. So, we wait for the RNG to be properly seeded. We do this by calling wait_for_random_bytes() in a function that is certainly called in process context, early on, so that all subsequent calls to

[PATCH v5 05/13] 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

[PATCH v5 08/13] cifs: use get_random_u32 for 32-bit lock random

Using get_random_u32 here is faster, more fitting of the use case, and just as cryptographically secure. It also has the benefit of providing better randomness at early boot, which is sometimes when this is used. Signed-off-by: Jason A. Donenfeld Cc: Steve French

[PATCH v5 06/13] iscsi: ensure RNG is seeded before use

It's not safe to use weak random data here, especially for the challenge response randomness. Since we're always in process context, it'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

[PATCH v5 11/13] net/route: use get_random_int for random counter

Using get_random_int here is faster, more fitting of the use case, and just as cryptographically secure. It also has the benefit of providing better randomness at early boot, which is when many of these structures are assigned. Also, semantically, it's not really proper to have been assigning an

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

This protocol uses lots of complex cryptography that relies on securely generated random numbers. Thus, it's important that the RNG is actually seeded before use. Fortuantely, it appears we're always operating in process context (there are many GFP_KERNEL allocations and other sleeping

[PATCH v5 13/13] random: warn when kernel uses unseeded randomness

This enables an important dmesg notification about when drivers have used the crng without it being seeded first. Prior, these errors would occur silently, and so there hasn't been a great way of diagnosing these types of bugs for obscure setups. By adding this as a config option, we can leave it

[PATCH v5 09/13] rhashtable: use get_random_u32 for hash_rnd

This is much faster and just as secure. It also has the added benefit of probably returning better randomness at early-boot on systems with architectural RNGs. Signed-off-by: Jason A. Donenfeld Cc: Thomas Graf Cc: Herbert Xu ---

[PATCH v5 10/13] net/neighbor: use get_random_u32 for 32-bit hash random

Using get_random_u32 here is faster, more fitting of the use case, and just as cryptographically secure. It also has the benefit of providing better randomness at early boot, which is when many of these structures are assigned. Signed-off-by: Jason A. Donenfeld Cc: David Miller

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

It's possible that get_random_{u32,u64} is used before the crng has initialized, in which case, its output might not be cryptographically secure. For this problem, directly, this patch set is introducing the *_wait variety of functions, but even with that, there's a subtle issue: what happens to

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

It's possible that get_random_{u32,u64} is used before the crng has initialized, in which case, its output might not be cryptographically secure. For this problem, directly, this patch set is introducing the *_wait variety of functions, but even with that, there's a subtle issue: what happens to

[PATCH v5 00/13] Unseeded In-Kernel Randomness Fixes

It looks like critique of this has come to an end. Could somebody take this into their tree for 4.12? As discussed in [1], there is a problem with get_random_bytes being used before the RNG has actually been seeded. The solution for fixing this appears to be multi-pronged. One of those prongs

Re: [PATCH v1 2/2] dt-bindings: crypto: remove mediatek ethif clock

On Thu, Jun 01, 2017 at 10:30:22AM +0800, Ryder Lee wrote: > This patch removes the parent clock 'ethif' in bindings, since we don't > need to control the parent of a clock in current clock framework. > > Moreover, the clocks are get by name in the driver, thus this change > does not break

Re: [kernel-hardening] Re: [PATCH v3 04/13] crypto/rng: ensure that the RNG is ready before using

On Wed, Jun 07, 2017 at 07:00:17AM +0200, Stephan Müller wrote: > > On that same idea, one could add an early_initramfs handler for entropy > > data. > > Any data that comes from outside during the boot process, be it some NVRAM > location, the /var/lib...seed file for /dev/random or other

Re: [PATCH v2 net-next 1/4] tcp: ULP infrastructure

From: Dave Watson Date: Tue, 6 Jun 2017 10:00:20 -0700 > +EXPORT_SYMBOL(tcp_register_ulp); EXPORT_SYMBOL_GPL() please. > +EXPORT_SYMBOL(tcp_unregister_ulp); Likewise.

Re: [PATCH v3 03/13] random: invalidate batched entropy after crng init

Strange, not all compilers do this warning. Fixing with: diff --git a/drivers/char/random.c b/drivers/char/random.c index 12758db..5252690 100644 --- a/drivers/char/random.c +++ b/drivers/char/random.c @@ -2061,8 +2061,8 @@ static DEFINE_PER_CPU(struct batched_entropy, batched_entropy_u64); u64

Re: [PATCH v3 03/13] random: invalidate batched entropy after crng init

Hi Jason, [auto build test WARNING on linus/master] [also build test WARNING on v4.12-rc4] [cannot apply to next-20170607] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Jason-A-Donenfeld

Re: [kernel-hardening] Re: [PATCH v3 04/13] crypto/rng: ensure that the RNG is ready before using

On Tue, Jun 06, 2017 at 01:03:19PM -0400, Theodore Ts'o wrote: > The other approach is to find a way to have initialized "seed" entropy > which we can count on at every boot. The problem is that this is very > much dependent on how the bootloader works. It's easy to say "store > it in the

Re: [kernel-hardening] Re: [PATCH v3 04/13] crypto/rng: ensure that the RNG is ready before using

On Wed, Jun 07, 2017 at 01:00:25PM -0400, Daniel Micay wrote: > > On the better bootloaders, an initramfs segment can be loaded > > independently (and you can have as many as required), which makes an > > early_initramfs a more palatable vector to inject large amounts of > > entropy into the next

Re: [kernel-hardening] Re: [PATCH v3 04/13] crypto/rng: ensure that the RNG is ready before using

> On the better bootloaders, an initramfs segment can be loaded > independently (and you can have as many as required), which makes an > early_initramfs a more palatable vector to inject large amounts of > entropy into the next boot than, say, modifying the kernel image > directly at every

Re: [PATCH 1/4] dt-bindings: rng: add generic bindings for MediaTek SoCs

On Wed, 2017-06-07 at 15:25 +0200, Matthias Brugger wrote: > > On 07/06/17 15:20, Sean Wang wrote: > > On Tue, 2017-06-06 at 13:07 +0200, Matthias Brugger wrote: > >> > >> On 31/05/17 20:44, sean.w...@mediatek.com wrote: > >>> From: Sean Wang > >>> > >>> Add the generic

Re: [kernel-hardening] Re: [PATCH v3 04/13] crypto/rng: ensure that the RNG is ready before using

On Wed, 07 Jun 2017, Stephan Müller wrote: > Am Mittwoch, 7. Juni 2017, 00:19:10 CEST schrieb Henrique de Moraes Holschuh: > > On that same idea, one could add an early_initramfs handler for entropy > > data. > > Any data that comes from outside during the boot process, be it some NVRAM >

Re: Can someone check linux kernel 4.4, and 4.9 rfc4309 test vectors?

Am Mittwoch, 7. Juni 2017, 15:57:31 CEST schrieb Che-Min Hsieh: Hi Che, > Rfc4309 test vectors in testmgr.h have gone through major changes from > linux3 to linux4. In linux 4.4, linux4.9, there are vectors as such I think you and the kernel implement crypto properly. It is just the

Can someone check linux kernel 4.4, and 4.9 rfc4309 test vectors?

Rfc4309 test vectors in testmgr.h have gone through major changes from linux3 to linux4. In linux 4.4, linux4.9, there are vectors as such 23194 static struct aead_testvec aes_ccm_rfc4309_enc_tv_template[] = { 23195{ /* Generated using Crypto++ */ 23196.key =

Re: [PATCH 1/4] dt-bindings: rng: add generic bindings for MediaTek SoCs

On 07/06/17 15:20, Sean Wang wrote: On Tue, 2017-06-06 at 13:07 +0200, Matthias Brugger wrote: On 31/05/17 20:44, sean.w...@mediatek.com wrote: From: Sean Wang Add the generic binding for allowing the support of RNG on MediaTek SoCs such as MT7622. Signed-off-by:

Re: [PATCH 1/4] dt-bindings: rng: add generic bindings for MediaTek SoCs

On Tue, 2017-06-06 at 13:07 +0200, Matthias Brugger wrote: > > On 31/05/17 20:44, sean.w...@mediatek.com wrote: > > From: Sean Wang > > > > Add the generic binding for allowing the support of RNG on MediaTek SoCs > > such as MT7622. > > > > Signed-off-by: Sean Wang

Re: [PATCH v4 00/13] Unseeded In-Kernel Randomness Fixes

Hi Ted, Could I get your Signed-off-by on this patchset, so that somebody can add it to their tree? Thanks, Jason