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=-8.8 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=unavailable 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 AAF16C63777 for ; Fri, 20 Nov 2020 19:25:54 +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 4ECBC221F1 for ; Fri, 20 Nov 2020 19:25:54 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="MWyKbo8U" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 4ECBC221F1 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=HlQ6RSrmhuFv1iSfxn5M/UqcDhbwHzmslA2vdqVMWGw=; b=MWyKbo8UDg+oemli5lNpk4F/3 83GmAX1JcvlFGr8LsFSdBBp9Xvdp9Evb1Jz/POi28AqU+p7KzcKSjVm1J1P5jJJpk/C9lsgSS2e8A VT3kFhwo4IxZRdiXFgZQPo1B2EpkDKO9KIbhoa9jjcqujpk8F5tOliCrxjbEDVLA7AVLoaWvEn1TD +5DgZNK00Iaz6Dqw6KOVde0uV5menuavDwHoxb7ucQDFczrRBwemo09KteOZbIl6ftla5PzzkN7Be jt8anY5ljLOO0FYcUMNtkO3h/EDoDDDqiYyZl/qxRAO8Ji6eNuGFBrZCNAfNmMOzQgfhJ9eBxZeUq V4HTZN7Pw==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1kgC1P-00042v-4Z; Fri, 20 Nov 2020 19:24:39 +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 1kgC1M-000424-TF for linux-arm-kernel@lists.infradead.org; Fri, 20 Nov 2020 19:24:38 +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 1kgC1F-0027H7-IK; Fri, 20 Nov 2020 12:24:29 -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 1kgC1E-00DlwZ-C7; Fri, 20 Nov 2020 12:24:29 -0700 From: ebiederm@xmission.com (Eric W. Biederman) To: Peter Collingbourne References: <20201119190921.3589081-1-pcc@google.com> <87wnyf3ovs.fsf@x220.int.ebiederm.org> Date: Fri, 20 Nov 2020 13:24:07 -0600 In-Reply-To: (Peter Collingbourne's message of "Fri, 20 Nov 2020 10:22:47 -0800") Message-ID: <878sav3k88.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=1kgC1E-00DlwZ-C7; ; ; mid=<878sav3k88.fsf@x220.int.ebiederm.org>; ; ; hst=in02.mta.xmission.com; ; ; ip=68.227.160.95; ; ; frm=ebiederm@xmission.com; ; ; spf=neutral X-XM-AID: U2FsdGVkX1+i7MlS8U5d+nsb2ZYbkgq9Wmx9qV+PC10= X-SA-Exim-Connect-IP: 68.227.160.95 X-SA-Exim-Mail-From: ebiederm@xmission.com Subject: Re: [PATCH v20] 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-20201120_142437_053008_2CAD9A96 X-CRM114-Status: GOOD ( 22.62 ) 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 , "James E.J. Bottomley" , Kostya Serebryany , Linux ARM , Andrey Konovalov , David Spickett , Vincenzo Frascino , Will Deacon , Dave Martin , Evgenii Stepanov 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: > On Fri, Nov 20, 2020 at 9:44 AM Eric W. Biederman wrote: >> >> 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, introduce a flag in >> > sigaction.sa_flags, SA_EXPOSE_TAGBITS, and only expose the tag bits >> > there if the signal handler has this flag set. >> > >> > [1] http://clang.llvm.org/docs/HardwareAssistedAddressSanitizerDesign.html >> >> For the generic bits: >> Acked-by: "Eric W. Biederman" > > Thanks for the review. > >> Some of the arm bits look wrong. There are a couple of cases where >> it looks like you are deliberately passing an untagged address into >> functions that normally take tagged addresses. >> >> It might be a good idea to have a type distinction between the two. >> Perhaps "(void __user *)" vs "(unsigned long)" so that accidentally >> using the wrong one generates a type error. >> >> I don't think I am really qualified to review all of the arm details, >> and I certainly don't want to be in the middle of any arm bugs this >> code might introduce. If you will split out the generic bits of this >> patch I will take it. The this whole thing can be merged into the arm > > Okay, I'll do that. Thank you. >> tree and you can ensure the arm bits are correct. > > So you want Catalin to merge your signal-for-v5.11 branch with the > generic patches into the arm64 tree and then add the arm64-specific > patch on top? Works for me. I think that is what we discussed. Unless he has objections I would prefer that. I based the branch on -rc3 in hopes that I would not cause problems for his process. In the cases where I was confused you probably want comments describing why the tag bits are being cleared. It may be obvious when you know the architecture intimately but it certainly was not for me. I certainly don't know the details of arm64 well enough to understand the architecture specific nuances. Eric _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel