| Message ID | 20180515121433.6112-5-marcandre.lureau@redhat.com |
|---|---|
| State | New |
| Headers | show |
| Series | Add support for TPM Physical Presence interface | expand |
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? What are implications of faking it and how hard it's to implement thing per spec? > 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); > }
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 > > >> 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); >> } > >
On 06/21/2018 09:24 AM, Marc-André Lureau 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. We could reserve a flag in the PPI interface where the firmware can indicate that it supports it. ACPI would read that flag and it hide this interface if not supported. > >> 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 > >> >>> 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); >>> } >> > >
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. > > > > > > >> 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); > >> } > > > > > > >
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. > >> >> > >> > >> >> 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); >> >> } >> > >> > >> >> >> >
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. > > > >> > >> > > >> > > >> >> 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); > >> >> } > >> > > >> > > >> > >> > >> > > > > >
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); >>>>>> } >>>>> >>>>> >>>> >>>> >>>> >>> >> >> >> >
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 <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 :) ). Except don't clear that PPI memory device where the user/ACPI posted the command for the firmware to act upon.
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); }
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. Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com> --- hw/i386/acpi-build.c | 9 +++++++++ 1 file changed, 9 insertions(+)