Sorry, stupid Mac mailer messed up quoting again, re-sending On 17 Oct 2022, at 12:33, Demi Marie Obenour <[email protected]<mailto:[email protected]>> wrote:
> How do you plan to handle multi-queue devices? Modern devices often > have multiple queues so that they can be used from multiple cores > without any CPU-side synchronization. We haven’t looked at this yet, but I don’t see how this would cause any inherent difficulties. Multiple device queues are logically not different from multiple devices, although they may require per-client de-multiplexing. We’ll look at this later > How do you plan on handling access control? Using a block device > as an example, a client must not be able to perform any requests > to regions of the block storage that it is not authorized to access. > This could either be handled in the multiplexer itself or by having the > multiplexer include an unforgeable client ID with each request sent to > the driver. Also, what are the consequences of a compromised driver? > Will drivers be able to escalate privileges directly, or will the > multiplexer and client libraries enforce some invariants even in this > case? There are multiple standard approaches for access control on storage: - trust your file system – verifying a simple SD file system should be doable - encrypt all data client-side – that’s the storage equivalent of using TLS etc - partition the storage medium – the multiplexer (or, for separation of concerns, a client-side filter component) will drop requests that go to the wrong partition - using a more dynamic scheme with block-level authentication tokens – this is overkill for the static systems we’re after, but might be a model for a dynamic system (eg https://trustworthy.systems/projects/TS/smos/) It shouldn’t be the driver’s job in any case. > Will it be possible for clients to pre-register buffers with the > multiplexer, and for the multiplexer to in turn register them with the > driver? That would allow for devices to DMA directly to client buffers > while still having the IOMMU restricting what the driver can do. > Zero-copy is a main driver of the design, but, keep in mind, this is (presently) for static architectures as needed for IoT/cyberphysical etc. Full zero-copy requires dynamic IOMMU remapping, which is know to be expensive on some platofrms (but not necessarily all). In the first instance we’re likely to use static IOMMU mappings, and use copying where required for security. This is a simple configuration option: optionally insert a copier between server and multiplexer. We’re planning to do a study of IOMMU overheads on recent platforms to driver further design considerations. Note that the results shown by Lucy at the Summit already include client-side copying (to simulate the inefficient Posix interface) – and we still beat Linux by a factor three. So we’ve got some performance headspace. Gernot _______________________________________________ Devel mailing list -- [email protected] To unsubscribe send an email to [email protected]
