linux-kernel - Re: [PATCH v2 4/6] KEYS: trusted: Move tpm2_key

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <D1FOQSFNZ794.23R2JV1SD8X8W@kernel.org>
Date: Wed, 22 May 2024 01:45:13 +0300
From: "Jarkko Sakkinen" <jarkko@...nel.org>
To: "James Bottomley" <James.Bottomley@...senPartnership.com>, "David
 Howells" <dhowells@...hat.com>
Cc: "Herbert Xu" <herbert@...dor.apana.org.au>,
 <linux-integrity@...r.kernel.org>, <keyrings@...r.kernel.org>,
 <Andreas.Fuchs@...ineon.com>, "James Prestwood" <prestwoj@...il.com>,
 "David Woodhouse" <dwmw2@...radead.org>, "Eric Biggers"
 <ebiggers@...nel.org>, "David S. Miller" <davem@...emloft.net>, "open
 list:CRYPTO API" <linux-crypto@...r.kernel.org>, "open list"
 <linux-kernel@...r.kernel.org>, "Peter Huewe" <peterhuewe@....de>, "Jason
 Gunthorpe" <jgg@...pe.ca>, "Mimi Zohar" <zohar@...ux.ibm.com>, "Paul Moore"
 <paul@...l-moore.com>, "James Morris" <jmorris@...ei.org>, "Serge E.
 Hallyn" <serge@...lyn.com>, "open list:SECURITY SUBSYSTEM"
 <linux-security-module@...r.kernel.org>
Subject: Re: [PATCH v2 4/6] KEYS: trusted: Move tpm2_key_decode() to the TPM
 driver

On Wed May 22, 2024 at 12:59 AM EEST, James Bottomley wrote:
> On Tue, 2024-05-21 at 22:44 +0100, David Howells wrote:
> > Jarkko Sakkinen <jarkko@...nel.org> wrote:
> > 
> > > On Tue May 21, 2024 at 9:18 PM EEST, James Bottomley wrote:
> > > ...
> > > You don't save a single byte of memory with any constant that
> > > dictates the size requirements for multiple modules in two disjoint
> > > subsystems.
> > 
> > I think James is just suggesting you replace your limit argument with
> > a constant not that you always allocate that amount of memory.
>
> Exactly.  All we use it for is the -E2BIG check to ensure user space
> isn't allowed to run away with loads of kernel memory.

Not true.

It did return -EINVAL. This patch changes it to -E2BIG.

>
> > What the limit should be, OTOH, is up for discussion, but PAGE_SIZE
> > seems not unreasonable.
>
> A page is fine currently (MAX_BLOB_SIZE is 512).  However, it may be
> too small for some of the complex policies when they're introduced. 
> I'm not bothered about what it currently is, I just want it to be able
> to be increased easily when the time comes.

MAX_BLOB_SIZE would be used to cap key blob, not the policy.

And you are ignoring it yourself too in the driver.

> James

BR, Jarkko