Stuart Henderson <s...@spacehopper.org> wrote: > On 2022/05/22 13:49, Caspar Schutijser wrote: > > I haven't tested this but shouldn't this be HAVE_CALLOC_CONCEAL?
I really don't understand the approach being taken here. The existing code uses mlock. It appears to be using mlock for a privacy reason. But mlock has no privacy reason. The mlock page does not make any privacy or security promises at all. At best it says "This region will be available in direct memory, without having to retrieve it from some (vague) slower memory" It does not say that a copy of this allocation won't go to swap. It also does not say that the contents won't land in coredump. mlock is a weird performance gaurantee system call which noone should actually use (and I want to remove) because it locks resources other processes might require. mlock is apparently being used for a reason that isn't specified or documented. But I want to understand what the goal here is. A subset of memory allocations in one library is being treated this way, for "secrecy" or "privacy". This library is used in a gigantic program which does a ton of other memory allocations, which uses a huge number of other libraries which do a ton of other memory allocations. Does that gigantic program keep track of any other secrets or privacy information in the other memory allocations it makes? Once this diff for this one library goes in, will that huge program and all the libraries it use receive the same attention? I would estimate it will require 10,000+ commits to the whole tree -- base and ports -- if we wanted to actually solve this problem. It won't happen. Unfortunately, our calloc_conceal() is in the same boat. Using it in a few corners of the tree ... feels so ineffective.
