From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pf1-f178.google.com (mail-pf1-f178.google.com [209.85.210.178]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id DEBFA76046 for ; Fri, 31 May 2024 20:19:18 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.210.178 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1717186760; cv=none; b=W1BAzdn16RjI+hm78wOl/eWLbOIpgMfpx/JL8/PyRDHFixZkZezPZlPMUI26UjZVegwwSazGVEX92smAjT3lZKcJtzj4IVoE8jsrQ+Dp66G2X9fjVA+Yy7MlxA+hndlYVXYUV3O4EREz4HGVzZ3SroymT+y+/088itQ+BBxPqT4= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1717186760; c=relaxed/simple; bh=shft3RVwUwjo21em7Y9Em5jABEKo/Olm3NJpZmv8t2w=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=cP8njcf51gTDoeCzubcu/0woeaJKKQ8lOoNbO3+shziPa6Eq15Oc1Z+oZmb9hanRQz4ejmvUX7GbSfyqW8lw7MQ7NBqigUgHu1FsKflGaYdwr0pOVll5DVyAXYLWNpCFbSZoiuR3rejc9G+9KEmsOHHNxzAXcbiRTS3KnWnF8UM= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=rivosinc.com; spf=pass smtp.mailfrom=rivosinc.com; dkim=pass (2048-bit key) header.d=rivosinc-com.20230601.gappssmtp.com header.i=@rivosinc-com.20230601.gappssmtp.com header.b=BE9vqqGo; arc=none smtp.client-ip=209.85.210.178 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=rivosinc.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=rivosinc.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=rivosinc-com.20230601.gappssmtp.com header.i=@rivosinc-com.20230601.gappssmtp.com header.b="BE9vqqGo" Received: by mail-pf1-f178.google.com with SMTP id d2e1a72fcca58-6f693306b7cso2194174b3a.1 for ; Fri, 31 May 2024 13:19:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rivosinc-com.20230601.gappssmtp.com; s=20230601; t=1717186758; x=1717791558; darn=lists.linux.dev; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=qAGjhFHnXf9IpViW/yMwbiFI16GqjUPhP70I5dCooFE=; b=BE9vqqGobxaWtXWczHmTGsWs2TE/Qj+Upn+r5dL2mdz2rM+ZRdk/h1ZaICemlHsdwo SYBdQ0E4u0RvTP4KMwnIsF9hO43+7+WYF/xpPpAt06VhB+Z2i7Oocr4GaKhmCfG/rxVE lyKBQbK0USBgS6+/YRcV1liD3Oo+rXxDihmClHoDNJRF8tvIKQ5WWQL1FZMw2YdjD6O/ HGefKzT1OH6QB2+BUEWGNzoRTRG1zY3481FFk9OD/rLN8Mhq34wB/JamIXFtm6xPzcfF IH7HFB+u2o69SbYNHFWxzam9sghizxdx4NhPE6uVj4gljDrG8CjLP2ZJqRCdpJQAWtTF gdZA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1717186758; x=1717791558; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=qAGjhFHnXf9IpViW/yMwbiFI16GqjUPhP70I5dCooFE=; b=LsWZ6zVbTn4HvNFo/X+ruO5w5aZY5e/w6x2YNC6m19LWrko9dPrI5X5E1iiLlyjhFw /GrbgRKsGc96Vg6mtUpV5OLf4JP2rwJE49lsPgeFl+6fOVcQSP8tPvRGXhdWj6RADkKp daE6ScfFvQLrHlHk5f3gYpy2tCle6x3tY5ur5sla7Tj727K2rNOhZe10aFtGcSkAZ0Hz qv6CzZ1GolySgBH3DwOAC5KOyY1HofH+t2CIdND3g7g5nso3wsGwCDazOnac8wBgiawO Vqj+ztLru9Gz1+16Y2Q4bNvuup01vOhpfFBktLgYsQvaQU1jWQgIL21lsVAUcVh7Wf8S kmVg== X-Forwarded-Encrypted: i=1; AJvYcCXRdqnYWic/tqIBlMMuJyQ8UvhCFY6uT+i4NaLmHmba9nQzkgVhjYEgJOSkQI3eftRwy2T8/JJuyLutuco7WVt4kR9ivw== X-Gm-Message-State: AOJu0YxlMBR90RsRUhgNkx/E8FvP8u+FYiqExLBHxxixLpH3xil1x2kX jmFRM+Kaby1Eu/cgr/MIQvnRYNBUpz/2DLiz8b73WNIcpQv8F9iqSzsCzlS2OkA= X-Google-Smtp-Source: AGHT+IGVzy3+vOIUubWLHwauUWb5Skr6TuZH88CsARiNo0nv/hRvULtFg2uHbqI0Wo/CnlmesOhwIw== X-Received: by 2002:a05:6a00:198d:b0:6f0:b53c:dfb4 with SMTP id d2e1a72fcca58-7024788e80bmr3955148b3a.22.1717186757959; Fri, 31 May 2024 13:19:17 -0700 (PDT) Received: from ghost ([2601:647:5700:6860:4d3b:392b:5722:91c1]) by smtp.gmail.com with ESMTPSA id d2e1a72fcca58-70242c245absm1745251b3a.200.2024.05.31.13.19.16 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 31 May 2024 13:19:17 -0700 (PDT) Date: Fri, 31 May 2024 13:19:14 -0700 From: Charlie Jenkins To: Conor Dooley Cc: 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 Subject: Re: [PATCH v0] RISC-V: Use Zkr to seed KASLR base address Message-ID: References: <20240531162327.2436962-1-jesse@rivosinc.com> <20240531-uselessly-spied-262ecf44e694@spud> Precedence: bulk X-Mailing-List: llvm@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20240531-uselessly-spied-262ecf44e694@spud> On Fri, May 31, 2024 at 06:31:09PM +0100, Conor Dooley wrote: > On Fri, May 31, 2024 at 12:23:27PM -0400, Jesse Taube wrote: > > Dectect the Zkr extension and use it to seed the kernel base address. > > > > Detection of the extension can not be done in the typical fashion, as > > this is very early in the boot process. Instead, add a trap handler > > and run it to see if the extension is present. > > You can't rely on the lack of a trap meaning that Zkr is present unless > you know that the platform implements Ssstrict. The CSR with that number > could do anything if not Ssstrict compliant, so this approach gets a > nak from me. Unfortunately, Ssstrict doesn't provide a way to detect > it, so you're stuck with getting that information from firmware. The Scalar Cryptography v1.0.1 spec says "If Zkr is not implemented, the [s,u]seed bits must be hardwired to zero". It also says "Without the corresponding access control bit set to 1, any attempted access to seed from U, S, or HS modes will raise an illegal instruction exception." There is a slight nuance here as the definition of Ssstrict is: "No non-conforming extensions are present. Attempts to execute unimplemented opcodes or access unimplemented CSRs in the standard or reserved encoding spaces raises an illegal instruction exception that results in a contained trap to the supervisor-mode trap handler." The trap that Jesse is relying on in the code here is related to access bits and not related to the CSR being unimplemented. Since the access bits are required to be 0 on an implementation without Zkr, it is required to trap if seed is accessed, regardless of Ssstrict. The situation here is slightly odd because the spec is defining behavior for what to do if the extension is not supported, and requires implementations to follow this aspect of the Scalar Cryptography spec even though they may not implement any of the instructions in the spec. > > For DT systems, you can actually parse the DT in the pi, we do it to get > the kaslr seed if present, so you can actually check for Zkr. With ACPI > I have no idea how you can get that information, I amn't an ACPI-ist. It is feasible to check if Zkr is present in the device tree at this stage in boot, but at first glance does not seem feasible to read the ACPI tables this early. The CSR being read is just for entropy so even if the seed CSR doesn't trap and provides an arbitrary value on an implementation that does not support Zkr, it can still be used as a source of entropy. If the implementation does trap, the entropy will be set to 0 which is just a different hard-coded arbitrary value. - Charlie > > Thanks, > Conor. > _______________________________________________ > linux-riscv mailing list > linux-riscv@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-riscv