Received: by 10.223.176.46 with SMTP id f43csp1340238wra; Fri, 19 Jan 2018 10:05:08 -0800 (PST) X-Google-Smtp-Source: ACJfBosx6l0qyesjIK3UuQYyJuNDy7V6p9u1oEezJMk61TvZg9KECeRNtcWc5AFdZ5iRXWZTCLXk X-Received: by 10.101.100.214 with SMTP id t22mr41385106pgv.286.1516385108808; Fri, 19 Jan 2018 10:05:08 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1516385108; cv=none; d=google.com; s=arc-20160816; b=xt1JmHvoJ4puLLJipM9iDpmfCOSuLnjqcgwi4ujnU7vs0accrpwt9sFXhlYMNRvlmu pc7choARnWTTC4H2PzfnFuHww1vdXE4WpEMow3VNXcbPPyUpo5tSOZSsW4yIEGrrr3qy +x9rJnHaTAYzFM4eWiqacQC63fgSuoKl3zIlMSsmV6J5bD/HavbT3wOpA4MfkZM5uUyO 4hG81AYdhfM3cA1w8/7ZvvBD0/Sl016sOijfgfZilgFgtEO3fb2FyDAfRIrHk2fkac82 wsiGjqCaTPBDoIyeiYgF4/+ADUU2uOgtgX7iUjeVhBomR57XacPEEzIxhuorf6ySCWEn qZxw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:arc-authentication-results; bh=ruZZqeVtzQC3gAWLAP7fI78amSYQDhD05YwIIwf4CTQ=; b=rtjUcuBjH9baR+/cyKz7Ur+fEOgKGwYWo8X+o1JbdTlYaGRj3Dhaq5WrTWRreGkx9c w1Vf3chGuQAETeP9vUMOaldNr/JaP7GgNjqinTX6pPCqYiJp4el+4Q+ULkfYDDRj7I7y hporuRyzQtP4BExVMAfJ21tqifo7e1U9ys+xU/0NX6gHmnE8agK9DmKuB/4pxWoLkCZt 7reZtiSDHVuJzGBOZh5JkFli+6pyZe+aWjGEt+Y8IhuJsHHlYW8IaUtW41wr/NJ8Wu2o BM8curOgHBfkz4EwVmrWO85DeItfIMYqnng3Yomdhf+768cXEF7+7jDhwIPNsfhxvOrn RBsA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id l1si8706455pgn.324.2018.01.19.10.04.54; Fri, 19 Jan 2018 10:05:08 -0800 (PST) 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; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756213AbeASSDa (ORCPT + 99 others); Fri, 19 Jan 2018 13:03:30 -0500 Received: from zeniv.linux.org.uk ([195.92.253.2]:57486 "EHLO ZenIV.linux.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755949AbeASSDY (ORCPT ); Fri, 19 Jan 2018 13:03:24 -0500 Received: from viro by ZenIV.linux.org.uk with local (Exim 4.87 #1 (Red Hat Linux)) id 1ecb0c-0005IJ-K3; Fri, 19 Jan 2018 18:03:22 +0000 Date: Fri, 19 Jan 2018 18:03:22 +0000 From: Al Viro To: "Eric W. Biederman" Cc: linux-kernel@vger.kernel.org, Oleg Nesterov , linux-arch@vger.kernel.org Subject: Re: [PATCH 22/22] signal: Unify and correct copy_siginfo_to_user32 Message-ID: <20180119180322.GK13338@ZenIV.linux.org.uk> References: <87k1wimybi.fsf_-_@xmission.com> <20180116004009.31036-22-ebiederm@xmission.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180116004009.31036-22-ebiederm@xmission.com> User-Agent: Mutt/1.9.1 (2017-09-22) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Jan 15, 2018 at 06:40:09PM -0600, Eric W. Biederman wrote: > Among the existing architecture specific versions of > copy_siginfo_to_user32 there are several different implementation > problems. Some architectures fail to handle all of the cases in in > the siginfo union. Some architectures perform a blind copy of the > siginfo union when the si_code is negative. A blind copy suggests the > data is expected to be in 32bit siginfo format, which means that > receiving such a signal via signalfd won't work, or that the data is > in 64bit siginfo and the code is copying nonsense to userspace. Huh? Negative si_code comes from rt_sigqueueinfo(2); in that case the sucker is supposed to pass user-supplied opaque chunk of data in ->_sifields._pad. "Copy everything when ->si_code is negative" is exactly the right behaviour. Failing to copy it out (and in, for copy_siginfo_from_user32()) is a bug. 32bit tasks should behave on 64bit host like they would on 32bit one when we have biarch compat. And "application using sigqueueinfo() to pass data might be using different layouts of the payload" is not an excuse for failing to transmit it in the first place.