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/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
