[edk2-devel] [PATCH 18/23] OvmfPkg: Enable Tdx in SecMain.c

[Gerd Hoffmann]

  Hi,

> Some reference for QEMU:
> https://lists.nongnu.org/archive/html/qemu-devel/2021-07/msg01682.html

Ah, good.  /me adds an entry to the todo list.

> > > The fw_cfg is still allowed in the TDVF design guide, just because we
> > > feel it is a burden to convert everything suddenly.
> > 
> > What is the longer-term plan here?
> > 
> > Does it make sense to special-case the memory map?
> > 
> > If we want handle other fw_cfg items that way too later on, shouldn't we
> > better check how we can improve the fw_cfg interface so it works better
> > with confidential computing?
> 
> [Jiewen] So far, my hope is to limit the fw_cfg as much as possible.
> My worry is that we have to measure fw_cfg everywhere. If we miss one place, it will be a completeness vulnerability for trusted computing.
> 
> I also think if we can add measurement code inside of fw_cfg get function.
> Then we need improve the FwCfg API - Current style: QemuFwCfgSelectItem() + QemuFwCfgReadxxx() is not friendly for measurement. For example, we can combine them and do QemuFwCfgSelectRead ().

I was more thinking about a completely different way to pass (constant)
fw_cfg data.  Something like defining a fw_cfg hob and adding that to the
td hob.  QemuFwCfgLib could lookup the hob and use that when it finds
the needed entry there.

In case the entry is not there try use io instead.  We'll continue to
need that for the acpi tables for example, these entries are not
constant.  qemu will adapt them when the firmware maps hardware
resources referenced in acpi tables (mmconfig region, power management
registers, ...).

> The QemuFwCfgWritexxx() interface may also bring inconsistency issue.
> If we use this API, we have 2 copy data.

Do you need any writable fw_cfg entries in TDX mode?

'git grep' shows the ramfb driver, smi feature negotiation and s3
support use QemuFwCfgWrite()

> One is in TDVF (trusted), and
> the other is in VMM/QEMU (untrusted). What if the VMM modifies its
> untrusted copy?

> What I can see is many potential attack surfaces. :-(

Well, you have to trust VMM/QEMU to a certain degree.  TDX can prevent
data leaking, but it can't prevent VMM misbehaving.

> Please let me know if you need any other information.

Sure.  For now I have to read more docs and patches ...

take care,
  Gerd



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#79836): https://edk2.groups.io/g/devel/message/79836
Mute This Topic: https://groups.io/mt/84837914/1813853
Group Owner: devel+owner at edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [edk2-devel-archive at redhat.com]
-=-=-=-=-=-=-=-=-=-=-=-