Am Mittwoch, 7. Juni 2017, 00:19:10 CEST schrieb Henrique de Moraes Holschuh:
Hi Henrique,
> 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/ran
On Tue, Jun 06, 2017 at 03:04:08PM -0400, David Miller wrote:
> From: David Miller
> Date: Fri, 02 Jun 2017 11:28:54 -0400 (EDT)
>
> >
> > On sparc, if we have an alloca() like situation, as is the case with
> > SHASH_DESC_ON_STACK(), we can end up referencing deallocated stack
> > memory. The
On Tue, Jun 06, 2017 at 07:19:10PM -0300, Henrique de Moraes Holschuh wrote:
> On that same idea, one could add an early_initramfs handler for entropy
> data.
>
> One could also ensure the kernel command line is used to feed some
> entropy for the CRNG init (for all I know, this is already being d
On Tue, 06 Jun 2017, Theodore Ts'o wrote:
> It might be possible, for example, to store a cryptographic key in a
> UEFI boot-services variable, where the key becomes inaccessible after
> the boot-time services terminate. But you also need either a reliable
> time-of-day clock, or a reliable counte
From: David Miller
Date: Fri, 02 Jun 2017 11:28:54 -0400 (EDT)
>
> On sparc, if we have an alloca() like situation, as is the case with
> SHASH_DESC_ON_STACK(), we can end up referencing deallocated stack
> memory. The result can be that the value is clobbered if a trap
> or interrupt arrives a
On Tue, Jun 6, 2017 at 7:57 PM, Stephan Müller wrote:
> Finally, I am very surprised that I get hardly any answers on patches to
> random.c let alone that any changes to random.c will be applied at all.
FWIW, this is my biggest concern too. You seem willing to work on this
difficult problem. I'm
Am Dienstag, 6. Juni 2017, 19:03:19 CEST schrieb Theodore Ts'o:
Hi Theodore,
> On Tue, Jun 06, 2017 at 02:34:43PM +0200, Jason A. Donenfeld wrote:
> > Yes, I agree whole-heartedly. A lot of people have proposals for
> > fixing the direct idea of entropy gathering, but for whatever reason,
> > Te
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
---
include/linux/net.h| 2 ++
include/linux/once.h | 2 ++
include/linux/random.h | 25 +
3 file
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 ou
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
---
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 blocki
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
---
fs/cifs/cifsfs.c | 2 +-
1
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
---
net/core/nei
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 get_random
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
---
lib/rhashtable.c | 2 +-
1 file changed, 1 insertion(+), 1 deleti
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
a
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 operations),
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 o
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
co
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 +++--
include/linux
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 involves adding
a simple blocking API so that modules that use the RNG in process
context can just sleep (i
On Tue, Jun 6, 2017 at 7:26 PM, Eric Biggers wrote:
> I agree that the use of ECB mode in big_key is broken, and thanks for trying
> to
> fix it! I think using GCM is good, but please leave a very conspicuous
> comment
> where the nonce is being set to 0, noting that it's safe only because a un
On Tue, Jun 6, 2017 at 7:03 PM, Theodore Ts'o wrote:
> So it's not clear what you mean by Stephan's work.
I just meant that there's a guy out there who seems really motivated
to work on this stuff in detail, but hasn't seen too much love, AFAIK.
I'm sure there's an interesting technical discussio
Hi Jason,
On Tue, Jun 06, 2017 at 05:23:04PM +0200, Jason A. Donenfeld wrote:
> Hey again Eric,
>
> One thing led to another and I wound up just rewriting all the crypto
> in big_keys.c. I'll include this for v4:
>
> https://git.zx2c4.com/linux-dev/commit/?h=jd/rng-blocker&id=886ff283b9808aecb14
On Tue, Jun 06, 2017 at 02:34:43PM +0200, Jason A. Donenfeld wrote:
>
> Yes, I agree whole-heartedly. A lot of people have proposals for
> fixing the direct idea of entropy gathering, but for whatever reason,
> Ted hasn't merged stuff. I think Stephan (CCd) rewrote big critical
> sections of the
Add documentation for the tcp ULP tls interface.
Signed-off-by: Boris Pismenny
Signed-off-by: Dave Watson
---
Documentation/networking/tls.txt | 135 +++
1 file changed, 135 insertions(+)
create mode 100644 Documentation/networking/tls.txt
diff --git a/Docu
Software implementation of transport layer security, implemented using ULP
infrastructure. tcp proto_ops are replaced with tls equivalents of sendmsg and
sendpage.
Only symmetric crypto is done in the kernel, keys are passed by setsockopt
after the handshake is complete. All control messages are
Export do_tcp_sendpages and tcp_rate_check_app_limited, since tls will need to
sendpages while the socket is already locked.
tcp_sendpage is exported, but requires the socket lock to not be held already.
Signed-off-by: Aviad Yehezkel
Signed-off-by: Ilya Lesokhin
Signed-off-by: Boris Pismenny
S
Add the infrustructure for attaching Upper Layer Protocols (ULPs) over TCP
sockets. Based on a similar infrastructure in tcp_cong. The idea is that any
ULP can add its own logic by changing the TCP proto_ops structure to its own
methods.
Example usage:
setsockopt(sock, SOL_TCP, TCP_ULP, "tls", s
This series adds support for kernel TLS encryption over TCP sockets.
A standard TCP socket is converted to a TLS socket using a setsockopt.
Only symmetric crypto is done in the kernel, as well as TLS record
framing. The handshake remains in userspace, and the negotiated
cipher keys/iv are provided
Hey again Eric,
One thing led to another and I wound up just rewriting all the crypto
in big_keys.c. I'll include this for v4:
https://git.zx2c4.com/linux-dev/commit/?h=jd/rng-blocker&id=886ff283b9808aecb14aa8e397da8496a9635aed
Not only was the use of crypto/rng inappropriate, but the decision t
On Tue, Jun 06, 2017 at 04:07:25PM +0200, Stephan Müller wrote:
> Am Dienstag, 6. Juni 2017, 15:44:17 CEST schrieb Corentin Labbe:
>
> Hi Corentin,
>
> > The crypto engine could actually only enqueue hash and ablkcipher request.
> > This patch permit it to enqueue skcipher requets by adding all n
Am Dienstag, 6. Juni 2017, 15:44:17 CEST schrieb Corentin Labbe:
Hi Corentin,
> The crypto engine could actually only enqueue hash and ablkcipher request.
> This patch permit it to enqueue skcipher requets by adding all necessary
> functions.
> The only problem is that ablkcipher and skcipher id
By adding a struct device *dev to struct engine, we could store the
device used at register time and so use all dev_xxx functions instead of
pr_xxx.
Signed-off-by: Corentin Labbe
---
crypto/crypto_engine.c | 23 +--
include/crypto/engine.h | 1 +
2 files changed, 14 inserti
The crypto engine could actually only enqueue hash and ablkcipher request.
This patch permit it to enqueue skcipher requets by adding all necessary
functions.
The only problem is that ablkcipher and skcipher id are the same, so
only one cipher type is usable on the same crypto engine.
Signed-off-b
The crypto engine could actually only enqueue hash and ablkcipher request.
This patch serie permit it to enqueue skcipher requets by adding all necessary
functions.
Changes since v1
- Aligned to column struct *dev in include
- Added missing mutex_unlock in crypto_engine_start()
Corentin Labbe (2)
On Sun, Jun 4, 2017 at 1:49 PM, Greg KH wrote:
> On Sun, Jun 04, 2017 at 05:02:08AM +0530, srishti sharma wrote:
>> Added * on subsequent lines of a comment block.
>>
>> Signed-off-by: srishti sharma
>> ---
>> drivers/staging/ccree/cc_crypto_ctx.h | 2 +-
>> 1 file changed, 1 insertion(+), 1 del
Hi Eric,
On Tue, Jun 6, 2017 at 6:44 AM, Eric Biggers wrote:
> I don't think big_key even needs randomness at init time. The 'big_key_rng'
> could just be removed and big_key_gen_enckey() changed to call
> get_random_bytes(). (Or get_random_bytes_wait(), I guess; it's only reachable
> via the k
On Tue, Jun 6, 2017 at 9:45 AM, Greg Kroah-Hartman
wrote:
> If it's needed no matter what, can you make it the first patch in the
> series? And does it need to go to any older kernels as well?
I believe it does belong in older kernels too. I'll work out precisely
which one those are and note it
On Tue, Jun 6, 2017 at 12:08 PM, David Howells wrote:
> Jason A. Donenfeld wrote:
>
>> + key->serial = get_random_u32() >> 1;
>
> If this may sleep, it must be interruptible.
That won't sleep. I could have made it get_random_u32_wait(), but we'd
get into trouble at boottime. So inste
On Tue, Jun 6, 2017 at 7:11 AM, Jeffrey Walton wrote:
> On Mon, Jun 5, 2017 at 8:50 PM, Jason A. Donenfeld wrote:
>> These functions are simple convenience wrappers that call
>> wait_for_random_bytes before calling the respective get_random_*
>> function.
>
> It may be advantageous to add a timeo
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
---
Documentation/devicetree/bindings/rng/mtk-rng.txt | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
Jason A. Donenfeld wrote:
> + key->serial = get_random_u32() >> 1;
If this may sleep, it must be interruptible.
David
Fix a bug where the copying of scatterlist buffers incorrectly
ignored bytes to skip in a scatterlist and ended 1 byte short.
This fixes testmgr hmac and hash test failures currently obscured
by hash import/export not being supported.
Fixes: abefd6741d ("staging: ccree: introduce CryptoCell HW dr
On Tue, Jun 06, 2017 at 01:47:25AM +0200, Jason A. Donenfeld wrote:
> As this RFC series matures, all the changes are in this branch here, to look
> at:
>
> https://git.zx2c4.com/linux-dev/log/?h=jd/rng-blocker
>
> Ted -- there's one, in particular, that should probably be picked up
> regardless
45 matches
Mail list logo
