On Thu, Feb 1, 2024 at 9:00 PM Theo de Raadt <deraadt@xxxxxxxxxxx> wrote: > > Jeff Xu <jeffxu@xxxxxxxxxxxx> wrote: > > > Even without free. > > I personally do not like the heap getting sealed like that. > > > > Component A. > > p=malloc(4096); > > writing something to p. > > > > Component B: > > mprotect(p,4096, RO) > > mseal(p,4096) > > > > This will split the heap VMA, and prevent the heap from shrinking, if > > this is in a frequent code path, then it might hurt the process's > > memory usage. > > > > The existing code is more likely to use malloc than mmap(), so it is > > easier for dev to seal a piece of data belonging to another component. > > I hope this pattern is not wide-spreading. > > > > The ideal way will be just changing the library A to use mmap. > > I think you are lacking some test programs to see how it actually > behaves; the effect is worse than you think, and the impact is immediately > visible to the programmer, and the lesson is clear: > > you can only seal objects which you gaurantee never get recycled. > > Pushing a sealed object back into reuse is a disasterous bug. > > Noone should call this interface, unless they understand that. > > I'll say again, you don't have a test program for various allocators to > understand how it behaves. The failure modes described in your docuemnts > are not correct. > I understand what you mean: I will add that part to the document: Try to recycle a sealed memory is disastrous, e.g. p=malloc(4096); mprotect(p,4096,RO) mseal(p,4096) free(p); My point is: I think sealing an object from the heap is a bad pattern in general, even dev doesn't free it. That was one of the reasons for the sealable flag, I hope saying this doesn't be perceived as looking for excuses. >
