lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Tue, 21 Feb 2017 11:30:56 +1300
From: (Eric W. Biederman)
To:     Oleg Nesterov <>
Cc:     Andrew Morton <>,
        Mika Penttilä 
        <>, Aleksa Sarai <>,
        Andy Lutomirski <>,
        Attila Fazekas <>,
        Jann Horn <>, Kees Cook <>,
        Michal Hocko <>,
        Ulrich Obergfell <>,
Subject: Re: [PATCH V2 1/2] exec: don't wait for zombie threads with cred_guard_mutex held


My apologies for not replying in-line but I think I can be clearer just
saying what I think needs to be said.

Today cred_guard_mutex is part of making exec appear to be an atomic
operation to ptrace and and proc.  To make exec appear to be atomic
we do need to take the mutex at the beginning and release it at the end
of exec.

The semantics of exec appear atomic to ptrace_attach and to proc readers
are necessary to ensure we use the proper process credentials in the
event of a suid exec.

I believe making cred_guard_mutex per task is an option.  Reducing the
scope of cred_guard_mutex concerns me.  There appear to be some fields
like sighand that we currently expose in proc that might possibly be
problematic.  So I am not certain we protect enough things in our proc

Do you know if we can make cred_guard_mutex a per-task lock again?


Powered by blists - more mailing lists