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=-15.2 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER, INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED, USER_AGENT_SANE_1 autolearn=ham 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 D4A10C4361B for ; Tue, 8 Dec 2020 17:35:49 +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 949F723B28 for ; Tue, 8 Dec 2020 17:35:49 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 949F723B28 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=arm.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:In-Reply-To:MIME-Version:References:Message-ID: Subject:To:From:Date:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=LRd8f599z5russU5grw1HebP+JUM5okWkthbMlyZhDc=; b=mb9QN8Nk5m0S8Xej94s/FauqZ e2HClnkBC/bEW/W2uFrTCGvCy/lp28nh6lYPiMAaBgBogm9/LctFWl20uIGhv0RtxzukgHhEdmxgg ecSiNlUnIur9xbd4FtNrPZKP4IUNSyZnVuAB+IFFG/5/SLRDrG9NpseTa4apuZBK/V/CmoAishHSN a3cQqG/SMf87HiZfQQdbi5qigw9XwRtfD5hVGkICd/gydWglqA3QUuCwwyYWAi3GMMu19xqrQx4+z AVQMP6VxmZo8EA/CVMccPCvkTN1qNKMkW7oKf1tu/v1CiYUNPhO2IQtk/8FS22+VkiRAt4uVOHjjs RkZmfkXfQ==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1kmgsl-00052V-Gc; Tue, 08 Dec 2020 17:34:35 +0000 Received: from mail.kernel.org ([198.145.29.99]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1kmgsj-00052B-Gg for linux-arm-kernel@lists.infradead.org; Tue, 08 Dec 2020 17:34:34 +0000 Date: Tue, 8 Dec 2020 17:34:29 +0000 From: Catalin Marinas To: Dave Martin Subject: Re: [PATCH 2/2] arm64: Introduce HWCAPS2_EXECONLY Message-ID: <20201208173429.GC13960@gaia> References: <20201119133953.15585-1-vladimir.murzin@arm.com> <20201119133953.15585-3-vladimir.murzin@arm.com> <20201208163614.GS6882@arm.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20201208163614.GS6882@arm.com> User-Agent: Mutt/1.10.1 (2018-07-13) X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20201208_123433_658141_19B18A01 X-CRM114-Status: GOOD ( 27.48 ) 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: Vladimir Murzin , keescook@chromium.org, linux-arm-kernel@lists.infradead.org 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 Tue, Dec 08, 2020 at 04:36:16PM +0000, Dave P Martin wrote: > On Thu, Nov 19, 2020 at 01:39:53PM +0000, Vladimir Murzin wrote: > > With EPAN supported it might be handy to user know that PROT_EXEC > > gives execute-only permission, so advertise it via HWCAPS2_EXECONLY > > > > Cc: Kees Cook > > Cc: Catalin Marinas > > Signed-off-by: Vladimir Murzin > > --- > > arch/arm64/include/asm/hwcap.h | 1 + > > arch/arm64/include/asm/sysreg.h | 1 + > > arch/arm64/include/uapi/asm/hwcap.h | 1 + > > arch/arm64/kernel/cpufeature.c | 3 +++ > > arch/arm64/kernel/cpuinfo.c | 1 + > > 5 files changed, 7 insertions(+) > > > > diff --git a/arch/arm64/include/asm/hwcap.h b/arch/arm64/include/asm/hwcap.h > > index 9a5498c..5ee5bce 100644 > > --- a/arch/arm64/include/asm/hwcap.h > > +++ b/arch/arm64/include/asm/hwcap.h > > @@ -105,6 +105,7 @@ > > #define KERNEL_HWCAP_RNG __khwcap2_feature(RNG) > > #define KERNEL_HWCAP_BTI __khwcap2_feature(BTI) > > #define KERNEL_HWCAP_MTE __khwcap2_feature(MTE) > > +#define KERNEL_HWCAP_EXECONLY __khwcap2_feature(EXECONLY) > > Should this definitely be an hwcap? > > [Apologies if I already made this comment, but if I did I can't find a > record of it, so here it is again (or not)]: I don't think you did ;). > This seems to have the wrong semantics for hwcaps: it's not a (purely) a > property of the hardware, not an arch-specific concept, and old code > that doesn't know about this flag may not work properly when the flag > is set. We could expose HWCAP2_EPAN which implies exec-only but I find it weird (we had the precedent of HWCAP_LPAE on arm32 which meant 64-bit atomics available). You can look at this as an architecture feature allowing user execute-only permissions. > Software that requires that any memory mapped without PROT_READ is > readable would be nonportable according to POSIX, but nonportable > doesn't mean not correct; it just means that POSIX doesn't gurarantee > that it works everywhere. We already made this decision when we first introduced the execute-only permission. We've had it for a while and haven't heard of any instance of PROT_EXEC-only mapping expecting PROT_READ. The reason we reverted that change was that it was invalidating the PAN kernel protection. So I'm not concerned about changing the ABI but what I'd like is to inform the user that exec-only is available, in case it wants to do something with it. > So: > > 1) Is true execute-only memory an ABI break that we care about, and do > we need an explicit opt-in? See above and commit cab15ce604e5 ("arm64: Introduce execute-only page access permissions") from 2016. > 2) Otherwise, is there another more suitable and less arch-specific > mechanism that could be used? (Maybe AT_FLAGS or similar?) If you don't like HWCAP, we could use a bit in AT_FLAGS (they are all currently 0). But, arguably, exec-only is a property that the hardware offers, though indirectly. I agree you can look at this either way. > This issue may have come up on other arches. I've not gone digging. I think x86 with protection keys can offer a similar mechanism but I haven't checked. -- Catalin _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel