On Thu, Oct 29, 2020 at 2:17 PM Marco Elver wrote:
> Inserts KFENCE hooks into the SLAB allocator.
[...]
> diff --git a/mm/slab.c b/mm/slab.c
[...]
> @@ -3416,6 +3427,11 @@ static void cache_flusharray(struct kmem_cache
> *cachep, struct array_cache *ac)
> static __always_inline void
On Thu, Oct 29, 2020 at 2:17 PM Marco Elver wrote:
> Add architecture specific implementation details for KFENCE and enable
> KFENCE for the x86 architecture. In particular, this implements the
> required interface in for setting up the pool and
> providing helper functions for protecting and
On Thu, Oct 29, 2020 at 2:17 PM Marco Elver wrote:
> This adds the Kernel Electric-Fence (KFENCE) infrastructure. KFENCE is a
> low-overhead sampling-based memory safety error detector of heap
> use-after-free, invalid-free, and out-of-bounds access errors.
[...]
> diff --git
ver
> Signed-off-by: Marco Elver
> Signed-off-by: Alexander Potapenko
Reviewed-by: Jann Horn
with one nit:
[...]
> diff --git a/mm/kasan/common.c b/mm/kasan/common.c
[...]
> @@ -141,6 +142,14 @@ void kasan_unpoison_shadow(const void *address, size_t
> size)
>
On Thu, Oct 29, 2020 at 2:16 PM Marco Elver wrote:
> This adds the Kernel Electric-Fence (KFENCE) infrastructure. KFENCE is a
> low-overhead sampling-based memory safety error detector of heap
> use-after-free, invalid-free, and out-of-bounds access errors. This
> series enables KFENCE for the
On Thu, Oct 29, 2020 at 3:04 AM Tycho Andersen wrote:
> On Thu, Oct 29, 2020 at 02:42:58AM +0100, Jann Horn wrote:
> > On Mon, Oct 26, 2020 at 10:55 AM Michael Kerrisk (man-pages)
> > wrote:
> > >static bool
> > >getTargetPathname(struct
On Thu, Oct 29, 2020 at 3:13 AM Tycho Andersen wrote:
> > > Consider the following scenario (with supervisor "S" and target "T"; S
> > > wants to wait for events on two file descriptors seccomp_fd and
> > > other_fd):
> > >
> > > S: starts poll() to wait for events on seccomp_fd and other_fd
> >
+luto just in case he has opinions on this
On Wed, Oct 28, 2020 at 12:18 PM Camille Mougey wrote:
> From my understanding, there is no way to delay the activation of
> seccomp filters, for instance "until an _execve_ call".
(FWIW, there are some tricks that you can use for this. In particular,
On Mon, Oct 26, 2020 at 10:55 AM Michael Kerrisk (man-pages)
wrote:
>static bool
>getTargetPathname(struct seccomp_notif *req, int notifyFd,
> char *path, size_t len)
>{
>char procMemPath[PATH_MAX];
>
>snprintf(procMemPath,
On Wed, Oct 28, 2020 at 11:53 PM Kees Cook wrote:
> On Mon, Oct 26, 2020 at 10:51:02AM +0100, Jann Horn wrote:
> > The problem is the scenario where a process is interrupted while it's
> > waiting for the supervisor to reply.
> >
> > Consider the following scenario (wit
On Wed, Oct 28, 2020 at 11:56 PM Kees Cook wrote:
> On Mon, Oct 26, 2020 at 11:31:01AM +0100, Jann Horn wrote:
> > Or I guess we could also just set O_NONBLOCK on the fd by default?
> > Since the one existing user is eventloop-based...
>
> I thought about that initially, but
On Tue, Oct 27, 2020 at 9:04 PM Mickaël Salaün wrote:
> This new patch series improves documentation, cleans up comments,
> renames ARCH_EPHEMERAL_STATES to ARCH_EPHEMERAL_INODES and removes
> LANDLOCK_ACCESS_FS_CHROOT.
Thanks for continuing to work on this! This is going to be really
valuable
> A following commit uses this generic object management for inodes.
>
> Cc: James Morris
> Cc: Jann Horn
> Cc: Kees Cook
> Cc: Serge E. Hallyn
> Signed-off-by: Mickaël Salaün
Reviewed-by: Jann Horn
except for some minor nits:
[...]
> diff --git a/security/landlo
t; processes. To be allowed to use ptrace(2) and related syscalls on a
> target process, a landlocked process must have a subset of the target
> process's rules (i.e. the tracee must be in a sub-domain of the tracer).
>
> Cc: James Morris
> Cc: Jann Horn
> Cc: Kees Cook
> Cc:
ain can transition to a new domain which is the
> intersection of all its constraints and those of a ruleset provided by
> the current process. This modification only impact the current process.
> This means that a process can only gain more constraints (i.e. lose
> accesses) over time
(On Tue, Oct 27, 2020 at 9:04 PM Mickaël Salaün wrote:
> Thanks to the Landlock objects and ruleset, it is possible to identify
> inodes according to a process's domain. To enable an unprivileged
> process to express a file hierarchy, it first needs to open a directory
> (or a file) and pass
On Tue, Oct 27, 2020 at 9:04 PM Mickaël Salaün wrote:
> This documentation can be built with the Sphinx framework.
>
> Cc: James Morris
> Cc: Jann Horn
> Cc: Kees Cook
> Cc: Serge E. Hallyn
> Signed-off-by: Mickaël Salaün
> Reviewed-by: Vincent Dagonneau
[...]
>
merally) tagged
> struct inodes. This comes from the unprivileged nature of Landlock
> described in the next commit.
>
> Cc: Al Viro
> Cc: James Morris
> Cc: Jann Horn
> Cc: Kees Cook
> Cc: Serge E. Hallyn
> Signed-off-by: Mickaël Salaün
Reviewed-by: Jann Horn
is inherited from a parent to its child the same way a thread
> inherits a seccomp policy.
>
> Cc: James Morris
> Cc: Jann Horn
> Cc: Kees Cook
> Cc: Serge E. Hallyn
> Signed-off-by: Mickaël Salaün
Reviewed-by: Jann Horn
On Wed, Oct 28, 2020 at 6:44 PM Sargun Dhillon wrote:
> On Wed, Oct 28, 2020 at 2:43 AM Jann Horn wrote:
> > On Wed, Oct 28, 2020 at 7:32 AM Sargun Dhillon wrote:
> > > On Tue, Oct 27, 2020 at 3:28 AM Jann Horn wrote:
> > > > On Tue, Oct 27, 2020 at 7:14
mp(2): the caller must have the
> no_new_privs attribute set or have CAP_SYS_ADMIN in the current user
> namespace.
[...]
> Cc: Arnd Bergmann
> Cc: James Morris
> Cc: Jann Horn
> Cc: Kees Cook
> Cc: Serge E. Hallyn
> Signed-off-by: Mickaël Salaün
[...]
> diff --gi
On Wed, Oct 28, 2020 at 7:35 PM Rich Felker wrote:
> On Wed, Oct 28, 2020 at 07:25:45PM +0100, Jann Horn wrote:
> > On Wed, Oct 28, 2020 at 6:52 PM Rich Felker wrote:
> > > On Wed, Oct 28, 2020 at 06:34:56PM +0100, Jann Horn wrote:
> > > > On Wed, Oct 28, 2020
es arm, arm64, csky, riscv, sh, and xtensa
> > > > did not have SECCOMP on by default prior to this and SECCOMP will
> > > > be default in this change.
> > > >
> > > > Architectures microblaze, mips, powerpc, s390, sh, and sparc
> > > > have an outdated depe
On Wed, Oct 28, 2020 at 7:32 AM Sargun Dhillon wrote:
> On Tue, Oct 27, 2020 at 3:28 AM Jann Horn wrote:
> > On Tue, Oct 27, 2020 at 7:14 AM Michael Kerrisk (man-pages)
> > wrote:
> > > On 10/26/20 4:54 PM, Jann Horn wrote:
> > > > I'm a bit on the fence now
On Wed, Oct 28, 2020 at 5:49 PM Rich Felker wrote:
> On Wed, Oct 28, 2020 at 01:42:13PM +0100, Jann Horn wrote:
> > On Wed, Oct 28, 2020 at 12:18 PM Camille Mougey wrote:
> > You're just focusing on execve() - I think it's important to keep in
> > mind what happens afte
On Wed, Oct 28, 2020 at 6:52 PM Rich Felker wrote:
> On Wed, Oct 28, 2020 at 06:34:56PM +0100, Jann Horn wrote:
> > On Wed, Oct 28, 2020 at 5:49 PM Rich Felker wrote:
> > > On Wed, Oct 28, 2020 at 01:42:13PM +0100, Jann Horn wrote:
> > > > On Wed, Oct 28, 2
On Tue, Oct 27, 2020 at 1:11 PM Michael Kerrisk (man-pages)
wrote:
> @Nicolas, your commit ebd6de6812387a changed the capability
> requirements for the prctl_set_mm_exe_file() operation from
>
> ns_capable(CAP_SYS_ADMIN)
>
> to
>
> ns_capable(CAP_SYS_ADMIN) ||
On Tue, Oct 27, 2020 at 12:54 AM Sasha Levin wrote:
> [ Upstream commit b2767d97f5ff758250cf28684aaa48bbfd34145f ]
>
> create_elf_tables() runs after setup_new_exec(), so other tasks can
> already access our new mm and do things like process_madvise() on it. (At
> the time I'm writing this
On Tue, Oct 27, 2020 at 7:14 AM Michael Kerrisk (man-pages)
wrote:
> On 10/26/20 4:54 PM, Jann Horn wrote:
> > I'm a bit on the fence now on whether non-blocking mode should use
> > ENOTCONN or not... I guess if we returned ENOENT even when there are
> > no more
On Mon, Oct 26, 2020 at 10:57 PM Eric Biggers wrote:
> On Mon, Oct 26, 2020 at 10:23:35PM +0100, 'Jann Horn' via syzkaller-bugs
> wrote:
> > On Mon, Oct 26, 2020 at 9:08 PM Eric Biggers wrote:
> > > Commit 3f69cc60768b ("crypto: af_alg - Allow arbitrarily long al
On Mon, Oct 26, 2020 at 9:08 PM Eric Biggers wrote:
> Commit 3f69cc60768b ("crypto: af_alg - Allow arbitrarily long algorithm
> names") made the kernel start accepting arbitrarily long algorithm names
> in sockaddr_alg.
That's not true; it's still limited by the size of struct
sockaddr_storage
On Sun, Oct 25, 2020 at 5:32 PM Michael Kerrisk (man-pages)
wrote:
> On 10/1/20 4:14 AM, Jann Horn wrote:
> > On Thu, Oct 1, 2020 at 3:52 AM Jann Horn wrote:
> >> On Thu, Oct 1, 2020 at 1:25 AM Tycho Andersen wrote:
> >>> On Thu, Oct 01, 2020 at 01:11:33AM +0200,
On Mon, Oct 26, 2020 at 10:51 AM Jann Horn wrote:
> On Mon, Oct 26, 2020 at 1:32 AM Kees Cook wrote:
> > On Thu, Oct 01, 2020 at 03:52:02AM +0200, Jann Horn wrote:
> > > On Thu, Oct 1, 2020 at 1:25 AM Tycho Andersen wrote:
> > > > On Thu, Oct 01, 2020 at 01:
On Mon, Oct 26, 2020 at 1:32 AM Kees Cook wrote:
> On Thu, Oct 01, 2020 at 03:52:02AM +0200, Jann Horn wrote:
> > On Thu, Oct 1, 2020 at 1:25 AM Tycho Andersen wrote:
> > > On Thu, Oct 01, 2020 at 01:11:33AM +0200, Jann Horn wrote:
> > > > On Thu, Oct 1, 2020 at
On Sat, Oct 24, 2020 at 2:53 PM Michael Kerrisk (man-pages)
wrote:
> On 10/17/20 2:25 AM, Jann Horn wrote:
> > On Fri, Oct 16, 2020 at 8:29 PM Michael Kerrisk (man-pages)
> > wrote:
[...]
> >> I'm not sure if I should write anything about this small UAPI
> >&g
On Sat, Oct 17, 2020 at 8:09 PM Alexander Graf wrote:
> There are applications way beyond that though. What do you do with
> applications that already consumed randomness? For example a cached pool
> of SSL keys. Or a higher level language primitive that consumes
> randomness and caches its seed
On Sat, Oct 17, 2020 at 12:50 PM Dmitry Vyukov wrote:
> On Sat, Oct 17, 2020 at 5:49 AM Kees Cook wrote:
> > On Fri, Oct 16, 2020 at 01:12:24AM -0700, syzbot wrote:
> > > dashboard link:
> > > https://syzkaller.appspot.com/bug?extid=92ead4eb8e26a26d465e
> > > [...]
> > > Reported-by:
On Sat, Oct 17, 2020 at 8:44 AM Willy Tarreau wrote:
> On Sat, Oct 17, 2020 at 07:52:48AM +0200, Jann Horn wrote:
> > On Sat, Oct 17, 2020 at 7:37 AM Willy Tarreau wrote:
> > > On Sat, Oct 17, 2020 at 07:01:31AM +0200, Jann Horn wrote:
> > > > Microsoft
+linux-api because this is about fixing UAPI without breaking userspace
On Sat, Oct 17, 2020 at 8:02 AM Kees Cook wrote:
> On Fri, Oct 16, 2020 at 01:12:24AM -0700, syzbot wrote:
> > dashboard link: https://syzkaller.appspot.com/bug?extid=92ead4eb8e26a26d465e
> > [...]
> > Reported-by:
On Fri, Oct 16, 2020 at 8:29 PM Michael Kerrisk (man-pages)
wrote:
> On 10/15/20 10:32 PM, Jann Horn wrote:
> > On Thu, Oct 15, 2020 at 1:24 PM Michael Kerrisk (man-pages)
> > wrote:
> >> On 9/30/20 5:53 PM, Jann Horn wrote:
> >>> On Wed, Sep 30, 2020 a
On Sat, Oct 17, 2020 at 5:36 AM Willy Tarreau wrote:
> On Sat, Oct 17, 2020 at 03:40:08AM +0200, Jann Horn wrote:
> > [adding some more people who are interested in RNG stuff: Andy, Jason,
> > Theodore, Willy Tarreau, Eric Biggers. also linux-api@, because this
> >
[adding some more people who are interested in RNG stuff: Andy, Jason,
Theodore, Willy Tarreau, Eric Biggers. also linux-api@, because this
concerns some pretty fundamental API stuff related to RNG usage]
On Fri, Oct 16, 2020 at 4:33 PM Catangiu, Adrian Costin
wrote:
> - Background
>
> The VM
On Sat, Oct 17, 2020 at 1:21 AM Jason Gunthorpe wrote:
> On Sat, Oct 17, 2020 at 01:09:12AM +0200, Jann Horn wrote:
> > Currently, mm_struct has two refcounts:
> >
> > - mm_users: preserves everything - the mm_struct, the page tables, the
> >memory mappings
On Sat, Oct 17, 2020 at 7:37 AM Willy Tarreau wrote:
> On Sat, Oct 17, 2020 at 07:01:31AM +0200, Jann Horn wrote:
> > Microsoft's documentation
> > (http://go.microsoft.com/fwlink/?LinkId=260709) says that the VM
> > Generation ID that we get after a fork "is a 128-
On Sat, Oct 17, 2020 at 6:34 AM Colm MacCarthaigh wrote:
> On 16 Oct 2020, at 21:02, Jann Horn wrote:
> > On Sat, Oct 17, 2020 at 5:36 AM Willy Tarreau wrote:
> > But in userspace, we just need a simple counter. There's no need for
> > us to worry about anything else, like t
on
CONFIG_ANDROID_BINDER_IPC.
Signed-off-by: Jann Horn
---
include/linux/mm_types.h | 2 ++
kernel/fork.c| 16
2 files changed, 2 insertions(+), 16 deletions(-)
diff --git a/include/linux/mm_types.h b/include/linux/mm_types.h
index 764d251966c7..8fde2068bde1 100644
--- a/include
and can't be cleaned up
from RCU callback context; we can use an mm_ref() reference instead.
Signed-off-by: Jann Horn
---
kernel/fork.c | 6 +-
mm/oom_kill.c | 2 +-
2 files changed, 2 insertions(+), 6 deletions(-)
diff --git a/kernel/fork.c b/kernel/fork.c
index fcdd1ace79e4..59c119b03351
o make things neater.
Signed-off-by: Jann Horn
---
kernel/exit.c | 2 +-
kernel/fork.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/kernel/exit.c b/kernel/exit.c
index 97253ef33486..03ba6d13ef1e 100644
--- a/kernel/exit.c
+++ b/kernel/exit.c
@@ -476,7 +476,7 @@ stati
goes away completely.
Note that this moves free_task() down in order to make mmdrop_async()
available without a forward declaration.
Cc: sta...@vger.kernel.org
Fixes: bfedb589252c ("mm: Add a user_ns owner to mm_struct and fix ptrace
permission checks")
Signed-off-by: Jann Horn
---
include
I want to use refcount_t in mm_struct, but if refcount_t is defined in
linux/refcount.h, that header would have to be included in
linux/mm_types.h; that would be wasteful.
Let's move refcount_t over into linux/types.h so that includes can be
written less wastefully.
Signed-off-by: Jann Horn
om (almost) any context.
Signed-off-by: Jann Horn
---
arch/x86/kernel/tboot.c| 2 ++
drivers/firmware/efi/efi.c | 2 ++
include/linux/mm_types.h | 13 +++--
include/linux/sched/mm.h | 13 +
kernel/fork.c | 14 ++
mm/init-mm.c
better approach?
Jann Horn (6):
ptrace: Keep mm around after exit_mm() for __ptrace_may_access()
refcount: Move refcount_t definition into linux/types.h
mm: Add refcount for preserving mm_struct without pgd
mm, oom: Use mm_ref()/mm_unref() and avoid mmdrop_async()
ptrace: Use
(bprm->vma is used after the switch
to the new mm).
I have boot-tested these patches on x64-64 (with lockdep) and
!MMU arm (the latter with both FLAT and ELF).
[1]
https://lkml.kernel.org/r/cag48ez03yjg9ju_6tgimcavjutyre_o4leq7901b5zocnna...@mail.gmail.com
Jann Horn (2):
mmap locking AP
...@sipsolutions.net/
Signed-off-by: Jann Horn
---
arch/um/include/asm/mmu_context.h | 3 +--
fs/exec.c | 4
include/linux/mmap_lock.h | 23 +--
kernel/fork.c | 7 ++-
4 files changed, 28 insertions(+), 9 deletions
p code.
Suggested-by: Jason Gunthorpe
Suggested-by: Michel Lespinasse
Signed-off-by: Jann Horn
---
fs/exec.c | 68 -
include/linux/binfmts.h | 2 +-
2 files changed, 35 insertions(+), 35 deletions(-)
diff --git a/fs/exec.c b/fs/exec.c
index 229dbc
on
CONFIG_ANDROID_BINDER_IPC.
Signed-off-by: Jann Horn
---
include/linux/mm_types.h | 2 ++
kernel/fork.c| 16
2 files changed, 2 insertions(+), 16 deletions(-)
diff --git a/include/linux/mm_types.h b/include/linux/mm_types.h
index 764d251966c7..8fde2068bde1 100644
--- a/include
of any better
way to do it.
So: Does this series (and in particular patch 1/6) look vaguely sane?
And if not, does anyone have a better approach?
Jann Horn (6):
ptrace: Keep mm around after exit_mm() for __ptrace_may_access()
refcount: Move refcount_t definition into linux/types.h
m
o make things neater.
Signed-off-by: Jann Horn
---
kernel/exit.c | 2 +-
kernel/fork.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/kernel/exit.c b/kernel/exit.c
index 97253ef33486..03ba6d13ef1e 100644
--- a/kernel/exit.c
+++ b/kernel/exit.c
@@ -476,7 +476,7 @@ stati
goes away completely.
Note that this moves free_task() down in order to make mmdrop_async()
available without a forward declaration.
Cc: sta...@vger.kernel.org
Fixes: bfedb589252c ("mm: Add a user_ns owner to mm_struct and fix ptrace
permission checks")
Signed-off-by: Jann Horn
---
include
om (almost) any context.
Signed-off-by: Jann Horn
---
arch/x86/kernel/tboot.c| 2 ++
drivers/firmware/efi/efi.c | 2 ++
include/linux/mm_types.h | 13 +++--
include/linux/sched/mm.h | 13 +
kernel/fork.c | 14 ++
mm/init-mm.c
and can't be cleaned up
from RCU callback context; we can use an mm_ref() reference instead.
Signed-off-by: Jann Horn
---
kernel/fork.c | 6 +-
mm/oom_kill.c | 2 +-
2 files changed, 2 insertions(+), 6 deletions(-)
diff --git a/kernel/fork.c b/kernel/fork.c
index fcdd1ace79e4..59c119b03351
I want to use refcount_t in mm_struct, but if refcount_t is defined in
linux/refcount.h, that header would have to be included in
linux/mm_types.h; that would be wasteful.
Let's move refcount_t over into linux/types.h so that includes can be
written less wastefully.
Signed-off-by: Jann Horn
+openrisc folks
On Thu, Oct 15, 2020 at 11:28 PM kernel test robot wrote:
> tree:
> https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
> linux-5.4.y
> head: 85b0841aab15c12948af951d477183ab3df7de14
> commit: c5665cafbedd2e2a523fe933e452391a02d3adb3 [665/2391]
On Thu, Oct 15, 2020 at 1:24 PM Michael Kerrisk (man-pages)
wrote:
> On 9/30/20 5:53 PM, Jann Horn wrote:
> > On Wed, Sep 30, 2020 at 1:07 PM Michael Kerrisk (man-pages)
> > wrote:
> >> I knew it would be a big ask, but below is kind of the manual page
> >>
On Wed, Oct 14, 2020 at 11:24 PM Khalid Aziz wrote:
[...]
> current code? What FreeBSD does seems like a reasonable thing to do. Any
> way first thing to do is to update sparc to use arch_validate_flags()
> and update sparc_validate_prot() to not peek into vma without lock. I
> can do that unless
+objtool folks
On Tue, Oct 13, 2020 at 2:35 AM Sami Tolvanen wrote:
> Running objtool --vmlinux --duplicate on vmlinux.o produces a few
> warnings about indirect jumps with retpoline:
>
> vmlinux.o: warning: objtool: wakeup_long64()+0x61: indirect jump
> found in RETPOLINE build
> ...
>
>
On Tue, Oct 13, 2020 at 2:34 AM Sami Tolvanen wrote:
> With LTO, the compiler can rename static functions to avoid global
> naming collisions. As initcall functions are typically static,
> renaming can break references to them in inline assembly. This
> change adds a global stub with a stable
...@sipsolutions.net/
Signed-off-by: Jann Horn
---
arch/um/include/asm/mmu_context.h | 3 +--
fs/exec.c | 4
include/linux/mmap_lock.h | 23 +--
kernel/fork.c | 7 ++-
4 files changed, 28 insertions(+), 9 deletions
p code.
Suggested-by: Jason Gunthorpe
Suggested-by: Michel Lespinasse
Signed-off-by: Jann Horn
---
fs/exec.c | 68 -
include/linux/binfmts.h | 2 +-
2 files changed, 35 insertions(+), 35 deletions(-)
diff --git a/fs/exec.c b/fs/exec.c
index 229dbc
FLAT and ELF).
[1]
https://lkml.kernel.org/r/cag48ez03yjg9ju_6tgimcavjutyre_o4leq7901b5zocnna...@mail.gmail.com
Jann Horn (2):
mmap locking API: Order lock of nascent mm outside lock of live mm
exec: Broadly lock nascent mm until setup_arg_pages()
arch/um/include/asm/mmu_context.h | 3
application to know which syscalls are definitely usable. For
> the same reason, it is also guarded by CAP_SYS_ADMIN.
>
> Suggested-by: Jann Horn
> Link:
> https://lore.kernel.org/lkml/CAG48ez3Ofqp4crXGksLmZY6=fgrf_twyucg7pbkaetvbbop...@mail.gmail.com/
> Signed-off-by: YiFei Zhu
Reviewed-by: Jann Horn
ll.
>
> [1]
> https://lore.kernel.org/lkml/20200923232923.3142503-5-keesc...@chromium.org/
> [2]
> https://lore.kernel.org/lkml/CAG48ez1p=dR_2ikKq=xVxkoGg0fYpTBpkhJSv1w-6BG=76p...@mail.gmail.com/
>
> Suggested-by: Jann Horn
> Co-developed-by: Kees Cook
> Signed-off-by: Kees Cook
> Signed-off-by: YiFei Zhu
Reviewed-by: Jann Horn
Operating System Support for System Call Security
> https://tianyin.github.io/pub/draco.pdf, MICRO-53, Oct. 2020
> [7] https://lore.kernel.org/bpf/202010091614.8BB0EB64@keescook/
>
> Co-developed-by: Dimitrios Skarlatos
> Signed-off-by: Dimitrios Skarlatos
> Signed-off-by: YiFei Zhu
Reviewed-by: Jann Horn
application to know which syscalls are definitely usable. For
> the same reason, it is also guarded by CAP_SYS_ADMIN.
>
> Suggested-by: Jann Horn
> Link:
> https://lore.kernel.org/lkml/CAG48ez3Ofqp4crXGksLmZY6=fgrf_twyucg7pbkaetvbbop...@mail.gmail.com/
> Signed-off-by: YiFei Zhu
[..
ding to test the bit against the
> bitmap with the syscall number as the index of the bit in the
> bitmap, and if the bit is set, seccomp returns allow. The bitmaps
> are all clear in this patch and will be initialized in the next
> commit.
[...]
> Co-developed-by: Dimitrios Skarlatos
> Signed-off-by: Dimitrios Skarlatos
> Signed-off-by: YiFei Zhu
Reviewed-by: Jann Horn
On Fri, Oct 9, 2020 at 7:15 PM YiFei Zhu wrote:
>
> From: YiFei Zhu
>
> SECCOMP_CACHE will only operate on syscalls that do not access
> any syscall arguments or instruction pointer. To facilitate
> this we need a static analyser to know whether a filter will
> return allow regardless of syscall
On Thu, Oct 8, 2020 at 9:13 PM Jann Horn wrote:
>
> On Thu, Oct 8, 2020 at 8:24 PM Colin Ian King
> wrote:
> > Static analysis with Coverity has detected a "dead-code" issue with the
> > following commit:
> >
> > commit af9c1a44f8dee7a958e07977f24ba4
On Thu, Oct 8, 2020 at 8:24 PM Colin Ian King wrote:
> Static analysis with Coverity has detected a "dead-code" issue with the
> following commit:
>
> commit af9c1a44f8dee7a958e07977f24ba40e3c770987
> Author: Jens Axboe
> Date: Thu Sep 24 13:32:18 2020 -0600
>
> io_uring: process task work
On Thu, Oct 8, 2020 at 8:10 PM Topi Miettinen wrote:
> On 8.10.2020 20.13, Jann Horn wrote:
> > On Thu, Oct 8, 2020 at 6:54 PM Topi Miettinen wrote:
> >> Writing a new value of 3 to /proc/sys/kernel/randomize_va_space
> >> enables full randomization of memory mapp
On Thu, Oct 8, 2020 at 7:23 PM Matthew Wilcox wrote:
> On Thu, Oct 08, 2020 at 07:13:51PM +0200, Jann Horn wrote:
> > And for expanding stacks, it might be a good idea for other
> > reasons as well (locking consistency) to refactor them such that the
> > size in the
On Thu, Oct 8, 2020 at 6:54 PM Topi Miettinen wrote:
> Writing a new value of 3 to /proc/sys/kernel/randomize_va_space
> enables full randomization of memory mappings created with mmap(NULL,
> ...). With 2, the base of the VMA used for such mappings is random,
> but the mappings are created in
On Wed, Oct 7, 2020 at 2:35 PM Christoph Hellwig wrote:
> On Wed, Oct 07, 2020 at 09:39:31AM +0200, Jann Horn wrote:
> > diff --git a/arch/powerpc/kernel/syscalls.c b/arch/powerpc/kernel/syscalls.c
> > index 078608ec2e92..b1fabb97d138 100644
> > --- a/arch/powerpc/kernel/sysc
On Wed, Oct 7, 2020 at 3:09 PM Marco Elver wrote:
> On Fri, 2 Oct 2020 at 07:45, Jann Horn wrote:
> > On Tue, Sep 29, 2020 at 3:38 PM Marco Elver wrote:
> > > Add architecture specific implementation details for KFENCE and enable
> > > KFENCE for the x86
On Wed, Oct 7, 2020 at 9:42 AM Johannes Berg wrote:
> On Wed, 2020-10-07 at 00:54 +0200, Jann Horn wrote:
> > Until now, the mmap lock of the nascent mm was ordered inside the mmap lock
> > of the old mm (in dup_mmap() and in UML's activate_mm()).
> > A following patch will
_prot()")
Suggested-by: Khalid Aziz
Suggested-by: Christoph Hellwig
Signed-off-by: Jann Horn
---
arch/arm64/include/asm/mman.h | 4 ++--
arch/powerpc/include/asm/mman.h | 3 ++-
arch/powerpc/kernel/syscalls.c | 2 +-
arch/sparc/include/asm/mman.h | 6 --
include/linux/mman.h|
(, , ...|PROT_ADI), we need
to *accept* cases where the range is not fully covered by VMAs.)
Cc: sta...@vger.kernel.org
Fixes: 74a04967482f ("sparc64: Add support for ADI (Application Data
Integrity)")
Signed-off-by: Jann Horn
---
compile-tested only, I don't have a Sparc ADI setup - might be nice if
On Wed, Oct 7, 2020 at 8:17 AM Christoph Hellwig wrote:
> On Wed, Oct 07, 2020 at 02:45:39AM +0200, Jann Horn wrote:
> > > I think arch_validate_prot() is still the right hook to validate the
> > > protection bits. sparc_validate_prot() can iterate over VMAs
RNDRESEEDCRNG")
> Cc: sta...@vger.kernel.org
> Signed-off-by: Eric Biggers
Reviewed-by: Jann Horn
> ---
> drivers/char/random.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/char/random.c b/drivers/char/random.c
> index d20ba1b1
On Tue, Sep 29, 2020 at 7:30 PM Khalid Aziz wrote:
> On 9/28/20 6:14 AM, Jann Horn wrote:
> > From what I can tell from looking at the code:
> >
> > SPARC's arch_validate_prot() looks up the VMA and peeks at it; that's
> > not permitted though. do_mprotect_pkey
(bprm->vma is used after the switch
to the new mm).
I have boot-tested these patches on x64-64 (with lockdep) and
!MMU arm (the latter with both FLAT and ELF).
[1]
https://lkml.kernel.org/r/cag48ez03yjg9ju_6tgimcavjutyre_o4leq7901b5zocnna...@mail.gmail.com
Jann Horn (2):
mmap locking AP
p code.
Suggested-by: Jason Gunthorpe
Suggested-by: Michel Lespinasse
Signed-off-by: Jann Horn
---
fs/exec.c | 68 -
include/linux/binfmts.h | 2 +-
2 files changed, 35 insertions(+), 35 deletions(-)
diff --git a/fs/exec.c b/fs/exec.c
index 229dbc
the locking out of exec_mmap().
Signed-off-by: Jann Horn
---
arch/um/include/asm/mmu_context.h | 3 +--
fs/exec.c | 4
include/linux/mmap_lock.h | 23 +--
kernel/fork.c | 7 ++-
4 files changed, 28 insertions(+), 9
On Tue, Oct 6, 2020 at 7:56 PM Alexander Popov wrote:
>
> On 06.10.2020 01:56, Jann Horn wrote:
> > On Thu, Oct 1, 2020 at 9:43 PM Alexander Popov wrote:
> >> On 29.09.2020 21:35, Alexander Popov wrote:
> >>> This is the second version of the heap quarantine pro
On Tue, Oct 6, 2020 at 4:09 AM Kees Cook wrote:
> On Tue, Oct 06, 2020 at 01:44:14AM +0100, Matthew Wilcox wrote:
> > On Tue, Oct 06, 2020 at 12:56:33AM +0200, Jann Horn wrote:
> > > It seems to me like, if you want to make UAF exploitation harder at
> > > the heap al
On Tue, Oct 6, 2020 at 2:44 AM Matthew Wilcox wrote:
> On Tue, Oct 06, 2020 at 12:56:33AM +0200, Jann Horn wrote:
> > It seems to me like, if you want to make UAF exploitation harder at
> > the heap allocator layer, you could do somewhat more effective things
> > with a
On Thu, Oct 1, 2020 at 9:43 PM Alexander Popov wrote:
> On 29.09.2020 21:35, Alexander Popov wrote:
> > This is the second version of the heap quarantine prototype for the Linux
> > kernel. I performed a deeper evaluation of its security properties and
> > developed new features like quarantine
On Mon, Oct 5, 2020 at 6:01 PM Alexander Potapenko wrote:
>
> On Tue, Sep 29, 2020 at 5:06 PM Mark Rutland wrote:
> >
> > On Tue, Sep 29, 2020 at 04:51:29PM +0200, Marco Elver wrote:
> > > On Tue, 29 Sep 2020 at 16:24, Mark Rutland wrote:
> > > [...]
> > > >
> > > > From other sub-threads it
The following commit has been merged into the objtool/core branch of tip:
Commit-ID: b0b8e56b82c06b3bb6e5fb66d0e9c9c3fd3ce555
Gitweb:
https://git.kernel.org/tip/b0b8e56b82c06b3bb6e5fb66d0e9c9c3fd3ce555
Author:Jann Horn
AuthorDate:Tue, 29 Sep 2020 00:49:16 +02:00
Committer
rn code to trap to userspace")
Reviewed-by: Tycho Andersen
Signed-off-by: Jann Horn
---
NOTE: After Tycho gave his Reviewed-by, I've had to adjust the errno
to -EBUSY (my original patch broke UAPI, good thing we have selftests),
remove the unused "cur" from init_listener(), and re
On Sat, Oct 3, 2020 at 11:30 PM Michel Lespinasse wrote:
> Unrelated to the above: copy_from_user and copy_to_user should not be
> called with mmap_lock held; it may be worth adding these assertions
> too (probably in separate patches) ?
We already have that: All (hopefully?) the userspace
101 - 200 of 1477 matches
Mail list logo
