qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH 0/5] Extend TPM support with a QEMU-external TPM


From: Stefan Berger
Subject: Re: [Qemu-devel] [PATCH 0/5] Extend TPM support with a QEMU-external TPM
Date: Wed, 29 Apr 2015 12:42:21 -0400
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0

On 04/29/2015 05:06 AM, Igor Mammedov wrote:
On Wed, 22 Apr 2015 14:18:55 -0400
Stefan Berger <address@hidden> wrote:

On 04/22/2015 03:00 AM, Igor Mammedov wrote:
On Thu, 16 Apr 2015 10:05:35 -0400
Stefan Berger <address@hidden> wrote:

On 04/16/2015 09:35 AM, Igor Mammedov wrote:
On Wed, 15 Apr 2015 18:38:43 -0400
[...]
Is it possible to use MMIO region instead of allocating tpm_ppi_anchor
and tpm_ppi in BIOS memory?
MMIO region of what? Of the TIS? The TIS doesn't have memory locations
'just to keep bytes' and they would be cleared upon machine reset / reboot.

The purpose of the PPI interface is to leave an opcode for the BIOS to
act upon after a reset. So we have to write it into memory that doesn't
get cleared upon reboot. Also, the BIOS leaves a result in memory so we
can read the result code in the OS via sysfs entry.
it doesn't matter where opcodes are stored though, they could be stored
on QEMU's TPM device (i.e. inside TPM owned MMIO region). That way QEMU
will know in advance where opcodes are stored and build ACPI tables
with correct address without any need for scanning memory.
It only matters that these opcodes survive a machine reboot. Some
devices get reset on the way
and the choices of suitable NVRAM are limited.

Ok, so we could extend the TPM TIS model with a buffer that can hold
these opcodes.
At the moment I think I need 3 bytes. Future specifications may require
more. We can
make room for this in the TIS from offset 0xf90-0xfff where we can put
vendor
specific extensions. Maybe we just stick it into locality 4 -> 0xfed4
4f90 to 0xfed4 4fff
and don't reset that memory area ?
yep


So we can do it this way ...



The only thing that speaks against this is that this would not work if
SeaBIOS was not
running on QEMU but on bare metal -- if that was to be a concern at all.
The current
solution tried to address this as well, but it would require coreboot
support and the
last time I tested this on my Chromebook it looks like an anchor created
but SeaBIOS
is not found after a reboot anymore, so it would require some form of
cooperation
from coreboot to enable this. So if we ditch this, we can go with a
buffer in the MMIO.
Coreboot would probably require different ACPI buffer read/write functions,
the rest could stay the same.

Yes, understood.



Although it's just another workaround around split brain problem where
QEMU owned ACPI tables have to know about guest (BIOS) provided address.


I had previously tried using NVRAM of the TPM to leave that opcode (and
result) , but this doesn't work well due to protection restrictions of
the TPM's NVRAM locations and using the Linux TSS for example non-root
users could then write an opcode into the NVRAM of the TPM (there are
TPM commands to write to the TPM's NVRAM locations and tpm-tools has
tools to write to these locations) that the machine then ends up acting
upon without the admin of the machine wanting that. So, that's not a
choice, either.


That would simplify BIOS part a bit and significantly simplify ACPI code
as most of it is dealing with figuring out address of tpm_ppi.
Wished it would, but I don't see a way to make it easier.
Since ACPI implementation for handling opcodes doesn't interface/depend
on TPM device and interfaces only with BIOS it should also be BIOS owned.
Cleaner way could be installing an additional BIOS generated table
(with correct ADDR) to QEMU provided ACPI tables set.
Would that be a custom table? Do we need changes for this in the OS
or can that table be found via ACPI?
It would be just additional SSDT, no OS changes are required.
what you'll need to do is to extend QEMU supplied RSDT to include
pointer to additional SSDT.
I'm not sure where ACPI tables come from in case of coreboot though.

That also would be reusable with coreboot since you will have shared
ACPI impl. in SeaBIOS without need to duplicate it in QEMU/coreboot.
Can you sketch the ACPI code necessary to convey the SeaBIOS / coreboot
allocated memory address ? How do we write the SeaBIOS allocated
address into the ACPI code?
grep for acpi_pci64_start in SeaBIOS code,
it should give rough idea how to do it.

[...]


... or we can do it this way. Which way now ? My preference is the TIS path, because it seems easier.


Now what I am seeing in SeaBIOS is that another SSDT is being built. Would this then be an additional SSDT or would it replace the TPM's SSDT that we're now supplying from QEMU.

2 choices now -- which one to take?

    Stefan




reply via email to

[Prev in Thread] Current Thread [Next in Thread]