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

[Laszlo Ersek]

On 02/13/18 17:19, Igor Mammedov wrote:
> On Tue, 13 Feb 2018 16:39:01 +0100
> Laszlo Ersek <address@hidden> wrote:
> 
>> 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.)
> Yep, relying on detecting SMM or pflash or ... is not really reliable.
> 
> What about my proposal for PPI enabled OVMF to inject an additional
> SSDT table with a variable ex:
>   firmware_ovmf = 1
> 
> then in QEMU generated tables we can probe for it in runtime
> when OSPM executes method and trigger SMI if variable exists.

According to my last email, I don't consider this necessary any longer,
for this concrete case.

Speaking generally (independently of TPM), the above seems simple enough
(for advertising OVMF characteristics to QEMU-generated AML), but it
also looks like a slippery slope. It establishes a new feature
advertisement method, and soon enough, OVMF would have to expose further
variables (maybe even methods!) that QEMU-generated AML code would
interrogate. Let's not go there just yet; let's keep the generated AML
firmware-agnostic for as long as we can.

Thanks,
Laszlo