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 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 smtp.lore.kernel.org (Postfix) with ESMTPS id 3F5ABC27C4F for ; Mon, 10 Jun 2024 21:56:59 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender:Content-Type: List-Subscribe:List-Help:List-Post:List-Archive:List-Unsubscribe:List-Id: In-Reply-To:MIME-Version:References:Message-ID:Subject:Cc:To:From:Date: Reply-To:Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date :Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=SsnPpRjTKMZ87ckdb3Km9b5RFvlZieN2SNRUSZZqtG4=; b=SVcx2Pgo3y7RFdrzakJIyOyMwk PgxSU1erjXl9P7KAbCPxytLT5k5TGg6yTb/y4emKSh2bgZzSgi6KkJqmYD3Zn6hVUS3KfNRoNd1Hz WAP5gyy+Lz1DABIX6SR0RLdnZoZyWDoHIBacGJAuaPg6BOZTZg16cFYogmk12EZeMER7A1HsJIcNX 4VK6Y87Api7gzUQM7jMNSihlZUt9G94r6Wta/gpERfLTSlDnYqEZu93Jc0OuoVbsdWB4WJFMpIaWI 3TqkwWueYB4VSsikSWxRUktbxllYZXjKicK4X76NprEM4JiKoLu26/q89Cxd42BbrNd8GzwXwhk8K BooYoARA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1sGn0V-00000006bhO-3uVc; Mon, 10 Jun 2024 21:56:51 +0000 Received: from dfw.source.kernel.org ([2604:1380:4641:c500::1]) by bombadil.infradead.org with esmtps (Exim 4.97.1 #2 (Red Hat Linux)) id 1sGn0N-00000006be7-0BlS for linux-riscv@lists.infradead.org; Mon, 10 Jun 2024 21:56:50 +0000 Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by dfw.source.kernel.org (Postfix) with ESMTP id F007960B58; Mon, 10 Jun 2024 21:56:41 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 10E41C2BBFC; Mon, 10 Jun 2024 21:56:37 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1718056601; bh=KoFsY2QSqRbBiXfDzmXBOyy6f22jp0uRonBy4MZFEPs=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=ILZonLi4KYvvONkwpufTrioY+XFWyVKpzIZHgquP+P20woB+3RxuhH9AkzOkzEyPc uTW/hkuY+AzkUu06YGBpDZbJGiglOn3VeOfqIKQ8FyVIUXyERAOPc3n+9DidVLTO9s 2aqx4PxwMGnnSdBd2RvJhEjPXahAigoBZior1fuhL2L7ppPcnz/iy3gs0cuc6Cfhcb gB3ngKFf3TCnVsnbUMTtItPYlTjieGCXMSo59GMdJX/KTLv9Wj8ETcQjSc6ITifhWx ACDwjW8WMqAdfrbVwvAk0RuHbv+/oPVaaCpygkbgkipXus/BtmPumlmZVGQb6k5y9b pyycPHtwSIiHg== Date: Mon, 10 Jun 2024 22:56:35 +0100 From: Conor Dooley To: Deepak Gupta Cc: =?iso-8859-1?Q?Cl=E9ment_L=E9ger?= , Conor Dooley , Alexandre Ghiti , Jesse Taube , linux-riscv@lists.infradead.org, linux-kernel@vger.kernel.org, llvm@lists.linux.dev, Alexandre Ghiti , Palmer Dabbelt , Albert Ou , =?iso-8859-1?Q?Bj=F6rn_T=F6pel?= , Paul Walmsley , Nathan Chancellor , Nick Desaulniers , Masahiro Yamada , Atish Patra Subject: Re: [PATCH v0] RISC-V: Use Zkr to seed KASLR base address Message-ID: <20240610-earplugs-anybody-ebd04a5fa777@spud> References: <20240531162327.2436962-1-jesse@rivosinc.com> <20240531-uselessly-spied-262ecf44e694@spud> <20240603-stinking-roster-cfad46696ae5@spud> <20240610-qualm-chalice-72d0cc743658@wendy> <01547275-8c8c-43cf-9da0-64825c234707@rivosinc.com> MIME-Version: 1.0 In-Reply-To: X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20240610_145648_879418_DF7D9F3B X-CRM114-Status: GOOD ( 35.70 ) X-BeenThere: linux-riscv@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============4251232196494213359==" Sender: "linux-riscv" Errors-To: linux-riscv-bounces+linux-riscv=archiver.kernel.org@lists.infradead.org --===============4251232196494213359== Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="mWdS1ikOOxMEfGUM" Content-Disposition: inline --mWdS1ikOOxMEfGUM Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Jun 10, 2024 at 02:06:50PM -0700, Deepak Gupta wrote: > On Mon, Jun 10, 2024 at 11:16:42AM +0200, Cl=E9ment L=E9ger wrote: > > On 10/06/2024 11:02, Conor Dooley wrote: > > > On Mon, Jun 10, 2024 at 10:33:34AM +0200, Cl=E9ment L=E9ger wrote: > > > > On 07/06/2024 20:51, Deepak Gupta wrote: > > > > > On Mon, Jun 03, 2024 at 01:47:40PM +0100, Conor Dooley wrote: > > > > > > On Mon, Jun 03, 2024 at 11:14:49AM +0200, Alexandre Ghiti wrote: > > > > > I don't know all the details but on first glance it seems like in= stead > > > > > of ACPI, > > > > > may be FWFT is a better place for discovery ? > > > > > https://lists.riscv.org/g/tech-prs/topic/patch_v12_add_firmware/1= 06479571 > > > >=20 > > > > IMHO, doing discovery in FWFT is not the goal of this extension. I = think > > > > the "real" solution would be to wait for the unified discovery task > > > > group to come up with something for that (which is their goal I thi= nk) [1] >=20 > Yeah I understand the conundrum here. >=20 > > >=20 > > > I'm curious to see how that works out. The proposal documents an m-mo= de > > > csr, so we'd have to smuggle the information to s-mode somehow... > >=20 > > Ahem, yeah, I spoke a bit too fast. Looked at the proposal and the > > mconfigptr CSR will be accessible by M-mode only so I guess we will have > > to find another way... >=20 > That's not the only problem. Even if you get mconfigptr access, parsing t= he format > is another thing that has to be done. This is early in boot. Although its= strictly (pun > intended) not a firmware feature extension, I think it's much easier to a= sk underlying > firmware if platform is `Sstrict`. or may be expose something like below >=20 > `ENABLE_SSTRICT`. > Platforms which support `Sstrict` can return success for this while platf= orms which don't > have `Sstrict` can return error code (not supported or not implemented). > This way its not feature discovery. I mean, it's feature discovery in all but name. You're calling it enable, but the behaviour you describe is feature discovery - not that I am against this being feature discovery since it gets us out of an annoying bind. I forget which extension Alex and I discussed previously, but there's some mm-related things that you're gonna have to probe super early and=20 we need to figure out if we can get that info from ACPI or not. I know we discussed it w.r.t. one of the T-Head vendor extensions, but I think another standard one got mentioned too. > It seems like arm64 parses fdt and it reads certain CSRs too > (`arch/arm64/kernel/pi/kaslr_early.c`). Although it doesn't look like it = has to do any > discovery for them. A decree from the Palmer that we don't support things that do not conform in this manner would allow us to do what arm64 does. I brought this up originally because it's been discussed before that we cannot rely on conformance because we want to support people's platforms, whether they comply or not. I'd be wary of making this an exception now, and then later on someone makes a platform we want to support that doesn't conform and hey presto, we regress KASLR support - even if I think it is pretty unlikely that someone is going to repurpose the Zkr CSRs. One of the problems with only supporting conforming platforms is that the definition of conforming changes over time! This has happened with the Andes PMU for example, which I believe uses an interrupt number that was later co-opted by AIA spec. That conformed at the time, but doesn't anymore - do they get to mark themselves as Sstrict? Maybe we can do this on a case-by-case basis, but it's up to Palmer whether or not we can do that. --mWdS1ikOOxMEfGUM Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEABYIAB0WIQRh246EGq/8RLhDjO14tDGHoIJi0gUCZmd2kwAKCRB4tDGHoIJi 0jiYAQCTudtf2cIt7L8o1XdE+wFCII3X2/gtf2RZ78X2JJF0SQD9H3PFBbLUuQ+e xhlLbZGztObPUHowGMnO5LqjIaJCbwc= =Dq40 -----END PGP SIGNATURE----- --mWdS1ikOOxMEfGUM-- --===============4251232196494213359== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ linux-riscv mailing list linux-riscv@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-riscv --===============4251232196494213359==--