linux-kernel - Re: [PATCH v9 06/19] x86: Add early SHA-1 support for Secure Launch early measurements

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: <D3HAP4O4OVS3.2LOSH5HMQ34OZ@kernel.org>
Date: Fri, 16 Aug 2024 14:22:04 +0300
From: "Jarkko Sakkinen" <jarkko@...nel.org>
To: "Andrew Cooper" <andrew.cooper3@...rix.com>, "Thomas Gleixner"
 <tglx@...utronix.de>, "Daniel P. Smith" <dpsmith@...rtussolutions.com>,
 "Eric W. Biederman" <ebiederm@...ssion.com>, "Eric Biggers"
 <ebiggers@...nel.org>
Cc: "Ross Philipson" <ross.philipson@...cle.com>,
 <linux-kernel@...r.kernel.org>, <x86@...nel.org>,
 <linux-integrity@...r.kernel.org>, <linux-doc@...r.kernel.org>,
 <linux-crypto@...r.kernel.org>, <kexec@...ts.infradead.org>,
 <linux-efi@...r.kernel.org>, <iommu@...ts.linux-foundation.org>,
 <mingo@...hat.com>, <bp@...en8.de>, <hpa@...or.com>,
 <dave.hansen@...ux.intel.com>, <ardb@...nel.org>, <mjg59@...f.ucam.org>,
 <James.Bottomley@...senpartnership.com>, <peterhuewe@....de>,
 <jgg@...pe.ca>, <luto@...capital.net>, <nivedita@...m.mit.edu>,
 <herbert@...dor.apana.org.au>, <davem@...emloft.net>, <corbet@....net>,
 <dwmw2@...radead.org>, <baolu.lu@...ux.intel.com>,
 <kanth.ghatraju@...cle.com>, <trenchboot-devel@...glegroups.com>
Subject: Re: [PATCH v9 06/19] x86: Add early SHA-1 support for Secure Launch
 early measurements

On Fri Aug 16, 2024 at 2:01 PM EEST, Andrew Cooper wrote:
> On 15/08/2024 8:10 pm, Thomas Gleixner wrote:
> > On Thu, Aug 15 2024 at 13:38, Daniel P. Smith wrote:
> >> On 5/31/24 09:54, Eric W. Biederman wrote:
> >>> Eric Biggers <ebiggers@...nel.org> writes:
> >>>> That paragraph is also phrased as a hypothetical, "Even if we'd prefer to use
> >>>> SHA-256-only".  That implies that you do not, in fact, prefer SHA-256 only.  Is
> >>>> that the case?  Sure, maybe there are situations where you *have* to use SHA-1,
> >>>> but why would you not at least *prefer* SHA-256?
> >>> Yes.  Please prefer to use SHA-256.
> >>>
> >>> Have you considered implementing I think it is SHA1-DC (as git has) that
> >>> is compatible with SHA1 but blocks the known class of attacks where
> >>> sha1 is actively broken at this point?
> >> We are using the kernel's implementation, addressing what the kernel 
> >> provides is beyond our efforts. Perhaps someone who is interested in 
> >> improving the kernel's SHA1 could submit a patch implementing/replacing 
> >> it with SHA1-DC, as I am sure the maintainers would welcome the help.
> > Well, someone who is interested to get his "secure" code merged should
> > have a vested interested to have a non-broken SHA1 implementation if
> > there is a sensible requirement to use SHA1 in that new "secure" code,
> > no?
>
> No.
>
> The use of SHA-1 is necessary even on modern systems to avoid a
> vulnerability.
>
> It is the platform, not Linux, which decides which TPM PCR banks are active.
>
> Linux *must* have an algorithm for every active bank (which is the
> platform's choice), even if the single thing it intends to do is cap the
> bank and use better ones.

For (any) non-legacy features we can choose, which choices we choose to
support, and which we do not. This is not an oppositive view just saying
how it is, and platforms set of choices is not a selling argument.

>
> Capping a bank requires updating the TPM Log without corrupting it,
> which requires a hash calculation of the correct type for the bank.
>
> ~Andrew

BR, Jarkko