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=-11.7 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_ADSP_CUSTOM_MED,DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_PATCH,MAILING_LIST_MULTI,MENTIONS_GIT_HOSTING,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 8F4C3C388F9 for ; Tue, 17 Nov 2020 03:24:52 +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 127A22469D for ; Tue, 17 Nov 2020 03:24:52 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="WlrbjHx7"; dkim=fail reason="signature verification failed" (2048-bit key) header.d=google.com header.i=@google.com header.b="SoCpXYdK" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 127A22469D 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+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: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=rV/JJX3JepLfZOPMbsQ6CULkCuq/0uQn1Ln7ibvPjrQ=; b=WlrbjHx7PAzXc8wml1eZhVEEA je+f3mVrmnSnjDaXT6VdJ/SQxZgyQdB2qwvBQNl3byObpBYf2756kgjBzi293chWBu55/JwRq2zZ3 2q4kRWLUF/VT58eXTaXx1+aqbhVX/CCURiPmcO/V8f1A8bhB7xhmYqW5+dwZAwUNFpgAYCP1RJKb+ Eixl22S3DmGB8P5d790tr5CRROJCjsuGJzHLtoh8DDtEHZWZ9AnCY/9Stu7W51MDy0SJwgTvvleq8 YtSbKOXDMNdELjKG87ynIlmw1JoFCfb6yev+HJfrZR1HcSarYIohVkSAFiKWz/e3idj8hT9D8oJBh 4DyiKauTg==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1kerbT-00052l-Qg; Tue, 17 Nov 2020 03:24:23 +0000 Received: from mail-vs1-xe44.google.com ([2607:f8b0:4864:20::e44]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1kerbQ-00052L-Vg for linux-arm-kernel@lists.infradead.org; Tue, 17 Nov 2020 03:24:21 +0000 Received: by mail-vs1-xe44.google.com with SMTP id v6so3855535vsd.1 for ; Mon, 16 Nov 2020 19:24:20 -0800 (PST) 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=7bUE7eowWyTAfTCkBC54YowXOHCPhLYjgh4SWAH3er4=; b=SoCpXYdKaMfUey5hz/0ORT5wWigeWdqjVHjkfuPTxmcw1eGFtOQoqEn9jpISPl4OBP IqLy4G1bPAa+U9/pajJm8GZgaAwX2dxfOfyrUm4eyA0lgqkOjInYcNW+xY/k/WzY9x4K bajGMHrEIH4kWY+OL7hL3rg9R/Ja4R+XslK/y+dBIwUTzu6DW0QkPQW5Sew2XGzV0hpH 5cSLx0yk4XOgIpPn2LbGcoV5yrKcV7VY2Jemm264LKFzH/IGLArLsIiVKgQ978fskC69 Jni1J+jnj3iIRmCaKPXmUK8F/Dv+VA/zPL5bAoaSwb1newfq+N39aiNpYS3gCyxEMcmi G2bQ== 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=7bUE7eowWyTAfTCkBC54YowXOHCPhLYjgh4SWAH3er4=; b=hpkHLoeiOx7kfV5SWiWAJAqK0Tl8RP25pnKvTnYGbkxrvhSXVBGnLpc2z0//xQjTdT UbnhzMrUfhmSclKWwv83I2aKEt7+AEhFohtgtorHABY4yd/2/PnyHBE56cWoB0XCwCmx 6BlzhjbIP2HRntB8z1IOk2ju2WkSw8EXj2V4Ly4i8KnuQ+azFEO7n9SdGgm8nFXRW/Bu nNbL2OuO7r9j4ZHYUVJOZanX2VLbuQjgmxNuhwAmBbErQvALvFZvWnMDrixMFJZ9MOZL GCbtR6IlwZDNt8KKhw4oRv1kFOhct/I6KM51wesRlQVAW5l+IqW+qp1lL8EeMw/JOnUi mYPw== X-Gm-Message-State: AOAM533QthRJpPWBleZsLuuJj5yQ1bXhKNy+X/MShgYtj7+CR8knahMm Kfq2JBh+rdyrOZwyiU4znxeYETMdf+9aEZFwrpOEyg== X-Google-Smtp-Source: ABdhPJz6Bb0nsQlOEK8y9bK6IdZPCfKqAzP+ygzodz5EeSxj9Aa/a2hOAzmMp83idVzYIAk1vUr4/fUXqqm1HOkM0Bk= X-Received: by 2002:a05:6102:1173:: with SMTP id k19mr9859636vsg.51.1605583458850; Mon, 16 Nov 2020 19:24:18 -0800 (PST) MIME-Version: 1.0 References: <81e1307108ca8ea67aa1060f6f47b34a507410f1.1605235762.git.pcc@google.com> <87d00dge6e.fsf@x220.int.ebiederm.org> <878sb0g8ek.fsf@x220.int.ebiederm.org> In-Reply-To: <878sb0g8ek.fsf@x220.int.ebiederm.org> From: Peter Collingbourne Date: Mon, 16 Nov 2020 19:24:07 -0800 Message-ID: Subject: Re: [PATCH v16 6/6] arm64: expose FAR_EL1 tag bits in siginfo To: "Eric W. Biederman" X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20201116_222421_103292_812DDE0F X-CRM114-Status: GOOD ( 43.76 ) 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 On Mon, Nov 16, 2020 at 4:00 PM Eric W. Biederman wrote: > > Peter Collingbourne writes: > > > On Mon, Nov 16, 2020 at 1:55 PM Eric W. Biederman wrote: > >> > >> 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 > > > > I hope I explained it well enough in [1]. If documenting the > > arch-specific bits that way looks good to you let me know and I will > > update patch 3. > > Bah. I missed your reply. > > Please send me an incremental patch against: > > https://git.kernel.org/pub/scm/linux/kernel/git/ebiederm/user-namespace.git signal-for-v5.11 > > As I have already applied your first 4 patches and have them in > linux-next. Okay, I've sent a v17 to be applied on top of your branch. > >> 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. > > > > As mentioned in [2] I would favor making the bits generic as that > > would simplify the client code. And I would personally not be too > > concerned about consuming bits here. Our historical rate of adding new > > bits is very low (as far as I know these are the first new bits to be > > added in about 20 years!) And once we are at the point where we are > > close to running out of bits it would be a good time to consider a new > > sigaction API anyway that addresses some of the historical warts of > > the existing one, and at that point we should be able to come up with > > a way to add more bits. > > It is a good point that this areay hasn't seen much action in ages. So > there is not too much need to be concerned. > > In general portable code will need to do "#ifdef SA_EXPOSE_TAGBITS" > somewhere. But certainly it should be at least as generic as Sure. It's worth noting though that if you know that you are targeting Linux and have the latest kernel headers (which is the case for Android platform code for example) you would be able to use new #defines unconditionally. > SA_RESTORER. With the same meaning everywhere it is defined. > And certainly it makes sense for the implementation to live > in the generic signal code for to ensure all architectures implement > it with the same semantics. > > I am going to sleep on this one and then see if I see any real concerns. > > This is bike-shedding I know, and you have done a very nice job gettin > this far. So I don't expect I will come up with any compelling reasons > to change after sleeping on it, but I am going to sleep on it. Okay, let me know if you find any concerns. Peter _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel