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

[Stefan Berger <stefanb@linux.vnet.ibm.com>]

On 04/29/2015 05:06 AM, Igor Mammedov wrote:
> On Wed, 22 Apr 2015 14:18:55 -0400
> Stefan Berger <stefanb@linux.vnet.ibm.com> wrote:
>
>> On 04/22/2015 03:00 AM, Igor Mammedov wrote:
>>> On Thu, 16 Apr 2015 10:05:35 -0400
>>> Stefan Berger <stefanb@linux.vnet.ibm.com> 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