Re: svn commit: r335068 - in head: share/man/man9 sys/amd64/amd64 sys/i386/i386 sys/kern sys/net sys/sys sys/vm
On 2018-06-15 04:04, Jonathan T. Looney wrote: On Thu, Jun 14, 2018 at 7:12 PM Olivier Houchard wrote: On Fri, Jun 15, 2018 at 12:23:36AM +0200, Emmanuel Vadot wrote: This brake module loading on armv7 and arm64 I think I fixed it with r335182. Jonathan probably missed it because modules are differnt on amd64 (and mips), and the code that handles those are different, and doesn't use malloc(). Hi Olivier, Thanks for fixing that! Indeed thanks. FWIW, I do have plans to make some further enhancements to fine-tune the permissions used for kernel modules. Once I have a patch, I would appreciate it if a few of the people impacted by this change would be willing to test it. Jonathan Don't hesitate to put me on review so I can test on arm/arm64. -- Emmanuel Vadot ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r335068 - in head: share/man/man9 sys/amd64/amd64 sys/i386/i386 sys/kern sys/net sys/sys sys/vm
On Thu, Jun 14, 2018 at 7:12 PM Olivier Houchard wrote: > On Fri, Jun 15, 2018 at 12:23:36AM +0200, Emmanuel Vadot wrote: > > This brake module loading on armv7 and arm64 > > I think I fixed it with r335182. > Jonathan probably missed it because modules are differnt on amd64 (and > mips), and the code that handles those are different, and doesn't use > malloc(). > Hi Olivier, Thanks for fixing that! FWIW, I do have plans to make some further enhancements to fine-tune the permissions used for kernel modules. Once I have a patch, I would appreciate it if a few of the people impacted by this change would be willing to test it. Jonathan ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r335068 - in head: share/man/man9 sys/amd64/amd64 sys/i386/i386 sys/kern sys/net sys/sys sys/vm
Hi, On Fri, Jun 15, 2018 at 12:23:36AM +0200, Emmanuel Vadot wrote: > > Hi Jonathan, > [...] > This brake module loading on armv7 and arm64 > kevans log on armv7 : > https://gist.github.com/kevans91/d0ffcd6c94a0e4cdfdc5433612fce2e8 > mine on arm64 : http://dpaste.com/3VVBZDV > > Do you have any idea what could cause that ? Is any MD stuff is > missing for those arches ? > > Thanks, > I think I fixed it with r335182. Jonathan probably missed it because modules are differnt on amd64 (and mips), and the code that handles those are different, and doesn't use malloc(). Regards, Olivier ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r335068 - in head: share/man/man9 sys/amd64/amd64 sys/i386/i386 sys/kern sys/net sys/sys sys/vm
Hi Jonathan, On Wed, 13 Jun 2018 17:04:42 + (UTC) "Jonathan T. Looney" wrote: > Author: jtl > Date: Wed Jun 13 17:04:41 2018 > New Revision: 335068 > URL: https://svnweb.freebsd.org/changeset/base/335068 > > Log: > Make UMA and malloc(9) return non-executable memory in most cases. > > Most kernel memory that is allocated after boot does not need to be > executable. There are a few exceptions. For example, kernel modules > do need executable memory, but they don't use UMA or malloc(9). The > BPF JIT compiler also needs executable memory and did use malloc(9) > until r317072. > > (Note that a side effect of r316767 was that the "small allocation" > path in UMA on amd64 already returned non-executable memory. This > meant that some calls to malloc(9) or the UMA zone(9) allocator could > return executable memory, while others could return non-executable > memory. This change makes the behavior consistent.) > > This change makes malloc(9) return non-executable memory unless the new > M_EXEC flag is specified. After this change, the UMA zone(9) allocator > will always return non-executable memory, and a KASSERT will catch > attempts to use the M_EXEC flag to allocate executable memory using > uma_zalloc() or its variants. > > Allocations that do need executable memory have various choices. They > may use the M_EXEC flag to malloc(9), or they may use a different VM > interfact to obtain executable pages. > > Now that malloc(9) again allows executable allocations, this change also > reverts most of r317072. > > PR: 228927 > Reviewed by:alc, kib, markj, jhb (previous version) > Sponsored by: Netflix > Differential Revision: https://reviews.freebsd.org/D15691 This brake module loading on armv7 and arm64 kevans log on armv7 : https://gist.github.com/kevans91/d0ffcd6c94a0e4cdfdc5433612fce2e8 mine on arm64 : http://dpaste.com/3VVBZDV Do you have any idea what could cause that ? Is any MD stuff is missing for those arches ? Thanks, -- Emmanuel Vadot ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
svn commit: r335068 - in head: share/man/man9 sys/amd64/amd64 sys/i386/i386 sys/kern sys/net sys/sys sys/vm
Author: jtl
Date: Wed Jun 13 17:04:41 2018
New Revision: 335068
URL: https://svnweb.freebsd.org/changeset/base/335068
Log:
Make UMA and malloc(9) return non-executable memory in most cases.
Most kernel memory that is allocated after boot does not need to be
executable. There are a few exceptions. For example, kernel modules
do need executable memory, but they don't use UMA or malloc(9). The
BPF JIT compiler also needs executable memory and did use malloc(9)
until r317072.
(Note that a side effect of r316767 was that the "small allocation"
path in UMA on amd64 already returned non-executable memory. This
meant that some calls to malloc(9) or the UMA zone(9) allocator could
return executable memory, while others could return non-executable
memory. This change makes the behavior consistent.)
This change makes malloc(9) return non-executable memory unless the new
M_EXEC flag is specified. After this change, the UMA zone(9) allocator
will always return non-executable memory, and a KASSERT will catch
attempts to use the M_EXEC flag to allocate executable memory using
uma_zalloc() or its variants.
Allocations that do need executable memory have various choices. They
may use the M_EXEC flag to malloc(9), or they may use a different VM
interfact to obtain executable pages.
Now that malloc(9) again allows executable allocations, this change also
reverts most of r317072.
PR: 228927
Reviewed by: alc, kib, markj, jhb (previous version)
Sponsored by: Netflix
Differential Revision:https://reviews.freebsd.org/D15691
Modified:
head/share/man/man9/malloc.9
head/share/man/man9/zone.9
head/sys/amd64/amd64/bpf_jit_machdep.c
head/sys/i386/i386/bpf_jit_machdep.c
head/sys/kern/kern_malloc.c
head/sys/kern/subr_vmem.c
head/sys/net/bpf_jitter.c
head/sys/net/bpf_jitter.h
head/sys/sys/malloc.h
head/sys/vm/uma.h
head/sys/vm/uma_core.c
head/sys/vm/vm_extern.h
head/sys/vm/vm_init.c
head/sys/vm/vm_kern.c
head/sys/vm/vm_kern.h
head/sys/vm/vm_pagequeue.h
Modified: head/share/man/man9/malloc.9
==
--- head/share/man/man9/malloc.9Wed Jun 13 17:01:57 2018
(r335067)
+++ head/share/man/man9/malloc.9Wed Jun 13 17:04:41 2018
(r335068)
@@ -29,7 +29,7 @@
.\" $NetBSD: malloc.9,v 1.3 1996/11/11 00:05:11 lukem Exp $
.\" $FreeBSD$
.\"
-.Dd January 24, 2018
+.Dd June 13, 2018
.Dt MALLOC 9
.Os
.Sh NAME
@@ -189,6 +189,11 @@ This option should only be used in combination with
.Dv M_NOWAIT
when an allocation failure cannot be tolerated by the caller without
catastrophic effects on the system.
+.It Dv M_EXEC
+Indicates that the system should allocate executable memory.
+If this flag is not set, the system will not allocate executable memory.
+Not all platforms enforce a distinction between executable and
+non-executable memory.
.El
.Pp
Exactly one of either
Modified: head/share/man/man9/zone.9
==
--- head/share/man/man9/zone.9 Wed Jun 13 17:01:57 2018(r335067)
+++ head/share/man/man9/zone.9 Wed Jun 13 17:04:41 2018(r335068)
@@ -25,7 +25,7 @@
.\"
.\" $FreeBSD$
.\"
-.Dd April 26, 2017
+.Dd June 13, 2018
.Dt ZONE 9
.Os
.Sh NAME
@@ -375,6 +375,15 @@ if the zone ran out of unused items
and
.Dv M_NOWAIT
was specified.
+.Sh IMPLEMENTATION NOTES
+The memory that these allocation calls return is not executable.
+The
+.Fn uma_zalloc
+function does not support the
+.Dv M_EXEC
+flag to allocate executable memory.
+Not all platforms enforce a distinction between executable and
+non-executable memory.
.Sh SEE ALSO
.Xr malloc 9
.Sh HISTORY
Modified: head/sys/amd64/amd64/bpf_jit_machdep.c
==
--- head/sys/amd64/amd64/bpf_jit_machdep.c Wed Jun 13 17:01:57 2018
(r335067)
+++ head/sys/amd64/amd64/bpf_jit_machdep.c Wed Jun 13 17:04:41 2018
(r335068)
@@ -44,9 +44,6 @@ __FBSDID("$FreeBSD$");
#include
#include
-#include
-#include
-#include
#else
#include
#include
@@ -605,11 +602,7 @@ bpf_jit_compile(struct bpf_insn *prog, u_int nins, siz
*size = stream.cur_ip;
#ifdef _KERNEL
- /*
-* We cannot use malloc(9) because DMAP is mapped as NX.
-*/
- stream.ibuf = (void *)kmem_malloc(kernel_arena, *size,
- M_NOWAIT);
+ stream.ibuf = malloc(*size, M_BPFJIT, M_EXEC | M_NOWAIT);
if (stream.ibuf == NULL)
break;
#else
@@ -657,15 +650,4 @@ bpf_jit_compile(struct bpf_insn *prog, u_int nins, siz
#endif
return ((bpf_filter_func)(void *)stream.ibuf);
-}
-
-void
-bpf_jit_free(void *func, size_t size)
-{
-
-#ifdef _KERNEL
- kmem_free(kernel_arena, (vm_offset_t)func, size);
-
