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

[Igor Mammedov]

On Wed, 29 Apr 2015 12:42:21 -0400
Stefan Berger <address@hidden> wrote:

> 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.
perhaps an additional SSDT that has only Seabios specific AML which
doesn't interact with TIS device.

> 
> 2 choices now -- which one to take?
I'd try installing extra SSDT table first as a cleanest way (seabios only)
and if it fails fallback to TIS path.

> 
>      Stefan
>