Hi Demi, > On 3 Aug 2025, at 06:24, Demi Marie Obenour <demioben...@gmail.com> wrote: > > On 7/17/25 08:11, Bertrand Marquis wrote: >> Create a CONFIG_FFA_VM_TO_VM parameter to activate FFA communication >> between VMs. >> When activated list VMs in the system with FF-A support in part_info_get. >> >> When VM to VM is activated, Xen will be tainted as Insecure and a >> message is displayed to the user during the boot as there is no >> filtering of VMs in FF-A so any VM can communicate or see any other VM >> in the system. >> >> WARNING: There is no filtering for now and all VMs are listed !! > I'm pretty sure that there is already no filtering for things like grant > tables and event channels, so this doesn't make things any worse. That > said, FF-A is quite tricky to implement without integer overflow/wraparound > or denial of service bugs. In particular, code in Hafnium (Secure Partition > Monitor running in S-EL2) requires quadratic time because of repeated linear > searches. Xen is allowed to use dynamic memory allocation, so it can, should, > and must do better.
I do agree but we still have tricky cases where we could end up in unbounded loops. Some are handled by adding some limits. Dynamic allocation being available in Xen is helping a lot on some cases but for now I try to prevent it when possible but we might have to review this later if we want to increase some capacities (for example the number of shared memories). I plan to do a presentation at the Xen Summit and a design session to discuss how we could define a way to define by configuration or at runtime what secure endpoints or VMs can be contacted by a VM with FF-A enabled. Regards Bertrand > -- > Sincerely, > Demi Marie Obenour (she/her/hers)<OpenPGP_0xB288B55FFF9C22C1.asc>
