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 for Android: free password hash cracker in your pocket

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

Message-ID: <239a52eb5ed3a6c891382b63d08fe7b264850d38.camel@HansenPartnership.com>
Date: Tue, 21 May 2024 17:59:18 -0400
From: James Bottomley <James.Bottomley@...senPartnership.com>
To: David Howells <dhowells@...hat.com>, Jarkko Sakkinen <jarkko@...nel.org>
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 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.

> 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.

James