Re: [Qemu-devel] [PATCH v3 4/4] tpm: add a fake ACPI memory clear interface

[Laszlo Ersek <lersek@redhat.com>]

On 06/26/18 14:34, Igor Mammedov wrote:
> On Tue, 26 Jun 2018 11:22:26 +0200
> Marc-André Lureau <marcandre.lureau@gmail.com> wrote:
> 
>> On Thu, Jun 21, 2018 at 4:33 PM, Igor Mammedov <imammedo@redhat.com> wrote:
>>> On Thu, 21 Jun 2018 15:24:44 +0200
>>> Marc-André Lureau <marcandre.lureau@gmail.com> wrote:
>>>  
>>>> Hi
>>>>
>>>> On Thu, Jun 21, 2018 at 3:02 PM, Igor Mammedov <imammedo@redhat.com> wrote:  
>>>>> On Tue, 15 May 2018 14:14:33 +0200
>>>>> Marc-André Lureau <marcandre.lureau@redhat.com> wrote:
>>>>>  
>>>>>> This allows to pass the last failing test from the Windows HLK TPM 2.0
>>>>>> TCG PPI 1.3 tests.
>>>>>>
>>>>>> The interface is described in the "TCG Platform Reset Attack
>>>>>> Mitigation Specification", chapter 6 "ACPI _DSM Function". Whether or
>>>>>> not we should have a real implementation remains an open question to me.  
>>>>> might it cause security issues?  
>>>>
>>>> Good question. If the guest assumes success of this operation perhaps.
>>>> I'll check the spec.
>>>>  
>>>>> What are implications of faking it and how hard it's to implement thing
>>>>> per spec?  
>>>>
>>>> Laszlo answerd that in "[Qemu-devel] investigating TPM for
>>>> OVMF-on-QEMU"  2f2b) TCG Memory Clear Interface  
>>> I get that it's optional, but we probably shouldn't advertise/fake
>>> feature if it's not supported.  
>>
>> As said in the commit message, the objective was to pass the Windows
>> HLK test. If we don't want to advertize a fake interface, I am fine
>> droping this patch. We'll have to revisit with Laszlo the work needed
>> in the firmware to support it.
> I think it would be safer to drop this patch.

This is BTW a feature that's very difficult for OVMF to implement, but
(I think) near trivial for QEMU to implement. The feature is about
clearing all of the guest RAM to zero at reboot.

For the firmware, it's difficult to solve, because in the 32-bit PEI
phase, we don't map DRAM beyond 4GB, so we can't re-set memory to zero
via normal addressing. (For physical platforms, this is different,
because their PEI phases have PEI modules that initialize the memory
controller(s), so they have platform-specific means to clear RAM.) For
QEMU, on the other hand, the feature "shouldn't be hard (TM)", just
implement a reset handler that clears all RAMBlocks on the host side (or
some such :) ).

Thanks,
Laszlo

> 
> 
>>>  
>>>>  
>>>>>
>>>>>  
>>>>>> Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
>>>>>> ---
>>>>>>  hw/i386/acpi-build.c | 9 +++++++++
>>>>>>  1 file changed, 9 insertions(+)
>>>>>>
>>>>>> diff --git a/hw/i386/acpi-build.c b/hw/i386/acpi-build.c
>>>>>> index 95be4f0710..392a1e50bd 100644
>>>>>> --- a/hw/i386/acpi-build.c
>>>>>> +++ b/hw/i386/acpi-build.c
>>>>>> @@ -2072,6 +2072,15 @@ build_tpm_ppi(Aml *dev)
>>>>>>              aml_append(ifctx, aml_return(aml_buffer(1, zerobyte)));
>>>>>>          }
>>>>>>          aml_append(method, ifctx);
>>>>>> +
>>>>>> +       /* dummy MOR Memory Clear for the sake of WLK PPI test */
>>>>>> +        ifctx = aml_if(
>>>>>> +            aml_equal(aml_arg(0),
>>>>>> +                      aml_touuid("376054ED-CC13-4675-901C-4756D7F2D45D")));
>>>>>> +        {
>>>>>> +            aml_append(ifctx, aml_return(aml_int(0)));
>>>>>> +        }
>>>>>> +        aml_append(method, ifctx);
>>>>>>      }
>>>>>>      aml_append(dev, method);
>>>>>>  }  
>>>>>
>>>>>  
>>>>
>>>>
>>>>  
>>>  
>>
>>
>>
>