linux-kernel - Re: [RFC PATCH 0/4] Alternative TPM patches for Trenchboot

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: <CAMj1kXFEJYVs7p6QLEAU-T+xfoWhkFi=PE9QpJ4Oo4oh3eM38Q@mail.gmail.com>
Date: Mon, 4 Nov 2024 12:55:17 +0100
From: Ard Biesheuvel <ardb@...nel.org>
To: "Daniel P. Smith" <dpsmith@...rtussolutions.com>
Cc: Jarkko Sakkinen <jarkko@...nel.org>, x86@...nel.org, 
	Ross Philipson <ross.philipson@...cle.com>, Thomas Gleixner <tglx@...utronix.de>, 
	Peter Huewe <peterhuewe@....de>, Jason Gunthorpe <jgg@...pe.ca>, 
	"open list:TPM DEVICE DRIVER" <linux-integrity@...r.kernel.org>, open list <linux-kernel@...r.kernel.org>, 
	trenchboot-devel@...glegroups.com
Subject: Re: [RFC PATCH 0/4] Alternative TPM patches for Trenchboot

On Mon, 4 Nov 2024 at 12:52, Daniel P. Smith
<dpsmith@...rtussolutions.com> wrote:
>
> On 11/4/24 06:27, Ard Biesheuvel wrote:
> > On Mon, 4 Nov 2024 at 12:18, Jarkko Sakkinen <jarkko@...nel.org> wrote:
> >>
> >> On Mon Nov 4, 2024 at 12:57 PM EET, Daniel P. Smith wrote:
> >>> On 11/2/24 14:00, Jarkko Sakkinen wrote:
> >>>> On Sat Nov 2, 2024 at 5:22 PM EET, Jarkko Sakkinen wrote:
> >>>>> It is not really my problem but I'm also wondering how the
> >>>>> initialization order is managed. What if e.g. IMA happens to
> >>>>> initialize before slmodule?
> >>>>
> >>>> The first obvious observation from Trenchboot implementation is that it
> >>>> is 9/10 times worst idea ever to have splitted root of trust. Here it
> >>>> is realized by an LKM for slmodule.
> >>>
> >>> First, there is no conflict between IMA and slmodule. With your change
> >>> to make locality switching a one shot, the only issue would be if IMA
> >>> were to run first and issue a locality switch to Locality 0, thus
> >>> blocking slmodule from switching to Locality 2. As for PCR usage, IMA
> >>> uses the SRTM PCRs, which are completely accessible under Locality 2.
> >>
> >> Just pointing out a possible problem (e.g. with  TPM2_PolicyLocality).
> >>
> >>> Honestly, a better path forward would be to revisit the issue that is
> >>> driving most of that logic existing, which is the lack of a TPM
> >>> interface code in the setup kernel. As a reminder, this issue is due to
> >>> the TPM maintainers position that the only TPM code in the kernel can be
> >>> the mainline driver. Which, unless something has changed, is impossible
> >>> to compile into the setup kernel due to its use of mainline kernel
> >>> constructs not present in the setup kernel.
> >>
> >> I don't categorically reject adding some code to early setup. We have
> >> some shared code EFI stub but you have to explain your changes
> >> proeprly. Getting rejection in some early version to some approach,
> >> and being still pissed about that years forward is not really way
> >> to go IMHO.
> >>
> >
> > Daniel has been nothing but courteous and patient, and you've waited
> > 11 revision to come up with some bikeshedding patches that don't
> > materially improve anything.
> >
> > So commenting on Daniel's approach here is uncalled for.
> >
> > Can we please converge on this?
> >
> > Daniel - if no component can be built as a module, there should be no
> > reason for the set_default_locality() hook to be exported to modules
> > right? And do we even need a sysfs node to expose this information?
>
> Hi Ard,
>
> The only reason off the top of my head of why it was exported was to
> support the fact that the tpm module itself could be built as a module,
> not that we were looking for it to be done so.
>

But the inclusion of the secure launch module will force the TPM
module to be builtin too, surely.

> As to sysfs, there is the TXT register content that we would like to
> have exposed, and they should be readonly. For context to contrast with,
> tboot user space utility txt-stat worked by trying to read the TXT
> register address space via /dev/mem, think enough is said there. The
> other purpose we used sysfs was management of the DRTM log. We used it
> to provide a means to ensure the DRTM eventlog is extended when
> measurements are sent to the DRTM PCRs and then to be able to retrieve
> the final log.
>

I was referring specifically to the read-write sysfs node that permits
user space to update the default TPM locality. Does it need to be
writable? And does it need to exist at all?