> The problem you seem to have with fully locked mseal() in chrome seems
> to be here:
>
> > about permission changes but sometimes we do need to mprotect data only
> > pages.
>
> Does that data have to be in the same region? Can your allocator not
> put the non-code pieces of the JIT elsewhere, w
On Thu, Oct 19, 2023 at 4:06 PM Linus Torvalds
wrote:
>
> On Thu, 19 Oct 2023 at 15:47, Pedro Falcato wrote:
> > >
> > > For mprotect()/mmap(), is Linux implementation limited by POSIX ?
> >
> > No. POSIX works merely as a baseline that UNIX systems aim towards.
> > You can (and very frequently d
On Thu, Oct 19, 2023 at 3:47 PM Pedro Falcato wrote:
>
> On Thu, Oct 19, 2023 at 6:30 PM Jeff Xu wrote:
> >
> > Hi Pedro
> >
> > Some followup on mmap() + mprotect():
> >
> > On Wed, Oct 18, 2023 at 11:20 AM Jeff Xu wrote:
> > >
> > > On Tue, Oct 17, 2023 at 3:35 PM Pedro Falcato
> > > wrote:
Stephen Röttger wrote:
> > I do like us starting with just "mimmutable()", since it already
> > exists. Particularly if chrome already knows how to use it.
> >
> > Maybe add a flag field (require it to be zero initially) just to allow
> > any future expansion. Maybe the chrome team has *wanted* t
Stephen Röttger wrote:
> > > IMO: The approaches mimmutable() and mseal() took are different, but
> > > we all want to seal the memory from attackers and make the linux
> > > application safer.
> >
> > I think you are building mseal for chrome, and chrome alone.
> >
> > I do not think this will w
On Thu, 19 Oct 2023 at 15:47, Pedro Falcato wrote:
> >
> > For mprotect()/mmap(), is Linux implementation limited by POSIX ?
>
> No. POSIX works merely as a baseline that UNIX systems aim towards.
> You can (and very frequently do) extend POSIX interfaces (in fact,
> it's how most of POSIX was wri
On Thu, Oct 19, 2023 at 6:30 PM Jeff Xu wrote:
>
> Hi Pedro
>
> Some followup on mmap() + mprotect():
>
> On Wed, Oct 18, 2023 at 11:20 AM Jeff Xu wrote:
> >
> > On Tue, Oct 17, 2023 at 3:35 PM Pedro Falcato
> > wrote:
> > >
> > > > >
> > > > > I think it's worth pointing out that this suggesti
Hi Pedro
Some followup on mmap() + mprotect():
On Wed, Oct 18, 2023 at 11:20 AM Jeff Xu wrote:
>
> On Tue, Oct 17, 2023 at 3:35 PM Pedro Falcato wrote:
> >
> > > >
> > > > I think it's worth pointing out that this suggestion (with PROT_*)
> > > > could easily integrate with mmap() and as such a
> > IMO: The approaches mimmutable() and mseal() took are different, but
> > we all want to seal the memory from attackers and make the linux
> > application safer.
>
> I think you are building mseal for chrome, and chrome alone.
>
> I do not think this will work out for the rest of the application
> I do like us starting with just "mimmutable()", since it already
> exists. Particularly if chrome already knows how to use it.
>
> Maybe add a flag field (require it to be zero initially) just to allow
> any future expansion. Maybe the chrome team has *wanted* to have some
> finer granularity thi
Jeff Xu wrote:
> On Wed, Oct 18, 2023 at 8:17 AM Matthew Wilcox wrote:
> >
> > Let's start with the purpose. The point of mimmutable/mseal/whatever is
> > to fix the mapping of an address range to its underlying object, be it
> > a particular file mapping or anonymous memory. After the call su
On Wed, Oct 18, 2023 at 8:17 AM Matthew Wilcox wrote:
>
> Let's start with the purpose. The point of mimmutable/mseal/whatever is
> to fix the mapping of an address range to its underlying object, be it
> a particular file mapping or anonymous memory. After the call succeeds,
> it must not be po
On Tue, Oct 17, 2023 at 3:35 PM Pedro Falcato wrote:
>
> > >
> > > I think it's worth pointing out that this suggestion (with PROT_*)
> > > could easily integrate with mmap() and as such allow for one-shot
> > > mmap() + mseal().
> > > If we consider the common case as 'addr = mmap(...); mseal(add
On Tue, Oct 17, 2023 at 08:18:47PM -0700, Jeff Xu wrote:
> In practice: libc could do below:
> #define MM_IMMUTABLE
> (MM_SEAL_MPROTECT|MM_SEAL_MUNMAP|MM_SEAL_MREMAP|MM_SEAL_MMAP)
> mseal(add,len, MM_IMMUTABLE)
> it will be equivalent to BSD's immutable().
No, it wouldn't, because you've carefully
Jeff Xu wrote:
> In linux cases, I think, eventually, mseal() will have a bigger scope than
> BSD's mimmutable().
I don't believe that, considering noone needed this behaviour from the VM
system in the last 4 decades.
> VMA's metadata(vm_area_struct) contains a lot
> of control info, depending
On Tue, Oct 17, 2023 at 4:57 PM Theo de Raadt wrote:
>
> Jeff Xu wrote:
>
> > May I ask, for BSD's implementation of immutable(), do you cover
> > things such as mlock(),
> > madvice() ? or just the protection bit (WRX) + remap() + unmap().
>
> It only prevents removal of the mapping, placement o
Jeff Xu wrote:
> May I ask, for BSD's implementation of immutable(), do you cover
> things such as mlock(),
> madvice() ? or just the protection bit (WRX) + remap() + unmap().
It only prevents removal of the mapping, placement of a replacement
mapping, or changing the existing permissions. If o
On Tue, Oct 17, 2023 at 11:20 AM Theo de Raadt wrote:
>
> Linus Torvalds wrote:
>
> > On Tue, 17 Oct 2023 at 02:08, Jeff Xu wrote:
> > >
> > > It is probably worth noting that I choose to check one and only
> > > one sealing type per syscall. i.e. munmap(2) checks
> > > MM_SEAL_MUNMAP only.
> >
On Tue, Oct 17, 2023 at 10:34 PM Jeff Xu wrote:
>
> On Tue, Oct 17, 2023 at 8:30 AM Pedro Falcato wrote:
> >
> > On Mon, Oct 16, 2023 at 4:18 PM Matthew Wilcox wrote:
> > >
> > > On Mon, Oct 16, 2023 at 02:38:19PM +, jef...@chromium.org wrote:
> > > > Modern CPUs support memory permissions s
On Tue, Oct 17, 2023 at 8:30 AM Pedro Falcato wrote:
>
> On Mon, Oct 16, 2023 at 4:18 PM Matthew Wilcox wrote:
> >
> > On Mon, Oct 16, 2023 at 02:38:19PM +, jef...@chromium.org wrote:
> > > Modern CPUs support memory permissions such as RW and NX bits. Linux has
> > > supported NX since the r
Linus Torvalds wrote:
> On Tue, 17 Oct 2023 at 11:20, Theo de Raadt wrote:
> >
> > The only case where the immutable marker is ignored is during address space
> > teardown as a result of process termination.
>
> .. and presumably also execve()?
Ah yes of course that also.
> I do like us start
On Tue, 17 Oct 2023 at 11:20, Theo de Raadt wrote:
>
> The only case where the immutable marker is ignored is during address space
> teardown as a result of process termination.
.. and presumably also execve()?
I do like us starting with just "mimmutable()", since it already
exists. Particularly
Linus Torvalds wrote:
> On Tue, 17 Oct 2023 at 02:08, Jeff Xu wrote:
> >
> > It is probably worth noting that I choose to check one and only
> > one sealing type per syscall. i.e. munmap(2) checks
> > MM_SEAL_MUNMAP only.
>
> Yeah, this is wrong.
>
> It's wrong exactly because other system cal
On Tue, 17 Oct 2023 at 02:08, Jeff Xu wrote:
>
> It is probably worth noting that I choose to check one and only
> one sealing type per syscall. i.e. munmap(2) checks
> MM_SEAL_MUNMAP only.
Yeah, this is wrong.
It's wrong exactly because other system calls will unmap things too.
Using mmap() to
On Mon, Oct 16, 2023 at 4:18 PM Matthew Wilcox wrote:
>
> On Mon, Oct 16, 2023 at 02:38:19PM +, jef...@chromium.org wrote:
> > Modern CPUs support memory permissions such as RW and NX bits. Linux has
> > supported NX since the release of kernel version 2.6.8 in August 2004 [1].
>
> This seems
On Tue, Oct 17, 2023 at 01:34:35AM -0700, Jeff Xu wrote:
> > > types: bit mask to specify which syscall to seal, currently they are:
> > > MM_SEAL_MSEAL 0x1
> > > MM_SEAL_MPROTECT 0x2
> > > MM_SEAL_MUNMAP 0x4
> > > MM_SEAL_MMAP 0x8
> > > MM_SEAL_MREMAP 0x10
> >
> > I don't understand why we want th
Hello Linus,
Thank you for the time reviewing this patch set.
On Mon, Oct 16, 2023 at 10:23 AM Linus Torvalds
wrote:
>
> On Mon, 16 Oct 2023 at 07:38, wrote:
> >
> > This patchset proposes a new mseal() syscall for the Linux kernel.
>
> So I have no objections to adding some kind of "lock down
Hi Jann,
Thank you for reviewing the patch and comments.
On Mon, Oct 16, 2023 at 10:35 AM Jann Horn wrote:
>
> On Mon, Oct 16, 2023 at 4:38 PM wrote:
> >
> > From: Jeff Xu
> >
> > This patchset proposes a new mseal() syscall for the Linux kernel.
> >
> > Modern CPUs support memory permissions
Hi Matthew.
Thanks for your comments and time to review the patchset.
On Mon, Oct 16, 2023 at 8:18 AM Matthew Wilcox wrote:
>
> On Mon, Oct 16, 2023 at 02:38:19PM +, jef...@chromium.org wrote:
> > Modern CPUs support memory permissions such as RW and NX bits. Linux has
> > supported NX since
On Mon, Oct 16, 2023 at 4:38 PM wrote:
>
> From: Jeff Xu
>
> This patchset proposes a new mseal() syscall for the Linux kernel.
>
> Modern CPUs support memory permissions such as RW and NX bits. Linux has
> supported NX since the release of kernel version 2.6.8 in August 2004 [1].
> The memory pe
On Mon, 16 Oct 2023 at 07:38, wrote:
>
> This patchset proposes a new mseal() syscall for the Linux kernel.
So I have no objections to adding some kind of "lock down memory
mappings" model, but this isn't it.
First off, the simple stuff: the commit messages are worthless. Having
check seal f
On Mon, Oct 16, 2023 at 02:38:19PM +, jef...@chromium.org wrote:
> Modern CPUs support memory permissions such as RW and NX bits. Linux has
> supported NX since the release of kernel version 2.6.8 in August 2004 [1].
This seems like a confusing way to introduce the subject. Here, you're
talki
From: Jeff Xu
This patchset proposes a new mseal() syscall for the Linux kernel.
Modern CPUs support memory permissions such as RW and NX bits. Linux has
supported NX since the release of kernel version 2.6.8 in August 2004 [1].
The memory permission feature improves security stance on memory
c
33 matches
Mail list logo
