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=-3.8 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,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 33FF7C2D0A3 for ; Tue, 10 Nov 2020 01:13:51 +0000 (UTC) Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id AA13A206D8 for ; Tue, 10 Nov 2020 01:13:50 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="AoGIF5aA" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org AA13A206D8 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=xmission.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=merlin.20170209; h=Sender:Content-Transfer-Encoding: Content-Type:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:Subject:MIME-Version:Message-ID:In-Reply-To:Date: References:To:From:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=4kBmhcCw1RzGYZJwYJe6PWOKGF3A2TOcDn7rwwDnIIg=; b=AoGIF5aAGEyBgh4Cmi7ZxAlns aGMCToHLtEDt4IzNJ8QaXMxNZ8yV3jBBQOd2lWr59vWnMRKqqd8tJ02/zbVvpKw2NTYb7RQI+5i+O AqjqiqGUJ6n3k01sHp1A6wCkJ1gfPhCYQobA2Xtd+CE8PJR6l8Q+LvgBNKaCSTsSTbRsyN5HMqZ5H KNI3nwdmOivlo1sZNIlXtCfDDCCFTAMBNfY0/tduPlhxTR1qkAkOQgT8v0s1/1T7/O+JneGth5W+h UNzcxABxbMeYb4DfVTOnMQAeqiqxAYAerj4tfsYu5+M9bQ3YpHpgdoYgwEEU9jc0RiAPANUgYPf02 AvJ+JSNdw==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1kcIDw-0006mf-IU; Tue, 10 Nov 2020 01:13:28 +0000 Received: from out02.mta.xmission.com ([166.70.13.232]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1kcIDu-0006lz-Ec for linux-arm-kernel@lists.infradead.org; Tue, 10 Nov 2020 01:13:27 +0000 Received: from in02.mta.xmission.com ([166.70.13.52]) by out02.mta.xmission.com with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.93) (envelope-from ) id 1kcIDm-00GbIv-Hx; Mon, 09 Nov 2020 18:13:18 -0700 Received: from ip68-227-160-95.om.om.cox.net ([68.227.160.95] helo=x220.xmission.com) by in02.mta.xmission.com with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.93) (envelope-from ) id 1kcIDl-00BdYI-6y; Mon, 09 Nov 2020 18:13:17 -0700 From: ebiederm@xmission.com (Eric W. Biederman) To: Peter Collingbourne References: <0ce3d90b5d6a4457b2fe3b0582f61fab70b17dfc.1604523707.git.pcc@google.com> Date: Mon, 09 Nov 2020 19:13:08 -0600 In-Reply-To: <0ce3d90b5d6a4457b2fe3b0582f61fab70b17dfc.1604523707.git.pcc@google.com> (Peter Collingbourne's message of "Wed, 4 Nov 2020 13:18:11 -0800") Message-ID: <87eel2ypy3.fsf@x220.int.ebiederm.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux) MIME-Version: 1.0 X-XM-SPF: eid=1kcIDl-00BdYI-6y; ; ; mid=<87eel2ypy3.fsf@x220.int.ebiederm.org>; ; ; hst=in02.mta.xmission.com; ; ; ip=68.227.160.95; ; ; frm=ebiederm@xmission.com; ; ; spf=neutral X-XM-AID: U2FsdGVkX19VidFgsnztWeSnS7Dkd47UYXIvr2cg2X4= X-SA-Exim-Connect-IP: 68.227.160.95 X-SA-Exim-Mail-From: ebiederm@xmission.com Subject: Re: [PATCH v14 8/8] arm64: expose FAR_EL1 tag bits in siginfo X-SA-Exim-Version: 4.2.1 (built Sat, 08 Feb 2020 21:53:50 +0000) X-SA-Exim-Scanned: Yes (on in02.mta.xmission.com) X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20201109_201326_548470_5B060A5C X-CRM114-Status: GOOD ( 19.37 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Catalin Marinas , Helge Deller , Kevin Brodsky , Oleg Nesterov , linux-api@vger.kernel.org, "James E.J. Bottomley" , Kostya Serebryany , Linux ARM , Andrey Konovalov , David Spickett , Vincenzo Frascino , Will Deacon , Dave Martin , Evgenii Stepanov , Richard Henderson Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org Peter Collingbourne writes: > The kernel currently clears the tag bits (i.e. bits 56-63) in the fault > address exposed via siginfo.si_addr and sigcontext.fault_address. However, > the tag bits may be needed by tools in order to accurately diagnose > memory errors, such as HWASan [1] or future tools based on the Memory > Tagging Extension (MTE). > > We should not stop clearing these bits in the existing fault address > fields, because there may be existing userspace applications that are > expecting the tag bits to be cleared. Instead, create a new pair of > fields in siginfo._sigfault, and store the tag bits of FAR_EL1 there, > together with a mask specifying which bits are valid. > > A flag is added to si_faultflags to allow userspace to determine whether > the values in the fields are valid. I think I am missing some things: Today it is documented that the tag bits are cleared, and so we can't use the highbits to hold the tag bits by default. Why do you need to deliver which tag bits are valid? That feels like an implementation detail that is needed to setup the tag bits. It feels like it would be constant per process. So I don't understand why the siginfo needs to report information the process should already have. Want prevents adding a sigaction sa_flag SA_EXPOSE_TABITS that when set causes the high bits to be set, and when clear (the default) will have the signal delivery code clear those bits. That should be enough for code that wants the tag bits to ask for them. As userspace would need to be updated to get the new bits Even if you have chained handlers. The chaining mechanism would need to be updated and it could call the aware handlers first then clear the tag bits and call the rest of the handlers. It feels like always passing the tag bits in the address and then clearing them in the copy to userspace if the signal handler is not ready for them would be easier to maintain. Eric _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel