Regarding these pieces
> The PROT_SEAL bit in prot field of mmap(). When present, it marks
> the map sealed since creation.
OpenBSD won't be doing this. I had PROT_IMMUTABLE as a draft. In my
research I found basically zero circumstances when you userland does
that. The most common circumstance is you create a RW mapping, fill it,
and then change to a more restrictve mapping, and lock it.
There are a few regions in the addressspace that can be locked while RW.
For instance, the stack. But the kernel does that, not userland. I
found regions where the kernel wants to do this to the address space,
but there is no need to export useless functionality to userland.
OpenBSD now uses this for a high percent of the address space. It might
be worth re-reading a description of the split of responsibility regarding
who locks different types of memory in a process;
- kernel (the majority, based upon what ELF layout tell us),
- shared library linker (the next majority, dealing with shared
library mappings and left-overs not determinable at kernel time),
- libc (a small minority, mostly regarding forced mutable objects)
- and the applications themselves (only 1 application today)
https://lwn.net/Articles/915662/
> The MAP_SEALABLE bit in the flags field of mmap(). When present, it marks
> the map as sealable. A map created without MAP_SEALABLE will not support
> sealing, i.e. mseal() will fail.
We definately won't be doing this. We allow a process to lock any and all
it's memory that isn't locked already, even if it means it is shooting
itself in the foot.
I think you are going to severely hurt the power of this mechanism,
because you won't be able to lock memory that has been allocated by a
different callsite not under your source-code control which lacks the
MAP_SEALABLE flag. (Which is extremely common with the system-parts of
a process, meaning not just libc but kernel allocated objects).
It may be fine inside a program like chrome, but I expect that flag to make
it harder to use in libc, and it will hinder adoption.
On Mon, Jan 22, 2024 at 7:49 AM Theo de Raadt <[email protected]> wrote:
>
> Regarding these pieces
>
> > The PROT_SEAL bit in prot field of mmap(). When present, it marks
> > the map sealed since creation.
>
> OpenBSD won't be doing this. I had PROT_IMMUTABLE as a draft. In my
> research I found basically zero circumstances when you userland does
> that. The most common circumstance is you create a RW mapping, fill it,
> and then change to a more restrictve mapping, and lock it.
>
> There are a few regions in the addressspace that can be locked while RW.
> For instance, the stack. But the kernel does that, not userland. I
> found regions where the kernel wants to do this to the address space,
> but there is no need to export useless functionality to userland.
>
I have a feeling that most apps that need to use mmap() in their code
are likely using RW mappings. Adding sealing to mmap() could stop
those mappings from being executable. Of course, those apps would
need to change their code. We can't do it for them.
Also, I believe adding this to mmap() has no downsides, only
performance gain, as Pedro Falcato pointed out in [1].
[1] https://lore.kernel.org/lkml/CAKbZUD2A+=bp_sd+Q0Yif7NJqMu8p__eb4yguq0agEcmLH8SDQ@mail.gmail.com/
> OpenBSD now uses this for a high percent of the address space. It might
> be worth re-reading a description of the split of responsibility regarding
> who locks different types of memory in a process;
> - kernel (the majority, based upon what ELF layout tell us),
> - shared library linker (the next majority, dealing with shared
> library mappings and left-overs not determinable at kernel time),
> - libc (a small minority, mostly regarding forced mutable objects)
> - and the applications themselves (only 1 application today)
>
> https://lwn.net/Articles/915662/
>
> > The MAP_SEALABLE bit in the flags field of mmap(). When present, it marks
> > the map as sealable. A map created without MAP_SEALABLE will not support
> > sealing, i.e. mseal() will fail.
>
> We definately won't be doing this. We allow a process to lock any and all
> it's memory that isn't locked already, even if it means it is shooting
> itself in the foot.
>
> I think you are going to severely hurt the power of this mechanism,
> because you won't be able to lock memory that has been allocated by a
> different callsite not under your source-code control which lacks the
> MAP_SEALABLE flag. (Which is extremely common with the system-parts of
> a process, meaning not just libc but kernel allocated objects).
>
MAP_SEALABLE was an open discussion item called out on V3 [2] and V4 [3].
I acknowledge that additional coordination would be required if
mapping were to be allocated by one software component and sealed in
another. However, this is feasible.
Considering the side effect of not having this flag (as discussed in
V3/V4) and the significant implications of altering the lifetime of
the mapping (since unmapping would not be possible), I believe it is
reasonable to expect developers to exercise additional care and
caution when utilizing memory sealing.
[2] https://lore.kernel.org/linux-mm/[email protected]/
[3] https://lore.kernel.org/all/[email protected]/
> It may be fine inside a program like chrome, but I expect that flag to make
> it harder to use in libc, and it will hinder adoption.
>
In the case of glibc and linux, as stated in the cover letter, Stephen
is working on a change to glibc to add sealing support to the dynamic
linker, also I plan to make necessary code changes in the linux kernel.
Jeff Xu <[email protected]> wrote:
> On Mon, Jan 22, 2024 at 7:49 AM Theo de Raadt <[email protected]> wrote:
> >
> > Regarding these pieces
> >
> > > The PROT_SEAL bit in prot field of mmap(). When present, it marks
> > > the map sealed since creation.
> >
> > OpenBSD won't be doing this. I had PROT_IMMUTABLE as a draft. In my
> > research I found basically zero circumstances when you userland does
> > that. The most common circumstance is you create a RW mapping, fill it,
> > and then change to a more restrictve mapping, and lock it.
> >
> > There are a few regions in the addressspace that can be locked while RW.
> > For instance, the stack. But the kernel does that, not userland. I
> > found regions where the kernel wants to do this to the address space,
> > but there is no need to export useless functionality to userland.
> >
> I have a feeling that most apps that need to use mmap() in their code
> are likely using RW mappings. Adding sealing to mmap() could stop
> those mappings from being executable. Of course, those apps would
> need to change their code. We can't do it for them.
I don't have a feeling about it.
I spent a year engineering a complete system which exercises the maximum
amount of memory you can lock.
I saw nothing like what you are describing. I had PROT_IMMUTABLE in my
drafts, and saw it turning into a dangerous anti-pattern.
> Also, I believe adding this to mmap() has no downsides, only
> performance gain, as Pedro Falcato pointed out in [1].
>
> [1] https://lore.kernel.org/lkml/CAKbZUD2A+=bp_sd+Q0Yif7NJqMu8p__eb4yguq0agEcmLH8SDQ@mail.gmail.com/
Are you joking? You don't have any code doing that today. More feelings?
OpenBSD userland has zero places it can use mmap() MAP_IMMUTABLE.
It has two places where it has mprotect() + mimmutable() adjacent to each
other, two codepaths for late mprotect() of RELRO, and then make the RELRO
immutable.
I think this idea is a premature optimization, and intentionally incompatible.
Like I say, I had a similar MAP_ flag for mprotect() and mmap() in my
development trees, and I recognized it was pointless, distracting developers
into the wrong patterns, and I threw it out.
> > OpenBSD now uses this for a high percent of the address space. It might
> > be worth re-reading a description of the split of responsibility regarding
> > who locks different types of memory in a process;
> > - kernel (the majority, based upon what ELF layout tell us),
> > - shared library linker (the next majority, dealing with shared
> > library mappings and left-overs not determinable at kernel time),
> > - libc (a small minority, mostly regarding forced mutable objects)
> > - and the applications themselves (only 1 application today)
> >
> > https://lwn.net/Articles/915662/
> >
> > > The MAP_SEALABLE bit in the flags field of mmap(). When present, it marks
> > > the map as sealable. A map created without MAP_SEALABLE will not support
> > > sealing, i.e. mseal() will fail.
> >
> > We definately won't be doing this. We allow a process to lock any and all
> > it's memory that isn't locked already, even if it means it is shooting
> > itself in the foot.
> >
> > I think you are going to severely hurt the power of this mechanism,
> > because you won't be able to lock memory that has been allocated by a
> > different callsite not under your source-code control which lacks the
> > MAP_SEALABLE flag. (Which is extremely common with the system-parts of
> > a process, meaning not just libc but kernel allocated objects).
> >
> MAP_SEALABLE was an open discussion item called out on V3 [2] and V4 [3].
>
> I acknowledge that additional coordination would be required if
> mapping were to be allocated by one software component and sealed in
> another. However, this is feasible.
>
> Considering the side effect of not having this flag (as discussed in
> V3/V4) and the significant implications of altering the lifetime of
> the mapping (since unmapping would not be possible), I believe it is
> reasonable to expect developers to exercise additional care and
> caution when utilizing memory sealing.
>
> [2] https://lore.kernel.org/linux-mm/[email protected]/
> [3] https://lore.kernel.org/all/[email protected]/
I disagree *strongly*. Developers need to exercise additional care on
memory, period. Memory sealing issues is the least of their worries.
(Except for handling RELRO, but only the ld.so developers will lose
their hair).
OK, so mseal and mimmutable are very different.
mimmutable can be used by any developer on the address space easily.
mseal requires control of the whole stack between allocation and consumption.
I'm sorry, but I don't think you understand how dangerous this MAP_SEALABLE
proposal is because of the difficulties it will create for use.
The immutable memory management we have today in OpenBSD would completely
impossible with such a flag. Seperation between allocator (that doesn't know
what is going to happen), and consumer (that does know), is completely common
in the systems environment (meaning the interaction between DSO, libc, other
libraries, and the underside of applications).
This is not not like an application where you can simply sprinkle the flag
into the mmap() calls that cause you problems. That mmap() call is now in
someone else's code, and you CANNOT gain security advantage unless you
convince them to gain an understanding of what that flag means -- and it is
a flag that other Linux variants don't have, not even in their #include
files.
> > It may be fine inside a program like chrome, but I expect that flag to make
> > it harder to use in libc, and it will hinder adoption.
> >
> In the case of glibc and linux, as stated in the cover letter, Stephen
> is working on a change to glibc to add sealing support to the dynamic
> linker, also I plan to make necessary code changes in the linux kernel.
How will ld.so seal memory which the kernel mapped? The kernel will now
automatically puts MAP_SEALABLE on the text segment and stack? Why not
put it on all mmap() allocations? Why not just skip the flag entirely?
To me, this is all very bizzare.
I don't understand what the MAP_SEALABLE flag is trying to solve.
* Theo de Raadt <[email protected]> [240122 17:35]:
> Jeff Xu <[email protected]> wrote:
>
> > On Mon, Jan 22, 2024 at 7:49 AM Theo de Raadt <[email protected]> wrote:
> > >
> > > Regarding these pieces
> > >
> > > > The PROT_SEAL bit in prot field of mmap(). When present, it marks
> > > > the map sealed since creation.
> > >
> > > OpenBSD won't be doing this. I had PROT_IMMUTABLE as a draft. In my
> > > research I found basically zero circumstances when you userland does
> > > that. The most common circumstance is you create a RW mapping, fill it,
> > > and then change to a more restrictve mapping, and lock it.
> > >
> > > There are a few regions in the addressspace that can be locked while RW.
> > > For instance, the stack. But the kernel does that, not userland. I
> > > found regions where the kernel wants to do this to the address space,
> > > but there is no need to export useless functionality to userland.
> > >
> > I have a feeling that most apps that need to use mmap() in their code
> > are likely using RW mappings. Adding sealing to mmap() could stop
> > those mappings from being executable. Of course, those apps would
> > need to change their code. We can't do it for them.
>
> I don't have a feeling about it.
>
> I spent a year engineering a complete system which exercises the maximum
> amount of memory you can lock.
>
> I saw nothing like what you are describing. I had PROT_IMMUTABLE in my
> drafts, and saw it turning into a dangerous anti-pattern.
>
> > Also, I believe adding this to mmap() has no downsides, only
> > performance gain, as Pedro Falcato pointed out in [1].
> >
> > [1] https://lore.kernel.org/lkml/CAKbZUD2A+=bp_sd+Q0Yif7NJqMu8p__eb4yguq0agEcmLH8SDQ@mail.gmail.com/
>
> Are you joking? You don't have any code doing that today. More feelings?
The 'no downside" is to combining two calls together; mmap() & mseal(),
at least that is how I read the linked discussion.
The common case (since there are no users today) of just calling
mmap()/munmap() will have the downside.
There will be a performance impact once you have can_modify_mm() doing
more than just returning true. Certainly, the impact will be larger
in munmap where multiple VMAs may need to be checked (assuming that's
the plan?).
This will require a new and earlier walk of the vma tree while holding
the mmap_lock. Since you are checking (potentially multiple) VMAs for
something, I don't think there is a way around holding the lock.
I'm not saying the cost will be large, but it will be a positive
non-zero number.
Thanks,
Liam
Liam R. Howlett <[email protected]> wrote:
> * Theo de Raadt <[email protected]> [240122 17:35]:
> > Jeff Xu <[email protected]> wrote:
> >
> > > On Mon, Jan 22, 2024 at 7:49 AM Theo de Raadt <[email protected]> wrote:
> > > >
> > > > Regarding these pieces
> > > >
> > > > > The PROT_SEAL bit in prot field of mmap(). When present, it marks
> > > > > the map sealed since creation.
> > > >
> > > > OpenBSD won't be doing this. I had PROT_IMMUTABLE as a draft. In my
> > > > research I found basically zero circumstances when you userland does
> > > > that. The most common circumstance is you create a RW mapping, fill it,
> > > > and then change to a more restrictve mapping, and lock it.
> > > >
> > > > There are a few regions in the addressspace that can be locked while RW.
> > > > For instance, the stack. But the kernel does that, not userland. I
> > > > found regions where the kernel wants to do this to the address space,
> > > > but there is no need to export useless functionality to userland.
> > > >
> > > I have a feeling that most apps that need to use mmap() in their code
> > > are likely using RW mappings. Adding sealing to mmap() could stop
> > > those mappings from being executable. Of course, those apps would
> > > need to change their code. We can't do it for them.
> >
> > I don't have a feeling about it.
> >
> > I spent a year engineering a complete system which exercises the maximum
> > amount of memory you can lock.
> >
> > I saw nothing like what you are describing. I had PROT_IMMUTABLE in my
> > drafts, and saw it turning into a dangerous anti-pattern.
> >
> > > Also, I believe adding this to mmap() has no downsides, only
> > > performance gain, as Pedro Falcato pointed out in [1].
> > >
> > > [1] https://lore.kernel.org/lkml/CAKbZUD2A+=bp_sd+Q0Yif7NJqMu8p__eb4yguq0agEcmLH8SDQ@mail.gmail.com/
> >
> > Are you joking? You don't have any code doing that today. More feelings?
>
> The 'no downside" is to combining two calls together; mmap() & mseal(),
> at least that is how I read the linked discussion.
>
> The common case (since there are no users today) of just calling
> mmap()/munmap() will have the downside.
>
> There will be a performance impact once you have can_modify_mm() doing
> more than just returning true. Certainly, the impact will be larger
> in munmap where multiple VMAs may need to be checked (assuming that's
> the plan?).
>
> This will require a new and earlier walk of the vma tree while holding
> the mmap_lock. Since you are checking (potentially multiple) VMAs for
> something, I don't think there is a way around holding the lock.
>
> I'm not saying the cost will be large, but it will be a positive
> non-zero number.
For future glibc changes, I predict you will have zero cases where you
can call mmap+immutable or mprotect+immutable, I say so, because I ended
up having none. You always have to fill the memory. (At first glance
you might think it works for a new DSO's BSS, but RELRO overlaps it, and
since RELRO mprotect happens quite late, the permission locking is quite
delayed relative to the allocation).
I think chrome also won't lock memory at allocation. I suspect the
generic allocator is quite seperate from the code using the allocation,
which knows which objects can have their permissions locked and which
objects can't.
In OpenBSD, the only cases where we could set immutable at the same time
as creating the mapping was in execve, for a new process's stack regions,
and that is kernel code, not the userland exposed system call APIs.
This change could skip adding PROT_MSEAL today, and add it later when
there are facts the need.
It's the same with MAP_MSEALABLE. I don't get it. So now there are 3
memory types:
- cannot be sealed, ever
- not yet sealed
- sealed
What purpose does the first type serve? Please explain the use case.
Today, processes have control over their entire address space.
What is the purpose of "permissions cannot be locked". Please supply
an example. If I am wrong, I'd like to know where I went wrong.
On Mon, Jan 22, 2024 at 2:34 PM Theo de Raadt <[email protected]> wrote:
>
> Jeff Xu <[email protected]> wrote:
>
> > On Mon, Jan 22, 2024 at 7:49 AM Theo de Raadt <[email protected]> wrote:
> > >
> > > Regarding these pieces
> > >
> > > > The PROT_SEAL bit in prot field of mmap(). When present, it marks
> > > > the map sealed since creation.
> > >
> > > OpenBSD won't be doing this. I had PROT_IMMUTABLE as a draft. In my
> > > research I found basically zero circumstances when you userland does
> > > that. The most common circumstance is you create a RW mapping, fill it,
> > > and then change to a more restrictve mapping, and lock it.
> > >
> > > There are a few regions in the addressspace that can be locked while RW.
> > > For instance, the stack. But the kernel does that, not userland. I
> > > found regions where the kernel wants to do this to the address space,
> > > but there is no need to export useless functionality to userland.
> > >
> > I have a feeling that most apps that need to use mmap() in their code
> > are likely using RW mappings. Adding sealing to mmap() could stop
> > those mappings from being executable. Of course, those apps would
> > need to change their code. We can't do it for them.
>
> I don't have a feeling about it.
>
> I spent a year engineering a complete system which exercises the maximum
> amount of memory you can lock.
>
> I saw nothing like what you are describing. I had PROT_IMMUTABLE in my
> drafts, and saw it turning into a dangerous anti-pattern.
>
I'm sorry, I have never looked at one line of openBSD code, prototype
or not, nor did I install openBSD before.
Because of this situation on my side, I failed to understand why you
have such a strong opinion on PROC_SEAL in mmap() in linux kernel,
based on your own OpenBSD's experience ?
For PROT_SEAL in mmap(), I see it as a good and reasonable suggestion
raised during the RFC process, and incorporate it into the patch set,
there is nothing more and nothing less.
If openBSD doesn't want it, that is fine to me, it is not that I'm
trying to force this into openBSD's kernel, I understand it is a
different code base.
> > Also, I believe adding this to mmap() has no downsides, only
> > performance gain, as Pedro Falcato pointed out in [1].
> >
> > [1] https://lore.kernel.org/lkml/CAKbZUD2A+=bp_sd+Q0Yif7NJqMu8p__eb4yguq0agEcmLH8SDQ@mail.gmail.com/
>
> Are you joking? You don't have any code doing that today. More feelings?
>
> OpenBSD userland has zero places it can use mmap() MAP_IMMUTABLE.
>
> It has two places where it has mprotect() + mimmutable() adjacent to each
> other, two codepaths for late mprotect() of RELRO, and then make the RELRO
> immutable.
>
> I think this idea is a premature optimization, and intentionally incompatible.
>
> Like I say, I had a similar MAP_ flag for mprotect() and mmap() in my
> development trees, and I recognized it was pointless, distracting developers
> into the wrong patterns, and I threw it out.
>
> > > OpenBSD now uses this for a high percent of the address space. It might
> > > be worth re-reading a description of the split of responsibility regarding
> > > who locks different types of memory in a process;
> > > - kernel (the majority, based upon what ELF layout tell us),
> > > - shared library linker (the next majority, dealing with shared
> > > library mappings and left-overs not determinable at kernel time),
> > > - libc (a small minority, mostly regarding forced mutable objects)
> > > - and the applications themselves (only 1 application today)
> > >
> > > https://lwn.net/Articles/915662/
> > >
> > > > The MAP_SEALABLE bit in the flags field of mmap(). When present, it marks
> > > > the map as sealable. A map created without MAP_SEALABLE will not support
> > > > sealing, i.e. mseal() will fail.
> > >
> > > We definately won't be doing this. We allow a process to lock any and all
> > > it's memory that isn't locked already, even if it means it is shooting
> > > itself in the foot.
> > >
> > > I think you are going to severely hurt the power of this mechanism,
> > > because you won't be able to lock memory that has been allocated by a
> > > different callsite not under your source-code control which lacks the
> > > MAP_SEALABLE flag. (Which is extremely common with the system-parts of
> > > a process, meaning not just libc but kernel allocated objects).
> > >
> > MAP_SEALABLE was an open discussion item called out on V3 [2] and V4 [3].
> >
> > I acknowledge that additional coordination would be required if
> > mapping were to be allocated by one software component and sealed in
> > another. However, this is feasible.
> >
> > Considering the side effect of not having this flag (as discussed in
> > V3/V4) and the significant implications of altering the lifetime of
> > the mapping (since unmapping would not be possible), I believe it is
> > reasonable to expect developers to exercise additional care and
> > caution when utilizing memory sealing.
> >
> > [2] https://lore.kernel.org/linux-mm/[email protected]/
> > [3] https://lore.kernel.org/all/20240104185138.169307-1-jeffxu@chromiumorg/
>
> I disagree *strongly*. Developers need to exercise additional care on
> memory, period. Memory sealing issues is the least of their worries.
>
> (Except for handling RELRO, but only the ld.so developers will lose
> their hair).
>
>
> OK, so mseal and mimmutable are very different.
>
> mimmutable can be used by any developer on the address space easily.
>
> mseal requires control of the whole stack between allocation and consumption.
>
> I'm sorry, but I don't think you understand how dangerous this MAP_SEALABLE
> proposal is because of the difficulties it will create for use.
>
> The immutable memory management we have today in OpenBSD would completely
> impossible with such a flag. Seperation between allocator (that doesn't know
> what is going to happen), and consumer (that does know), is completely common
> in the systems environment (meaning the interaction between DSO, libc, other
> libraries, and the underside of applications).
>
> This is not not like an application where you can simply sprinkle the flag
> into the mmap() calls that cause you problems. That mmap() call is now in
> someone else's code, and you CANNOT gain security advantage unless you
> convince them to gain an understanding of what that flag means -- and it is
> a flag that other Linux variants don't have, not even in their #include
> files.
>
I respect your reasoning with OpenBSD, but do you have a real example
that this will be problematic for linux ?
In my opinion, the extra communication part with mmap()'s owner has
its pros and cons.
The cons is what you mentioned: extra time for convincing and approval.
The pro is that there won't be unexpected behavior from the code owner
point of view, once this communication process is completed. It can
reduce the possibility of introducing bugs.
So far, I do not have enough information to say this is a bad idea.
if you can provide a real example in the context of linux, e.g. DSO
and libc you mentioned with details, that will be helpful.
On Tue, Jan 23, 2024 at 10:58 AM Theo de Raadt <[email protected]> wrote:
>
> It's the same with MAP_MSEALABLE. I don't get it. So now there are 3
> memory types:
> - cannot be sealed, ever
> - not yet sealed
> - sealed
>
> What purpose does the first type serve? Please explain the use case.
>
> Today, processes have control over their entire address space.
>
> What is the purpose of "permissions cannot be locked". Please supply
> an example. If I am wrong, I'd like to know where I went wrong.
>
The linux example is in the V3 and V4 cover letter [1] [2] of the open
discussion section.
[1] https://lore.kernel.org/linux-mm/[email protected]/T/
[2] https://lore.kernel.org/linux-mm/[email protected]/T/
Copied below for ease of reading.
-----------------------------------------------------------------------------------------
During the development of V3, I had new questions and thoughts and
wished to discuss.
1> shm/aio
From reading the code, it seems to me that aio/shm can mmap/munmap
maps on behalf of userspace, e.g. ksys_shmdt() in shm.c. The lifetime
of those mapping are not tied to the lifetime of the process. If those
memories are sealed from userspace, then unmap will fail. This isn’t a
huge problem, since the memory will eventually be freed at exit or
exec. However, it feels like the solution is not complete, because of
the leaks in VMA address space during the lifetime of the process.
2> Brk (heap/stack)
Currently, userspace applications can seal parts of the heap by
calling malloc() and mseal(). This raises the question of what the
expected behavior is when sealing the heap is attempted.
let's assume following calls from user space:
ptr = malloc(size);
mprotect(ptr, size, RO);
mseal(ptr, size, SEAL_PROT_PKEY);
free(ptr);
Technically, before mseal() is added, the user can change the
protection of the heap by calling mprotect(RO). As long as the user
changes the protection back to RW before free(), the memory can be
reused.
Adding mseal() into picture, however, the heap is then sealed
partially, user can still free it, but the memory remains to be RO,
and the result of brk-shrink is nondeterministic, depending on if
munmap() will try to free the sealed memory.(brk uses munmap to shrink
the heap).
3> Above two cases led to the third topic:
There one option to address the problem mentioned above.
Option 1: A “MAP_SEALABLE” flag in mmap().
If a map is created without this flag, the mseal() operation will
fail. Applications that are not concerned with sealing will expect
their behavior to be unchanged. For those that are concerned, adding a
flag at mmap time to opt in is not difficult. For the short term, this
solves problems 1 and 2 above. The memory in shm/aio/brk will not have
the MAP_SEALABLE flag at mmap(), and the same is true for the heap.
If we choose not to go with path, all mapping will by default
sealable. We could document above mentioned limitations so devs are
more careful at the time to choose what memory to seal. I think
deny of service through mseal() by attacker is probably not a concern,
if attackers have access to mseal() and unsealed memory, then they can
also do other harmful thing to the memory, such as munmap, etc.
4>
I think it might be possible to seal the stack or other special
mappings created at runtime (vdso, vsyscall, vvar). This means we can
enforce and seal W^X for certain types of application. For instance,
the stack is typically used in read-write mode, but in some cases, it
can become executable. To defend against unintented addition of
executable bit to stack, we could let the application to seal it.
Sealing the heap (for adding X) requires special handling, since the
heap can shrink, and shrink is implemented through munmap().
Indeed, it might be possible that all virtual memory accessible to user
space, regardless of its usage pattern, could be sealed. However, this
would require additional research and development work.
-----------------------------------------------------------------------------------------------------
Jeff Xu <[email protected]> wrote:
> > I don't have a feeling about it.
> >
> > I spent a year engineering a complete system which exercises the maximum
> > amount of memory you can lock.
> >
> > I saw nothing like what you are describing. I had PROT_IMMUTABLE in my
> > drafts, and saw it turning into a dangerous anti-pattern.
> >
> I'm sorry, I have never looked at one line of openBSD code, prototype
> or not, nor did I install openBSD before.
That is really disingeneous.
It is obvious to everyone that mseal is a derivative of the mimmutable
mechanism, the raw idea stems directly from this and you didn't need to
stay at a Holiday Express Inn.
> Because of this situation on my side, I failed to understand why you
> have such a strong opinion on PROC_SEAL in mmap() in linux kernel,
> based on your own OpenBSD's experience ?
Portable and compatible interfaces are good.
Historically, incompatible interfaces are less good.
> For PROT_SEAL in mmap(), I see it as a good and reasonable suggestion
> raised during the RFC process, and incorporate it into the patch set,
> there is nothing more and nothing less.
Yet, you and those who suggested it don't have a single line of userland
code ready which will use this.
> If openBSD doesn't want it, that is fine to me, it is not that I'm
> trying to force this into openBSD's kernel, I understand it is a
> different code base.
This has nothing to do with code base.
It is about attempting to decrease differences between systems; this
approach which has always been valuable.
Divergence has always been painful.
> > > > OpenBSD now uses this for a high percent of the address space. It might
> > > > be worth re-reading a description of the split of responsibility regarding
> > > > who locks different types of memory in a process;
> > > > - kernel (the majority, based upon what ELF layout tell us),
> > > > - shared library linker (the next majority, dealing with shared
> > > > library mappings and left-overs not determinable at kernel time),
> > > > - libc (a small minority, mostly regarding forced mutable objects)
> > > > - and the applications themselves (only 1 application today)
> > > >
> > > > https://lwn.net/Articles/915662/
> > > >
> > > > > The MAP_SEALABLE bit in the flags field of mmap(). When present, it marks
> > > > > the map as sealable. A map created without MAP_SEALABLE will not support
> > > > > sealing, i.e. mseal() will fail.
> > > >
> > > > We definately won't be doing this. We allow a process to lock any and all
> > > > it's memory that isn't locked already, even if it means it is shooting
> > > > itself in the foot.
> > > >
> > > > I think you are going to severely hurt the power of this mechanism,
> > > > because you won't be able to lock memory that has been allocated by a
> > > > different callsite not under your source-code control which lacks the
> > > > MAP_SEALABLE flag. (Which is extremely common with the system-parts of
> > > > a process, meaning not just libc but kernel allocated objects).
> > > >
> > > MAP_SEALABLE was an open discussion item called out on V3 [2] and V4 [3].
> > >
> > > I acknowledge that additional coordination would be required if
> > > mapping were to be allocated by one software component and sealed in
> > > another. However, this is feasible.
> > >
> > > Considering the side effect of not having this flag (as discussed in
> > > V3/V4) and the significant implications of altering the lifetime of
> > > the mapping (since unmapping would not be possible), I believe it is
> > > reasonable to expect developers to exercise additional care and
> > > caution when utilizing memory sealing.
> > >
> > > [2] https://lore.kernel.org/linux-mm/[email protected]/
> > > [3] https://lore.kernel.org/all/[email protected]/
> >
> > I disagree *strongly*. Developers need to exercise additional care on
> > memory, period. Memory sealing issues is the least of their worries.
> >
> > (Except for handling RELRO, but only the ld.so developers will lose
> > their hair).
> >
> >
> > OK, so mseal and mimmutable are very different.
> >
> > mimmutable can be used by any developer on the address space easily.
> >
> > mseal requires control of the whole stack between allocation and consumption.
> >
> > I'm sorry, but I don't think you understand how dangerous this MAP_SEALABLE
> > proposal is because of the difficulties it will create for use.
> >
> > The immutable memory management we have today in OpenBSD would completely
> > impossible with such a flag. Seperation between allocator (that doesn't know
> > what is going to happen), and consumer (that does know), is completely common
> > in the systems environment (meaning the interaction between DSO, libc, other
> > libraries, and the underside of applications).
> >
> > This is not not like an application where you can simply sprinkle the flag
> > into the mmap() calls that cause you problems. That mmap() call is now in
> > someone else's code, and you CANNOT gain security advantage unless you
> > convince them to gain an understanding of what that flag means -- and it is
> > a flag that other Linux variants don't have, not even in their #include
> > files.
> >
> I respect your reasoning with OpenBSD, but do you have a real example
> that this will be problematic for linux ?
See below.
> In my opinion, the extra communication part with mmap()'s owner has
> its pros and cons.
See below.
> The cons is what you mentioned: extra time for convincing and approval.
No, it is much worse than that. See below.
> The pro is that there won't be unexpected behavior from the code owner
> point of view, once this communication process is completed. It can
> reduce the possibility of introducing bugs.
>
> So far, I do not have enough information to say this is a bad idea.
> if you can provide a real example in the context of linux, e.g. DSO
> and libc you mentioned with details, that will be helpful.
Does the kernel map the main program's text segment, data segment, bss
segment, and stack with MAP_SEALABLE or without MAP_SEALABLE?
Once it is mapped, userland starts running.
If those objects don't have MAP_SEALABLE, then ld.so and libc cannot
perform locking of those mappings. And ld.so or libc must do some of
those lockings later, some of these map lockings cannot be performed in
the kernel because userland makes data modifications and permission modifications
before proceeding into main().
This is unavoidable, because of RELRO; binaries with text relocation; binaries
with W|X mappings; it is probably required for IFUNC setup; and I strongly
suspect there are additional circumstances which require this, *just for glibc*
to use the mechanism.
If the kernel does map those regions with MAP_SEALABLE, then it seems
the most important parts of the address space are going to have MAP_SEALABLE
anyways. So what were you trying to defend against?
So why are you doing this MAP_SEALABLE dance? It makes no sense.
I'm sorry, but it is you who must justify these strange semantics which
you are introducing -- to change a mechanism previously engineered and
fully deployed in another operating system. To me, not being able to
justify these behavious seems to be based on intentional ignorance.
"Not Invented Here", is what I see.
You say glibc will use this. I call bollocks. I see a specific behaviour
which will prevent use by glibc. I designed my mechanism with libc specifically
considered -- it was a whole system environment.
You work on chrome. You don't work on glibc. The glibc people aren't publically
talking about this. From my perspective, this is looking really dumb.