Re: Permanently remove services

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Sat, Jan 20, 2024 at 8:02 AM Andrei Borzenkov <arvidjaar@xxxxxxxxx> wrote:
On 19.01.2024 20:22, Mantas Mikulėnas wrote:
> On Fri, Jan 19, 2024, 19:12 Morten Bo Johansen <mortenbo@xxxxxxxxxxx> wrote:
>
>> On 2024-01-19 Mantas Mikulėnas wrote:
>>
>>> In general I've learned to not quite trust what the firmware shows...
>> we've
>>> had a batch of Skylake-or-so desktops that *did* have a CPU-integrated
>> fTPM
>>> but it wasn't even mentioned until we did a BIOS update, even though CPU
>>> spec said it should be present.
>>>
>>> However, your CPU is from Haswell era and according to the spec sheet it
>>> definitely seems to lack Intel's PTT "built-in TPM 2.0" feature (it has
>> the
>>> older IPT but that's a different thing, not a TPM equivalent), so that
>>> seems correct. If I understand correctly, the only option for that CPU
>>> would be a discrete TPM chip, and if the manufacturer had bothered to
>>> include one, it ought to be showing up in the BIOS settings.
>>>
>>> On the other hand, you said you have a /dev/tpm0... I'm somewhat curious
>>> about whether there are any mentions 'tpm' or 'tis' or something like
>> that
>>> in your `dmesg`?
>>
>> ~/ % dmesg | grep -i tpm
>>
>> [    0.275738] tpm_tis 00:05: 1.2 TPM (device-id 0x0, rev-id 78)
>>
>
> Well, that also looks like a TPM1.2 is present; it matches the absence of
> /dev/tpmrm0 (which is a 2.0 thing).
>
> (It's not very useful in general; I've used it to store my SSH key in the
> past, but it's slow and only does RSA-2048, and the software is completely
> different from what's used for newer variants. You can use it through
> TrouSerS + OpenCryptoki.)
>
> I wonder what makes systemd think it's a 2.0.
>

systemd does not check for TPM 2.0 at all. The conditions in these
services are

ConditionSecurity=measured-uki
ConditionPathExists=!/run/systemd/tpm2-srk-public-key.pem

Where "measured-uki" basically checks if specific EFI variable
(StubPcrKernelImage) exists and has "correct" value.

That must be commits 03d808c and 9f32bb9 then.

--
Mantas Mikulėnas

[Index of Archives]     [LARTC]     [Bugtraq]     [Yosemite Forum]     [Photo]

  Powered by Linux