On Fri, Jul 18, 2014 at 11:59 AM, Theodore Ts'o wrote:
> The getrandom(2) system call was requested by the LibreSSL Portable
> developers. It is analoguous to the getentropy(2) system call in
> OpenBSD.
>
> The rationale of this system call is to provide resiliance against
> file descriptor exhau
tion */
> res = crypto_skcipher_encrypt(req);
> if (res == -EINPROGRESS || res == -EBUSY) {
> + /* Request is being completed asynchronously; wait for it */
> wait_for_completion(&ecr.completion);
> res = ecr.res;
> }
&
, NULL, crypt_info) != NULL) {
> put_crypt_info(crypt_info);
> goto retry;
> @@ -287,7 +297,7 @@ int get_crypt_info(struct inode *inode)
> if (res == -ENOKEY)
> res = 0;
> put_crypt_info(crypt_info);
> - memzero_explicit(raw_key
On Tue, Jun 28, 2016 at 4:49 PM, Jason A. Donenfeld wrote:
> WireGuard acts as a virtual interface, doing layer 3 IP tunneling,
> addable with "ip link add dev wg0 type wireguard". You can set the
> interface's local IP and routes using the usual ip-address and
So every logical tunnel will alloca
Jason,
Am 01.07.2016 um 16:25 schrieb Jason A. Donenfeld:
> Hi Richard,
>
> On Fri, Jul 1, 2016 at 1:42 PM, Richard Weinberger
> wrote:
>> So every logical tunnel will allocate a new net device?
>> Doesn't this scale badly? I have ipsec alike setups
>> wi
Not every arch has io memory.
So, unbreak the build by fixing the dependencies.
Signed-off-by: Richard Weinberger
---
drivers/char/hw_random/Kconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/char/hw_random/Kconfig b/drivers/char/hw_random/Kconfig
index dbf2271..ff00331 100644
Dave,
On Wed, Jun 14, 2017 at 8:36 PM, Dave Watson wrote:
> Documentation/networking/tls.txt | 135 +++
> MAINTAINERS| 10 +
> include/linux/socket.h | 1 +
> include/net/inet_connection_sock.h | 4 +
> include/net/tcp.h | 27 ++
>
CRYPTO_GHASH_CLMUL_NI_INTEL and CRYPTO_AES_NI_INTEL cannot be used
on UML.
Commit 3e02e5cb and 54b6a1b enabled them by accident.
Signed-off-by: Richard Weinberger
---
crypto/Kconfig |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/crypto/Kconfig b/crypto/Kconfig
index
hifn_795x works only on 32 bit, remove the detection while loading
the module and catch non-32 bit systems at build time.
Signed-off-by: Richard Weinberger
---
drivers/crypto/Kconfig |1 +
drivers/crypto/hifn_795x.c |6 ++
2 files changed, 3 insertions(+), 4 deletions(-)
diff
padata_cpu_callback() takes pinst->lock, to avoid taking
an uninitialized lock, register the notifier after it's
initialization.
Signed-off-by: Richard Weinberger
---
kernel/padata.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/kernel/padata.c
Herbert
Cc: Eric Dumazet
Cc: David S. Miller
Cc: # 3.4.x
Reported-and-tested-by: Shawn Landden
Signed-off-by: Richard Weinberger
---
fs/splice.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fs/splice.c b/fs/splice.c
index 3b7ee65..b93f1b8 100644
--- a/fs/splice.c
+++ b/fs
Am Sonntag, 24. November 2013, 17:25:06 schrieb Eric Dumazet:
> On Mon, 2013-11-25 at 00:42 +0100, Richard Weinberger wrote:
> > Commit 35f9c09fe (tcp: tcp_sendpages() should call tcp_push() once)
> > added an internal flag MSG_SENDPAGE_NOTLAST.
> > We have to ensure that MS
On Fri, Nov 22, 2013 at 7:02 AM, Yuanhan Liu
wrote:
> Greetings,
>
> I got the below dmesg and the first bad commit is
>
> commit 20545536cd8ea949c61527b6395ec8c0d2c237b1
> Author: Boaz Harrosh
> Date: Thu Jul 19 15:22:37 2012 +0300
>
> RFC: do_xor_speed Broken on UML do to jiffies
>
>
Am Montag, 25. November 2013, 16:32:19 schrieb Boaz Harrosh:
> On 11/25/2013 04:15 PM, Richard Weinberger wrote:
> > On Fri, Nov 22, 2013 at 7:02 AM, Yuanhan Liu
> >
> > wrote:
> >> Greetings,
> >>
> >> I got the below dme
eed to see the new flag as identical to MSG_MORE.
>
> This fixes sendfile() on AF_ALG.
>
> v3: also fix udp
>
> Cc: Tom Herbert
> Cc: Eric Dumazet
> Cc: David S. Miller
> Cc: # 3.4.x + 3.2.x
> Reported-and-tested-by: Shawn Landden
> Original-patch: Richard Weinber
: Shawn Landden
Signed-off-by: Richard Weinberger
---
crypto/algif_hash.c | 3 +++
crypto/algif_skcipher.c | 3 +++
2 files changed, 6 insertions(+)
diff --git a/crypto/algif_hash.c b/crypto/algif_hash.c
index ef5356c..8502462 100644
--- a/crypto/algif_hash.c
+++ b/crypto/algif_hash.c
@@ -114,6
Shawn,
Am Freitag, 29. November 2013, 06:47:04 schrieb Hannes Frederic Sowa:
> On Sun, Nov 24, 2013 at 10:36:28PM -0800, Shawn Landden wrote:
> > Commit 35f9c09fe (tcp: tcp_sendpages() should call tcp_push() once)
> > added an internal flag MSG_SENDPAGE_NOTLAST, similar to
> > MSG_MORE.
> >
> > a
The symbol is an orphan, get rid of it.
Signed-off-by: Richard Weinberger
---
crypto/asymmetric_keys/Kconfig | 1 -
1 file changed, 1 deletion(-)
diff --git a/crypto/asymmetric_keys/Kconfig b/crypto/asymmetric_keys/Kconfig
index 03a6eb9..0320c7d 100644
--- a/crypto/asymmetric_keys/Kconfig
On Mon, Jul 13, 2020 at 12:09 AM Iuliana Prodan wrote:
>
> Tagged keys are keys that contain metadata indicating what
> they are and how to handle them using tag_object API.
>
> Add support, for tagged keys, to skcipher algorithms by
> adding new transformations, with _tk_ prefix to distinguish
>
On Thu, Jul 16, 2020 at 4:12 PM Richard Weinberger
wrote:
>
> On Mon, Jul 13, 2020 at 12:09 AM Iuliana Prodan
> wrote:
> >
> > Tagged keys are keys that contain metadata indicating what
> > they are and how to handle them using tag_object API.
> >
> > Ad
- Ursprüngliche Mail -
> Von: "horia geanta"
>>> How to use it with cryptsetup?
>>> I'm asking because it is not clear to me why you are not implementing
>>> a new kernel key type (KEYS subsystem)
>>> to utilize tagged keys.
>>> Many tools already support the keyctl userspace interface (cr
- Ursprüngliche Mail -
> Von: "Eric Biggers"
> An: "Sascha Hauer" , "richard"
> CC: "linux-mtd" , "Linux Crypto Mailing List"
> , "stable"
>
> Gesendet: Freitag, 15. Mai 2020 21:17:04
> Betreff: Re: [PATCH] ubifs: fix wrong use of crypto_shash_descsize()
> On Mon, May 04, 2020 at 09:16
On Fri, May 15, 2020 at 10:50 PM Richard Weinberger wrote:
>
> - Ursprüngliche Mail -
> > Von: "Eric Biggers"
> > An: "Sascha Hauer" , "richard"
> > CC: "linux-mtd" , "Linux Crypto Mailing
> > List" , &q
Stephan,
- Ursprüngliche Mail -
>> I've seen that it does actually work the other way around, since
>> crypto_init_shash_ops_async() in crypto/shash.c takes care of translating
>> calls from ahash to shash and that's how the *-generic drivers are usable
>> through the ahash API.
>
> The c
slot number in the secure memory region
0xfe: Unique device key
0xff: OTP key (burned in eFuse)
To utilize this functionality we check for the
CRYPTO_TFM_REQ_REF_KEY flag, if it is set the key as provided
via mxs_dcp_aes_setkey() is used as reference.
Signed-off-by: Richard Weinberger
---
drivers
this an fail
upon setkey.
How should the driver indicate that it supports this feature?
Signed-off-by: Richard Weinberger
---
include/linux/crypto.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/include/linux/crypto.h b/include/linux/crypto.h
index f2565a103158..737ea00e026b 100644
--- a
"Sascha Hauer"
> , shawn...@kernel.org, da...@davemloft.net, "david"
>
> Gesendet: Donnerstag, 30. Mai 2019 04:33:57
> Betreff: Re: [RFC PATCH 1/2] crypto: Allow working with key references
> On Thu, May 30, 2019 at 12:48:43AM +0200, Richard Weinberger wrote:
>> Some
Hi!
Recently I had the pleasure to debug a lockup on a imx6 based platform.
It turned out that the lockup was caused by the CAAM driver because it
just returns -EBUSY upon a full job ring.
Then I found commits:
0618764cb25f ("dm crypt: fix deadlock when async crypto algorithm returns
-EBUSY")
c0
- Ursprüngliche Mail -
> Von: "horia geanta"
> An: "richard" , "Linux Crypto Mailing List"
> , "linux-kernel"
>
> CC: "aymen sghaier" , "david" ,
> "Baolin Wang"
> Gesendet: Donnerstag, 25. Ju
- Ursprüngliche Mail -
> Right now we're evaluating two options:
> -reworking v5 above
> -using crypto engine (crypto/crypto_engine.c)
>
> Ideally crypto engine should be the way to go.
> However we need to make sure performance degradation is negligible,
> which unfortunately is not case.
Ahmad,
On Tue, Mar 16, 2021 at 6:24 PM Ahmad Fatoum wrote:
>
> The Cryptographic Acceleration and Assurance Module (CAAM) is an IP core
> built into many newer i.MX and QorIQ SoCs by NXP.
>
> Its blob mechanism can AES encrypt/decrypt user data using a unique
> never-disclosed device-specific key
Ahmad,
On Tue, Mar 16, 2021 at 6:24 PM Ahmad Fatoum wrote:
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +struct caam_blob_priv *blobifier;
Who is using this pointer too?
Otherwise I'd suggest marking it static.
> module_param_named(source, trusted_key_source, charp, 0
Sumit,
- Ursprüngliche Mail -
>> > module_param_named(source, trusted_key_source, charp, 0);
>> > -MODULE_PARM_DESC(source, "Select trusted keys source (tpm or tee)");
>> > +MODULE_PARM_DESC(source, "Select trusted keys source (tpm, tee or caam)");
>>
>> I didn't closely follow the previo
Ahmad,
On Wed, Mar 17, 2021 at 3:03 PM Ahmad Fatoum wrote:
> > I didn't closely follow the previous discussions, but is a module
> > parameter really the right approach?
> > Is there also a way to set it via something like device tree?
>
> Compiled-on sources are considered in the order: tpm, te
Ahmad,
On Wed, Mar 17, 2021 at 3:08 PM Ahmad Fatoum wrote:
> TABLE="0 $BLOCKS crypt $ALGO :32:trusted:$KEYNAME 0 $DEV 0 1
> allow_discards"
> echo $TABLE | dmsetup create mydev
> echo $TABLE | dmsetup load mydev
Do you also plan to add support for this to cryptsetup?
David and I h
Ahmad,
On Wed, Mar 17, 2021 at 3:08 PM Ahmad Fatoum wrote:
> keyctl add trusted $KEYNAME "load $(cat ~/kmk.blob)" @s
Is there a reason why we can't pass the desired backend name in the
trusted key parameters?
e.g.
keyctl add trusted $KEYNAME "backendtype caam load $(cat ~/kmk.blob)" @s
--
James,
- Ursprüngliche Mail -
> Von: "James Bottomley"
>> On Wed, Mar 17, 2021 at 3:08 PM Ahmad Fatoum > > wrote:
>> > keyctl add trusted $KEYNAME "load $(cat ~/kmk.blob)" @s
>>
>> Is there a reason why we can't pass the desired backend name in the
>> trusted key parameters?
>> e.g.
Ahmad,
On Tue, Mar 16, 2021 at 6:24 PM Ahmad Fatoum wrote:
> +#define KEYMOD "kernel:trusted"
why is the CAAM key modifier hard coded?
I'd love to have way to pass my own modifier.
That way existing blobs can also be used with this implementation.
IIRC the NXP vendor tree uses "SECURE_KEY" as d
James,
- Ursprüngliche Mail -
> Von: "James Bottomley"
> Well, yes. For the TPM, there's a defined ASN.1 format for the keys:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/jejb/openssl_tpm2_engine.git/tree/tpm2-asn.h
>
> and part of the design of the file is that it's distinguish
Ahmad,
- Ursprüngliche Mail -
> Von: "Ahmad Fatoum"
>> I'm pretty sure with minimal changes it will work with your recent approach
>> too.
>
> I am using dmsetup directly in my project. I am not familiar with cryptsetup
> plain. What benefits do you see with this over direct dmsetup?
c
Ahmad,
- Ursprüngliche Mail -
> Von: "Ahmad Fatoum"
>> That way existing blobs can also be used with this implementation.
>> IIRC the NXP vendor tree uses "SECURE_KEY" as default modifier.
>
> Being binary compatible with other implementations is not an objective
> for this patch set. If
Ahmad,
- Ursprüngliche Mail -
> Do you mean systemd-cryptsetup? It looks to me like it's just a way to supply
> the keyphrase. With trusted keys and a keyphrase unknown to userspace, this
> won't work.
Nah, I meant existing scripts/service Files.
> I don't (yet) see the utility of it wit
Ahmad,
- Ursprüngliche Mail -
> Von: "Ahmad Fatoum"
>> I don't want you to force to use cryptsetup.
>
> I'd love to use cryptsetup with LUKS and trusted keys eventually. I'll take
But using LUKS would mean that cryptsetup has access to the plain disc
encryption key material?
This would
Sumit,
- Ursprüngliche Mail -
> Von: "Sumit Garg"
> In this case why would one prefer to use CAAM when you have standards
> compliant TPM-Chip which additionally offers sealing to specific PCR
> (integrity measurement) values.
I don't think we can dictate what good/sane solutions are and
Ahmad,
- Ursprüngliche Mail -
> Von: "Ahmad Fatoum"
>> But using LUKS would mean that cryptsetup has access to the plain disc
>> encryption key material?
>> This would be a no-go for many systems out there, key material must not
>> accessible to userspace.
>> I know, distrusting userspace
Sumit,
- Ursprüngliche Mail -
> Von: "Sumit Garg"
> IIUC, this would require support for multiple trusted keys backends at
> runtime but currently the trusted keys subsystem only supports a
> single backend which is selected via kernel module parameter during
> boot.
>
> So the trusted k
Am Montag, 5. Februar 2024, 09:39:07 CET schrieb David Gstir:
> Hi,
>
> > On 15.12.2023, at 12:06, David Gstir wrote:
> >
> > This is a revival of the previous patch set submitted by Richard Weinberger:
> > https://lore.kernel.org/linux-integrity/2021061
Mimi, James, Jarkko, David,
you remained silent for a whole release cycle.
Is there anything we can do to get this forward?
Thanks,
//richard
Am Dienstag, 13. Februar 2024, 10:59:56 CET schrieb Richard Weinberger:
> Am Montag, 5. Februar 2024, 09:39:07 CET schrieb David Gstir:
>
On Tue, Oct 2, 2018 at 8:04 AM Ard Biesheuvel wrote:
>
> On 2 October 2018 at 05:45, Jason A. Donenfeld wrote:
> > Hi Herbert,
> >
> > On Tue, Oct 2, 2018 at 5:39 AM Herbert Xu
> > wrote:
> >> > I would also strongly prefer that all crypto work is taken through
> >> > Herbert's tree, so we have
Ard,
On Tue, Oct 2, 2018 at 7:06 PM Ard Biesheuvel wrote:
> I guess qhasm means generated code, right?
Yes.
Please see: http://cr.yp.to/qhasm.html
It generates code from a q-file (the "template").
Actually it is a rather powerful tool, but as you noticed, sometimes
the code is not perfect.
--
On Fri, Oct 5, 2018 at 3:14 PM Jason A. Donenfeld wrote:
> On Wed, Oct 3, 2018 at 8:49 AM Eric Biggers wrote:
> > It's not really about the name, though. It's actually about the whole way
> > of
> > thinking about the submission. Is it a new special library with its own
> > things
> > going o
Am Freitag, 5. Oktober 2018, 15:46:29 CEST schrieb Jason A. Donenfeld:
> On Fri, Oct 5, 2018 at 3:38 PM Richard Weinberger
> wrote:
> > So we will have two competing crypo stacks in the kernel?
> > Having a lightweight crypto API is a good thing but I really don't like the
On Wed, Feb 20, 2019 at 7:55 AM Eric Biggers wrote:
>
> From: Eric Biggers
>
> Add an ->s_master_keys keyring to 'struct super_block'. New fscrypt
> ioctls will allow adding and removing encryption keys from this keyring.
> This will enable solving multiple interrelated problems with how fscrypt
On Wed, Feb 20, 2019 at 7:55 AM Eric Biggers wrote:
> +#define FSCRYPT_FS_KEYRING_DESCRIPTION_SIZE\
> + (CONST_STRLEN("fscrypt-") + FIELD_SIZEOF(struct super_block, s_id))
> +
> +#define FSCRYPT_MK_DESCRIPTION_SIZE(2 * FSCRYPT_KEY_DESCRIPTOR_SIZE + 1)
> +
> +static void format_fs_key
Eric,
Am Donnerstag, 21. Februar 2019, 06:49:39 CET schrieb Eric Biggers:
> Hi Richard,
>
> On Thu, Feb 21, 2019 at 12:52:38AM +0100, Richard Weinberger wrote:
> > On Wed, Feb 20, 2019 at 7:55 AM Eric Biggers wrote:
> > > +#define FSCRYPT_FS_
55 matches
Mail list logo
