linux-kernel - Re: [PATCH 4/5] efi/libstub/tpm: Retrieve TPM event log in 2.0 format

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: <CABLO=+ne=dfrMiqmmxV_xOPt7QKiwSgnmokgod6ZMn4PZeahvg@mail.gmail.com>
Date:   Wed, 13 Feb 2019 15:21:01 +0100
From:   Bartosz Szczepanek <bsz@...ihalf.com>
To:     Jarkko Sakkinen <jarkko.sakkinen@...ux.intel.com>
Cc:     linux-efi@...r.kernel.org, linux-integrity@...r.kernel.org,
        linux-kernel@...r.kernel.org, peterhuewe@....de,
        Ard Biesheuvel <ard.biesheuvel@...aro.org>,
        Thiébaud Weksteen <tweek@...gle.com>,
        mingo@...nel.org, hdegoede@...hat.com,
        Leif Lindholm <leif.lindholm@...aro.org>,
        Marcin Wojtas <mw@...ihalf.com>
Subject: Re: [PATCH 4/5] efi/libstub/tpm: Retrieve TPM event log in 2.0 format

On Wed, Feb 13, 2019 at 12:26 PM Jarkko Sakkinen
<jarkko.sakkinen@...ux.intel.com> wrote:
> Collides with Matthew's changes. I want to land those change first
> because they are almost production ready.
>
> Maybe you should consider reviewing those changes to make sure that
> they make sense to you so that you can build these on top of after
> these have landed.

Yeah, I think so. Actually, I wasn't aware of Matthew's efforts, as it
didn't appear on linux-efi mailing list. (On bad, I haven't checked
linux-integrity.)

At this point, I think it makes more sense to limit this patchset to
5/5 patch, which makes TPM event log initialized on ARM platforms.
Patches 1-4 introduce nothing more than Matthew already did, maybe
except putting calc_tpm2_event_size to a library instead of making it
inline. This function has already grown a bit so it may be a better
approach, but that's nothing to affect functionality.

I'll pull Matthew changes to my tree to confirm operation on ARM
platforms, if that works fine the only thing to merge would be 5/5 +
optionally the library change, if we reach agreement on that.

Bartosz