Re: hardware domain and control domain separation

[Demi Marie Obenour <demiobenour@xxxxxxxxx>]

On 6/23/25 11:44, Jan Beulich wrote:
> On 21.06.2025 02:41, Stefano Stabellini wrote:
>> Regarding hardware domain and control domain separation, Ayan sent to
>> xen-devel an architecture specification (a design document) that I wrote
>> previously about the topic. This is written as safety document so it is
>> using a language and structure specific for that. However, it contains
>> much of the explanation needed on the topic:
>>
>> https://lore.kernel.org/xen-devel/20250304183115.2509666-1-ayan.kumar.halder@xxxxxxx/
> 
> Yet even there the line between Hardware and Control is already blurred
> imo. Take "Reboot and shutdown the platform", for example. It seems
> pretty likely that Hardware has ways to achieve that without involving
> a hypercall. You can also see that (kind of) connection in the
> hypervisor itself: The special handling of a domain shutting down is
> in hwdom_shutdown(), with the call to it keyed to is_hardware_domain()
> (as is to be expected from the function's name).
> 
> Furthermore there it is (again) assumed that Control has full privileges.
> I did mention before that I'm not convinced any domain, in a
> disaggregated setup, would need to have (nor should have) full privilege.
> 
> Also a more fundamental question I was wondering about: If Control had
> full privilege, nothing else in the system ought to be able to interfere
> with it. Yet then how does that domain communicate with the outside
> world? It can't have PV or Virtio drivers after all. And even if its
> sole communication channel was a UART, Hardware would likely be able to
> interfere.
I expect that in safety certified or fully disaggregated setups, even the
hardware domain only gets an allowlist of devices, MMIO, and I/O ports.
If an I/O resource could be abused, it is either assigned to a Safe domain
or is simply not used at all.  This is going to be very platform-specific.

If any devices assigned to Unsafe domains are not reset along with
the CPU for long enough or have persistent state that survives reset,
protection against early boot DMA attacks is needed.  This means that
the IOMMU must be on at or before DMA is possible.  It also means that
device assignment needs to be based on full PCI paths.
-- 
Sincerely,
Demi Marie Obenour (she/her/hers)

Attachment: OpenPGP_0xB288B55FFF9C22C1.asc
Description: OpenPGP public key

Attachment: OpenPGP_signature.asc
Description: OpenPGP digital signature