Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
From:   Bernd Edlinger <bernd.edlinger@hotmail.de>
To:     Oleg Nesterov <oleg@redhat.com>
CC:     Jann Horn <jannh@google.com>,
        Christian Brauner <christian.brauner@ubuntu.com>,
        Jonathan Corbet <corbet@lwn.net>,
        Alexander Viro <viro@zeniv.linux.org.uk>,
        Andrew Morton <akpm@linux-foundation.org>,
        Alexey Dobriyan <adobriyan@gmail.com>,
        "Eric W. Biederman" <ebiederm@xmission.com>,
        Thomas Gleixner <tglx@linutronix.de>,
        Frederic Weisbecker <frederic@kernel.org>,
        Andrei Vagin <avagin@gmail.com>,
        Ingo Molnar <mingo@kernel.org>,
        "Peter Zijlstra (Intel)" <peterz@infradead.org>,
        Yuyang Du <duyuyang@gmail.com>,
        David Hildenbrand <david@redhat.com>,
        Sebastian Andrzej Siewior <bigeasy@linutronix.de>,
        Anshuman Khandual <anshuman.khandual@arm.com>,
        David Howells <dhowells@redhat.com>,
        James Morris <jamorris@linux.microsoft.com>,
        Kees Cook <keescook@chromium.org>,
        Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
        Shakeel Butt <shakeelb@google.com>,
        Jason Gunthorpe <jgg@ziepe.ca>,
        Christian Kellner <christian@kellner.me>,
        Andrea Arcangeli <aarcange@redhat.com>,
        Aleksa Sarai <cyphar@cyphar.com>,
        "Dmitry V. Levin" <ldv@altlinux.org>,
        "linux-doc@vger.kernel.org" <linux-doc@vger.kernel.org>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        "linux-fsdevel@vger.kernel.org" <linux-fsdevel@vger.kernel.org>,
        "linux-mm@kvack.org" <linux-mm@kvack.org>,
        "stable@vger.kernel.org" <stable@vger.kernel.org>
Subject: Re: [PATCHv2] exec: Fix a deadlock in ptrace
Thread-Topic: [PATCHv2] exec: Fix a deadlock in ptrace
Thread-Index: AQHV8AjGwZG4WijWc0+aQpdADP+q6qg1PBaAgAA5/QA=
Date:   Mon, 2 Mar 2020 15:56:04 +0000
Message-ID: <AM6PR03MB51706D69E3F0126237DDD110E4E70@AM6PR03MB5170.eurprd03.prod.outlook.com>
References: <AM6PR03MB5170B06F3A2B75EFB98D071AE4E60@AM6PR03MB5170.eurprd03.prod.outlook.com>
 <CAG48ez3QHVpMJ9Rb_Q4LEE6uAqQJeS1Myu82U=fgvUfoeiscgw@mail.gmail.com>
 <20200301185244.zkofjus6xtgkx4s3@wittgenstein>
 <CAG48ez3mnYc84iFCA25-rbJdSBi3jh9hkp569XZTbFc_9WYbZw@mail.gmail.com>
 <AM6PR03MB5170EB4427BF5C67EE98FF09E4E60@AM6PR03MB5170.eurprd03.prod.outlook.com>
 <20200302122828.GA9769@redhat.com>
In-Reply-To: <20200302122828.GA9769@redhat.com>
Accept-Language: en-US, en-GB, de-DE
Content-Language: en-US
x-ms-exchange-messagesentrepresentingtype: 1
x-tmn:  [RgRM/hymeKlspWJoHmyR0Ulb73pdTH9g]
x-microsoft-original-message-id: <a3723c53-2c41-ed50-309f-ba0d8555f67b@hotmail.de>
x-ms-publictraffictype: Email
x-incomingheadercount: 50
x-eopattributedmessage: 0
x-ms-office365-filtering-correlation-id: b61d0c25-2554-4b5a-1def-08d7bec23679
x-ms-traffictypediagnostic: VE1EUR01HT123:
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: zGFfTOXtwopFCtyvp7ptFwafemwNiCw/uWpTmVi+SLPvY/6zuwibbsn8jTFPu/q2u2H6q8coBRQSeCgdgFDYwHrY3rtF5IsrQXElOAMtsrgIiN5EHlgln0I7tWBp6pwuZO7kOf9/huDfs3VB5dZWQAnep8rzczUeg+2gWknmc1KDpBTdjEbspnnS2QTbrGb2lvk4zzlDGbQQ27IB//zFxqMUM5tkCXNn1q4/dbz4gEE=
x-ms-exchange-antispam-messagedata: 5b5OpsuSrxieJKpRNkYaSOPnTdNv+Phjlo/8abt2jrLPA/WxuhhMsDmFiKcLHzV+6jKJLoxI6QI9LkQJHYJcQn0kl/B+AwkcAN4XXQUap6t+GL3Qw5sqxWNdwePFmm7WZmHpszbmMt79ctrvP8Wu2w==
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="Windows-1252"
Content-ID: <AF6DD11A35CDD44D93462FA5182F8F18@eurprd03.prod.outlook.com>
Content-Transfer-Encoding: 8BIT
MIME-Version: 1.0
X-OriginatorOrg: outlook.com
X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: 00000000-0000-0000-0000-000000000000
X-MS-Exchange-CrossTenant-Network-Message-Id: b61d0c25-2554-4b5a-1def-08d7bec23679
X-MS-Exchange-CrossTenant-rms-persistedconsumerorg: 00000000-0000-0000-0000-000000000000
X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Mar 2020 15:56:04.6412
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Internet
X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa
X-MS-Exchange-Transport-CrossTenantHeadersStamped: VE1EUR01HT123
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org


On 3/2/20 1:28 PM, Oleg Nesterov wrote:
> On 03/01, Bernd Edlinger wrote:
>>
>> This fixes a deadlock in the tracer when tracing a multi-threaded
>> application that calls execve while more than one thread are running.
> 
> Heh. Yes, known problem. See my attempt to fix it:
> https://lore.kernel.org/lkml/20170213141452.GA30203@redhat.com/
> 
>> @@ -1224,7 +1224,7 @@ struct mm_struct *mm_access(struct task_struct *task, unsigned int mode)
>>  	struct mm_struct *mm;
>>  	int err;
>>  
>> -	err =  mutex_lock_killable(&task->signal->cred_guard_mutex);
>> +	err =  mutex_lock_killable(&task->signal->cred_change_mutex);
> 
> So if I understand correctly your patch doesn't fix other problems
> with debugger waiting for cred_guard_mutex.
> 

No, but I see this just as a first step.

> I too do not think this can justify the new mutex in signal_struct...
> 

I think for the vm_access the semantic of this mutex is clear, that it
prevents the credentials to change while it is held by vm_access,
and probably other places can take advantage of this mutex as well.

While on the other hand, the cred_guard_mutex is needed to avoid two
threads calling execve at the same time.  So that is needed as well.

What remains is probably making PTHREAD_ATTACH detect that the process
is currently in execve, and make that call fail in that situation.
I have not thought in depth about that problem, but it will probably
just need the right mutex to access current->in_execve.


That's at least how I see it.


Thanks
Bernd.