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 81C3AC7EE43 for ; Mon, 12 Jun 2023 19:14:16 +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-Transfer-Encoding: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-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=CrFIlLYnDPHMgCtBkblLIubYqiIk1Y3I5JKMHDk0ix4=; b=Zfuun8r5/pOOSz sE4IKBkEuSXGVL84zxQbbQCoXniOGxh3QxVmx041mcQrgDznLWwjAG3WNjFOY9TKOCZu35BBbDrBT rJY2fJEgl59omFo8vlnrZMKeMINxJERwOHOExP+AQkIFMlPM8GvprZ6vwH9PcgA8XM5p/6FcFT31o DWC5tkaU1cuUlDRVTY8AFeoT0a8PtIsYJwGn2txHsH39kOkjPovlQ1SY/mdDM+MHjv9Hw9CLQUoeo kMO/r3rdwug0vtOgE28SIKK6Ywx0uDsLolL9h9fYJ6HaMBdqSe9SZzsCb68tVwG1l5S6Cvi1Ljatg QNr+l0ru36YWEM9IvxQA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.96 #2 (Red Hat Linux)) id 1q8mz8-0054RA-1R; Mon, 12 Jun 2023 19:13:50 +0000 Received: from out-5.mta1.migadu.com ([2001:41d0:203:375::5]) by bombadil.infradead.org with esmtps (Exim 4.96 #2 (Red Hat Linux)) id 1q8mz5-0054Q1-0W for linux-arm-kernel@lists.infradead.org; Mon, 12 Jun 2023 19:13:49 +0000 Date: Mon, 12 Jun 2023 21:13:41 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1686597223; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=HxGQvsB7fcRIz73MLbhBAve1ENUGJm6b0AdpqTHIpqE=; b=BmixyGpow9WXKsKoIICxCywoB6nARvJSBuFSil9BVrJYhdu91Q1xEeah/tdb+1jAUSeLgA DJoR3p3DSTGXOA+gOefFf1+2ulTBBQGN6Q17ici9wHaPMcpuH6yrGJ1g1JgJUfc7Lz4s/l 2oaw+m2SXoKHlR5EDs3BwZxhcmhGBvM= X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Oliver Upton To: Mostafa Saleh Cc: Will Deacon , maz@kernel.org, linux-arm-kernel@lists.infradead.org, kvmarm@lists.linux.dev, linux-kernel@vger.kernel.org, tabba@google.com, kaleshsingh@google.com, catalin.marinas@arm.com, yuzenghui@huawei.com, suzuki.poulose@arm.com, james.morse@arm.com Subject: Re: [PATCH] KVM: arm64: Use different pointer authentication keys for pKVM Message-ID: References: <20230516141531.791492-1-smostafa@google.com> <20230608215525.GA2742@willie-the-truck> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: X-Migadu-Flow: FLOW_OUT X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20230612_121347_624432_112B76F2 X-CRM114-Status: GOOD ( 24.46 ) X-BeenThere: linux-arm-kernel@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: 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 Hi Mostafa, Thank you for bumping this, I didn't see Will's reply. On Mon, Jun 12, 2023 at 09:20:16AM +0000, Mostafa Saleh wrote: > On Thu, Jun 08, 2023 at 10:55:26PM +0100, Will Deacon wrote: > > I appreciate the sentiment, but I think we should avoid adding additional > > complexity here if it adds no security benefit. If nothing else, it adds > > pointless overhead, but beyond that it gives the false illusion of a > > security boundary. > > > > Prior to deprivilege, the kernel can write to the hypervisor text, modify > > its stage-1 page-table and change its data values. I think the pointer > > auth keys are the least of our worries if it's compromised... Ack -- well aware of the other issues there :) My whining as it relates to security was more focused at the changelog than the diff of the patch. My tilt in terms of the functionality is more aimed at limiting the interactions between pKVM and the host before it deprivilege. Longer term, it'd be interesting to have pKVM capable of bootstrapping itself, such that it can possibly be used in other contexts. So, when I saw the patch I had questioned whether or not the dependency was strictly necessary. No reason to boil the ocean as part of this otherwise isolated change. Tangent: Will you folks need random in EL2 at runtime? > Thanks a lot Will for explaining this. > > Oliver, what do you think for V2, about it including FEAT_RNG/TRNG in EL2? The patch itself looks good to me. May I suggest something along these lines for the changelog? I can do it myself to avoid the need for a v2: """ When the use of pointer authentication is enabled in the kernel it applies to both the kernel itself as well as KVM's nVHE hypervisor. The same keys are used for both the kernel and the nVHE hypervisor, which is less than desirable for pKVM as the host is not trusted at runtime. Naturally, the fix is to use a different set of keys for the hypervisor when running in protected mode. Have the host generate a new set of keys for the hypervisor before deprivileging the kernel. While there might be other sources of random directly available at EL2, this keeps the implementation simple, and the host is trusted anyways until it is deprivileged. Since the host and hypervisor no longer share a set of pointer authentication keys, start context switching them on the host entry/exit path exactly as we do for guest entry/exit. There is no need to handle CPU migration as the nVHE code is not migratable in the first place. """ -- Thanks, Oliver _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel