[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CABi2SkXW9atWJLCDQboKwLoXCX7w9sgs7H3Wm4U2soG4cFLosw@mail.gmail.com>
Date: Mon, 7 Oct 2024 08:00:00 -0700
From: Jeff Xu <jeffxu@...omium.org>
To: Theo de Raadt <deraadt@...nbsd.org>
Cc: Randy Dunlap <rdunlap@...radead.org>, akpm@...ux-foundation.org, keescook@...omium.org,
corbet@....net, jorgelo@...omium.org, groeck@...omium.org,
linux-kernel@...r.kernel.org, linux-kselftest@...r.kernel.org,
linux-mm@...ck.org, jannh@...gle.com, sroettger@...gle.com,
pedro.falcato@...il.com, linux-hardening@...r.kernel.org, willy@...radead.org,
gregkh@...uxfoundation.org, torvalds@...ux-foundation.org,
usama.anjum@...labora.com, surenb@...gle.com, merimus@...gle.com,
lorenzo.stoakes@...cle.com, Liam.Howlett@...cle.com, enh@...gle.com
Subject: Re: [PATCH v2 1/1] mseal: update mseal.rst
Hi Theo
On Fri, Oct 4, 2024 at 12:11 PM Theo de Raadt <deraadt@...nbsd.org> wrote:
>
> Jeff Xu <jeffxu@...omium.org> wrote:
>
> > > > + replacement with a new mapping with new set of attributes, or can
> > > > + overwrite the existing mapping with another mapping.
> > > > +
> > > > + mprotect and pkey_mprotect are blocked because they changes the
> > > > + protection bits (RWX) of the mapping.
> > > > +
> > > > + Some destructive madvise behaviors (MADV_DONTNEED, MADV_FREE,> + MADV_DONTNEED_LOCKED, MADV_FREE, MADV_DONTFORK, MADV_WIPEONFORK)
> > > > + for anonymous memory, when users don't have write permission to the
> > > > + memory. Those behaviors can alter region contents by discarding pages,
> > >
> > > above is not a sentence but I don't know how to fix it.
> > >
> > Would below work ?
> >
> > Certain destructive madvise behaviors, specifically MADV_DONTNEED,
> > MADV_FREE, MADV_DONTNEED_LOCKED, MADV_FREE, MADV_DONTFORK,
> > MADV_WIPEONFORK, can pose risks when applied to anonymous memory by
> > threads without write permissions. These behaviors have the potential
> > to modify region contents by discarding pages, effectively performing
> > a memset(0) operation on the anonymous memory.
>
>
> In OpenBSD, mimmutable blocks all those madvise() operations.
>
>
> I don't understand the sentence supplied above. Is it saying that
> mseal() solves that problem, or that mseal() does not solve that
> problem.
>
Yes. The mseal solved the problem, I will modify the sentence to clarify that.
thanks
> I would hope it solves that problem. But the sentence explains the
> problem without taking a position on what to do.
>
Powered by blists - more mailing lists