[openib-general] Re: mthca FMR correctness (and memory windows)

[Caitlin Bestler]

openib-general-bounces at openib.org wrote:
> On 3/21/06, Michael S. Tsirkin <mst at mellanox.co.il> wrote:
>> Quoting Fabian Tillier <ftillier at silverstorm.com>:
>>> I'd still be interested in seeing regular registration calls
>>> improved, as it's clear that an application that is sensitive about
>>> its security must either restrict itself to send/recv, buffer the
>>> data (data copy overhead), or register/unregister for each I/O.
>> 
>> I guess regular registration calls could be improved, but the
>> benefit is not all that obvious. 
>> 
>> Which applications do register/unregister for each I/O?
> 
> I think if register/unregister wasn't so painfully slow, a
> lot more applications would do it.  It's the most secure, and
> unlike memory windows, supports scatter gather.
> 
> There was enough people who wanted to register on the fly
> that Mellanox invented their FMR implementation - regular
> registration wasn't cutting it.  Otherwise, why would there be a need
> for it? 
> 
> The problem with the mthca FMRs is that they're still
> insecure, on par with the full frontal DMA MR from a security
> standpoint.  Anyone worried about security is stuck with good
> old regular registration, or memory windows.
> 
> - Fab


the point of a memory window is that it is an alias for
a slice of memory that is already registered, subsetting
by address range and/or access permissions. As such the
subsetting request can be taken in an unsecure work request
on the fast path directly from a non-privileged user. Since
they are only creating an alias for a subset of the access
rights already established there is no need for involvement
of a privileged agent -- hence it can be lightweight.

Memory registration will *always* cost more, because it
MUST involve a privileged intermediary who can vouch for
ownership of the registered memory.

And all applications *should* worry about memory, and the
API needs to support those applications with reasonable
options -- those include memory windows and FMR work
requests. Forcing applications to chose between painful
memory registration and security is a dead-end that must
be avoided.