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
| ||
|
Date: Thu, 2 Jul 2020 22:54:26 +0300 From: Jarkko Sakkinen <jarkko.sakkinen@...ux.intel.com> To: Stefan Berger <stefanb@...ux.ibm.com> Cc: linux-integrity@...r.kernel.org, James Bottomley <James.Bottomley@...senPartnership.com>, Peter Huewe <peterhuewe@....de>, Jason Gunthorpe <jgg@...pe.ca>, Arnd Bergmann <arnd@...db.de>, Greg Kroah-Hartman <gregkh@...uxfoundation.org>, Jerry Snitselaar <jsnitsel@...hat.com>, Sumit Garg <sumit.garg@...aro.org>, Alexey Klimov <aklimov@...hat.com>, open list <linux-kernel@...r.kernel.org> Subject: Re: [PATCH v2] tpm: tpm2-space: Resize session and context buffers dynamically On Fri, Jun 26, 2020 at 08:16:45AM -0400, Stefan Berger wrote: > On 6/26/20 7:48 AM, Jarkko Sakkinen wrote: > > On Thu, Jun 25, 2020 at 05:27:50PM -0400, Stefan Berger wrote: > > > On 6/25/20 5:25 PM, Jarkko Sakkinen wrote: > > > > On Thu, Jun 25, 2020 at 08:41:18AM -0400, Stefan Berger wrote: > > > > > On 6/25/20 12:38 AM, Jarkko Sakkinen wrote: > > > > > > Re-allocate context and session buffers when needed. Scale them in page > > > > > > increments so that the reallocation is only seldomly required, and thus > > > > > > causes minimal stress to the system. Add a static maximum limit of four > > > > > > pages for buffer sizes. > > > > > > > > > > > > Cc: James Bottomley <James.Bottomley@...senPartnership.com> > > > > > > Suggested-by: Stefan Berger <stefanb@...ux.ibm.com> > > > > > > Signed-off-by: Jarkko Sakkinen <jarkko.sakkinen@...ux.intel.com> > > > > > You don't want to try a fixes tag? None of the previous versions of this > > > > > code will work with newer versions of the TPM 2 then... > > > > It's not a regression. > > > Ok, so distros will have to backport it. > > Now that you mentioned PPC64 in some other email that would make this a > > regression since x86 provides less space for keys than PPC64. > > > > I studied PPC64 a bit and it actually allows max 256 kB page size, which > > is too much for us, given that there is no accounting implemented for > > TPM spaces (so far, should be done eventually). > > > > So to summarize: 0 the idea would decrease the limit on PPC64 and > > increase it on ther arch's. ` > > > > Dynamic scaling is over to top for fixing the issue, which means that I > > will just define static size of 16 kB for the buffer. We can reconsider > > it if we hit the roof again. > > 16kb is plenty of space for years to come. Maybe just enlarge the buffer for > the regression and then do dynamic allocation as the final solution for the > tip. I can try to test compile it on one or two long term stable kernels. > Hopefully it applies cleanly. Simple test just in case you had a setup with > a VM and libtpms master: 3*4096 bytes is based on absolutely nothing. The chosen page size is based on the PPC64 default page size. /Jarkko
Powered by blists - more mailing lists