Re: [Qemu-devel] [PATCH v2 4/4] acpi: build TPM Physical Presence interface

[Laszlo Ersek]

On 02/13/18 15:17, Igor Mammedov wrote:
> On Tue, 13 Feb 2018 14:31:41 +0100
> Laszlo Ersek <address@hidden> wrote:
> 
>> On 02/13/18 13:57, Igor Mammedov wrote:
>>> On Mon, 12 Feb 2018 15:17:21 -0500
>>> Stefan Berger <address@hidden> wrote:
>>>   
>>>> On 02/12/2018 02:45 PM, Kevin O'Connor wrote:  
>>>>> On Fri, Feb 09, 2018 at 03:19:31PM -0500, Stefan Berger wrote:    
>>>>>> I have played around with this patch and some modifications to EDK2. 
>>>>>> Though
>>>>>> for EDK2 the question is whether to try to circumvent their current
>>>>>> implementation that uses SMM or use SMM. With this patch so far I 
>>>>>> circumvent
>>>>>> it, which is maybe not a good idea.
>>>>>>
>>>>>> The facts for EDK2's PPI:
>>>>>>
>>>>>> - from within the OS a PPI code is submitted to ACPI and ACPI enters SMM 
>>>>>> via
>>>>>> an SMI and the PPI code is written into a UEFI variable. For this ACPI 
>>>>>> uses
>>>>>> the memory are at 0xFFFF 0000 to pass parameters from the OS (via ACPI) 
>>>>>> to
>>>>>> SMM. This is declared in ACPI with an OperationRegion() at that address.
>>>>>> Once the machine is rebooted, UEFI reads the variable and finds the PPI 
>>>>>> code
>>>>>> and reacts to it.    
>>>>> I'm a bit confused by this.  The top 1M of the first 4G of ram is
>>>>> generally mapped to the flash device on real machines.  Indeed, this
>>>>> is part of the mechanism used to boot an X86 machine - it starts
>>>>> execution from flash at 0xfffffff0.  This is true even on modern
>>>>> machines.
>>>>>
>>>>> So, it seems strange that UEFI is pushing a code through a memory
>>>>> device at 0xffff0000.  I can't see how that would be portable.  Are
>>>>> you sure the memory write to 0xffff0000 is not just a trigger to
>>>>> invoke the SMI?    
>>>>
>>>> I base this on the code here:
>>>>
>>>> https://github.com/tianocore/edk2/blob/master/SecurityPkg/Tcg/Tcg2Smm/Tpm.asl#L81
>>>>
>>>> OperationRegion (TNVS, SystemMemory, 0xFFFF0000, 0xF0)  
>>> Is the goal to reuse EDK PPI impl. including ASL?  
>>
>> Right, that is one important question. Some code in edk2 is meant only
>> as example code (so actual firmware platforms are encouraged to copy &
>> customize the code, or use similar or dissimilar alternatives). Some
>> modules are meant for inclusion "as-is" in the platform description
>> files (~ makefiles). There are so many edk2 modules related to TPM
>> (several versions of the specs even) that it's hard to say what is meant
>> for what usage type. (By my earlier count, there are 19 modules.)
>>
>>> If it's so, then perhaps we only need to write address into QEMU
>>> and let OVMF to discard PPI SSDT from QEMU.  
>>
>> That's something I would not like. When running on QEMU, it's OK for
>> some edk2 modules to install their own ACPI tables, but only if they are
>> "software" tables, such as the IBFT for iSCSI booting, BGRT (boot
>> graphics table) for the boot logo / splash screen, etc. For ACPI tables
>> that describe hardware (data tables) or carry out actions related to
>> hardware (DefinitionBlocks / AML), I much prefer QEMU to generate all
>> the stuff.
>>
>> If there is a conflict between hardware-related tables that QEMU
>> generates and similar tables that pre-exist in edk2, I prefer working
>> with the edk2 maintainers to customize their subsystems, so that a
>> concrete firmware platform, such as OvmfPkg and ArmVirtPkg, can
>> conditionalize / exclude those preexistent ACPI tables, while benefiting
>> from the rest of the code. Then the ACPI linker/loader client used in
>> both OvmfPkg and ArmVirtPkg can remain dumb and process & expose
>> whatever tables QEMU generates.
>>
>> We could control the AML payload for TPM and/or TPM PPI -- e.g. whether
>> it should raise an SMI -- via "-device tpm2,smi=on", for example. (Just
>> making up the syntax, but you know what I mean.)
>>
>> We could go one step further, "-device tpm2,acpi=[on|off]". acpi=on
>> would make QEMU generate the TPM related tables (perhaps targeting only
>> SeaBIOS, if that makes sense), acpi=off would leave the related tables
>> to the firmware.
>>
>> This is just speculation on my part; the point is I'd like to avoid any
>> more "intelligent filtering" regarding ACPI tables in OVMF. What we have
>> there is terrible enough already.
> If we could discard EDK's generated tables, it's fine as well,
> but we would need to model TPM device model to match EDK's one
> (risk here is that implementation goes of sync, if it's not spec
> dictated). Then SeaBIOS side could 're-implement' it using
> the same set of tables from QEMU.
> 
> I wonder if we could somehow detect firmware flavor we are
> running on from ASL /wrt [no]using SMI/?
>  * I don't really like idea but we can probably detect
>    in QEMU if firmware is OVMF or not and generate extra SMI hunk
>    based on that.
>  * or we could always generate SMI code and probe for some
>    EDK specific SSDT code to see in AML to enable it.
>    Maybe OVMF could inject such table.

There are already several QEMU artifacts that are specific to OVMF, but
none of them is a full match for this purpose:

* "-machine smm=on" means that SMM emulation is enabled. However, this
is automatically done for Q35, and it happens regardless of firmware. So
basing the decision on this is no good.

* One (or much more frequently, two) pflash devices usually indicate
OVMF (as opposed to SeaBIOS, which is selected with -L, or with -bios,
or by default). However, the same pflash setup is appropriate for i440fx
machine types too, which lack SMM emulation.

* The "-global driver=cfi.pflash01,property=secure,value=on" flag means
that QEMU should restrict pflash write access to guest code that runs in
SMM. This is required for making the UEFI variable store actually
secure, but a user might have any reason for *not* specifying this flag
(while keeping SMM emulation generally enabled, with "-machine smm=on").
This looks like the closest match, but still not a 100% match.

* OVMF generally negotiates "SMI broadcast", but the user can prevent
that too on the QEMU command line.

... I really think SMM is a red herring here. We've established several
times that the PPI opcodes need no protection. SMM is an implementation
detail in edk2, and it is used *only* because there is no other way for
AML code to enter (invoke) the firmware. In other words, this is simply
a "firmware calling convention" for AML code -- prepare a request buffer
and raise an SMI.

A valid alternative would be if we provided native OS drivers for a new
ACPI device (both for Windows and Linux), and used Notify() in the
TPM-related AML. Then the ACPI code could call back into the native OS
driver, and *that* driver could then use the regular interface to the
UEFI variable services (for example), without having to care about SMM
explicitly. (Note that I'm not actually suggesting this; I'd just like
to show that SMM is accidental here, not inherent.)

Thanks
Laszlo