From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756558AbeASVF1 (ORCPT ); Fri, 19 Jan 2018 16:05:27 -0500 Received: from out02.mta.xmission.com ([166.70.13.232]:36821 "EHLO out02.mta.xmission.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756525AbeASVFK (ORCPT ); Fri, 19 Jan 2018 16:05:10 -0500 From: ebiederm@xmission.com (Eric W. Biederman) To: Al Viro Cc: linux-kernel@vger.kernel.org, Oleg Nesterov , linux-arch@vger.kernel.org References: <87k1wimybi.fsf_-_@xmission.com> <20180116004009.31036-22-ebiederm@xmission.com> <20180119180322.GK13338@ZenIV.linux.org.uk> Date: Fri, 19 Jan 2018 15:04:15 -0600 In-Reply-To: <20180119180322.GK13338@ZenIV.linux.org.uk> (Al Viro's message of "Fri, 19 Jan 2018 18:03:22 +0000") Message-ID: <87shb1a7cg.fsf@xmission.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-XM-SPF: eid=1ecdqX-0004CH-1I;;;mid=<87shb1a7cg.fsf@xmission.com>;;;hst=in02.mta.xmission.com;;;ip=97.121.73.102;;;frm=ebiederm@xmission.com;;;spf=neutral X-XM-AID: U2FsdGVkX18GvsaK6E2X5vI/Ic5FQ+SZ/qIh2bp3kWw= X-SA-Exim-Connect-IP: 97.121.73.102 X-SA-Exim-Mail-From: ebiederm@xmission.com X-Spam-Report: * -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP * 0.7 XMSubLong Long Subject * 1.5 XMNoVowels Alpha-numberic number with no vowels * 0.5 XMGappySubj_01 Very gappy subject * 0.0 TVD_RCVD_IP Message was received from an IP address * 0.0 T_TM2_M_HEADER_IN_MSG BODY: No description available. * 0.8 BAYES_50 BODY: Bayes spam probability is 40 to 60% * [score: 0.5000] * -0.0 DCC_CHECK_NEGATIVE Not listed in DCC * [sa06 1397; Body=1 Fuz1=1 Fuz2=1] * 0.0 T_TooManySym_01 4+ unique symbols in subject * 1.0 T_XMDrugObfuBody_08 obfuscated drug references X-Spam-DCC: XMission; sa06 1397; Body=1 Fuz1=1 Fuz2=1 X-Spam-Combo: ***;Al Viro X-Spam-Relay-Country: X-Spam-Timing: total 247 ms - load_scoreonly_sql: 0.03 (0.0%), signal_user_changed: 2.6 (1.0%), b_tie_ro: 1.76 (0.7%), parse: 0.77 (0.3%), extract_message_metadata: 11 (4.5%), get_uri_detail_list: 1.93 (0.8%), tests_pri_-1000: 6 (2.2%), tests_pri_-950: 1.16 (0.5%), tests_pri_-900: 1.01 (0.4%), tests_pri_-400: 22 (9.0%), check_bayes: 21 (8.6%), b_tokenize: 7 (2.8%), b_tok_get_all: 7 (3.0%), b_comp_prob: 2.4 (1.0%), b_tok_touch_all: 2.4 (1.0%), b_finish: 0.58 (0.2%), tests_pri_0: 196 (79.2%), check_dkim_signature: 0.48 (0.2%), check_dkim_adsp: 2.6 (1.1%), tests_pri_500: 4.0 (1.6%), rewrite_mail: 0.00 (0.0%) Subject: Re: [PATCH 22/22] signal: Unify and correct copy_siginfo_to_user32 X-Spam-Flag: No X-SA-Exim-Version: 4.2.1 (built Thu, 05 May 2016 13:38:54 -0600) X-SA-Exim-Scanned: Yes (on in02.mta.xmission.com) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Al Viro writes: > 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. If glibc actually offered rt_sigqueueinfo or any function that would queue a full siginfo that would be a compelling argument. As it is the only users of rt_sigqueueinfo that I am aware of is CRIU and the implementation of sigqueue. A couple of months ago I went hunting for users and for anyone who was defining si_codes and I did not find a single instance of anything defining signals that would pass more information than is known to the kernel, and except for CRIU all I found was limited to what you can do with sigqueue. So no I do not think my choice will cause a regression. Further SI_TIMER which the kernel does send is also negative. The difference between negative and positive is that negative si_codes are supposed to be signal agnostic and positive si_codes are signal specific. If this causes a single regression, or if anyone can point me at the code of an application this will cause a regression for. I will change the code right then and there. My concern is that people have not been careful when defining new signals. What looks like rules in one place are not the rules in another place. If we had been careful struct siginfo would be the same on both 32bit and 64bit, and in singalfd. As it is I am battling accidental redefinitions of SI_USER by the kernel to be something else. I think it is far more likley that someone will define a signal layout that needs help going from 64bit to 32bit that my choice not copying all of the bits will catch, rather than I will break some existing userspace application. And if we catch it and the siginfo needs translation because we are not commited to copying everything we can fix it. Which is a long way of saying I think it would be gravely irresponsible to just copy all of the bits of struct siginfo when si_code is negative. Eric