From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f46.google.com (mail-wm1-f46.google.com [209.85.128.46]) (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 80AFD3D9E for ; Mon, 29 May 2023 11:17:58 +0000 (UTC) Received: by mail-wm1-f46.google.com with SMTP id 5b1f17b1804b1-3f70597707eso19585e9.0 for ; Mon, 29 May 2023 04:17:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20221208; t=1685359076; x=1687951076; 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=I+lZausDryKG4ZO3Nqwp8m14ca0rBbgR6EbQ29PXNuc=; b=PO2JytkJv+VJn62NFUGU6ShfAlH/PsBE+8W6DxWhBq/UC8fHtabftJqNjIkkyinugL bZVjMV+qoFLcMQ5F0K9hkbw0SJxrMu+wJC5vCLRtZbj3HrT2D1dZmmxifZ1xFQjZxtTJ Dt1byvQYMkKsbhulNIYKkHXjnTXTAdiDyLCvPAkc3gKpe/gkNlipSd1390Itl5PKzOPe tn4uZEkdwMZL8uxmNnauSmUmY6T1bvIlnaOtLHhitosqFzOhWZhj+4+m/8d6D6a4WNsV FMQEco3KGwf4SGGYH8/hETD/xnVtQ/C4UXobbRYOZJLJyQXuGTYn14H8urIwpDvXUG3e 7eEg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1685359076; x=1687951076; 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=I+lZausDryKG4ZO3Nqwp8m14ca0rBbgR6EbQ29PXNuc=; b=H7od0Odi7bUnLGBqfXE7Tte0lBevPjKFhPGmGG2xlZGEGpHlcnyZHLtAe57fEvbEPj tb1PrSwgkIGKLvb4cNtfDE7iYuf7/LngBaZoo1rxf6LH9WoacccUV8/Xg9IRP2CwzIy8 uXMhT1tnhqhaEU7CmWDYrN1OgCw2J2xiS/QA0ZY0uKTaG6WkIYhJ9FXwl2lda8T/5666 lNKrSiv4hVzLWTY+XeceYXTm+XdGbIyZWTpWyY8AIMrwfcOHlnBJa+avKsJBAL+Mguo9 0EuYbkssrWCn02HtBPrBCM3WxkXuiVqg7VhxQz+yzvAiMDnZRmlQhrHD0DReoIKw8TxZ 5/Rg== X-Gm-Message-State: AC+VfDzF6TBZOyYvFxisl5swCf7+fU48Ds9P9yGIL2ELxtqevdilE+fC OqDiZIu4VkbwG09dXVCm8dOryw== X-Google-Smtp-Source: ACHHUZ7xBl6bStss7nwx99oIzv0OGh31v16NM+89xyXK86HZHTCFsi/YXJiP732JrW9t9QfMa+XPGA== X-Received: by 2002:a05:600c:3b0d:b0:3f1:70d1:21a6 with SMTP id m13-20020a05600c3b0d00b003f170d121a6mr444931wms.0.1685359076605; Mon, 29 May 2023 04:17:56 -0700 (PDT) Received: from google.com (44.232.78.34.bc.googleusercontent.com. [34.78.232.44]) by smtp.gmail.com with ESMTPSA id o4-20020a5d4744000000b003062675d4c9sm13449166wrs.39.2023.05.29.04.17.55 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 29 May 2023 04:17:56 -0700 (PDT) Date: Mon, 29 May 2023 11:17:51 +0000 From: Mostafa Saleh To: Oliver Upton Cc: maz@kernel.org, linux-arm-kernel@lists.infradead.org, kvmarm@lists.linux.dev, linux-kernel@vger.kernel.org, tabba@google.com, kaleshsingh@google.com, will@kernel.org, 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> Precedence: bulk X-Mailing-List: kvmarm@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: Hi Oliver, Thanks for reviewing the patch. On Fri, May 26, 2023 at 08:47:52PM +0000, Oliver Upton wrote: > On Tue, May 16, 2023 at 02:15:31PM +0000, Mostafa Saleh wrote: > > When the kernel is compiled with CONFIG_ARM64_PTR_AUTH_KERNEL, it > > uses Armv8.3-Pauth for return address protection for the kernel code > > including nvhe code in EL2. > > > > Same keys are used in both kernel(EL1) and nvhe code(EL2), this is > > fine for nvhe but not when running in protected mode(pKVM) as the host > > can't be trusted. > > But we trust it enough to hand pKVM a fresh set of keys before firing > off? I understand there is some degree of initialization required to get > pKVM off the ground, but I question in this case if key handoff is > strictly necessary. > > There are potentially other sources of random directly available at EL2, > such as the SMCCC TRNG ABI or FEAT_RNG. Should pKVM prefer one of these > random implementations and only fall back to host-provided keys if > absolutely necessary? > According to my understanding, the kernel is still completely trusted at this point (it sets the initial page table for the hypervisor), so I believe it should be fine to trust it for ptrauth keys. However, I agree, it would be better if the hypervisor can get its own keys through firmware/hardware if supported. I will add this in V2. > > The keys for the hypervisor are generated from the kernel before it > > de-privileges, each cpu has different keys, this relies on nvhe code > > not being migratable while running. > > > > This patch adds host/hyp save/restore for the keys. > > For guest/hyp, they are already handled in common kvm code in > > __guest_enter, where they are saved/restored if they are not > > trapped. > > Try to avoid "this patch" or any self-referential language in the > changelog. Just directly state what the patch does: > > Similar to guest entry/exit, start context switching the pointer > I will update it in V2. Thanks, Mostafa 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 D4712C77B7E for ; Mon, 29 May 2023 11:18:31 +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=7COZthTBB3rvKVDxypo9RYarR5qOK1qDjVPlGIncDB8=; b=tWC6/kcIDjm/CP 9p5nl8m35dT/DXkcQL4f9tMqtmD39qfwFpXEcqP8f6sXhoOVJrcfRCeAJBCRkxNs+C8FUJmYn4DPn xx/eAmoPAB1Tz2V7YFMe6hkKIB7U29vr0up58OTsSVpOL4AD6JeawYCjdX93uzVXghRN8D9QsOnjh UmpoJjIHhAqN/nygZONMeGvbJvhKGk1/yCq9ufrMZ9l7k14DIuXpYP4Fz2MtYDiQq7RHk73TGGdIB jVq8TtqTOg0GKPPtAojRl04C23eOMSGaAzqr9NeqVOtjrRIBxFeJ9p/8l1CT4ndQ8ZPhwGYlwquIP TRr4IDaR6UT2vIVpQXJQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.96 #2 (Red Hat Linux)) id 1q3at3-00AGQQ-0u; Mon, 29 May 2023 11:18:05 +0000 Received: from mail-wm1-x32c.google.com ([2a00:1450:4864:20::32c]) by bombadil.infradead.org with esmtps (Exim 4.96 #2 (Red Hat Linux)) id 1q3at0-00AGPQ-2i for linux-arm-kernel@lists.infradead.org; Mon, 29 May 2023 11:18:04 +0000 Received: by mail-wm1-x32c.google.com with SMTP id 5b1f17b1804b1-3f7024e66adso24655e9.1 for ; Mon, 29 May 2023 04:17:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20221208; t=1685359076; x=1687951076; 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=I+lZausDryKG4ZO3Nqwp8m14ca0rBbgR6EbQ29PXNuc=; b=PO2JytkJv+VJn62NFUGU6ShfAlH/PsBE+8W6DxWhBq/UC8fHtabftJqNjIkkyinugL bZVjMV+qoFLcMQ5F0K9hkbw0SJxrMu+wJC5vCLRtZbj3HrT2D1dZmmxifZ1xFQjZxtTJ Dt1byvQYMkKsbhulNIYKkHXjnTXTAdiDyLCvPAkc3gKpe/gkNlipSd1390Itl5PKzOPe tn4uZEkdwMZL8uxmNnauSmUmY6T1bvIlnaOtLHhitosqFzOhWZhj+4+m/8d6D6a4WNsV FMQEco3KGwf4SGGYH8/hETD/xnVtQ/C4UXobbRYOZJLJyQXuGTYn14H8urIwpDvXUG3e 7eEg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1685359076; x=1687951076; 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=I+lZausDryKG4ZO3Nqwp8m14ca0rBbgR6EbQ29PXNuc=; b=Gr/XlD7atYQ4arlogm3ZZn73eBlUkg6fywEN0iq1wrxrNl+6VDoWnTm9oZcBEGg0ke tl6rz/xw+S/9gB3Hcx7yjOMKJPxu3yjyYlra4A8Q20kNHosYhCwEvb+9ppbc/+eSG2ay S/tX4upX1lIuZMoCFvodR4ZbWlq4npNvmhi/zEAIJPdcya9euXX6Pi+ztxtK1X0KLSjd w3u/tbZEKVHpGlUaYUryYHIpZwYDmmBZbt/A1lCYqrs8isaRnQ0lrgdnyU6nyRecJo5u TMPXF9S5rgsN79DqdbG1RJh+hTDe/VxSBGTOK3+8WVKZ6ohO/K+H09zDWISB8DSKivAl f0YA== X-Gm-Message-State: AC+VfDwx4y91AKo4WAN3848gETmvpoYPbXAEaH5u4mDw+fFjPw4FXn69 AhQSoMrJm77I256upArzGezvSVsiyGl2Si1/+XjzaA== X-Google-Smtp-Source: ACHHUZ7xBl6bStss7nwx99oIzv0OGh31v16NM+89xyXK86HZHTCFsi/YXJiP732JrW9t9QfMa+XPGA== X-Received: by 2002:a05:600c:3b0d:b0:3f1:70d1:21a6 with SMTP id m13-20020a05600c3b0d00b003f170d121a6mr444931wms.0.1685359076605; Mon, 29 May 2023 04:17:56 -0700 (PDT) Received: from google.com (44.232.78.34.bc.googleusercontent.com. [34.78.232.44]) by smtp.gmail.com with ESMTPSA id o4-20020a5d4744000000b003062675d4c9sm13449166wrs.39.2023.05.29.04.17.55 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 29 May 2023 04:17:56 -0700 (PDT) Date: Mon, 29 May 2023 11:17:51 +0000 From: Mostafa Saleh To: Oliver Upton Cc: maz@kernel.org, linux-arm-kernel@lists.infradead.org, kvmarm@lists.linux.dev, linux-kernel@vger.kernel.org, tabba@google.com, kaleshsingh@google.com, will@kernel.org, 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> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20230529_041802_917349_8FA59B88 X-CRM114-Status: GOOD ( 29.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 Oliver, Thanks for reviewing the patch. On Fri, May 26, 2023 at 08:47:52PM +0000, Oliver Upton wrote: > On Tue, May 16, 2023 at 02:15:31PM +0000, Mostafa Saleh wrote: > > When the kernel is compiled with CONFIG_ARM64_PTR_AUTH_KERNEL, it > > uses Armv8.3-Pauth for return address protection for the kernel code > > including nvhe code in EL2. > > > > Same keys are used in both kernel(EL1) and nvhe code(EL2), this is > > fine for nvhe but not when running in protected mode(pKVM) as the host > > can't be trusted. > > But we trust it enough to hand pKVM a fresh set of keys before firing > off? I understand there is some degree of initialization required to get > pKVM off the ground, but I question in this case if key handoff is > strictly necessary. > > There are potentially other sources of random directly available at EL2, > such as the SMCCC TRNG ABI or FEAT_RNG. Should pKVM prefer one of these > random implementations and only fall back to host-provided keys if > absolutely necessary? > According to my understanding, the kernel is still completely trusted at this point (it sets the initial page table for the hypervisor), so I believe it should be fine to trust it for ptrauth keys. However, I agree, it would be better if the hypervisor can get its own keys through firmware/hardware if supported. I will add this in V2. > > The keys for the hypervisor are generated from the kernel before it > > de-privileges, each cpu has different keys, this relies on nvhe code > > not being migratable while running. > > > > This patch adds host/hyp save/restore for the keys. > > For guest/hyp, they are already handled in common kvm code in > > __guest_enter, where they are saved/restored if they are not > > trapped. > > Try to avoid "this patch" or any self-referential language in the > changelog. Just directly state what the patch does: > > Similar to guest entry/exit, start context switching the pointer > I will update it in V2. Thanks, Mostafa _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel