On Thu, 23 May 2024 at 16:54, Andrew Morton wrote:
>
> The testing and implementation review seem OK. But from a higher-level
> perspective Linus doesn't seem to be on board(?).
Oh, I'm fine with mseal.
I wasn't fine with the insane "m*() system calls should be atomic"
discussion where Theo
On Thu, 23 May 2024 16:32:26 -0700 Kees Cook wrote:
> On Tue, May 14, 2024 at 12:52:13PM -0700, Kees Cook wrote:
> > On Tue, May 14, 2024 at 10:46:46AM -0700, Andrew Morton wrote:
> > > On Mon, 15 Apr 2024 16:35:19 + jef...@chromium.org wrote:
> > >
> > > > This patchset proposes a new
On Tue, May 14, 2024 at 12:52:13PM -0700, Kees Cook wrote:
> On Tue, May 14, 2024 at 10:46:46AM -0700, Andrew Morton wrote:
> > On Mon, 15 Apr 2024 16:35:19 + jef...@chromium.org wrote:
> >
> > > This patchset proposes a new mseal() syscall for the Linux kernel.
> >
> > I have not moved this
On Tue, May 21, 2024 at 9:00 AM Liam R. Howlett wrote:
>
>
> TL;DR for Andrew (and to save his page down key):
>
> Reviewed-by: Liam R. Howlett
>
Many thanks!
-Jeff
TL;DR for Andrew (and to save his page down key):
Reviewed-by: Liam R. Howlett
* Jeff Xu [240515 20:59]:
> On Wed, May 15, 2024 at 3:19 PM Liam R. Howlett
> wrote:
> >
> > * Jeff Xu [240515 13:18]:
> > ...
> >
> > > The current mseal patch does up-front checking in two different
> > >
On Wed, May 15, 2024 at 3:19 PM Liam R. Howlett wrote:
>
> * Jeff Xu [240515 13:18]:
> ...
>
> > The current mseal patch does up-front checking in two different situations:
> > 1 when applying mseal()
> >Checking for unallocated memory in the given memory range.
> >
> > 2 When checking mseal
* Jeff Xu [240515 13:18]:
...
> The current mseal patch does up-front checking in two different situations:
> 1 when applying mseal()
>Checking for unallocated memory in the given memory range.
>
> 2 When checking mseal flag during mprotect/unmap/remap/mmap
> Checking mseal flag is placed
On Tue, May 14, 2024 at 2:28 PM Liam R. Howlett wrote:
>
> * Andrew Morton [240514 13:47]:
> > On Mon, 15 Apr 2024 16:35:19 + jef...@chromium.org wrote:
> >
> > > This patchset proposes a new mseal() syscall for the Linux kernel.
> >
> > I have not moved this into mm-stable for a 6.10 merge.
On Tue, May 14, 2024 at 09:14:37PM -0700, Linus Torvalds wrote:
> On Tue, 14 May 2024 at 20:36, Linus Torvalds
> wrote:
> >
> > Guys, if you let untrusted code execute random system calls, the whole
> > "look, now unmap() acts oddly" IS THE LEAST OF YOUR ISSUES.
I totally agree with this, I'm
* Theo de Raadt [240514 22:42]:
> Linus Torvalds wrote:
>
> > On Tue, 14 May 2024 at 18:47, Theo de Raadt wrote:
> > >
> > > Linus Torvalds wrote:
> > >
> > > Regarding mprotect(), POSIX also says:
> > >
> > > An implementation may permit accesses other than those specified by
> > >
On Tue, 14 May 2024 at 20:36, Linus Torvalds
wrote:
>
> Guys, if you let untrusted code execute random system calls, the whole
> "look, now unmap() acts oddly" IS THE LEAST OF YOUR ISSUES.
Side note: it doesn't even help to make things "atomic". munmap() acts
oddly whether it fals completely or
On Tue, 14 May 2024 at 20:13, Willy Tarreau wrote:
>
> Wouldn't it be more effective to have a non-resettable prctl() allowing
> the application to prefer to be killed upon such an munmap() failure in
> order to stay consistent and more robust against such class of attacks?
This whole argument
On Tue, May 14, 2024 at 05:47:30PM -0600, Theo de Raadt wrote:
> Andrew Morton wrote:
>
> > > I worry that the non-atomicity will one day be used by an attacker.
> >
> > How might an attacker exploit this?
>
> Various ways which are going to be very application specific. Most ways
> will
Linus Torvalds wrote:
> On Tue, 14 May 2024 at 18:47, Theo de Raadt wrote:
> >
> > Linus Torvalds wrote:
> >
> > Regarding mprotect(), POSIX also says:
> >
> > An implementation may permit accesses other than those specified by
> > prot; however, no implementation shall permit a write
On Tue, 14 May 2024 at 18:47, Theo de Raadt wrote:
>
> Linus Torvalds wrote:
>
> Regarding mprotect(), POSIX also says:
>
> An implementation may permit accesses other than those specified by
> prot; however, no implementation shall permit a write to succeed where
> PROT_WRITE has
Linus Torvalds wrote:
Regarding mprotect(), POSIX also says:
An implementation may permit accesses other than those specified by
prot; however, no implementation shall permit a write to succeed where
PROT_WRITE has not been set or shall permit any access where PROT_NONE
alone
On Tue, 14 May 2024 at 17:57, Theo de Raadt wrote:
>
> Let's wait and see.
You may not be aware, but the Open Group literally endorses the Linux model:
"When mprotect() fails for reasons other than [EINVAL], the
protections on some of the pages in the range [addr,addr+len) may have
been
> > I worry that the non-atomicity will one day be used by an attacker.
>
> Blah blah blah. That's a made-up scare tactic if I ever heard one.
> It's unworthy of you.
Let's wait and see.
(Linus, don't be a jerk)
On Tue, 14 May 2024 at 15:48, Theo de Raadt wrote:
>
> and can't imagine it affecting a single application
Honestly, that's the reason for not caring.
You have to do actively wrong things for this to matter AT ALL.
So no, we're not making gratuitous changes for stupid reasons.
> I worry that
On Tue, 14 May 2024 16:48:47 -0600 "Theo de Raadt" wrote:
> Matthew Wilcox wrote:
>
> > > Not taking a position on merging, but I have to ask: are we convinced at
> > > this point that mseal() isn't a chrome-only system call? Did we ever
> > > see the glibc patches that were promised?
> >
>
Matthew Wilcox wrote:
> > Not taking a position on merging, but I have to ask: are we convinced at
> > this point that mseal() isn't a chrome-only system call? Did we ever
> > see the glibc patches that were promised?
>
> I think _this_ version of mseal() is OpenBSD's mimmutable() with a
>
* Andrew Morton [240514 13:47]:
> On Mon, 15 Apr 2024 16:35:19 + jef...@chromium.org wrote:
>
> > This patchset proposes a new mseal() syscall for the Linux kernel.
>
> I have not moved this into mm-stable for a 6.10 merge. Mainly because
> of the total lack of Reviewed-by:s and
On Tue, May 14, 2024 at 02:59:57PM -0600, Jonathan Corbet wrote:
> Andrew Morton writes:
>
> > On Mon, 15 Apr 2024 16:35:19 + jef...@chromium.org wrote:
> >
> >> This patchset proposes a new mseal() syscall for the Linux kernel.
> >
> > I have not moved this into mm-stable for a 6.10 merge.
Andrew Morton writes:
> On Mon, 15 Apr 2024 16:35:19 + jef...@chromium.org wrote:
>
>> This patchset proposes a new mseal() syscall for the Linux kernel.
>
> I have not moved this into mm-stable for a 6.10 merge. Mainly because
> of the total lack of Reviewed-by:s and Acked-by:s.
>
> The
On Tue, May 14, 2024 at 10:46:46AM -0700, Andrew Morton wrote:
> On Mon, 15 Apr 2024 16:35:19 + jef...@chromium.org wrote:
>
> > This patchset proposes a new mseal() syscall for the Linux kernel.
>
> I have not moved this into mm-stable for a 6.10 merge. Mainly because
> of the total lack
On Mon, 15 Apr 2024 16:35:19 + jef...@chromium.org wrote:
> This patchset proposes a new mseal() syscall for the Linux kernel.
I have not moved this into mm-stable for a 6.10 merge. Mainly because
of the total lack of Reviewed-by:s and Acked-by:s.
The code appears to be stable enough for a
On Fri, Apr 19, 2024 at 10:59 AM Pedro Falcato wrote:
>
> On Fri, Apr 19, 2024 at 2:22 AM Jeff Xu wrote:
> > The overhead is likely to grow linearly with the number of VMA, since
> > it takes time to retrieve VMA's metadata.
> >
> > Let's use one data sample to look at impact:
> >
> > Test:
On Fri, Apr 19, 2024 at 2:22 AM Jeff Xu wrote:
> The overhead is likely to grow linearly with the number of VMA, since
> it takes time to retrieve VMA's metadata.
>
> Let's use one data sample to look at impact:
>
> Test: munmap 1000 memory range, each memory range has 1 VMA
>
> syscall__
On Fri, Apr 19, 2024 at 3:15 PM Jeff Xu wrote:
>
> On Fri, Apr 19, 2024 at 7:57 AM Suren Baghdasaryan wrote:
> >
> > On Thu, Apr 18, 2024 at 6:22 PM Jeff Xu wrote:
> > >
> > > On Thu, Apr 18, 2024 at 1:19 PM Suren Baghdasaryan
> > > wrote:
> > > >
> > > > On Tue, Apr 16, 2024 at 12:40 PM Jeff
On Fri, Apr 19, 2024 at 7:57 AM Suren Baghdasaryan wrote:
>
> On Thu, Apr 18, 2024 at 6:22 PM Jeff Xu wrote:
> >
> > On Thu, Apr 18, 2024 at 1:19 PM Suren Baghdasaryan
> > wrote:
> > >
> > > On Tue, Apr 16, 2024 at 12:40 PM Jeff Xu wrote:
> > > >
> > > > On Tue, Apr 16, 2024 at 8:13 AM Liam
On Thu, Apr 18, 2024 at 6:22 PM Jeff Xu wrote:
>
> On Thu, Apr 18, 2024 at 1:19 PM Suren Baghdasaryan wrote:
> >
> > On Tue, Apr 16, 2024 at 12:40 PM Jeff Xu wrote:
> > >
> > > On Tue, Apr 16, 2024 at 8:13 AM Liam R. Howlett
> > > wrote:
> > > >
> > > > * jef...@chromium.org [240415 12:35]:
On Thu, Apr 18, 2024 at 1:19 PM Suren Baghdasaryan wrote:
>
> On Tue, Apr 16, 2024 at 12:40 PM Jeff Xu wrote:
> >
> > On Tue, Apr 16, 2024 at 8:13 AM Liam R. Howlett
> > wrote:
> > >
> > > * jef...@chromium.org [240415 12:35]:
> > > > From: Jeff Xu
> > > >
> > > > This is V10 version, it
On Tue, Apr 16, 2024 at 12:40 PM Jeff Xu wrote:
>
> On Tue, Apr 16, 2024 at 8:13 AM Liam R. Howlett
> wrote:
> >
> > * jef...@chromium.org [240415 12:35]:
> > > From: Jeff Xu
> > >
> > > This is V10 version, it rebases v9 patch to 6.9.rc3.
> > > We also applied and tested mseal() in chrome
On Tue, Apr 16, 2024 at 8:13 AM Liam R. Howlett wrote:
>
> * jef...@chromium.org [240415 12:35]:
> > From: Jeff Xu
> >
> > This is V10 version, it rebases v9 patch to 6.9.rc3.
> > We also applied and tested mseal() in chrome and chromebook.
> >
> >
* jef...@chromium.org [240415 12:35]:
> From: Jeff Xu
>
> This is V10 version, it rebases v9 patch to 6.9.rc3.
> We also applied and tested mseal() in chrome and chromebook.
>
> --
...
> MM perf benchmarks
> ==
>
From: Jeff Xu
This is V10 version, it rebases v9 patch to 6.9.rc3.
We also applied and tested mseal() in chrome and chromebook.
--
This patchset proposes a new mseal() syscall for the Linux kernel.
In a nutshell, mseal() protects
36 matches
Mail list logo
