On Thu, Feb 11, 2021 at 01:30:42PM +0100, Michal Hocko wrote: > On Thu 11-02-21 13:20:08, Mike Rapoport wrote: > [...] > > Sealing is anyway controlled via fcntl() and I don't think > > MFD_ALLOW_SEALING makes much sense for the secretmem because it is there to > > prevent rogue file sealing in tmpfs/hugetlbfs. > > This doesn't really match my understanding. The primary usecase for the > sealing is to safely and predictably coordinate over shared memory. I > absolutely do not see why this would be incompatible with an additional > requirement to unmap the memory from the kernel to prevent additional > interference from the kernel side. Quite contrary it looks like a very > nice extension to this model. I didn't mean that secretmem should not support sealing. I meant that MFD_ALLOW_SEALING flag does not make sense. Unlike tmpfs, the secretmem fd does not need protection from somebody unexpectedly sealing it. > > As for the huge pages, I'm not sure at all that supporting huge pages in > > secretmem will involve hugetlbfs. > > Have a look how hugetlb proliferates through our MM APIs. I strongly > suspect this is strong signal that this won't be any different. > > > And even if yes, adding SECRETMEM_HUGE > > flag seems to me less confusing than saying "from kernel x.y you can use > > MFD_CREATE | MFD_SECRET | MFD_HUGE" etc for all possible combinations. > > I really fail to see your point. This is a standard model we have. It is > quite natural that flags are added. Moreover adding a new syscall will > not make it any less of a problem. Nowadays adding a new syscall is not as costly as it used to be. And I think it'll provide better extensibility when new features would be added to secretmem. For instance, for creating a secretmem fd backed with sealing we'd have memfd_secretm(SECRETMEM_HUGE); rather than memfd_create(MFD_ALLOW_SEALING | MFD_HUGETLB | MFD_SECRET); Besides, if we overload memfd_secret we add complexity to flags validation of allowable flag combinations even with the simplest initial implementation. And what it will become when more features are added to secretmem? > > > I by no means do not insist one way or the other but from what I have > > > seen so far I have a feeling that the interface hasn't been thought > > > through enough. > > > > It has been, but we have different thoughts about it ;-) > > Then you must be carrying a lot of implicit knowledge which I want you > to document. I don't have any implicit knowledge, we just have a different perspective. -- Sincerely yours, Mike.
