On Tue 16-02-21 08:25:39, James Bottomley wrote: > On Mon, 2021-02-15 at 20:20 +0100, Michal Hocko wrote: > [...] > > > > What kind of flags are we talking about and why would that be a > > > > problem with memfd_create interface? Could you be more specific > > > > please? > > > > > > You mean what were the ioctl flags in the patch series linked > > > above? They were SECRETMEM_EXCLUSIVE and SECRETMEM_UNCACHED in > > > patch 3/5. > > > > OK I see. How many potential modes are we talking about? A few or > > potentially many? > > Well I initially thought there were two (uncached or not) until you > came up with the migratable or non-migratable, which affects the > security properties. But now there's also potential for hardware > backing, like mktme, described by flags as well. I do not remember details about mktme but from what I still recall it had keys associated with direct maps. Is the key management something that fits into flags management? > I suppose you could > also use RDT to restrict which cache the data goes into: say L1 but not > L2 on to lessen the impact of fully uncached (although the big thrust > of uncached was to blunt hyperthread side channels). So there is > potential for quite a large expansion even though I'd be willing to bet > that a lot of the modes people have thought about turn out not to be > very effective in the field. Are those very HW specific features really viable through a generic syscall? Don't get me wrong but I find it much more likely somebody will want a hugetlb (pretty HW independent) without a direct map than a very close to the HW caching mode soon. But thanks for the clarification anyway. -- Michal Hocko SUSE Labs
