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=DKIMWL_WL_HIGH, DKIM_ADSP_CUSTOM_MED,DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SIGNED_OFF_BY,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 37E7CC83000 for ; Wed, 29 Apr 2020 21:42:27 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (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 D59FB208E0 for ; Wed, 29 Apr 2020 21:42:26 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="qxFSkSsw"; dkim=fail reason="signature verification failed" (2048-bit key) header.d=google.com header.i=@google.com header.b="OBWdSZZE" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org D59FB208E0 Authentication-Results: mail.kernel.org; dmarc=fail (p=reject dis=none) header.from=google.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+infradead-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=bombadil.20170209; h=Sender: Content-Transfer-Encoding:Content-Type:Cc:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:To:Subject:Message-ID:Date:From: In-Reply-To:References:MIME-Version:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=035vGtTfyraq303ipInN4Cup41Pztg8zlCN1B0QnZbI=; b=qxFSkSsw1PBdr6 KWPqqEupsX3uup1eo1YeuwGewRvs0kq2XiIoc/hUDKMsxBnux73wEJJY4IkIHYIw7uFj3n9gro4vj Nil9IyWDmvceDj1+fx4QIsPTVSsgADHfogxjfAz9+cXhShUMatvtiyGMpp+QB36PEI7pIDOPv5Lds 6B08xN87ZEdI5YavnyAKaMWFWHA6zsNUC6lx2hk3RnUiKb2r5BfQm0K2yF5ESs5jCh9Qqg3DV1XZb oS3rLthsd0j8Y6wPN+zs0kqlKzUKNGbRE/iOdSLHyFYCEkSuK22JsXEGcJB8pk2tsKaSlGUzHwDLA 66bRaLFtaBAuwrIpL/gQ==; Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1jTuTG-0001fc-OX; Wed, 29 Apr 2020 21:42:22 +0000 Received: from mail-wm1-x344.google.com ([2a00:1450:4864:20::344]) by bombadil.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1jTuTD-0001en-Mz for linux-arm-kernel@lists.infradead.org; Wed, 29 Apr 2020 21:42:21 +0000 Received: by mail-wm1-x344.google.com with SMTP id e26so3675964wmk.5 for ; Wed, 29 Apr 2020 14:42:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=JKDBwJcZax2PzLVw1ePltj5BC4bx576vKdr0MA9gIUc=; b=OBWdSZZEU8v5bf+acHlcUOOaYOskE6i8eOyUUgFTdXH8nkoFmXkXnUdLdKYnofMrJ9 8bPZBv9f0/i0lnKsE7WKEMsZn98XFGUhIUSpeiI7YOC/XAn8XdwfSYIfwuZHS4wnW7JN bbqvLWuKdzgCwoif3vbb3ya+xsXeK9C2HD5Cak36PsiAyNppRAyTmFrbRlOl/IBgOIFP DMQ8d7mjRUoSAb7aKg/cVigA9zcW3aZMCMeGiiSWkmND2ILJ6czhhEiQk/uIkhjPaS2l gqC2Xb09sYEu1xV/AUNNLKi7bs/tl25SeW4R9bnAbjRody6vMFzIzcC8VLo8s9tzWcRc jvEQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=JKDBwJcZax2PzLVw1ePltj5BC4bx576vKdr0MA9gIUc=; b=RlHz1qLSp4l2pn90Vknr2Evi4yFhCmA/E19vpzhgu9wm3oXEanybC5gwbVG7sk+Y2o KAurcvg9IC59Ny61pyxuAQWRdV7OJn52gHUDNCPSkv3JM74k2s66JDr0JRnsHnfYUfpN XzC9AjmlUlVBkPouzQPaS1pgZ0qBcl6+a7ApV/xD75y7V2qVTUEj7uVp8kvgb8WLVpXN 3mxrdSlSQZeu0ScvRl8OOyEJ7wAJnSraKKsc7D0Doeux/MWYTqDFC3PGV5YMn6rOQR9B g96sZG/l2Xiqrn/Pa99yNzFc+yC03EwL3zGw7Y6dnZrvG2rUyuB6IaQefjOUHXPXsrQf ijEA== X-Gm-Message-State: AGi0Pubg6sp+45CD+tR1ZFEPhKFabQKmS9BEST3xcC4PPuM8P5hfn5sz V+vPsss3hniYqsCfvU15zYXnz3LAskl94CBPuOzEvQ== X-Google-Smtp-Source: APiQypJz2j6tcSqobZP8V1gKRyP21DzGYQxJBgW2rw26J2kl+VXzqSpYuBskMD35Bfik5ALm25O8eRfCalQ5amsJVfY= X-Received: by 2002:a05:600c:21d6:: with SMTP id x22mr5661958wmj.95.1588196534951; Wed, 29 Apr 2020 14:42:14 -0700 (PDT) MIME-Version: 1.0 References: <20200325174001.234803-1-pcc@google.com> <20200327191915.257116-1-pcc@google.com> <20200429210826.GA8604@willie-the-truck> In-Reply-To: <20200429210826.GA8604@willie-the-truck> From: Peter Collingbourne Date: Wed, 29 Apr 2020 14:42:01 -0700 Message-ID: Subject: Re: [PATCH v3] arm64: Expose original FAR_EL1 value in sigcontext To: Will Deacon X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20200429_144219_773144_E8396A72 X-CRM114-Status: GOOD ( 20.31 ) 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 , Kevin Brodsky , Kostya Serebryany , Evgenii Stepanov , Andrey Konovalov , Vincenzo Frascino , Linux ARM , Richard Henderson Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Wed, Apr 29, 2020 at 2:08 PM Will Deacon wrote: > > On Fri, Mar 27, 2020 at 12:19:15PM -0700, Peter Collingbourne wrote: > > 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 far_context in > > sigcontext (similar to the existing esr_context), and store the original > > value of FAR_EL1 (including the tag bits) there. > > > > [1] http://clang.llvm.org/docs/HardwareAssistedAddressSanitizerDesign.html > > > > Signed-off-by: Peter Collingbourne > > --- > > v3: > > - add documentation to tagged-pointers.rst > > - update comments in sigcontext.h > > Hmm, although the code looks fine, why don't we just expose the tag in the > new field, rather than duplicate the address information? I'm nervous about > exposing privileged registers directly to userspace. I have no strong opinion on whether this should just contain the tag or not. > Also, Catalin, could you elaborate on the MTE use-case please? The > architecture says that FAR_EL1[63:60] are UNKNOWN on a synchronous tag > check fault, so we'd have to *avoid* exposing them in that case! The basic use case is to allow a signal handler to identify which allocation was accessed improperly in order to provide better diagnostics. For example, if you have granules tagged 1,2,3 consecutively and see an access with pointer tag 1 on the granule tagged 2, you can tell that it was probably a buffer overflow from the 1 granule and you can report that to the user. It seems unfortunate that bits 63:60 are now UNKNOWN on synchronous tag check faults. It seems to be a recent change to the specification. I can think of a number of use cases for bits 63:60 after a synchronous tag check fault -- for example, an allocator could store an additional set of random bits there, and later use them to determine with more accuracy which allocation was used after free or out of bounds. That being said, we aren't planning to do this in the initial version of the MTE-aware scudo allocator. If there is no chance of changing the architecture at this point, I will send a v4 with the bits masked out when handling a tag check fault. Peter _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel