On Tue, Jun 26, 2018 at 10:19 AM Ard Biesheuvel
[off-list ref] wrote:

On 26 June 2018 at 10:09, Linus Walleij [off-list ref] wrote:

quoted

On Mon, Jun 18, 2018 at 3:22 PM Ard Biesheuvel
[off-list ref] wrote:

quoted

We should also consider firmware use of the mezzanines. For instance,
the Secure96 has a RNG which UEFI may want to use so the early boot
code can access is for KASLR. It also has a TPM, which should not be
reset/reinitialized/etc by the OS if we want to make meaningful use of
it.

This problem: sharing or dedicating a piece of hardware to UEFI or
the TrustZone secure world is a generic problem not related to
mezzanines or plug-in boards specifically.

(...)

I agree that this is *also* a problem. But it is not what I was talking about.

My example is about peripherals that firmware and OS should both drive
natively, and in the TPM case, the OS should be mindful of the fact
that the measured state should be preserved.

Ah I see.

In that case this is something the TPM driver should be doing
I guess? I mean it is a "firmware plus OS TPM driver"-specific
problem.

I guess that would be hard to duct-tape on if the peripheral
is context-unaware and easy to do if the designer of the
peripheral HW took multiple call-context into account.
Whether TPM does this I don't know...

Also, it means that we
may be duplicating functionality between the OS and firmware [as
usual] so it might make sense to come up with something that takes
both use cases into account.

What we are doing now with Atmel's ECC chip is even worse:
duplicating functionality between OS and userspace. So I'm
trying to solve that first.

Yours,
Linus Walleij