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 was
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
o
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 is
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
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 change
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 t
On Mon, 15 Apr 2024 at 11:11, Muhammad Usama Anjum
wrote:
>
> It isn't logical to wire up something which isn't present
Actually, with system calls, the rules end up being almost opposite.
There's no point in adding the code if it's not reachable. So adding
the system call code before adding the
On Fri, 1 Mar 2024 at 02:27, Nikolai Kondrashov wrote:
>
> I agree, it's hard to imagine even a simple majority agreeing on how GitLab CI
> should be done. Still, we would like to help people, who are interested in
> this kind of thing, to set it up. How about we reframe this contribution as a
> s
On Thu, 29 Feb 2024 at 01:23, Nikolai Kondrashov wrote:
>
> However, I think a better approach would be *not* to add the .gitlab-ci.yaml
> file in the root of the source tree, but instead change the very same repo
> setting to point to a particular entry YAML, *inside* the repo (somewhere
> under
On Thu, 22 Feb 2024 at 09:36, Daniel Latypov wrote:
>
> Copying the line for context, it's about `p-r` where
> p = memchr_inv(&r[1], 0, sizeof(r) - sizeof(r[0]));
> `p-r` should never be negative unless something has gone horribly
> horribly wrong.
Sure it would - if 'p' is NULL.
Of course, th
On Wed, 21 Feb 2024 at 21:05, Lucas De Marchi wrote:
>
> this has a potential to cause conflicts with upcoming work, so I think
> it's better to apply this through drm-xe-next. Let me know if you agree.
I disagree. Violently.
For this to be fixed, we need to have the printf format checking enabl
On Tue, 20 Feb 2024 at 11:57, Linus Torvalds
wrote:
>
> It turns out that that commit is buggy for another reason, but it's
> hidden by the fact that apparently KUNIT_ASSERT_FALSE_MSG() doesn't
> check the format string.
The fix for that is this:
--- a/include/kunit/
On Fri, 2 Feb 2024 at 13:18, Liam R. Howlett wrote:
>
> There will be a larger performance cost to checking up front without
> allowing the partial completion.
I suspect that for mseal(), the only half-way common case will be
sealing an area that is entirely contained within one vma.
So the cost
On Fri, 2 Feb 2024 at 11:32, Theo de Raadt wrote:
>
> Unix system calls must be atomic.
>
> They either return an error, and that is a promise they made no changes.
That's actually not true, and never has been.
It's a good thing to aim for, but several errors means "some or all
may have been don
On Thu, 1 Feb 2024 at 19:24, Jeff Xu wrote:
>
> The patch Stephan developed was based on V1 of the patch, IIRC, which
> is really ancient, and it is not based on MAP_SEALABLE, which is a
> more recent development entirely from me.
So the problem with this whole patch series from the very beginnin
On Thu, 1 Feb 2024 at 14:54, Theo de Raadt wrote:
>
> Linus, you are in for a shock when the proposal doesn't work for glibc
> and all the applications!
Heh. I've enjoyed seeing your argumentative style that made you so
famous back in the days. Maybe it's always been there, but I haven't
seen the
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
One comment:
On Thu, 4 Jan 2024 at 10:51, wrote:
>
> diff --git a/kernel/sys_ni.c b/kernel/sys_ni.c
> index 9a846439b36a..02280199069b 100644
> --- a/kernel/sys_ni.c
> +++ b/kernel/sys_ni.c
> @@ -193,6 +193,7 @@ COND_SYSCALL(migrate_pages);
> COND_SYSCALL(move_pages);
> COND_SYSCALL(set_mempoli
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 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
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
On Wed, 15 Nov 2023 at 11:39, David Howells wrote:
>
> I was trying to make it possible to do these tests before starting userspace
> as there's a good chance that if the UBUF/IOVEC iterators don't work right
> then your system can't be booted.
Oh, I don't think that any unit test should bother t
On Wed, 15 Nov 2023 at 10:50, David Howells wrote:
>
> Add kunit tests to benchmark 256MiB copies to a KVEC iterator, a BVEC
> iterator, an XARRAY iterator and to a loop that allocates 256-page BVECs
> and fills them in (similar to a maximal bio struct being set up).
I see *zero* advantage of doi
On Wed, 15 Nov 2023 at 10:50, David Howells wrote:
>
> This requires access to otherwise unexported core symbols: mm_alloc(),
> vm_area_alloc(), insert_vm_struct() arch_pick_mmap_layout() and
> anon_inode_getfile_secure(), which I've exported _GPL.
>
> [?] Would it be better if this were done in c
On Wed, 15 Nov 2023 at 10:50, David Howells wrote:
>
> (3) Add a function to set up a userspace VM, attach the VM to the kunit
> testing thread, create an anonymous file, stuff some pages into the
> file and map the file into the VM to act as a buffer that can be used
> with UBUF/I
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 Wed, 18 Oct 2023 at 10:14, Jeff Xu wrote:
>
> There is also alternative approach:
>
> For all the places that call do_vmi_munmap(), find out which
> case should ignore the sealing flag legitimately,
NO.
Christ.
THERE ARE NO LEGITIMATE CASES OF IGNORING SEALING FLAGS.
If you ignore a sealing
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
On Tue, 17 Oct 2023 at 10:04, Linus Torvalds
wrote:
>
> Honestly, there is only two kinds of sealing that makes sense:
>
> - you cannot change the permissions of some area
>
> - you cannot unmap an area
Actually, I guess at least theoretically, there could be three differe
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 Tue, 17 Oct 2023 at 02:08, wrote:
>
> Note: Of all the call paths that goes into do_mmap(),
> ksys_mmap_pgoff() is the only place where
> checkSeals = MM_SEAL_MMAP. The rest has checkSeals = 0.
Again, this is all completely nonsensical.
First off, since seals only exist on existing vma's, the
On Tue, 17 Oct 2023 at 02:08, wrote:
>
> Of all the call paths that call into do_vmi_munmap(),
> this is the only place where checkSeals = MM_SEAL_MUNMAP.
> The rest has checkSeals = 0.
Why?
None of this makes sense.
So you say "we can't munmap in this *one* place, but all others ignore
the sea
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
33 matches
Mail list logo
