> 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
32 matches
Mail list logo
