Jeff Xu wrote:
> > Jeff - mind changing the EACESS to EPERM, and we'll have something
> > that is more-or-less compatible between Linux and OpenBSD?
> >
> Sounds Good. I will make the necessary changes in the next version.
Thanks! That is so awesome!
On the OpenBSD side, I am close to landing
On Sat, Jan 20, 2024 at 8:40 AM Linus Torvalds
wrote:
>
> On Sat, 20 Jan 2024 at 07:23, Theo de Raadt wrote:
> >
> > There is an one large difference remainig between mimmutable() and mseal(),
> > which is how other system calls behave.
> >
> > We return EPERM for failures in all the system calls
Linus Torvalds wrote:
> On Sat, 20 Jan 2024 at 07:23, Theo de Raadt wrote:
> >
> > There is an one large difference remainig between mimmutable() and mseal(),
> > which is how other system calls behave.
> >
> > We return EPERM for failures in all the system calls that fail upon
> > immutable mem
On Sat, 20 Jan 2024 at 07:23, Theo de Raadt wrote:
>
> There is an one large difference remainig between mimmutable() and mseal(),
> which is how other system calls behave.
>
> We return EPERM for failures in all the system calls that fail upon
> immutable memory (since Oct 2022).
>
> You are retu
Some notes about compatibility between mimmutable(2) and mseal().
This morning, the "RW -> R demotion" code in mimmutable(2) was removed.
As described previously, that was a development crutch to solved a problem
but we found a better way with a new ELF section which is available at
compile time w
On Thu, Dec 14, 2023 at 12:14 PM Linus Torvalds
wrote:
>
> On Thu, 14 Dec 2023 at 10:07, Stephen Röttger wrote:
> >
> > AIUI, the madvise(DONTNEED) should effectively only change the content of
> > anonymous pages, i.e. it's similar to a memset(0) in that case. That's why
> > we
> > added this s
On Thu, 14 Dec 2023 at 10:07, Stephen Röttger wrote:
>
> AIUI, the madvise(DONTNEED) should effectively only change the content of
> anonymous pages, i.e. it's similar to a memset(0) in that case. That's why we
> added this special case: if you want to madvise(DONTNEED) an anonymous page,
> you sh
On Thu, Dec 14, 2023 at 6:07 PM Stephen Röttger wrote:
>
> On Thu, Dec 14, 2023 at 2:31 AM Linus Torvalds
> wrote:
> >
> > On Wed, 13 Dec 2023 at 16:36, Jeff Xu wrote:
> > >
> > >
> > > > IOW, when would you *ever* say "seal this area, but MADV_DONTNEED is
> > > > ok"?
> > > >
> > > The MADV_DO
On Thu, Dec 14, 2023 at 2:31 AM Linus Torvalds
wrote:
>
> On Wed, 13 Dec 2023 at 16:36, Jeff Xu wrote:
> >
> >
> > > IOW, when would you *ever* say "seal this area, but MADV_DONTNEED is ok"?
> > >
> > The MADV_DONTNEED is OK for file-backed mapping.
>
> Right. It makes no semantic difference. So
Jeff Xu wrote:
> In short, BSD's immutable is designed specific for libc case, and Chrome
> case is just different (e.g. the lifetime of those mappings and requirement of
> free/discard unused memory).
That is not true. During the mimmutable design I took the entire
software ecosystem into cons
On Wed, 13 Dec 2023 at 16:36, Jeff Xu wrote:
>
>
> > IOW, when would you *ever* say "seal this area, but MADV_DONTNEED is ok"?
> >
> The MADV_DONTNEED is OK for file-backed mapping.
Right. It makes no semantic difference. So there's no point to it.
My point was that you added this magic flag for
Jeff Xu wrote:
> > Or when would you *ever* say "seal this area, but mprotect()" is ok.
> >
> The fact that openBSD allows RW=>RO transaction, as in its man page [2]
>
> " At present, mprotect(2) may reduce permissions on immutable pages
> marked PROT_READ | PROT_WRITE to the less permissiv
On Tue, Dec 12, 2023 at 4:39 PM Linus Torvalds
wrote:
>
> On Tue, 12 Dec 2023 at 15:17, wrote:
> > +
> > +**types**: bit mask to specify the sealing types, they are:
>
> I really want a real-life use-case for more than one bit of "don't modify".
>
For the real-life use case question, Stephen Rött
On Tue, 12 Dec 2023 at 15:17, wrote:
> +
> +**types**: bit mask to specify the sealing types, they are:
I really want a real-life use-case for more than one bit of "don't modify".
IOW, when would you *ever* say "seal this area, but MADV_DONTNEED is ok"?
Or when would you *ever* say "seal this a
From: Jeff Xu
Add documentation for mseal().
Signed-off-by: Jeff Xu
---
Documentation/userspace-api/mseal.rst | 189 ++
1 file changed, 189 insertions(+)
create mode 100644 Documentation/userspace-api/mseal.rst
diff --git a/Documentation/userspace-api/mseal.rst
b/Doc
15 matches
Mail list logo
