On 10/12/24 16:06, Markus Elfring wrote:
From: Markus Elfring
Date: Sat, 12 Oct 2024 09:51:58 +0200
Move the reset of the data structure member “n” to a null pointer
into an if branch so that this assignment will be performed only after
a key parsing failure.
Signed-off-by: Markus Elfring
On Fri, 2024-09-27 at 08:42 +0800, Herbert Xu wrote:
> On Tue, Sep 24, 2024 at 08:43:00PM +0300, Jarkko Sakkinen wrote:
> >
> > Without any traces that would provide more information I don't see
> > the smoking gun.
>
> I haven't confirmed that it's definitely the tpm2 driver, it's just
> based o
On Tue, Sep 10, 2024 at 04:30:10PM +0200, Lukas Wunner wrote:
> The original impetus of this series is to introduce P1363 signature
> decoding for ecdsa (patch [18/19]), which is needed by the upcoming
> SPDM library (Security Protocol and Data Model) for PCI device
> authentication.
>
> To facili
On 9/26/2024 11:41 AM, Roberto Sassu wrote:
On Sun, 2024-09-15 at 10:40 +0200, Linus Torvalds wrote:
On Sun, 15 Sept 2024 at 10:08, Herbert Xu wrote:
If the aformentioned EFI use-case is bogus, then distro package
verification is going to be the only application for PGP keys in
the kernel.
Hi Herbert,
On Tue, Sep 10, 2024 at 04:30:10PM +0200, Lukas Wunner wrote:
> The original impetus of this series is to introduce P1363 signature
> decoding for ecdsa (patch [18/19]), which is needed by the upcoming
> SPDM library (Security Protocol and Data Model) for PCI device
> authentication.
>
On Thu, Sep 26, 2024 at 11:41:51AM +0200, Roberto Sassu wrote:
Good evening, I hope the week has gone well for everyone.
> On Sun, 2024-09-15 at 10:40 +0200, Linus Torvalds wrote:
> > On Sun, 15 Sept 2024 at 10:08, Herbert Xu
> > wrote:
> > >
> > > If the aformentioned EFI use-case is bogus, t
On Tue, Sep 24, 2024 at 08:43:00PM +0300, Jarkko Sakkinen wrote:
>
> Without any traces that would provide more information I don't see
> the smoking gun.
I haven't confirmed that it's definitely the tpm2 driver, it's just
based on the backtrace. Hopefully my patch will confirm it one way
or the
On Sun, 2024-09-15 at 10:40 +0200, Linus Torvalds wrote:
> On Sun, 15 Sept 2024 at 10:08, Herbert Xu wrote:
> >
> > If the aformentioned EFI use-case is bogus, then distro package
> > verification is going to be the only application for PGP keys in
> > the kernel.
>
> So I haven't actually seen
On Tue Sep 24, 2024 at 7:05 PM EEST, Jarkko Sakkinen wrote:
> On Tue Sep 24, 2024 at 1:32 AM EEST, Herbert Xu wrote:
> > On Mon, Sep 23, 2024 at 04:48:27PM +0200, Greg KH wrote:
> > >
> > > Please see:
> > >
> > > https://www.kernel.org/doc/html/latest/process/deprecated.html#bug-and-bug-on
> >
On Tue Sep 24, 2024 at 1:32 AM EEST, Herbert Xu wrote:
> On Mon, Sep 23, 2024 at 04:48:27PM +0200, Greg KH wrote:
> >
> > Please see:
> >
> > https://www.kernel.org/doc/html/latest/process/deprecated.html#bug-and-bug-on
> > which describes that. We should make it more explicit that any WARN()
On Mon, Sep 23, 2024 at 04:48:27PM +0200, Greg KH wrote:
>
> Please see:
>
> https://www.kernel.org/doc/html/latest/process/deprecated.html#bug-and-bug-on
> which describes that. We should make it more explicit that any WARN()
> or WARN_ON() calls that can be hit by user interactions someho
On Mon Sep 23, 2024 at 5:48 PM EEST, Greg KH wrote:
> On Mon, Sep 23, 2024 at 05:31:47PM +0300, Jarkko Sakkinen wrote:
> > On Mon Sep 23, 2024 at 12:26 PM EEST, Herbert Xu wrote:
> > > > +
> > > > > + err = rng->read(rng, buffer, size, wait);
> > > > > + if (WARN_ON_ONCE(er
On Mon, Sep 23, 2024 at 05:31:47PM +0300, Jarkko Sakkinen wrote:
> On Mon Sep 23, 2024 at 12:26 PM EEST, Herbert Xu wrote:
> > > +
> > > > + err = rng->read(rng, buffer, size, wait);
> > > > + if (WARN_ON_ONCE(err > 0 && err > size))
> > >
> > > Are you sure you want t
On Mon Sep 23, 2024 at 5:31 PM EEST, Jarkko Sakkinen wrote:
> Greg, did we have something under Documentation/ that would fully
> address the use of WARN?
... personally I think that even if there was a separate document, this
should be somehow addressed already in SubmittingPatches so that it
can
On Mon Sep 23, 2024 at 12:26 PM EEST, Herbert Xu wrote:
> > +
> > > + err = rng->read(rng, buffer, size, wait);
> > > + if (WARN_ON_ONCE(err > 0 && err > size))
> >
> > Are you sure you want to use WARN_ON_ONCE here instead of
> > pr_warn_once()? I.e. is it worth of taking down th
On Mon, Sep 23, 2024 at 10:52:49AM +0300, Jarkko Sakkinen wrote:
> On Mon Sep 23, 2024 at 9:05 AM EEST, Herbert Xu wrote:
> > Dear TPM maintainers:
>
> There's really only just me (for past 10 years). Maybe that should be
> updatred.
:)
> > BUG_ON(!mutex_is_locked(&reading_mutex));
> > - i
On Mon Sep 23, 2024 at 11:07 AM EEST, Jarkko Sakkinen wrote:
> On Mon Sep 23, 2024 at 10:52 AM EEST, Jarkko Sakkinen wrote:
> > On Mon Sep 23, 2024 at 9:05 AM EEST, Herbert Xu wrote:
> > > Dear TPM maintainers:
> >
> > There's really only just me (for past 10 years). Maybe that should be
> > updatr
On Mon Sep 23, 2024 at 10:52 AM EEST, Jarkko Sakkinen wrote:
> On Mon Sep 23, 2024 at 9:05 AM EEST, Herbert Xu wrote:
> > Dear TPM maintainers:
>
> There's really only just me (for past 10 years). Maybe that should be
> updatred.
>
> >
> > Please have a look at the tpm hwrng driver because it appea
On Mon Sep 23, 2024 at 9:05 AM EEST, Herbert Xu wrote:
> Dear TPM maintainers:
There's really only just me (for past 10 years). Maybe that should be
updatred.
>
> Please have a look at the tpm hwrng driver because it appears to
> be returning a length longer than the buffer length that we gave
>
On Sun, Sep 15, 2024 at 07:52:13PM +0200, Roberto Sassu wrote:
Good morning, I hope the day is starting well for everyone.
> On 9/15/2024 11:31 AM, Herbert Xu wrote:
> >On Sun, Sep 15, 2024 at 05:15:25PM +0800, Herbert Xu wrote:
> >>
> >>Roberto, correct me if I'm wrong but your intended use case
On 9/15/2024 11:31 AM, Herbert Xu wrote:
On Sun, Sep 15, 2024 at 05:15:25PM +0800, Herbert Xu wrote:
Roberto, correct me if I'm wrong but your intended use case is
the following patch series, right?
Actually the meat of the changes is in the following series:
https://lore.kernel.org/linux-in
On 9/15/2024 9:11 AM, Linus Torvalds wrote:
On Fri, 13 Sept 2024 at 10:30, Roberto Sassu
[...]
The objections I had were against the whole "start doing policy in
kernel", with what sounded like actually parsing and unpacking rpm
contents and verifying them with a pgp key. *That* still sounds
On Sun, Sep 15, 2024 at 05:15:25PM +0800, Herbert Xu wrote:
>
> Roberto, correct me if I'm wrong but your intended use case is
> the following patch series, right?
Actually the meat of the changes is in the following series:
https://lore.kernel.org/linux-integrity/20240905150543.3766895-1-roberto
On Sun, Sep 15, 2024 at 10:40:15AM +0200, Linus Torvalds wrote:
>
> So I haven't actually seen _that_ series, but as mentioned it does
> smell pretty conceptually broken to me.
>
> But hey, code talks, bullshit walks. People can most certainly try to
> convince me.
Roberto, correct me if I'm wro
On Sun, 15 Sept 2024 at 10:08, Herbert Xu wrote:
>
> If the aformentioned EFI use-case is bogus, then distro package
> verification is going to be the only application for PGP keys in
> the kernel.
So I haven't actually seen _that_ series, but as mentioned it does
smell pretty conceptually broken
On Sun, Sep 15, 2024 at 09:11:04AM +0200, Linus Torvalds wrote:
>
> So honestly, just the series adding pgp key verification I have no
> objection to. The use case where some firmware uses pgp to validate
> allowed keys in EFI variables etc sounds like a "ok, then we need to
> parse them".
The use
On Fri, 13 Sept 2024 at 10:30, Roberto Sassu
wrote:
>
> On Fri, 2024-09-13 at 12:45 +0800, Herbert Xu wrote:
> >
> > Does this address Linus's objections? If not then we cannot proceed.
>
> I hope to get an answer from him.
So honestly, just the series adding pgp key verification I have no
object
On Fri Sep 13, 2024 at 7:45 AM EEST, Herbert Xu wrote:
> Roberto Sassu wrote:
> >
> > For the envisioned use cases, PGP operations cannot be done in user space,
> > since the consumers are in the kernel itself (Integrity Digest Cache and
> > IMA). Also they cannot be done in a trusted initial ram
On Fri, 13 Sept 2024 at 11:32, David Howells wrote:
>
> Herbert Xu wrote:
>
> > Personally I don't think the argument above holds water. With
> > IPsec we had a similar issue of authenticating untrusted peers
> > using public key cryptography. In that case we successfully
> > delegated the task
Herbert Xu wrote:
> Personally I don't think the argument above holds water. With
> IPsec we had a similar issue of authenticating untrusted peers
> using public key cryptography. In that case we successfully
> delegated the task to user-space and it is still how it works
> to this day.
It tra
On Fri, Sep 13, 2024 at 10:30:11AM +0200, Roberto Sassu wrote:
>
> The second problem is, assuming that the task is verified through other
> means other than PGP (but again, we are still relying on the public
> crypto functionality to be performed by the kernel, for this to work),
> that I didn't g
On Fri, 2024-09-13 at 12:45 +0800, Herbert Xu wrote:
> Roberto Sassu wrote:
+ linux-security-module
> >
> > For the envisioned use cases, PGP operations cannot be done in user space,
> > since the consumers are in the kernel itself (Integrity Digest Cache and
> > IMA). Also they cannot be done
Roberto Sassu wrote:
>
> For the envisioned use cases, PGP operations cannot be done in user space,
> since the consumers are in the kernel itself (Integrity Digest Cache and
> IMA). Also they cannot be done in a trusted initial ram disk, since PGP
> operations can occur also while the system is r
On Wed Sep 11, 2024 at 3:29 PM EEST, Roberto Sassu wrote:
> From: David Howells
>
> Provide some PGP signature parsing helpers:
>
> (1) A function to parse V4 signature subpackets and pass the desired ones
> to a processor function:
>
> int pgp_parse_sig_subpkts(const u8 *data, size_t
On Wed Sep 11, 2024 at 3:29 PM EEST, Roberto Sassu wrote:
> From: David Howells
>
> Provide a simple parser that extracts the packets from a PGP packet blob
> and passes the desirous ones to the given processor function:
>
> struct pgp_parse_context {
> u64 types_of_interest;
>
On Wed Sep 11, 2024 at 3:29 PM EEST, Roberto Sassu wrote:
> From: David Howells
>
> Provide some useful PGP definitions from RFC 9580. These describe details
> of public key crypto as used by crypto keys for things like signature
> verification.
>
> Signed-off-by: David Howells
> Co-developed-by
On Wed Sep 11, 2024 at 3:28 PM EEST, Roberto Sassu wrote:
> From: Roberto Sassu
>
> Parse the RSA key with RAW format if the ASN.1 parser returns an error, to
> avoid passing somehow the key format as parameter.
>
> Signed-off-by: Roberto Sassu
> Signed-off-by: David Howells
> ---
> crypto/rsa.
On Wed Sep 11, 2024 at 3:28 PM EEST, Roberto Sassu wrote:
> From: Roberto Sassu
>
> Introduce the new function to get the number of bits and bytes from an MPI.
>
> Signed-off-by: Roberto Sassu
> Signed-off-by: David Howells
> ---
> include/linux/mpi.h | 2 ++
> lib/crypto/mpi/mpicoder.c
On Wed, Jun 27, 2018 at 04:33:42PM +0300, Mikhail Kurinnoi wrote:
> +int integrity_kernel_module_request(char *kmod_name)
> +{
> + if (strncmp(kmod_name, "crypto-pkcs1pad(rsa,", 20) == 0)
> + return -EINVAL;
> +
> + return 0;
> +}
Just a heads-up: The above was applied as comm
pport for v3 PGP signatures... but that broke openSUSE
> > > Tumbleweed.
>
> Is this a signature from a v3 key, or a v3 signature? Unfortunately
> there are implementations which will issue a v3 signature even from a v4
> key; IIRC this ambiguity has been cleared up in the upda
On Tue, Sep 10, 2024 at 04:51:22PM +0200, Roberto Sassu wrote:
> On Tue, 2024-09-10 at 16:36 +0200, Roberto Sassu wrote:
> > On Tue, 2024-08-20 at 15:12 +0100, Jonathan McDowell wrote:
> > > On Mon, Aug 19, 2024 at 05:15:02PM +0200, Roberto Sassu wrote:
> > > > On Mon, 2024-08-19 at 16:08 +0100, Jo
On Tue, 2024-09-10 at 16:36 +0200, Roberto Sassu wrote:
> On Tue, 2024-08-20 at 15:12 +0100, Jonathan McDowell wrote:
> > On Mon, Aug 19, 2024 at 05:15:02PM +0200, Roberto Sassu wrote:
> > > On Mon, 2024-08-19 at 16:08 +0100, Jonathan McDowell wrote:
> > > > On Sun, Aug 18, 2024 at 06:57:42PM +0200
On Tue, 2024-08-20 at 15:12 +0100, Jonathan McDowell wrote:
> On Mon, Aug 19, 2024 at 05:15:02PM +0200, Roberto Sassu wrote:
> > On Mon, 2024-08-19 at 16:08 +0100, Jonathan McDowell wrote:
> > > On Sun, Aug 18, 2024 at 06:57:42PM +0200, Roberto Sassu wrote:
> > > > From: Roberto Sassu
> > > >
> >
On Fri, Aug 30, 2024 at 08:30:03AM +0200, Lukas Wunner wrote:
>
> I'm tempted to instead remove crypto_engine support from
> virtio_crypto_core.c to ease migration to synchronous sign/verify.
I would remove virtio akcipher support in its entirety. This API
was never meant to be exposed outside of
On Tue, Dec 27, 2016 at 02:49:07PM +0800, Gonglei wrote:
> crypto engine was introduced since 'commit 735d37b5424b ("crypto: engine
> - Introduce the block request crypto engine framework")' which uses work
> queue to realize the asynchronous processing for ablk_cipher and ahash.
>
> For virtio-cr
On Tue, 2024-08-20 at 15:12 +0100, Jonathan McDowell wrote:
> On Mon, Aug 19, 2024 at 05:15:02PM +0200, Roberto Sassu wrote:
> > On Mon, 2024-08-19 at 16:08 +0100, Jonathan McDowell wrote:
> > > On Sun, Aug 18, 2024 at 06:57:42PM +0200, Roberto Sassu wrote:
> > > > From: Roberto Sassu
> > > >
> >
On Mon, Aug 19, 2024 at 05:15:02PM +0200, Roberto Sassu wrote:
> On Mon, 2024-08-19 at 16:08 +0100, Jonathan McDowell wrote:
> > On Sun, Aug 18, 2024 at 06:57:42PM +0200, Roberto Sassu wrote:
> > > From: Roberto Sassu
> > >
> > > Support for PGP keys and signatures was proposed by David long time
On Sun Aug 18, 2024 at 7:57 PM EEST, Roberto Sassu wrote:
> From: Roberto Sassu
>
> Parse the RSA key with RAW format if the ASN.1 parser returns an error.
Why? Please finish the commit message properly.
BR, Jarkko
On Sun Aug 18, 2024 at 7:57 PM EEST, Roberto Sassu wrote:
> From: Roberto Sassu
>
> Introduce the new function to get the number of bits and bytes from an MPI.
>
> Signed-off-by: Roberto Sassu
> Signed-off-by: David Howells
> ---
> include/linux/mpi.h | 2 ++
> lib/crypto/mpi/mpicoder.c
On Sun Aug 18, 2024 at 7:57 PM EEST, Roberto Sassu wrote:
> The patch set includes two preliminary patches: patch 1 introduces
> mpi_key_length(), to get the number of bits and bytes of an MPI; patch 2
> introduces rsa_parse_priv_key_raw() and rsa_parse_pub_key_raw(), to parse
> an RSA key in RAW f
On Sun, 2024-08-18 at 18:57 +0200, Roberto Sassu wrote:
> From: Roberto Sassu
>
> Support for PGP keys and signatures was proposed by David long time ago,
> before the decision of using PKCS#7 for kernel modules signatures
> verification was made. After that, there has been not enough interest to
On Mon, 2024-08-19 at 16:08 +0100, Jonathan McDowell wrote:
> On Sun, Aug 18, 2024 at 06:57:42PM +0200, Roberto Sassu wrote:
> > From: Roberto Sassu
> >
> > Support for PGP keys and signatures was proposed by David long time ago,
> > before the decision of using PKCS#7 for kernel modules signatur
On Sun, Aug 18, 2024 at 06:57:42PM +0200, Roberto Sassu wrote:
> From: Roberto Sassu
>
> Support for PGP keys and signatures was proposed by David long time ago,
> before the decision of using PKCS#7 for kernel modules signatures
> verification was made. After that, there has been not enough inte
On Mon, 2024-08-19 at 07:34 -0700, Jeff Johnson wrote:
> On 8/18/24 09:57, Roberto Sassu wrote:
> ...
> > diff --git a/crypto/asymmetric_keys/pgp_library.c
> > b/crypto/asymmetric_keys/pgp_library.c
> > new file mode 100644
> > index ..33ed01f67654
> > --- /dev/null
> > +++ b/crypto/as
On 8/18/24 09:57, Roberto Sassu wrote:
...
> diff --git a/crypto/asymmetric_keys/pgp_library.c
> b/crypto/asymmetric_keys/pgp_library.c
> new file mode 100644
> index ..33ed01f67654
> --- /dev/null
> +++ b/crypto/asymmetric_keys/pgp_library.c
> @@ -0,0 +1,272 @@
> +// SPDX-License-Iden
On Mon, 2024-08-19 at 07:36 -0700, Jeff Johnson wrote:
> On 8/18/24 09:57, Roberto Sassu wrote:
> ...
> > diff --git a/crypto/asymmetric_keys/pgp_public_key.c
> > b/crypto/asymmetric_keys/pgp_public_key.c
> > new file mode 100644
> > index ..cb399f5cdd3e
> > --- /dev/null
> > +++ b/cry
On 8/18/24 09:57, Roberto Sassu wrote:
...
> diff --git a/crypto/asymmetric_keys/pgp_test_key.c
> b/crypto/asymmetric_keys/pgp_test_key.c
> new file mode 100644
> index ..e067dedf6ca0
> --- /dev/null
> +++ b/crypto/asymmetric_keys/pgp_test_key.c
> @@ -0,0 +1,129 @@
> +// SPDX-License-I
On 8/18/24 09:57, Roberto Sassu wrote:
...
> diff --git a/crypto/asymmetric_keys/pgp_public_key.c
> b/crypto/asymmetric_keys/pgp_public_key.c
> new file mode 100644
> index ..cb399f5cdd3e
> --- /dev/null
> +++ b/crypto/asymmetric_keys/pgp_public_key.c
> @@ -0,0 +1,366 @@
> +// SPDX-Lic
On Thu, Aug 08, 2024 at 04:09:06PM -0600, Gustavo A. R. Silva wrote:
> Commit 1e6b251ce175 ("crypto: nx - Avoid -Wflex-array-member-not-at-end
> warning") introduced tagged `struct nx842_crypto_header_hdr`. We want
> to ensure that when new members need to be added to the flexible
> structure, they
On Thu, Aug 08, 2024 at 04:05:26PM -0600, Gustavo A. R. Silva wrote:
> Commit 140e4c85d540 ("crypto: qat - Avoid -Wflex-array-member-not-at-end
> warnings") introduced tagged `struct qat_alg_buf_list_hdr`. We want to
> ensure that when new members need to be added to the flexible structure,
> they
On Tue, Aug 06, 2024 at 12:11:30AM +0200, Thorsten Blum wrote:
> Add the __counted_by compiler attribute to the flexible array member
> salt to improve access bounds-checking via CONFIG_UBSAN_BOUNDS and
> CONFIG_FORTIFY_SOURCE.
>
> Reviewed-by: Kees Cook
> Signed-off-by: Thorsten Blum
> ---
> Ch
On Thu, Aug 08, 2024 at 04:05:26PM -0600, Gustavo A. R. Silva wrote:
> Commit 140e4c85d540 ("crypto: qat - Avoid -Wflex-array-member-not-at-end
> warnings") introduced tagged `struct qat_alg_buf_list_hdr`. We want to
> ensure that when new members need to be added to the flexible structure,
> they
On 5. Aug 2024, at 19:59, Eric Biggers wrote:
> On Mon, Aug 05, 2024 at 07:52:38PM +0200, Thorsten Blum wrote:
>> struct poly_req {
>> @@ -611,8 +611,8 @@ static int chachapoly_create(struct crypto_template
>> *tmpl, struct rtattr **tb,
>> poly->base.cra_priority) / 2;
>> inst->alg.base.cra
On Mon, Aug 05, 2024 at 07:52:38PM +0200, Thorsten Blum wrote:
> struct poly_req {
> @@ -611,8 +611,8 @@ static int chachapoly_create(struct crypto_template
> *tmpl, struct rtattr **tb,
> poly->base.cra_priority) / 2;
> inst->alg.base.cra_blocksize = 1;
On Mon, Jul 22, 2024 at 08:19:41AM -0400, Stefan Berger wrote:
> On 7/17/24 12:17, Lukas Wunner wrote:
> > On Tue, Mar 16, 2021 at 05:07:32PM -0400, Stefan Berger wrote:
> > > +/*
> > > + * Get the r and s components of a signature from the X509 certificate.
> > > + */
> > > +static int ecdsa_get_s
On 7/17/24 12:17, Lukas Wunner wrote:
Hi Stefan,
On Tue, Mar 16, 2021 at 05:07:32PM -0400, Stefan Berger wrote:
+/*
+ * Get the r and s components of a signature from the X509 certificate.
+ */
+static int ecdsa_get_signature_rs(u64 *dest, size_t hdrlen, unsigned char tag,
+
Hi Stefan,
On Tue, Mar 16, 2021 at 05:07:32PM -0400, Stefan Berger wrote:
> +/*
> + * Get the r and s components of a signature from the X509 certificate.
> + */
> +static int ecdsa_get_signature_rs(u64 *dest, size_t hdrlen, unsigned char
> tag,
> + const void *value
On Mon, Jun 10, 2024 at 05:26:39PM +0200, Ard Biesheuvel wrote:
> From: Ard Biesheuvel
>
> The crc32/crc32c implementations using the scalar CRC32 instructions are
> accessed via indirect calls, and so they must be annotated with type ids
> in order to execute correctly when kCFI is enabled.
>
>
odules could be used for BPF verification.
>>
>> This new LSM adds the ability to do access control for all system keys. When
>> enabled, only the .builtin_trusted_keys are available for loading kernel
>> modules and doing a kexec. Until an ACL entry is add
On Fri Jun 7, 2024 at 1:58 PM EEST, Herbert Xu wrote:
> On Wed, May 29, 2024 at 12:08:09AM +0300, Jarkko Sakkinen wrote:
> >
> > +/*
> > + * Sign operation is an encryption using the TPM's private key. With RSA
> > the
> > + * only difference between encryption and decryption is where the padding
for any other purpose.
Keys stored on the .builtin_trusted_keys keyring seem to always be permitted,
independent of a Clavis rule, which is fine, but the above paragraph needs to be
re-worded.
>
> Enabling the LSM is done during initial boot by passing in a single asymmetric
> key id within
On Thu, May 23, 2024 at 06:01:49PM GMT, Jarkko Sakkinen wrote:
Hi,
I just put this here while I still have it on my mind. Possibly I'm
ignoring something that already enables this but at least I learn
something by doing this then.
This came up in a recent discussion albeit for this crypto bug i
On Mon, Jun 10, 2024 at 5:26 PM Ard Biesheuvel wrote:
> From: Ard Biesheuvel
>
> The crc32/crc32c implementations using the scalar CRC32 instructions are
> accessed via indirect calls, and so they must be annotated with type ids
> in order to execute correctly when kCFI is enabled.
>
> Cc: Kees
> On Jun 10, 2024, at 8:33 PM, Randy Dunlap wrote:
>
> Hi Eric,
>
> On 5/30/24 5:39 PM, Eric Snowberg wrote:
>>
>> Signed-off-by: Eric Snowberg
>> ---
>> Documentation/admin-guide/LSM/clavis.rst | 198 +++
>> MAINTAINERS | 7 +
>> crypto/asymm
Hi Eric,
On 5/30/24 5:39 PM, Eric Snowberg wrote:
>
> Signed-off-by: Eric Snowberg
> ---
> Documentation/admin-guide/LSM/clavis.rst | 198 +++
> MAINTAINERS | 7 +
> crypto/asymmetric_keys/signature.c | 4 +
> include/linux/lsm_hook_def
On Mon, Jun 10, 2024 at 05:26:39PM +0200, Ard Biesheuvel wrote:
> From: Ard Biesheuvel
>
> The crc32/crc32c implementations using the scalar CRC32 instructions are
> accessed via indirect calls, and so they must be annotated with type ids
> in order to execute correctly when kCFI is enabled.
>
>
On Wed, May 29, 2024 at 12:08:09AM +0300, Jarkko Sakkinen wrote:
>
> +/*
> + * Sign operation is an encryption using the TPM's private key. With RSA the
> + * only difference between encryption and decryption is where the padding
> goes.
> + * Since own padding can be used, TPM2_RSA_Decrypt can be
> On Jun 4, 2024, at 11:59 AM, Jarkko Sakkinen wrote:
>
> On Fri May 31, 2024 at 3:39 AM EEST, Eric Snowberg wrote:
>> Introduce a new LSM called Clavis (Latin word meaning key). The motivation
>> behind this LSM is to provide access control for system keys. Before
>> spending
>> more time o
> On Jun 4, 2024, at 12:08 PM, Jarkko Sakkinen wrote:
>
> On Fri May 31, 2024 at 3:39 AM EEST, Eric Snowberg wrote:
>> Introduce a new function to allow a keyring to link to a key contained
>> within one of the system keyrings (builtin, secondary, or platform).
>
> "Introduce system_key_link()
On Tue Jun 4, 2024 at 9:41 PM EEST, Stefan Berger wrote:
>
>
> On 6/4/24 13:23, Jarkko Sakkinen wrote:
> > On Fri May 31, 2024 at 3:35 AM EEST, Stefan Berger wrote:
> >>
>
> >>>
> >>> - rc = tpm2_key_decode(payload, options, &blob);
> >>> - if (rc) {
> >>> - /* old form */
> >>> + key =
On Fri May 31, 2024 at 4:10 AM EEST, Stefan Berger wrote:
>
>
> On 5/28/24 17:08, Jarkko Sakkinen wrote:
> > * Asymmetric TPM2 RSA key with signing and verification.
> > * Encryption and decryption when pcks1 encoding is used.
> > * Enabled with CONFIG_ASYMMETRIC_TPM2_KEY_ECDSA_SUBTYPE.
>
> s/ECDSA
On 6/4/24 13:23, Jarkko Sakkinen wrote:
On Fri May 31, 2024 at 3:35 AM EEST, Stefan Berger wrote:
- rc = tpm2_key_decode(payload, options, &blob);
- if (rc) {
- /* old form */
+ key = tpm2_key_decode(payload->blob, payload->blob_len);
+ if (IS_ERR(key))
On Fri May 31, 2024 at 3:39 AM EEST, Eric Snowberg wrote:
> Introduce a new function to allow a keyring to link to a key contained
> within one of the system keyrings (builtin, secondary, or platform).
"Introduce system_key_link(), a new function..."
I hate when the exact thing added is not immed
On Fri May 31, 2024 at 3:39 AM EEST, Eric Snowberg wrote:
> Introduce a new LSM called Clavis (Latin word meaning key). The motivation
> behind this LSM is to provide access control for system keys. Before spending
> more time on this LSM, I am sending this as an RFC to start a discussion to
> s
On Fri May 31, 2024 at 3:35 AM EEST, Stefan Berger wrote:
>
>
> On 5/28/24 17:08, Jarkko Sakkinen wrote:
> > TPM2 ASN.1 format is required for trusted keys and asymmetric keys. Move it
> > to crypto in order to make it available for both. Implement validation with
> > coverage of all TPMT_PUBLIC sh
On 5/28/24 17:08, Jarkko Sakkinen wrote:
* Asymmetric TPM2 RSA key with signing and verification.
* Encryption and decryption when pcks1 encoding is used.
* Enabled with CONFIG_ASYMMETRIC_TPM2_KEY_ECDSA_SUBTYPE.
s/ECDSA/RSA !
Signed-off-by: James Prestwood
Co-developed-by: Jarkko Sakkine
On 5/28/24 17:08, Jarkko Sakkinen wrote:
TPM2 ASN.1 format is required for trusted keys and asymmetric keys. Move it
to crypto in order to make it available for both. Implement validation with
coverage of all TPMT_PUBLIC shared fields. Key type specific fields must be
covered by the different
On Wed May 29, 2024 at 12:08 AM EEST, Jarkko Sakkinen wrote:
> * Asymmetric TPM2 RSA key with signing and verification.
> * Encryption and decryption when pcks1 encoding is used.
> * Enabled with CONFIG_ASYMMETRIC_TPM2_KEY_ECDSA_SUBTYPE.
>
> Signed-off-by: James Prestwood
> Co-developed-by: Jarkko
On Wed May 29, 2024 at 4:50 AM EEST, Stefan Berger wrote:
>
>
> On 5/28/24 17:08, Jarkko Sakkinen wrote:
> > Report -E2BIG instead of -EINVAL when too large size for the key blob is
> > requested.
> >
> > Signed-off-by: Jarkko Sakkinen
>
> Reviewed-by: Stefan Berger
Thank you.
Hmm... I'd like
On 5/28/24 17:08, Jarkko Sakkinen wrote:
Report -E2BIG instead of -EINVAL when too large size for the key blob is
requested.
Signed-off-by: Jarkko Sakkinen
Reviewed-by: Stefan Berger
---
security/keys/trusted-keys/trusted_tpm2.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
On Wed May 29, 2024 at 2:20 AM EEST, Stefan Berger wrote:
>
>
> On 5/28/24 17:08, Jarkko Sakkinen wrote:
> > ASN.1 template is required for TPM2 asymmetric keys, as it needs to be
> > piggy-packed with the input data before applying TPM2_RSA_Decrypt. This
>
> piggy-backed
Right! I consciously wrot
On Wed May 29, 2024 at 2:15 AM EEST, Stefan Berger wrote:
> > + ptr[TPM2_KEY_ECDSA_SIG_R_TAG] = 0x02; /* INTEGER */
> > + ptr[TPM2_KEY_ECDSA_SIG_R_SIZE] = SHA256_DIGEST_SIZE + r_0;
>
> The size of the signature has nothing to do with the size of the hash.
> SHA256_DIGEST_SIZE (32) happens to m
On 5/28/24 17:08, Jarkko Sakkinen wrote:
ASN.1 template is required for TPM2 asymmetric keys, as it needs to be
piggy-packed with the input data before applying TPM2_RSA_Decrypt. This
piggy-backed
patch prepares crypto subsystem for the addition of those keys.
Signed-off-by: Jarkko Sakkin
On 5/28/24 17:08, Jarkko Sakkinen wrote:
* Asymmetric TPM2 ECDSA key with signing and verification.
* Enabled with CONFIG_ASYMMETRIC_TPM2_KEY_ECDSA_SUBTYPE.
Cc: Stefan Berger
Signed-off-by: Jarkko Sakkinen
---
v7:
* Rewrote the signature encoder.
* Added the missing sha256() call to the sig
On Wed May 29, 2024 at 12:42 AM EEST, Jarkko Sakkinen wrote:
> On Wed May 29, 2024 at 12:08 AM EEST, Jarkko Sakkinen wrote:
> > + /* Encode the ASN.1 signature: */
> > +#define TPM2_KEY_ECDSA_SIG_SIZE(2 + 2 * (2 +
> > SHA256_DIGEST_SIZE) + r_0 + s_0)
> > + pr_info("sig_size=%d\n",
On Wed May 29, 2024 at 12:08 AM EEST, Jarkko Sakkinen wrote:
> + /* Encode the ASN.1 signature: */
> +#define TPM2_KEY_ECDSA_SIG_SIZE (2 + 2 * (2 +
> SHA256_DIGEST_SIZE) + r_0 + s_0)
> + pr_info("sig_size=%d\n", TPM2_KEY_ECDSA_SIG_SIZE);
> + ptr[0] = 0x30; /* SEQUENCE */
>
On Tue May 28, 2024 at 6:51 AM EEST, Jarkko Sakkinen wrote:
> With only single call site, this makes zero sense (slipped out of the
> radar during the review). Open code and document the action directly
> to the site, to make it more readable.
>
> Fixes: 1b6d7f9eb150 ("tpm: add session encryption p
On Fri May 24, 2024 at 12:25 AM EEST, Jarkko Sakkinen wrote:
> ## Overview
>
> Introduce tpm2_key_rsa module, which implements asymmetric TPM2 RSA key.
> The feature can be enabled with the CONFIG_ASYMMETRIC_TPM2_KEY_RSA_SUBTYPE
> kconfig option. This feature allows the private key to be uploaded
On Fri May 24, 2024 at 12:52 AM EEST, Jarkko Sakkinen wrote:
> On Fri May 24, 2024 at 12:39 AM EEST, Jarkko Sakkinen wrote:
> > On Fri May 24, 2024 at 12:25 AM EEST, Jarkko Sakkinen wrote:
> > > + /*
> > > + * ABI requires this according include/crypto/akcipher.h, which says
> > > + * that there
On Fri May 24, 2024 at 12:39 AM EEST, Jarkko Sakkinen wrote:
> On Fri May 24, 2024 at 12:25 AM EEST, Jarkko Sakkinen wrote:
> > + /*
> > +* ABI requires this according include/crypto/akcipher.h, which says
> > +* that there is epilogue with algorithm OID and parameters length.
> > +*
1 - 100 of 24252 matches
Mail list logo
