Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 28 Apr 2020 23:20:20 +0200
From: Florian Weimer <>
To: Jann Horn <>
Cc: Mickaël Salaün <>,  kernel list
 <>,  Aleksa Sarai <>,  Alexei
 Starovoitov <>,  Al Viro <>,  Andy
 Lutomirski <>,  Christian Heimes <>,
  Daniel Borkmann <>,  Deven Bowers
 <>,  Eric Chiang <>,
    James Morris <>,  Jan Kara <>,  Jonathan
 Corbet <>,  Kees Cook <>,  Matthew
 Garrett <>,  Matthew Wilcox <>,
  Michael Kerrisk <>,  Mickaël Salaün
 <>,  Mimi Zohar <>,  Philippe
 Trébuchet <>,  Scott Shell
 <>,  Sean Christopherson
 <>,  Shuah Khan <>,  Steve
 Dower <>,  Steve Grubb <>,  Thibaut
 Sautereau <>,  Vincent Strubel
 <>,  Kernel Hardening
 <>,  Linux API
 <>,  linux-security-module
 <>,  linux-fsdevel
Subject: Re: [PATCH v3 0/5] Add support for RESOLVE_MAYEXEC

* Jann Horn:

> Just as a comment: You'd probably also have to use RESOLVE_MAYEXEC in
> the dynamic linker.

Absolutely.  In typical configurations, the kernel does not enforce
that executable mappings must be backed by files which are executable.
It's most obvious with using an explicit loader invocation to run
executables on noexec mounts.  RESOLVE_MAYEXEC is much more useful
than trying to reimplement the kernel permission checks (or what some
believe they should be) in userspace.

Powered by blists - more mailing lists

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.