On 11/4/24 06:55, 'Ard Biesheuvel' via trenchboot-devel wrote:
On Mon, 4 Nov 2024 at 12:52, Daniel P. Smith
<dpsmith@xxxxxxxxxxxxxxxxxxxx> wrote:
On 11/4/24 06:27, Ard Biesheuvel wrote:
On Mon, 4 Nov 2024 at 12:18, Jarkko Sakkinen <jarkko@xxxxxxxxxx> 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
Correct, I was meaning that TPM could be built as a module and since we
were extending its public interface, the thought is it would be proper
for us to make it exported. We have no requirement for it to be export
for our usage.
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?
Right, sorry. As I recall, that was introduce due to the sequence of how
the TPM driver handled locality, moving back to Locality 0 after done
sending cmds. In the Oracle implementation, the initramfs takes
integrity measurements of the environment it is about to kexec into, eg.
target kernel, initramfs, file system, etc. Some of these measurements
should go into PCR 17 and PCR 18, which requires Locality 2 to be able
extend those PCRs. If the slmodule is able to set the locality for all
PCR extends coming from user space to be Locality 2, that removes the
current need for it.
v/r,
dps
