On Mon, Oct 14, 2019 at 7:38 PM Hridya Valsaraju wrote:
> On Fri, Oct 11, 2019 at 3:11 PM Jann Horn wrote:
> > On Fri, Oct 11, 2019 at 11:59 PM Jann Horn wrote:
> > > (I think you could also let A receive a handle
> > > to itself and then transact with i
On Mon, Oct 14, 2019 at 8:16 PM Daniel Colascione wrote:
> On Mon, Oct 14, 2019 at 8:39 AM Jann Horn wrote:
> >
> > On Sat, Oct 12, 2019 at 9:16 PM Daniel Colascione wrote:
> > > Add functions forwarding from the old names to the new ones so we
> > >
On Sun, Oct 13, 2019 at 3:14 AM Andy Lutomirski wrote:
> [adding more people because this is going to be an ABI break, sigh]
> On Sat, Oct 12, 2019 at 5:52 PM Daniel Colascione wrote:
> > On Sat, Oct 12, 2019 at 4:10 PM Andy Lutomirski wrote:
> > > On Sat, Oct 12, 2019 at 12:16 PM Daniel
On Sat, Oct 12, 2019 at 9:16 PM Daniel Colascione wrote:
> Add functions forwarding from the old names to the new ones so we
> don't need to change any callers.
This patch does more than the commit message says; it also refactors
the body of the function. (I would've moved that refactoring over
On Sat, Oct 12, 2019 at 12:19 PM Christian Brauner
wrote:
> Currently, the fdinfo file of contains the field Pid:
nit: something missing after "of"?
> It contains the pid a given pidfd refers to in the pid namespace of the
> opener's procfs instance.
s/opener's // here and in various places
On Mon, Oct 14, 2019 at 12:32 PM Christian Brauner
wrote:
> On Mon, Oct 14, 2019 at 11:43:01AM +0200, Christian Kellner wrote:
> > On Sat, 2019-10-12 at 12:21 +0200, Christian Brauner wrote:
> > > I tried to think of cases where the first entry of Pid is not
> > > identical
> > > to the first
On Fri, Oct 11, 2019 at 11:59 PM Jann Horn wrote:
> (I think you could also let A receive a handle
> to itself and then transact with itself, but I haven't tested that.)
Ignore this sentence, that's obviously wrong because same-binder_proc
nodes will always show up as a binder, not a handle.
On Mon, Jul 15, 2019 at 9:18 PM Hridya Valsaraju wrote:
> Currently, a transaction to context manager from its own process
> is prevented by checking if its binder_proc struct is the same as
> that of the sender. However, this would not catch cases where the
> process opens the binder device
On Fri, Oct 11, 2019 at 6:58 PM Christian Brauner
wrote:
> On Fri, Oct 11, 2019 at 05:30:03PM +0200, Jann Horn wrote:
> > On Fri, Oct 11, 2019 at 5:17 PM Christian Brauner
> > wrote:
> > >
> > > On Fri, Oct 11, 2019 at 04:55:59PM +0200, Jann Horn wrote:
> &
On Fri, Oct 11, 2019 at 5:17 PM Christian Brauner
wrote:
>
> On Fri, Oct 11, 2019 at 04:55:59PM +0200, Jann Horn wrote:
> > On Fri, Oct 11, 2019 at 2:23 PM Christian Kellner
> > wrote:
> > > The fdinfo file for a process file descriptor already contains t
On Wed, Oct 9, 2019 at 6:10 PM Christian Kellner wrote:
> Add tests that check that if pid namespaces are configured the fdinfo
> file of a pidfd contains an NSpid: entry containing the process id
> in the current and additionally all nested namespaces.
[...]
> +static int
On Fri, Oct 11, 2019 at 2:23 PM Christian Kellner wrote:
> The fdinfo file for a process file descriptor already contains the
> pid of the process in the callers namespaces. Additionally, if pid
> namespaces are configured, show the process ids of the process in
> all nested namespaces in the
Hi!
There is a use-after-free read in print_binder_transaction_log_entry()
on ANDROID_BINDERFS kernels because
print_binder_transaction_log_entry() prints the char* e->context_name
as string, and if the transaction occurred on a binder device from
binderfs, e->context_name belongs to the binder
On Thu, Oct 3, 2019 at 4:56 PM Aleksa Sarai wrote:
> Traditionally, magic-links have not been a well-understood topic in
> Linux. Given the new changes in their semantics (related to the link
> mode of trailing magic-links), it seems like a good opportunity to shine
> more light on magic-links
On Sun, Oct 6, 2019 at 6:49 PM Salvatore Mesoraca
wrote:
> Salvatore Mesoraca wrote:
> > Jann Horn wrote:
> > > On Sat, Jul 6, 2019 at 12:55 PM Salvatore Mesoraca
> > > wrote:
> > > > Creation of a generic Discrete Finite Automata implementation
>
+Kostya (code owner for LLVM sanitizer_common) as FYI
On Wed, Oct 2, 2019 at 12:54 AM Eric W. Biederman wrote:
> Kees Cook writes:
> > On Tue, Oct 01, 2019 at 01:36:32PM -0500, Eric W. Biederman wrote:
[...]
> > I think you can actually take this further and remove (or at least
> > empty) the
On Mon, Sep 23, 2019 at 1:26 PM Florian Weimer wrote:
> * Michael Kerrisk:
> >The pidfd_send_signal() system call allows the avoidance of race
> >conditions that occur when using traditional interfaces (such as
> >kill(2)) to signal a process. The problem is that the
On Fri, Sep 20, 2019 at 4:37 PM Andy Lutomirski wrote:
> It has no effect any more, so remove it. We can revert this if
> there is some user code that expects to be able to set this sysctl.
>
> Signed-off-by: Andy Lutomirski
> ---
> drivers/char/random.c | 18 +-
> 1 file
On Thu, Sep 19, 2019 at 11:59 AM Christian Brauner
wrote:
> This allows the seccomp notifier to continue a syscall.
[...]
> Recently we landed seccomp support for SECCOMP_RET_USER_NOTIF (cf. [4])
> which enables a process (watchee) to retrieve an fd for its seccomp
> filter. This fd can then be
On Tue, Aug 13, 2019 at 12:09 PM Michal Hocko wrote:
> On Mon 12-08-19 20:14:38, Jann Horn wrote:
> > On Wed, Aug 7, 2019 at 7:16 PM Joel Fernandes (Google)
> > wrote:
> > > The page_idle tracking feature currently requires looking up the pagemap
> > > for
On Tue, Aug 13, 2019 at 4:25 PM Joel Fernandes wrote:
> On Tue, Aug 13, 2019 at 12:08:56PM +0200, Michal Hocko wrote:
> > On Mon 12-08-19 20:14:38, Jann Horn wrote:
> > > On Wed, Aug 7, 2019 at 7:16 PM Joel Fernandes (Google)
> > > wrote:
> > > > The page_i
Commit-ID: cb361d8cdef69990f6b4504dc1fd9a594d983c97
Gitweb: https://git.kernel.org/tip/cb361d8cdef69990f6b4504dc1fd9a594d983c97
Author: Jann Horn
AuthorDate: Tue, 16 Jul 2019 17:20:47 +0200
Committer: Ingo Molnar
CommitDate: Thu, 25 Jul 2019 15:37:05 +0200
sched/fair: Use RCU
Commit-ID: 16d51a590a8ce3befb1308e0e7ab77f3b661af33
Gitweb: https://git.kernel.org/tip/16d51a590a8ce3befb1308e0e7ab77f3b661af33
Author: Jann Horn
AuthorDate: Tue, 16 Jul 2019 17:20:45 +0200
Committer: Ingo Molnar
CommitDate: Thu, 25 Jul 2019 15:37:04 +0200
sched/fair: Don't free p
On Wed, Jul 24, 2019 at 8:27 PM Christian Brauner wrote:
> On July 24, 2019 8:14:26 PM GMT+02:00, Jann Horn wrote:
> >On Wed, Jul 24, 2019 at 4:48 PM Christian Brauner
> > wrote:
> >> If CLONE_WAIT_PID is set the newly created process will not be
> >> co
On Wed, Jul 24, 2019 at 4:48 PM Christian Brauner wrote:
> If CLONE_WAIT_PID is set the newly created process will not be
> considered by process wait requests that wait generically on children
> such as:
>
> syscall(__NR_wait4, -1, wstatus, options, rusage)
>
On Wed, Jul 24, 2019 at 5:54 PM Kees Cook wrote:
> On Wed, Jul 24, 2019 at 04:28:31PM +0200, Jann Horn wrote:
> > On Wed, Jul 24, 2019 at 12:17 AM Kees Cook wrote:
> > > Perhaps we need a "statistics" counter type for these kinds of counters?
> > > "cou
On Wed, Jul 24, 2019 at 12:17 AM Kees Cook wrote:
> On Tue, Jul 23, 2019 at 04:53:47PM +0200, Jann Horn wrote:
> > On Mon, Jul 22, 2019 at 3:44 PM Ondrej Mosnacek wrote:
> > > On Mon, Jul 22, 2019 at 1:35 PM NitinGote wrote:
> > > > refcount_t type and correspond
On Mon, Jul 22, 2019 at 3:44 PM Ondrej Mosnacek wrote:
> On Mon, Jul 22, 2019 at 1:35 PM NitinGote wrote:
> > refcount_t type and corresponding API should be
> > used instead of atomic_t when the variable is used as
> > a reference counter. This allows to avoid accidental
> > refcounter
Commit-ID: bd98c81346468fc2f86aeeb44d4d0d6f763a62b7
Gitweb: https://git.kernel.org/tip/bd98c81346468fc2f86aeeb44d4d0d6f763a62b7
Author: Jann Horn
AuthorDate: Wed, 17 Jul 2019 20:36:54 -0500
Committer: Thomas Gleixner
CommitDate: Thu, 18 Jul 2019 21:01:09 +0200
objtool: Support
Commit-ID: 50e04acf2990d0d93983720b0a85b11ef805df60
Gitweb: https://git.kernel.org/tip/50e04acf2990d0d93983720b0a85b11ef805df60
Author: Jann Horn
AuthorDate: Sat, 13 Jul 2019 00:41:52 +0200
Committer: Thomas Gleixner
CommitDate: Wed, 17 Jul 2019 00:42:27 +0200
x86/process: Delete
Commit-ID: 68c2976d7d93392d33ccd8871e9e61b33b5e640f
Gitweb: https://git.kernel.org/tip/68c2976d7d93392d33ccd8871e9e61b33b5e640f
Author: Jann Horn
AuthorDate: Sat, 13 Jul 2019 00:41:52 +0200
Committer: Thomas Gleixner
CommitDate: Tue, 16 Jul 2019 23:13:50 +0200
x86/process: Delete
At release_thread(), ->mm is NULL; and it is fine for the former mm to
still have an LDT. Delete this check in process_64.c, similar to
commit 2684927c6b93 ("[PATCH] x86: Deprecate useless bug"), which did the
same in process_32.c.
Signed-off-by: Jann Horn
---
arch/x86/kernel/proc
On Thu, Jul 11, 2019 at 11:00 PM Arnd Bergmann wrote:
>
> On Thu, Jul 11, 2019 at 7:26 PM Josh Poimboeuf wrote:
> >
> > On Thu, Jul 11, 2019 at 02:40:06PM +0200, Arnd Bergmann wrote:
> > > During randconfig testing with clang-9, I came across an object file
> > > that makes objtool segfault, see
On Sun, Jul 7, 2019 at 6:01 PM Salvatore Mesoraca
wrote:
> Jann Horn wrote:
> > Throughout the series, you are adding files that both add an SPDX
> > identifier and have a description of the license in the comment block
> > at the top. The SPDX identifier already identifi
On Sat, Jul 6, 2019 at 12:55 PM Salvatore Mesoraca
wrote:
> Creation of a generic Discrete Finite Automata implementation
> for string matching. The transition tables have to be produced
> in user-space.
> This allows us to possibly support advanced string matching
> patterns like regular
On Sat, Jul 6, 2019 at 12:55 PM Salvatore Mesoraca
wrote:
> Prevent a task from opening, in "write" mode, any /proc/*/mem
> file that operates on the task's mm.
> A process could use it to overwrite read-only memory, bypassing
> S.A.R.A. restrictions.
[...]
> +static void
On Fri, Jun 28, 2019 at 9:35 PM Joel Fernandes (Google)
wrote:
> struct pid's count is an atomic_t field used as a refcount. Use
> refcount_t for it which is basically atomic_t but does additional
> checking to prevent use-after-free bugs.
[...]
> struct pid
> {
> - atomic_t count;
> +
On Mon, Jun 24, 2019 at 8:52 PM Joel Fernandes wrote:
> On Mon, Jun 24, 2019 at 02:45:34PM -0400, Joel Fernandes (Google) wrote:
> > struct pid's count is an atomic_t field used as a refcount. Use
> > refcount_t for it which is basically atomic_t but does additional
> > checking to prevent
On Tue, Jun 18, 2019 at 6:55 AM Kees Cook wrote:
> With sensitive CR4 bits pinned now, it's possible that the WP bit for
> CR0 might become a target as well. Following the same reasoning for
> the CR4 pinning, this pins CR0's WP bit (but this can be done with a
> static value).
>
> Suggested-by:
On Fri, May 31, 2019 at 10:04 PM Nadav Amit wrote:
> > On May 31, 2019, at 12:20 PM, Jann Horn wrote:
> > On Fri, May 31, 2019 at 8:29 PM Nadav Amit wrote:
> >> [ +Jann Horn ]
> >>
> >>> On May 31, 2019, at 3:57 AM, Peter Zijlstra wrote:
> >&
On Fri, May 31, 2019 at 3:35 PM Oleg Nesterov wrote:
> On 05/31, Jann Horn wrote:
> >
> > So I guess I should make a v2 that still adds the smp_rmb() in
> > __ptrace_may_access(), but gets rid of the smp_wmb() in
> > commit_creds()? (With a comment above the rcu_assign_
On Fri, May 31, 2019 at 8:29 PM Nadav Amit wrote:
>
> [ +Jann Horn ]
>
> > On May 31, 2019, at 3:57 AM, Peter Zijlstra wrote:
> >
> > On Thu, May 30, 2019 at 11:36:44PM -0700, Nadav Amit wrote:
> >> When we flush userspace mappings, we can defer the TLB
On Thu, May 30, 2019 at 3:42 AM Eric W. Biederman wrote:
> Jann Horn writes:
>
> > I'm actually trying to get rid of the ->mm access in
> > __ptrace_may_access() entirely by moving the dumpability and the
> > user_ns into the signal_struct, but I don't have patc
On Thu, May 30, 2019 at 2:35 PM Oleg Nesterov wrote:
> On 05/29, Jann Horn wrote:
> > --- a/kernel/cred.c
> > +++ b/kernel/cred.c
> > @@ -450,6 +450,15 @@ int commit_creds(struct cred *new)
> > if (task->mm)
> >
On Wed, May 29, 2019 at 6:21 PM Oleg Nesterov wrote:
> On 05/29, Jann Horn wrote:
> > --- a/kernel/ptrace.c
> > +++ b/kernel/ptrace.c
> > @@ -324,6 +324,16 @@ static int __ptrace_may_access(struct task_struct
> > *task, unsigned int mode)
[...]
> > mm = tas
On Wed, May 29, 2019 at 6:21 PM Oleg Nesterov wrote:
> On 05/29, Jann Horn wrote:
> > (I have no clue whatsoever what the relevant tree for this is, but I
> > guess Oleg is the relevant maintainer?)
>
> we usually route ptrace changes via -mm tree, plus I lo
On Wed, May 29, 2019 at 5:59 PM Eric W. Biederman wrote:
> Jann Horn writes:
>
> > Restore the read memory barrier in __ptrace_may_access() that was deleted
> > a couple years ago. Also add comments on this barrier and the one it pairs
> > with to explain why th
On Wed, May 29, 2019 at 2:32 PM John Paul Adrian Glaubitz
wrote:
> On 5/28/19 12:56 PM, Greg Ungerer wrote:
> >> Maybe... but I didn't want to rip it out without having one of the
> >> maintainers confirm that this really isn't likely to be used anymore.
> >
> > I have not used shared libraries
ssion checks")
Cc: sta...@vger.kernel.org
Signed-off-by: Jann Horn
---
(I have no clue whatsoever what the relevant tree for this is, but I
guess Oleg is the relevant maintainer?)
kernel/cred.c | 9 +
kernel/ptrace.c | 10 ++
2 files changed, 19 insertions(+)
diff --gi
-terminated before passing it to
strcmp().
Cc: sta...@vger.kernel.org
Signed-off-by: Jann Horn
---
Warning: The existence of this bug has not been verified at runtime, and
the patch is compile-tested only. I noticed this while browsing through
the code, but didn't want to spend the time necessary
+Kees
On Mon, May 27, 2019 at 9:27 PM Linus Torvalds
wrote:
> On Mon, May 27, 2019 at 3:42 AM Christian Brauner
> wrote:
> > Hm, still pondering whether having one unsigned int argument passed
> > through registers that captures all the flags from the old clone() would
> > be a good idea.
>
>
On Sat, May 25, 2019 at 11:43 PM Andrew Morton
wrote:
> On Fri, 24 May 2019 22:18:17 +0200 Jann Horn wrote:
> > load_flat_shared_library() is broken: It only calls load_flat_file() if
> > prepare_binprm() returns zero, but prepare_binprm() returns the number of
> > byte
ot;, "file" and "filename" of the
linux_binprm struct. Instead, call kernel_read() directly.
Cc: sta...@vger.kernel.org
Fixes: 287980e49ffc ("remove lots of IS_ERR_VALUE abuses")
Signed-off-by: Jann Horn
---
I only found the bug by looking at the code, I have not
On Tue, May 21, 2019 at 7:04 PM Kirill Tkhai wrote:
> On 21.05.2019 19:20, Jann Horn wrote:
> > On Tue, May 21, 2019 at 5:52 PM Kirill Tkhai wrote:
> >> On 21.05.2019 17:43, Andy Lutomirski wrote:
> >>> On Mon, May 20, 2019 at 7:01 AM Kirill Tkhai wrote:
&g
On Tue, May 21, 2019 at 5:52 PM Kirill Tkhai wrote:
> On 21.05.2019 17:43, Andy Lutomirski wrote:
> > On Mon, May 20, 2019 at 7:01 AM Kirill Tkhai wrote:
> >> New syscall, which allows to clone a remote process VMA
> >> into local process VM. The remote process's page table
> >> entries related
On Thu, May 16, 2019 at 4:43 PM Oleksandr Natalenko
wrote:
> On Thu, May 16, 2019 at 04:20:13PM +0200, Oleksandr Natalenko wrote:
> > > [...]
> > > > @@ -2960,15 +2962,63 @@ static int proc_stack_depth(struct seq_file *m,
> > > > struct pid_namespace *ns,
> > > > static ssize_t
On Thu, May 16, 2019 at 4:20 PM Oleksandr Natalenko
wrote:
> On Thu, May 16, 2019 at 12:00:24PM +0200, Jann Horn wrote:
> > On Thu, May 16, 2019 at 11:43 AM Oleksandr Natalenko
> > wrote:
> > > Use previously introduced remote madvise knob to mark task's
> > &
On Thu, May 16, 2019 at 3:08 PM Christian Brauner wrote:
> On Wed, May 15, 2019 at 10:45:06AM -0700, Daniel Colascione wrote:
> > On Wed, May 15, 2019 at 3:04 AM Christian Brauner
> > wrote:
> > >
> > > This adds the pidfd_open() syscall. It allows a caller to retrieve
> > > pollable
> > >
On Wed, May 15, 2019 at 5:11 PM Kirill Tkhai wrote:
> This patchset adds a new syscall, which makes possible
> to clone a mapping from a process to another process.
> The syscall supplements the functionality provided
> by process_vm_writev() and process_vm_readv() syscalls,
> and it may be
On Thu, May 16, 2019 at 3:03 PM Kirill Tkhai wrote:
> On 15.05.2019 21:46, Jann Horn wrote:
> > On Wed, May 15, 2019 at 5:11 PM Kirill Tkhai wrote:
> >> This patchset adds a new syscall, which makes possible
> >> to clone a mapping from a process to another process.
&
On Thu, May 16, 2019 at 11:43 AM Oleksandr Natalenko
wrote:
> Use previously introduced remote madvise knob to mark task's
> anonymous memory as mergeable.
>
> To force merging task's VMAs, "merge" hint is used:
>
># echo merge > /proc//madvise
>
> Force unmerging is done similarly:
>
>#
On Wed, May 15, 2019 at 5:11 PM Kirill Tkhai wrote:
> This patchset adds a new syscall, which makes possible
> to clone a mapping from a process to another process.
> The syscall supplements the functionality provided
> by process_vm_writev() and process_vm_readv() syscalls,
> and it may be
On Fri, May 10, 2019 at 02:20:23PM -0700, Andy Lutomirski wrote:
> On Fri, May 10, 2019 at 1:41 PM Jann Horn wrote:
> >
> > On Tue, May 07, 2019 at 05:17:35AM +1000, Aleksa Sarai wrote:
> > > On 2019-05-06, Jann Horn wrote:
> > > > In my opinion, CVE-2019-57
On Thu, May 09, 2019 at 01:24:20PM +0200, Roberto Sassu wrote:
> This patch adds support for an alternative method to add xattrs to files in
> the rootfs filesystem. Instead of extracting them directly from the ram
> disk image, they are extracted from a regular file called .xattr-list, that
> can
On Thu, May 09, 2019 at 01:24:18PM +0200, Roberto Sassu wrote:
> Similarly to commit 03450e271a16 ("fs: add ksys_fchmod() and do_fchmodat()
> helpers and ksys_chmod() wrapper; remove in-kernel calls to syscall"), this
> patch introduces the ksys_lsetxattr() helper to avoid in-kernel calls to
> the
On Tue, May 07, 2019 at 05:17:35AM +1000, Aleksa Sarai wrote:
> On 2019-05-06, Jann Horn wrote:
> > In my opinion, CVE-2019-5736 points out two different problems:
> >
> > The big problem: The __ptrace_may_access() logic has a special-case
> > short-circuit for "i
On Tue, May 07, 2019 at 07:38:58PM -0500, Eric W. Biederman wrote:
> Jann Horn writes:
> > In my opinion, CVE-2019-5736 points out two different problems:
> >
> > The big problem: The __ptrace_may_access() logic has a special-case
> > short-circuit for "intro
On Mon, May 6, 2019 at 6:56 PM Aleksa Sarai wrote:
> The need to be able to scope path resolution of interpreters became
> clear with one of the possible vectors used in CVE-2019-5736 (which
> most major container runtimes were vulnerable to).
>
> Naively, it might seem that openat(2) -- which
to
userspace
Signed-off-by: Jann Horn
---
compile-tested only, so you might want to test this before applying the
patch
drivers/misc/habanalabs/debugfs.c | 60 ++-
1 file changed, 18 insertions(+), 42 deletions(-)
diff --git a/drivers/misc/habanalabs/debugfs.c
b/drivers/misc
On Fri, May 3, 2019 at 2:12 PM Joel Savitz wrote:
> When PR_GET_TASK_SIZE is passed to prctl, the kernel will attempt to
> copy the value of TASK_SIZE to the userspace address in arg2.
A commit message shouldn't just describe what you're doing, but also
why you're doing it. Is this intended for
[extremely slow reply]
On Fri, Mar 2, 2018 at 4:26 PM Matthew Wilcox wrote:
> Here's my third effort to handle page->_mapcount overflows.
>
> The idea is to minimise overhead, so we keep a list of users with more
> than 5000 mappings. In order to overflow _mapcount, you have to have
> 2 billion
On Mon, Apr 29, 2019 at 4:21 PM Linus Torvalds
wrote:
>
> On Mon, Apr 29, 2019 at 12:55 PM Jann Horn wrote:
> >
> > ... I guess that already has a name, and it's called vfork(). (Well,
> > except that the Linux vfork() isn't a real vfork().)
>
> What?
>
> Lin
On Mon, Apr 29, 2019 at 3:30 PM Jann Horn wrote:
> On Sat, Apr 20, 2019 at 3:14 AM Kevin Easton wrote:
> > On Mon, Apr 15, 2019 at 01:29:23PM -0700, Andy Lutomirski wrote:
> > > On Mon, Apr 15, 2019 at 12:59 PM Aleksa Sarai wrote:
> > > >
> > > > On 20
On Sat, Apr 20, 2019 at 3:14 AM Kevin Easton wrote:
> On Mon, Apr 15, 2019 at 01:29:23PM -0700, Andy Lutomirski wrote:
> > On Mon, Apr 15, 2019 at 12:59 PM Aleksa Sarai wrote:
> > >
> > > On 2019-04-15, Enrico Weigelt, metux IT consult wrote:
> > > > > This patchset makes it possible to
On Sun, Apr 28, 2019 at 10:30 PM kernel test robot
wrote:
> FYI, we noticed the following commit (built with gcc-7):
>
> commit: 0830cf62f5290b2f878faacc2b6f32e77bc2ea12 ("x86/unwind: Add hardcoded
> ORC entry for NULL")
> https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable-rc.git
On Fri, Apr 26, 2019 at 3:47 PM Michal Hocko wrote:
> On Fri 26-04-19 15:33:25, Jann Horn wrote:
> > On Fri, Apr 26, 2019 at 7:31 AM Michal Hocko wrote:
> > > On Thu 25-04-19 14:42:52, Jann Horn wrote:
> > > > On Thu, Apr 25, 2019 at 2:14 PM Michal Hocko wrote:
>
On Fri, Apr 26, 2019 at 7:31 AM Michal Hocko wrote:
> On Thu 25-04-19 14:42:52, Jann Horn wrote:
> > On Thu, Apr 25, 2019 at 2:14 PM Michal Hocko wrote:
> > [...]
> > > On Wed 24-04-19 14:10:39, Matthew Garrett wrote:
> > > > From: Matthew Garrett
> >
On Thu, Apr 25, 2019 at 6:14 PM Dmitry Safonov wrote:
> Time Namespace isolates clock values.
>
> The kernel provides access to several clocks CLOCK_REALTIME,
> CLOCK_MONOTONIC, CLOCK_BOOTTIME, etc.
>
> CLOCK_REALTIME
> System-wide clock that measures real (i.e., wall-clock) time.
>
>
On Thu, Apr 25, 2019 at 6:17 PM Dmitry Safonov wrote:
> Although, time namespace can work with VVAR VMA split, it seems worth
> to forbid splitting VVAR resulting in stricter ABI and reducing amount
> of corner-cases to consider while working further on VDSO.
[...]
> diff --git
On Thu, Apr 25, 2019 at 6:14 PM Dmitry Safonov wrote:
>
> As it has been discussed on timens RFC, adding a new conditional branch
> `if (inside_time_ns)` on VDSO for all processes is undesirable.
> It will add a penalty for everybody as branch predictor may mispredict
> the jump. Also there are
On Thu, Apr 25, 2019 at 6:15 PM Dmitry Safonov wrote:
> API to set time namespace offsets for children processes, i.e.:
> echo "clockid off_ses off_nsec" > /proc/self/timens_offsets
[...]
> diff --git a/fs/proc/base.c b/fs/proc/base.c
> index 6a803a0b75df..76d58e9b5178 100644
> ---
On Thu, Apr 25, 2019 at 6:15 PM Dmitry Safonov wrote:
> As it has been discussed on timens RFC, adding a new conditional branch
> `if (inside_time_ns)` on VDSO for all processes is undesirable.
> It will add a penalty for everybody as branch predictor may mispredict
> the jump. Also there are
On Thu, Apr 25, 2019 at 2:14 PM Michal Hocko wrote:
[...]
> On Wed 24-04-19 14:10:39, Matthew Garrett wrote:
> > From: Matthew Garrett
> >
> > Applications that hold secrets and wish to avoid them leaking can use
> > mlock() to prevent the page from being pushed out to swap and
> > MADV_DONTDUMP
On Wed, Apr 24, 2019 at 6:14 PM David Howells wrote:
> Move the user and user-session keyrings to the user_namespace struct rather
> than pinning them from the user_struct struct. This prevents these
> keyrings from propagating across user-namespaces boundaries with regard to
> the KEY_SPEC_*
+linux-api, +musl
On Tue, Apr 23, 2019 at 8:12 PM Kees Cook wrote:
> The READ_IMPLIES_EXEC work-around was designed for old CPUs lacking NX
> (to have the visible permission flags on memory regions reflect reality:
> they are all executable), and for old toolchains that lacked the ELF
>
On Wed, Apr 17, 2019 at 3:09 PM Oleg Nesterov wrote:
> On 04/16, Joel Fernandes wrote:
> > On Tue, Apr 16, 2019 at 02:04:31PM +0200, Oleg Nesterov wrote:
> > >
> > > Could you explain when it should return POLLIN? When the whole process
> > > exits?
> >
> > It returns POLLIN when the task is
Commit-ID: 7e94a7b659eefedda82cde97229a26f319fb1182
Gitweb: https://git.kernel.org/tip/7e94a7b659eefedda82cde97229a26f319fb1182
Author: Jann Horn
AuthorDate: Thu, 4 Apr 2019 13:11:28 +0200
Committer: Borislav Petkov
CommitDate: Wed, 10 Apr 2019 22:40:25 +0200
x86/microcode/intel
On Fri, Apr 5, 2019 at 10:02 PM Aubrey Li wrote:
> AVX-512 components use could cause core turbo frequency drop. So
> it's useful to expose AVX-512 usage elapsed time as a heuristic hint
> for the user space job scheduler to cluster the AVX-512 using tasks
> together.
>
> Tensorflow example:
> $
On Thu, Apr 4, 2019 at 6:47 PM Borislav Petkov wrote:
> On Thu, Apr 04, 2019 at 06:31:37PM +0200, Jann Horn wrote:
> > Uuuh. I *definitely* tested this. I ran this yesterday evening on my
> > home machine, on top of commit
> > 14c741de93861749dfb60b4964028541f5c506ca from
g refcount_t.
- The pointers stored in ->private were only zeroed out when the last
reference to the buffer_ref was dropped. As far as I know, this
shouldn't be necessary anyway, but if we do it, let's always do it.
Cc: sta...@vger.kernel.org # v4.11
Signed-off-by: Jann Horn
---
Completely untes
On Thu, Apr 4, 2019 at 6:28 PM Borislav Petkov wrote:
>
> On Thu, Apr 04, 2019 at 01:11:28PM +0200, Jann Horn wrote:
> > This changes generic_load_microcode() to use the iov_iter API instead of
> > an open-coded version. This allows us to avoid explicitly casting between
&
of the microcode header (which
could e.g. lead to out-of-bounds reads in microcode_sanity_check()).
Not that it matters much, only root can do this anyway...
Signed-off-by: Jann Horn
---
I have tested that with this patch applied, microcode loading still works
both via "iucode-tool -k" an
Commit-ID: a6cbfbe6677efb5ca47bb7958c2718236c25126e
Gitweb: https://git.kernel.org/tip/a6cbfbe6677efb5ca47bb7958c2718236c25126e
Author: Jann Horn
AuthorDate: Fri, 29 Mar 2019 22:46:52 +0100
Committer: Borislav Petkov
CommitDate: Wed, 3 Apr 2019 16:26:17 +0200
x86/uaccess: Fix implicit
Commit-ID: 89833fab15d6017ba006a45b5af68caa067171a7
Gitweb: https://git.kernel.org/tip/89833fab15d6017ba006a45b5af68caa067171a7
Author: Jann Horn
AuthorDate: Fri, 29 Mar 2019 22:46:51 +0100
Committer: Borislav Petkov
CommitDate: Wed, 3 Apr 2019 14:12:40 +0200
x86/fpu: Fix __user
Commit-ID: a0fe2c6479aab5723239b315ef1b552673f434a3
Gitweb: https://git.kernel.org/tip/a0fe2c6479aab5723239b315ef1b552673f434a3
Author: Jann Horn
AuthorDate: Fri, 29 Mar 2019 22:46:49 +0100
Committer: Borislav Petkov
CommitDate: Wed, 3 Apr 2019 11:43:49 +0200
linux/kernel.h: Use
On Tue, Apr 2, 2019 at 5:10 AM kernel test robot wrote:
> FYI, we noticed the following commit (built with gcc-7):
>
> commit: c1e0d2be0acff5e99a59ddcc5af415e48abc6c5e ("mt76: mmio: introduce
> mt76x02_check_tx_hang watchdog")
> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git
On Mon, Apr 1, 2019 at 7:30 PM Borislav Petkov wrote:
>
> On Fri, Mar 29, 2019 at 10:46:50PM +0100, Jann Horn wrote:
> > generic_load_microcode() deals with a pointer that can be either a kernel
> > pointer or a user pointer. Pass it around as a __user pointer so that it
> &g
On Mon, Apr 1, 2019 at 4:36 PM David Laight wrote:
>
> From: Jann Horn
> > Sent: 28 March 2019 21:23
> > Fix __user annotations in various places across the x86 tree:
> >
> ...
> > - generic_load_microcode() deals with a pointer that can be either a
> &
On Mon, Apr 1, 2019 at 2:04 PM Christian Brauner wrote:
> On Sun, Mar 31, 2019 at 08:13:38PM -0600, Andy Lutomirski wrote:
> > > On Mar 31, 2019, at 3:17 PM, Linus Torvalds
> > > wrote:
> > >> On Sun, Mar 31, 2019 at 2:10 PM Christian Brauner
> > >> wrote:
> > >>
> > >> I don't think that we
On Mon, Apr 1, 2019 at 12:33 AM Christian Brauner wrote:
> On Sun, Mar 31, 2019 at 03:16:47PM -0700, Linus Torvalds wrote:
> > On Sun, Mar 31, 2019 at 3:03 PM Christian Brauner
> > wrote:
> > > Thanks for the input. The problem Jann and I saw with this is that it
> > > would be awkward to have
401 - 500 of 1477 matches
Mail list logo
