From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.7 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 646A7C388F9 for ; Mon, 16 Nov 2020 21:55:38 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 1E285222E8 for ; Mon, 16 Nov 2020 21:55:38 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726621AbgKPVzh (ORCPT ); Mon, 16 Nov 2020 16:55:37 -0500 Received: from out02.mta.xmission.com ([166.70.13.232]:46636 "EHLO out02.mta.xmission.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727130AbgKPVzh (ORCPT ); Mon, 16 Nov 2020 16:55:37 -0500 Received: from in01.mta.xmission.com ([166.70.13.51]) by out02.mta.xmission.com with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.93) (envelope-from ) id 1kemT4-00Bu1J-50; Mon, 16 Nov 2020 14:55:22 -0700 Received: from ip68-227-160-95.om.om.cox.net ([68.227.160.95] helo=x220.xmission.com) by in01.mta.xmission.com with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.87) (envelope-from ) id 1kemT3-0005JW-7s; Mon, 16 Nov 2020 14:55:22 -0700 From: ebiederm@xmission.com (Eric W. Biederman) To: Catalin Marinas Cc: Peter Collingbourne , Evgenii Stepanov , Kostya Serebryany , Vincenzo Frascino , Dave Martin , Will Deacon , Oleg Nesterov , "James E.J. Bottomley" , Linux ARM , Kevin Brodsky , Andrey Konovalov , linux-api@vger.kernel.org, Helge Deller , David Spickett References: <81e1307108ca8ea67aa1060f6f47b34a507410f1.1605235762.git.pcc@google.com> Date: Mon, 16 Nov 2020 15:55:05 -0600 In-Reply-To: (Catalin Marinas's message of "Mon, 16 Nov 2020 19:01:18 +0000") Message-ID: <87d00dge6e.fsf@x220.int.ebiederm.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-XM-SPF: eid=1kemT3-0005JW-7s;;;mid=<87d00dge6e.fsf@x220.int.ebiederm.org>;;;hst=in01.mta.xmission.com;;;ip=68.227.160.95;;;frm=ebiederm@xmission.com;;;spf=neutral X-XM-AID: U2FsdGVkX19k++9Pb29rKqviHnrrXVeKG7pYWi03qds= X-SA-Exim-Connect-IP: 68.227.160.95 X-SA-Exim-Mail-From: ebiederm@xmission.com Subject: Re: [PATCH v16 6/6] arm64: expose FAR_EL1 tag bits in siginfo X-SA-Exim-Version: 4.2.1 (built Thu, 05 May 2016 13:38:54 -0600) X-SA-Exim-Scanned: Yes (on in01.mta.xmission.com) Precedence: bulk List-ID: X-Mailing-List: linux-api@vger.kernel.org Catalin Marinas writes: > On Thu, Nov 12, 2020 at 06:53:36PM -0800, Peter Collingbourne wrote: >> diff --git a/Documentation/arm64/tagged-pointers.rst b/Documentation/arm64/tagged-pointers.rst >> index eab4323609b9..19d284b70384 100644 >> --- a/Documentation/arm64/tagged-pointers.rst >> +++ b/Documentation/arm64/tagged-pointers.rst >> @@ -53,12 +53,25 @@ visibility. >> Preserving tags >> --------------- >> >> -Non-zero tags are not preserved when delivering signals. This means that >> -signal handlers in applications making use of tags cannot rely on the >> -tag information for user virtual addresses being maintained for fields >> -inside siginfo_t. One exception to this rule is for signals raised in >> -response to watchpoint debug exceptions, where the tag information will >> -be preserved. >> +When delivering signals, non-zero tags are not preserved in >> +siginfo.si_addr unless the flag SA_EXPOSE_TAGBITS was set in >> +sigaction.sa_flags when the signal handler was installed. This means >> +that signal handlers in applications making use of tags cannot rely >> +on the tag information for user virtual addresses being maintained >> +in these fields unless the flag was set. >> + >> +Due to architecture limitations, bits 63:60 of the fault address >> +are not preserved in response to synchronous tag check faults >> +(SEGV_MTESERR) even if SA_EXPOSE_TAGBITS was set. Applications should >> +treat the values of these bits as undefined in order to accommodate >> +future architecture revisions which may preserve the bits. > > If future architecture versions will preserve these bits, most likely > we'll add a new HWCAP bit so that the user knows what's going on. But > the user shouldn't rely on them being 0, just in case. > >> +For signals raised in response to watchpoint debug exceptions, the >> +tag information will be preserved regardless of the SA_EXPOSE_TAGBITS >> +flag setting. >> + >> +Non-zero tags are never preserved in sigcontext.fault_address >> +regardless of the SA_EXPOSE_TAGBITS flag setting. > > We could've done it the other way around (fault_address tagged, si_addr > untagged) but that would be specific to arm64, so I think we should > solve it for other architectures that implement (or plan to) tagging. > The fault_address in the arm64 sigcontext was an oversight, we should > have removed it but when we realised it was already ABI. > > Anyway, I'm fine with the arm64 changes here: > > Reviewed-by: Catalin Marinas > > With Eric's ack, I'm happy to take the series through the arm64 tree, > otherwise Eric's tree is fine as well. In general I am fine with the last two patches. I want to understand where the value for SA_UNSUPPORTED comes from, and while I have good answers I am still digesting the question of if SA_EXPOSE_TAGBITS should be implemented in the arch specific header or in a generic header. I quite agree it should have a generic definition/implementation. I just don't know if it makes sense to make the value available to userspace if the architecture does not have tagbits. Mostly my concern is about bit consumption as we only have 30ish sigaction bits. I will follow with my acks when I have resolved those issues. Thank you, Eric