On Fri, Aug 30, 2024 at 12:23 PM Lorenzo Stoakes
wrote:
>
> On Fri, Aug 30, 2024 at 07:43:12PM GMT, Lorenzo Stoakes wrote:
> > On Fri, Aug 30, 2024 at 06:02:36PM GMT, jef...@chromium.org wrote:
> > > From: Jeff Xu
> > >
> > > Add sealing test to cover mma
Hi Pedro
On Fri, Aug 30, 2024 at 5:57 AM Pedro Falcato wrote:
>
> On Thu, Aug 29, 2024 at 09:43:51PM GMT, jef...@chromium.org wrote:
> > From: Jeff Xu
> >
> > Add sealing test to cover mmap for
> > Expand/shrink across vmas.
> > Reuse the same address in !M
On Fri, Aug 30, 2024 at 5:52 AM Pedro Falcato wrote:
>
> On Thu, Aug 29, 2024 at 09:43:50PM GMT, jef...@chromium.org wrote:
> > From: Jeff Xu
> >
> > Add a testcase to cover all sealed madvise type.
> >
> > Signed-off-by: Jeff Xu
> > ---
> >
Hi Pedro
On Fri, Aug 30, 2024 at 5:45 AM Pedro Falcato wrote:
>
> On Thu, Aug 29, 2024 at 09:43:49PM GMT, jef...@chromium.org wrote:
> > From: Jeff Xu
> >
> > Add check for vma size, prot bits and error return.
> >
> > Signed-off-by: Jeff Xu
> > ---
&g
Hi Pedro
On Fri, Aug 30, 2024 at 5:31 AM Pedro Falcato wrote:
>
> On Thu, Aug 29, 2024 at 09:43:48PM GMT, jef...@chromium.org wrote:
> > From: Jeff Xu
> >
> > This series increase the test coverage of mseal_test by:
> >
> > Add check for vma_size, pro
Hi Matthew
On Thu, Aug 29, 2024 at 12:58 PM Matthew Wilcox wrote:
> > > > > Can you send this as a separate patch, preferably as an RFC so we can
> > > > > ensure that we all agree on how mseal() should behave?
> > > > >
> > It is not an RFC because it doesn't change any semanic to mseal. The
> >
Hi Lorenzo
On Thu, Aug 29, 2024 at 8:44 AM Lorenzo Stoakes
wrote:
> > >
> > > Also, this is a really unusual way to send a series - why is this a 2/2 in
> > > reply to the 1/2 and no cover letter? Why is this change totally unrelated
> > > to the other patch?
> > >
1/2 has a fix that 2/2 is depe
Hi Mark
On Thu, Aug 29, 2024 at 9:16 AM Mark Brown wrote:
>
> On Wed, Aug 28, 2024 at 10:55:22PM +, jef...@chromium.org wrote:
>
> > Add more testcases and increase test coverage, e.g. add
> > get_vma_size to check VMA size and prot bits.
>
> I think this needs to be split into multiple patch
Hi Lorenzo
On Thu, Aug 29, 2024 at 8:14 AM Lorenzo Stoakes
wrote:
>
> On Thu, Aug 29, 2024 at 07:45:56AM GMT, Jeff Xu wrote:
> > HI Andrew
> >
> > On Wed, Aug 28, 2024 at 3:55 PM wrote:
> > >
> > > From: Jeff Xu
> > >
> >
HI Andrew
On Wed, Aug 28, 2024 at 3:55 PM wrote:
>
> From: Jeff Xu
>
> Add more testcases and increase test coverage, e.g. add
> get_vma_size to check VMA size and prot bits.
>
Could you please pull the self-test part of this patch series to mm-unstable ?
It will help to
On Thu, Aug 29, 2024 at 7:03 AM Liam R. Howlett wrote:
>
> I will fix this in my series, thanks Jeff.
>
Sure.
-Jeff
> Regards,
> Liam
Howlett
> R: Vlastimil Babka
> R: Lorenzo Stoakes
> L: linux...@kvack.org
> S: Maintained
> W: http://www.linux-mm.org
> T: git git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm
> F: mm/mmap.c
>
> On Wed, Aug 28, 2024 at 10:
On Wed, Aug 28, 2024 at 4:38 PM Pedro Falcato wrote:
>
> +CC vma reviewers
> On Wed, Aug 28, 2024 at 10:55:21PM GMT, jef...@chromium.org wrote:
> > From: Jeff Xu
> >
> > mmap(MAP_FIXED) should return EPERM when memory is sealed.
> >
> > Fixes: 4205a39e06da
On Wed, Aug 21, 2024 at 9:24 AM Pedro Falcato wrote:
>
> On Wed, Aug 21, 2024 at 5:16 PM Jeff Xu wrote:
> >
> > On Fri, Aug 16, 2024 at 5:18 PM Pedro Falcato
> > wrote:
> > >
> > > We were doing an extra mmap tree traversal just to check if the ent
On Wed, Aug 21, 2024 at 9:20 AM Pedro Falcato wrote:
>
> On Wed, Aug 21, 2024 at 4:56 PM Jeff Xu wrote:
> >
> > Hi Pedro
> >
> > On Fri, Aug 16, 2024 at 5:18 PM Pedro Falcato
> > wrote:
> > >
> > > Add more mseal traversal tests acros
On Fri, Aug 16, 2024 at 5:18 PM Pedro Falcato wrote:
>
> We were doing an extra mmap tree traversal just to check if the entire
> range is modifiable. This can be done when we iterate through the VMAs
> instead.
>
> Signed-off-by: Pedro Falcato
> ---
> mm/mmap.c | 11 +--
> mm/vma.c | 1
Hi Pedro
On Fri, Aug 16, 2024 at 5:18 PM Pedro Falcato wrote:
>
> Add more mseal traversal tests across VMAs, where we could possibly
> screw up sealing checks. These test more across-vma traversal for
> mprotect, munmap and madvise. Particularly, we test for the case where a
> regular VMA is fol
Hi Oliver
On Tue, Aug 20, 2024 at 11:19 PM Oliver Sang wrote:
>
> hi, Jeff,
>
> here is a update per your test request.
>
> we extented the runtime to 600 seconds, and run 10 times for each commit.
>
> =
> com
Hi Oliver
On Thu, Aug 15, 2024 at 7:39 PM Oliver Sang wrote:
>
> hi, Jeff,
>
> On Thu, Aug 15, 2024 at 01:19:06PM -0700, Jeff Xu wrote:
> > Hi Oliver,
> >
> > On Thu, Aug 15, 2024 at 11:16 AM Jeff Xu wrote:
> > >
> > > On Wed, Aug 14, 2024 a
On Thu, Aug 15, 2024 at 1:14 PM Liam R. Howlett wrote:
>
> * Jeff Xu [240815 13:23]:
> > On Thu, Aug 15, 2024 at 9:50 AM Liam R. Howlett
> > wrote:
> > >
> > > * Jeff Xu [240814 23:46]:
> > > > On Wed, Aug 14, 2024 at 12:55 PM Liam R. Howle
Hi Oliver,
On Thu, Aug 15, 2024 at 11:16 AM Jeff Xu wrote:
>
> On Wed, Aug 14, 2024 at 12:14 AM wrote:
> >
> > From: Jeff Xu
> >
> > mremap doesn't allow relocate, expand, shrink across VMA boundaries,
> > refactor the code to check src addre
On Wed, Aug 14, 2024 at 12:14 AM wrote:
>
> From: Jeff Xu
>
> mremap doesn't allow relocate, expand, shrink across VMA boundaries,
> refactor the code to check src address range before doing anything on
> the destination, i.e. destination won't be unmapped, if src add
On Thu, Aug 15, 2024 at 9:50 AM Liam R. Howlett wrote:
>
> * Jeff Xu [240814 23:46]:
> > On Wed, Aug 14, 2024 at 12:55 PM Liam R. Howlett
> > wrote:
> > > The majority of the comments to V2 are mine, you only told us that
> > > splitting a sealed vma is
On Wed, Aug 14, 2024 at 12:55 PM Liam R. Howlett
wrote:
> The majority of the comments to V2 are mine, you only told us that
> splitting a sealed vma is wrong (after I asked you directly to answer)
> and then you made a comment about testing of the patch set. Besides the
> direct responses to me,
On Wed, Aug 14, 2024 at 7:40 AM Liam R. Howlett wrote:
>
> * jef...@chromium.org [240814 03:14]:
> > From: Jeff Xu
> >
> > mremap doesn't allow relocate, expand, shrink across VMA boundaries,
> > refactor the code to check src address range before doing a
Hi Muhammad
On Fri, Aug 9, 2024 at 1:25 AM Muhammad Usama Anjum
wrote:
>
> The __NR_mmap isn't found on armhf. The mmap() is commonly available
> system call and its wrapper is presnet on all architectures. So it
> should be used directly. It solves problem for armhf and doesn't create
> problem
On Wed, Aug 7, 2024 at 2:20 PM Pedro Falcato wrote:
>
> On Wed, Aug 7, 2024 at 7:03 PM Jeff Xu wrote:
> > Do you have any suggestions here ? I can think of two options to choose
> > from:
> >
> > 1> use 0xd000
> > 2> allocate a memory then free it,
On Wed, Aug 7, 2024 at 11:03 AM Jeff Xu wrote:
>
> On Wed, Aug 7, 2024 at 9:38 AM Pedro Falcato wrote:
> >
> > On Wed, Aug 7, 2024 at 4:35 PM wrote:
> >
> > > /* shrink from 4 pages to 2 pages. */
> > > - ret2 = mremap(ptr, size
On Wed, Aug 7, 2024 at 9:38 AM Pedro Falcato wrote:
>
> On Wed, Aug 7, 2024 at 4:35 PM wrote:
>
> > /* shrink from 4 pages to 2 pages. */
> > - ret2 = mremap(ptr, size, 2 * page_size, 0, 0);
> > + ret2 = sys_mremap(ptr, size, 2 * page_size, 0, 0);
> > if (seal) {
> >
Hi
On Sun, Jun 30, 2024 at 11:49 AM Barnabás Pőcze wrote:
>
> `MFD_NOEXEC_SEAL` should remove the executable bits and set `F_SEAL_EXEC`
> to prevent further modifications to the executable bits as per the comment
> in the uapi header file:
>
> not executable and sealed to prevent changing to ex
helpers.h.
> >
> > 3. These tests still need their own definition of u64, so also move that
> > to the header file.
> >
> > Cc: Jeff Xu
> > Cc: David Hildenbrand
> > Signed-off-by: John Hubbard
> > ---
>
> Acked-by: David Hildenbrand
Reviewed-by: Jeff Xu
>
> --
> Cheers,
>
> David / dhildenb
>
On Tue, Jun 11, 2024 at 3:41 PM Randy Dunlap wrote:
>
>
>
> On 6/10/24 8:49 PM, jef...@chromium.org wrote:
> > From: Jeff Xu
> >
> > Add documentation for memfd_create flags: MFD_NOEXEC_SEAL
> > and MFD_EXEC
> >
> > Cc: s
On Mon, Jun 10, 2024 at 11:26 PM John Hubbard wrote:
>
> On 6/10/24 9:45 PM, Jeff Xu wrote:
> > On Mon, Jun 10, 2024 at 9:34 PM John Hubbard wrote:
> >> On 6/10/24 9:21 PM, Jeff Xu wrote:
> >>> Hi
> >>>
> >>>
> >>> On Fri,
On Mon, Jun 10, 2024 at 9:34 PM John Hubbard wrote:
>
> On 6/10/24 9:21 PM, Jeff Xu wrote:
> > Hi
> >
> >
> > On Fri, Jun 7, 2024 at 7:10 PM John Hubbard wrote:
> >>
> >> Eventually, once the build succeeds on a sufficiently old distro, the
Hi
On Fri, Jun 7, 2024 at 7:10 PM John Hubbard wrote:
>
> Now that the test macros are factored out into their final location, and
> simplified, it's time to rename TEST_END_CHECK to something that
> represents its new functionality: REPORT_TEST_PASS.
>
> Cc: Jeff Xu
need an intrusive label to goto; they can simply return.
>
> 2. PKEY* items. We cannot, unfortunately use pkey-helpers.h. The best we
> can do is to factor out these few items into mseal_helpers.h.
>
> 3. These tests still need their own definition of u64, so also move that
>
right now, but subsequent patches will add a lot more content to
> it.
>
> [1] commit e076eaca5906 ("selftests: break the dependency upon local
> header files")
>
> Fixes: 4926c7a52de7 ("selftest mm/mseal memory sealing")
> Cc: Jeff Xu
> Signed-off-by:
Hi
On Fri, Jun 7, 2024 at 7:10 PM John Hubbard wrote:
>
> Eventually, once the build succeeds on a sufficiently old distro, the
> idea is to delete $(KHDR_INCLUDES) from the selftests/mm build, and then
> after that, from selftests/lib.mk and all of the other selftest builds.
>
> For now, this s
Hi
On Mon, Jun 10, 2024 at 7:20 PM Randy Dunlap wrote:
>
> Hi--
>
> On 6/7/24 1:35 PM, jef...@chromium.org wrote:
> > From: Jeff Xu
> >
> > Add documentation for memfd_create flags: FMD_NOEXEC_SEAL
>
> s/FMD/MFD/
>
> > and MFD_EXEC
> >
>
Resent, (previous email is not plain text)
Hi
On Fri, Jun 7, 2024 at 2:41 PM Barnabás Pőcze wrote:
>
> Hi
>
>
> 2024. június 7., péntek 22:35 keltezéssel, jef...@chromium.org
> írta:
>
> > From: Jeff Xu
> >
> > When MFD_NOEXEC_SEAL was introduced, t
Hi Barnabás
On Fri, May 31, 2024 at 11:56 AM Barnabás Pőcze wrote:
>
> 2024. május 30., csütörtök 0:24 keltezéssel, Jeff Xu írta:
>
> > On Wed, May 29, 2024 at 2:46 PM Barnabás Pőcze wrote:
> > >
> > > Hi
> > >
> > >
> > > 202
Hi David,
On Fri, Jun 7, 2024 at 1:38 AM David Rheinsberg wrote:
>
> Hi
>
> On Tue, May 28, 2024, at 7:13 PM, Jeff Xu wrote:
> >> > Another solution is to change memfd to be by-default sealable,
> >> > although that will be an api change, but what side effe
On Wed, May 29, 2024 at 2:46 PM Barnabás Pőcze wrote:
>
> Hi
>
>
> 2024. május 29., szerda 23:30 keltezéssel, Jeff Xu írta:
>
> > Hi David and Barnabás
> >
> > On Fri, May 24, 2024 at 7:15 AM David Rheinsberg wrote:
> > >
> > >
Hi David and Barnabás
On Fri, May 24, 2024 at 7:15 AM David Rheinsberg wrote:
>
> Hi
>
> On Fri, May 24, 2024, at 5:39 AM, jef...@chromium.org wrote:
> > From: Jeff Xu
> >
> > By default, memfd_create() creates a non-sealable MFD, unless the
> > MFD_ALLOW_S
Hi Aleksa,
On Fri, May 24, 2024 at 9:12 AM Aleksa Sarai wrote:
>
> On 2024-05-23, Jeff Xu wrote:
> > Regarding vm.memfd_noexec, on another topic.
> > I think in addition to vm.memfd_noexec = 1 and 2, there still could
> > be another state: 3
> >
> > =
On Fri, May 24, 2024 at 7:29 AM David Rheinsberg wrote:
>
> Hi
>
> On Thu, May 23, 2024, at 6:55 PM, Jeff Xu wrote:
> > On Thu, May 23, 2024 at 9:20 AM Jeff Xu wrote:
> >> On Thu, May 23, 2024 at 1:24 AM David Rheinsberg
> >> wrote:
> >> > We a
Hi Aleksa
On Thu, May 23, 2024 at 8:39 PM wrote:
>
> From: Jeff Xu
>
> Add documentation for MFD_NOEXEC_SEAL and MFD_EXEC
>
> Cc: sta...@vger.kernel.org
> Signed-off-by: Jeff Xu
> ---
> Documentation/userspace-api/index.rst | 1 +
> Documentation/use
Hi Barnabás
Is that OK that I work on V2 ? It will be based on your V1 change and
I will also add more test cases.
Thanks
-Jeff
-
On Thu, May 23, 2024 at 12:45 PM Andrew Morton
wrote:
>
> On Wed, 22 May 2024 19:32:35 -0700 Jeff Xu wrote:
>
> > >
> > > It's
On Thu, May 23, 2024 at 9:20 AM Jeff Xu wrote:
>
> On Thu, May 23, 2024 at 1:24 AM David Rheinsberg wrote:
> >
> > Hi
> >
> > On Thu, May 23, 2024, at 4:25 AM, Barnabás Pőcze wrote:
> > > 2024. május 23., csütörtök 1:23 keltezéssel, Andrew Morton
> >
On Thu, May 23, 2024 at 1:24 AM David Rheinsberg wrote:
>
> Hi
>
> On Thu, May 23, 2024, at 4:25 AM, Barnabás Pőcze wrote:
> > 2024. május 23., csütörtök 1:23 keltezéssel, Andrew Morton
> > írta:
> >> It's a change to a userspace API, yes? Please let's have a detailed
> >> description of why thi
On Wed, May 22, 2024 at 7:25 PM Barnabás Pőcze wrote:
>
> Hi
>
>
> 2024. május 23., csütörtök 1:23 keltezéssel, Andrew Morton
> írta:
>
> > On Wed, 15 May 2024 23:11:12 -0700 Jeff Xu wrote:
> >
> > > On Mon, May 13, 202
On Wed, May 22, 2024 at 4:23 PM Andrew Morton wrote:
>
> On Wed, 15 May 2024 23:11:12 -0700 Jeff Xu wrote:
>
> > On Mon, May 13, 2024 at 12:15 PM Barnabás Pőcze
> > wrote:
> > >
> > > `MFD_NOEXEC_SEAL` should remove the executable bits and set
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
6a7ad68c3c1 100644
> --- a/tools/testing/selftests/memfd/memfd_test.c
> +++ b/tools/testing/selftests/memfd/memfd_test.c
> @@ -1151,7 +1151,7 @@ static void test_noexec_seal(void)
> mfd_def_size,
> MFD_CLOEXEC | MFD_NOEXEC_SEAL);
>
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.
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 Thu, May 2, 2024 at 4:24 AM Ryan Roberts wrote:
>
> On 15/04/2024 17:35, jef...@chromium.org wrote:
> > From: Jeff Xu
> >
> > selftest for memory sealing change in mmap() and mseal().
> >
> > Signed-off-by: Jeff Xu
> > ---
> > tools/testi
On Thu, May 2, 2024 at 4:24 AM Ryan Roberts wrote:
>
> On 15/04/2024 17:35, jef...@chromium.org wrote:
> > From: Jeff Xu
> >
> > selftest for memory sealing change in mmap() and mseal().
> >
> > Signed-off-by: Jeff Xu
> > ---
> > tools/testi
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 dat
On Fri, Apr 19, 2024 at 9:43 AM Pedro Falcato wrote:
>
> On Fri, Apr 19, 2024 at 4:44 AM wrote:
> >
> > From: Jeff Xu
> >
> > fix compile warning reported by test robot
> >
> > Signed-off-by: Jeff Xu
> > Reported-by: kernel test robot
&g
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:
> > &g
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 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 ms
in the test, the code will have
too many "if" and decrease readability. If there is a better
solution, I'm happy to do that, suggestions are welcome.
>
> On 4/15/24 9:35 PM, jef...@chromium.org wrote:
> > From: Jeff Xu
> >
> > selftest for memory sea
On Mon, Apr 15, 2024 at 11:21 AM Linus Torvalds
wrote:
>
> 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
On Fri, Feb 2, 2024 at 10:52 AM Pedro Falcato wrote:
>
> On Fri, Feb 2, 2024 at 5:59 PM Jeff Xu wrote:
> >
> > On Thu, Feb 1, 2024 at 9:00 PM Theo de Raadt wrote:
> > >
> > > Jeff Xu wrote:
> > >
> > > > Even without free.
> >
On Fri, Feb 2, 2024 at 9:05 AM Theo de Raadt wrote:
>
> Another interaction to consider is sigaltstack().
>
> In OpenBSD, sigaltstack() forces MAP_STACK onto the specified
> (pre-allocated) region, because on kernel-entry we require the "sp"
> register to point to a MAP_STACK region (this severely
On Fri, Feb 2, 2024 at 12:37 PM Linus Torvalds
wrote:
>
> 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
On Fri, Feb 2, 2024 at 11:21 AM Liam R. Howlett wrote:
>
> * Jeff Xu [240202 12:24]:
>
> ...
>
> > > Provide code that uses this feature.
>
> Please do this too :)
>
Yes. Will do.
> > >
> > > Provide benchmark results where you apply mseal to
On Thu, Feb 1, 2024 at 9:00 PM Theo de Raadt wrote:
>
> Jeff Xu wrote:
>
> > Even without free.
> > I personally do not like the heap getting sealed like that.
> >
> > Component A.
> > p=malloc(4096);
> > writing something to p.
> >
> &g
On Fri, Feb 2, 2024 at 7:13 AM Liam R. Howlett wrote:
>
> * Jeff Xu [240201 22:15]:
> > On Thu, Feb 1, 2024 at 12:45 PM Liam R. Howlett
> > wrote:
> > >
> > > * Jeff Xu [240131 20:27]:
> > > > On Wed, Jan 31, 2024 at 11:34 AM Liam R. Howlett
>
On Thu, Feb 1, 2024 at 8:05 PM Theo de Raadt wrote:
>
> Jeff Xu wrote:
>
> > To me, the most important thing is to deliver a feature that's easy to
> > use and works well. I don't want users to mess things up, so if I'm
> > the one giving them the t
On Thu, Feb 1, 2024 at 8:10 PM Theo de Raadt wrote:
>
> Jeff Xu wrote:
>
> > On Thu, Feb 1, 2024 at 7:54 PM Theo de Raadt wrote:
> > >
> > > Jeff Xu wrote:
> > >
> > > > On Thu, Feb 1, 2024 at 3:11 PM Eric Biggers wrote:
> > &
On Thu, Feb 1, 2024 at 7:54 PM Theo de Raadt wrote:
>
> Jeff Xu wrote:
>
> > On Thu, Feb 1, 2024 at 3:11 PM Eric Biggers wrote:
> > >
> > > On Wed, Jan 31, 2024 at 05:50:24PM +, jef...@chromium.org wrote:
> > >
On Thu, Feb 1, 2024 at 7:29 PM Linus Torvalds
wrote:
>
> 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 recen
On Thu, Feb 1, 2024 at 3:11 PM Eric Biggers wrote:
>
> On Wed, Jan 31, 2024 at 05:50:24PM +, jef...@chromium.org wrote:
> > [PATCH v8 2/4] mseal: add mseal syscall
> [...]
> > +/*
> > + * The PROT_SEAL defines memory sealing in the prot argument of mmap().
> > + */
> > +#define PROT_SEAL0x
On Thu, Feb 1, 2024 at 5:06 PM Greg KH wrote:
>
> On Thu, Feb 01, 2024 at 03:24:40PM -0700, Theo de Raadt wrote:
> > As an outsider, Linux development is really strange:
> >
> > Two sub-features are being pushed very hard, and the primary developer
> > doesn't have code which uses either of them.
On Thu, Feb 1, 2024 at 3:15 PM Linus Torvalds
wrote:
>
> 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 b
On Thu, Feb 1, 2024 at 12:45 PM Liam R. Howlett wrote:
>
> * Jeff Xu [240131 20:27]:
> > On Wed, Jan 31, 2024 at 11:34 AM Liam R. Howlett
> > wrote:
> > >
>
> Having to opt-in to allowing mseal will probably not work well.
I'm leaving the opt-in discussion
On Thu, Feb 1, 2024 at 12:45 PM Liam R. Howlett wrote:
> >
> > I would love to hear more from Linux developers on this.
>
> Linus said it was really important to get the semantics correct, but you
> took his (unfinished) list and kept going. I think there are some
> unanswered questions and that'
On Wed, Jan 31, 2024 at 11:34 AM Liam R. Howlett
wrote:
>
> Please add me to the Cc list of these patches.
Ok.
>
> * jef...@chromium.org [240131 12:50]:
> > From: Jeff Xu
> >
> > This patchset proposes a new mseal() syscall for the Linux kernel.
> >
> >
On Mon, Jan 29, 2024 at 2:37 PM Jonathan Corbet wrote:
>
> jef...@chromium.org writes:
>
> > Although the initial version of this patch series is targeting the
> > Chrome browser as its first user, it became evident during upstream
> > discussions that we would also want to ensure that the patch s
On Wed, Jan 24, 2024 at 2:49 PM Jeff Xu wrote:
>
> On Wed, Jan 24, 2024 at 12:06 PM Liam R. Howlett
> wrote:
> >
> > > Considering this is the MAP_FIXED case, and maybe that is not used
> > > that often in practice, I think this is acceptable performance-wi
On Wed, Jan 24, 2024 at 12:06 PM Liam R. Howlett
wrote:
>
> * Jeff Xu [240124 12:50]:
> > On Tue, Jan 23, 2024 at 10:15 AM Liam R. Howlett
> > wrote:
> > >
> > > * jef...@chromium.org [240122 10:29]:
> > > > From: Jeff Xu
> > > >
&
On Tue, Jan 23, 2024 at 10:58 AM Theo de Raadt wrote:
>
> It's the same with MAP_MSEALABLE. I don't get it. So now there are 3
> memory types:
>- cannot be sealed, ever
>- not yet sealed
>- sealed
>
> What purpose does the first type serve? Please explain the use case.
>
On Mon, Jan 22, 2024 at 2:34 PM Theo de Raadt wrote:
>
> Jeff Xu wrote:
>
> > On Mon, Jan 22, 2024 at 7:49 AM Theo de Raadt wrote:
> > >
> > > Regarding these pieces
> > >
> > > > The PROT_SEAL bit in prot field of mmap(). When p
On Tue, Jan 23, 2024 at 10:15 AM Liam R. Howlett
wrote:
>
> * jef...@chromium.org [240122 10:29]:
> > From: Jeff Xu
> >
> > The new mseal() is an syscall on 64 bit CPU, and with
> > following signature:
> >
> > int mseal(void addr, size_t len, unsig
On Mon, Jan 22, 2024 at 7:49 AM Theo de Raadt wrote:
>
> Regarding these pieces
>
> > The PROT_SEAL bit in prot field of mmap(). When present, it marks
> > the map sealed since creation.
>
> OpenBSD won't be doing this. I had PROT_IMMUTABLE as a draft. In my
> research I found basically zero cir
On Sat, Jan 20, 2024 at 8:40 AM Linus Torvalds
wrote:
>
> 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
On Sat, Jan 13, 2024 at 11:48 AM Kees Cook wrote:
>
> On Thu, Jan 11, 2024 at 11:41:39PM +, jef...@chromium.org wrote:
> > diff --git a/include/linux/mm.h b/include/linux/mm.h
> > index f5a97dec5169..345667583b03 100644
> > --- a/include/linux/mm.h
> > +++ b/include/linux/mm.h
> > @@ -30,6 +30
On Fri, Jan 12, 2024 at 6:20 PM Randy Dunlap wrote:
>
>
>
> On 1/11/24 15:41, jef...@chromium.org wrote:
> > From: Jeff Xu
> >
> > This patchset proposes a new mseal() syscall for the Linux kernel.
> >
>
> Jeff,
> Building arm64 defconfig, on linux-
On Fri, Jan 12, 2024 at 5:10 PM Randy Dunlap wrote:
>
> Hi Jeff,
>
>
> On 1/11/24 15:41, jef...@chromium.org wrote:
> > From: Jeff Xu
> >
> > Add documentation for mseal().
> >
> > Signed-off-by: Jeff Xu
> > ---
> > Documentation/usersp
On Wed, Jan 10, 2024 at 7:16 PM Randy Dunlap wrote:
>
>
>
> On 1/9/24 07:45, jef...@chromium.org wrote:
> > From: Jeff Xu
> >
> > Add documentation for mseal().
> >
> > Signed-off-by: Jeff Xu
> > ---
> > Documentation/userspace-api/mseal.rs
rt. We
> want the sub-tests to get executed indepdendent of other tests.
>
> ksft_test_result(condition, fmt, ...);
> ksft_test_result_pass(fmt, ...);
>
> See some examples below:
>
> On 1/4/24 11:51 PM, jef...@chromium.org wrote:
> > From: Jeff Xu
> >
>
On Tue, Jan 9, 2024 at 12:36 PM Matthew Wilcox wrote:
>
> On Tue, Jan 09, 2024 at 03:45:40PM +, jef...@chromium.org wrote:
> > +extern bool can_modify_mm(struct mm_struct *mm, unsigned long start,
> > + unsigned long end);
> > +extern bool can_modify_mm_madv(struct mm_struct *mm, u
On Tue, Jan 9, 2024 at 10:32 AM Geert Uytterhoeven wrote:
>
> Hi Jeff,
>
> On Tue, Jan 9, 2024 at 4:46 PM wrote:
> > From: Jeff Xu
> >
> > Wire up mseal syscall for all architectures.
> >
> > Signed-off-by: Jeff Xu
>
> Thanks for the update!
&
On Tue, Jan 9, 2024 at 11:47 AM Kees Cook wrote:
>
> On Tue, Jan 09, 2024 at 03:45:38PM +, jef...@chromium.org wrote:
> > This patchset proposes a new mseal() syscall for the Linux kernel.
>
> Thanks for continuing to work on this! Given Linus's general approval
> on the v4, I think this serie
On Sun, Jan 7, 2024 at 10:42 AM Linus Torvalds
wrote:
>
> 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_SYSCAL
On Thu, Jan 4, 2024 at 11:44 PM Greg KH wrote:
>
> On Thu, Jan 04, 2024 at 06:51:34PM +, jef...@chromium.org wrote:
> > From: Jeff Xu
> >
> > Wire up mseal syscall for all architectures.
> >
> > Signed-off-by: Jeff Xu
>
> Doesn't this break the
On Thu, Jan 4, 2024 at 3:47 PM Randy Dunlap wrote:
>
>
>
> On 1/4/24 10:51, jef...@chromium.org wrote:
> > From: Jeff Xu
> >
> > Add documentation for mseal().
> >
> > Signed-off-by: Jeff Xu
> > ---
> > Documentation/userspace-api/mseal.rs
1 - 100 of 118 matches
Mail list logo
