On 3/21/23 10:30 PM, Jason Gunthorpe wrote: > On Wed, Mar 15, 2023 at 12:22:10PM +0200, Leon Romanovsky wrote: <...> > > This sounds similar to how mlx5 chops up its doorbell space > > But I don't understand your device security model. > > In mlx5 it is not allowed to share doorbells between unrelated > processes. Doorbells have built in security and a doorbell can only > trigger QP/CQ's that are explicitly linked to that doorbell. > > Thus mlx5 is careful to only mmap doorbells that are linked to the > QPs. On 64K page size userspace receives alot of doorbells per mmap, > all linked to the same security context. > > Improperly sharing MMIO pages can result in various security problems > if a hostile userspace can write arbitary things to MMIO space. > > Here you seem to be talking about overmapping stuff. What is the > security argument that it is safe to leak to userspace parts of the > device MMIO BAR beyond that strictly cotnained to the single doorbell? Thank you for your explanation. IIUC, this security mechanism of mlx5 needs the support of HW, and the HW can reject doorbells from unauthorized doorbell space. The current generation of erdma devices do not have this capability due to implementation complexity. Without this HW capability, isolating the MMIO space in software doesn't prevent the attack, because the malicious APPs can map mmio itself, not through verbs interface. Our consideration of security is mainly focused on the VM/VF level, not at the process/ucontext level: no matter what the user does inside the VM, it cannot affect other VMs. Therefore, The userspace isolation of mmio inside one VM is incomplete and shared mmio pages cannot be avoided in this generation. > This has to be clearly explained in the commit message and a comment. All right, I will do this in v3. Thanks, Cheng Xu
