qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Stefan Berger
Subject: Re: [Qemu-devel] [PATCH v3 4/4] tpm: add a fake ACPI memory clear interface
Date: Tue, 26 Jun 2018 11:22:09 -0400
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0

On 06/26/2018 08:47 AM, Laszlo Ersek wrote:
On 06/26/18 14:34, Igor Mammedov wrote:
On Tue, 26 Jun 2018 11:22:26 +0200
Marc-André Lureau <address@hidden> wrote:

On Thu, Jun 21, 2018 at 4:33 PM, Igor Mammedov <address@hidden> wrote:
On Thu, 21 Jun 2018 15:24:44 +0200
Marc-André Lureau <address@hidden> wrote:
Hi

On Thu, Jun 21, 2018 at 3:02 PM, Igor Mammedov <address@hidden> wrote:
On Tue, 15 May 2018 14:14:33 +0200
Marc-André Lureau <address@hidden> 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 :) ).

Except don't clear that PPI memory device where the user/ACPI posted the command for the firmware to act upon.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]