[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 01 Feb 2024 22:00:35 -0700
From: "Theo de Raadt" <deraadt@...nbsd.org>
To: Jeff Xu <jeffxu@...omium.org>
cc: Jeff Xu <jeffxu@...gle.com>,
Linus Torvalds <torvalds@...ux-foundation.org>,
"Liam R. Howlett" <Liam.Howlett@...cle.com>,
Jonathan Corbet <corbet@....net>, akpm@...ux-foundation.org,
keescook@...omium.org, jannh@...gle.com, sroettger@...gle.com,
willy@...radead.org, gregkh@...uxfoundation.org,
usama.anjum@...labora.com, rdunlap@...radead.org,
jorgelo@...omium.org, groeck@...omium.org,
linux-kernel@...r.kernel.org, linux-kselftest@...r.kernel.org,
linux-mm@...ck.org, pedro.falcato@...il.com, dave.hansen@...el.com,
linux-hardening@...r.kernel.org
Subject: Re: [PATCH v8 0/4] Introduce mseal
Jeff Xu <jeffxu@...omium.org> 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.
Powered by blists - more mailing lists