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.