Received: by 2002:a05:6a10:206:0:0:0:0 with SMTP id 6csp3546459pxj; Mon, 24 May 2021 09:05:54 -0700 (PDT) X-Google-Smtp-Source: ABdhPJw/h1Aeec2jFNVWbLNViBcrl7V0Wnt8yWg1jpVf1lGxbPEk5qGGA7huUDYdWdUWLHSRZtzX X-Received: by 2002:a05:6402:4310:: with SMTP id m16mr26541096edc.279.1621872354288; Mon, 24 May 2021 09:05:54 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1621872354; cv=none; d=google.com; s=arc-20160816; b=Xa7RINyiRmO0Sjv0q5uspxMR57OA0KHyGpB2hTFmsoV/oNphKqB5VUNw6CeydgW44Q SP9v5JM0z8f5KJoU5gW05a7fDqRfY2uE3RrK9qIXTZHSyfD9m47Ot7wvVLHI4HgZVX7e oGTyc2Q3Xe0PmJwtszssjxXq4Lol86vTzpjgIwzUyAkAuN74lv3d2dJTy1GNzg7TQG06 NHAWph9Yw++q7sOlNgX1x0d5F6E4QrAQvW0Dqg2PiuXszDNiWu9NEJPPz+R6JEhdkG7B HBIJ9jz89kvotXrqBdLXmnGqjuYpRiebBDT3s4CMNhXrvMAYvcsmkkBWy1iwfExml6aO rTJg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :user-agent:references:in-reply-to:message-id:date:subject:cc:to :from:dkim-signature; bh=FDY4e+X6KhJH7KcxFixToQ1F6cmlDdfKtsADuYm/j9I=; b=RvkW1h/kJI22s3b/Tu4gCUaX2IVNi3ffh1lP4GIMNZipNP3QOjqVMXbDvR+eeWR/zF hgBfOAa9gJ7TyvZebwHcJR9adC9K8h4U2hkUnwudTngocE8KEXpWdYaiYmS62uCMsytk jw1A8G4fMZRZYfisEmMXV4baj5MkpA+Pp63oZNJxo5KohfA8BvBR3g/J7kLCS6zlDZ1k DCZ9yJKZ1yAEwHsTt8lU8RsXNbeG1qrJHwrwMjpY94l+3RQJikE9vBhd0siNwhbxWiYT qFG9NwAuelhdOFXZPWCRv11JN/I9L2EQXEMkU0IRsvm0a6niQmlz5IBBVwsTWgRUaR/G RX0Q== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=JYPXQq9R; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id by9si12309455edb.20.2021.05.24.09.05.24; Mon, 24 May 2021 09:05:54 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=JYPXQq9R; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S237739AbhEXQFg (ORCPT + 99 others); Mon, 24 May 2021 12:05:36 -0400 Received: from mail.kernel.org ([198.145.29.99]:40462 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S235754AbhEXP7J (ORCPT ); Mon, 24 May 2021 11:59:09 -0400 Received: by mail.kernel.org (Postfix) with ESMTPSA id DD71561969; Mon, 24 May 2021 15:44:55 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1621871096; bh=6LlI/WolxupHlz9B/VtgcQD5lFbpjlG7zI70KKiUago=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=JYPXQq9Ra0d0cNK/37lAZkxP0x85TqgPrbVypu5uytuDIS395QzfVAx9QK3vH9sMG 8gEOnJVLU3UHcXm2kuEUvd+ma80MoRAUiGU9Q86akKq3w1QPuJzcDPO73vr+ZFE0Xw Fp5Ilns610J148ev5rBMDl6AB38TOkSm23+BtCNU= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Joerg Roedel , Borislav Petkov Subject: [PATCH 5.12 072/127] x86/sev-es: Use __put_user()/__get_user() for data accesses Date: Mon, 24 May 2021 17:26:29 +0200 Message-Id: <20210524152337.290079245@linuxfoundation.org> X-Mailer: git-send-email 2.31.1 In-Reply-To: <20210524152334.857620285@linuxfoundation.org> References: <20210524152334.857620285@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Joerg Roedel commit 4954f5b8ef0baf70fe978d1a99a5f70e4dd5c877 upstream. The put_user() and get_user() functions do checks on the address which is passed to them. They check whether the address is actually a user-space address and whether its fine to access it. They also call might_fault() to indicate that they could fault and possibly sleep. All of these checks are neither wanted nor needed in the #VC exception handler, which can be invoked from almost any context and also for MMIO instructions from kernel space on kernel memory. All the #VC handler wants to know is whether a fault happened when the access was tried. This is provided by __put_user()/__get_user(), which just do the access no matter what. Also add comments explaining why __get_user() and __put_user() are the best choice here and why it is safe to use them in this context. Also explain why copy_to/from_user can't be used. In addition, also revert commit 7024f60d6552 ("x86/sev-es: Handle string port IO to kernel memory properly") because using __get_user()/__put_user() fixes the same problem while the above commit introduced several problems: 1) It uses access_ok() which is only allowed in task context. 2) It uses memcpy() which has no fault handling at all and is thus unsafe to use here. [ bp: Fix up commit ID of the reverted commit above. ] Fixes: f980f9c31a92 ("x86/sev-es: Compile early handler code into kernel image") Signed-off-by: Joerg Roedel Signed-off-by: Borislav Petkov Cc: stable@vger.kernel.org # v5.10+ Link: https://lkml.kernel.org/r/20210519135251.30093-4-joro@8bytes.org Signed-off-by: Greg Kroah-Hartman --- arch/x86/kernel/sev-es.c | 66 ++++++++++++++++++++++++++++++++--------------- 1 file changed, 46 insertions(+), 20 deletions(-) --- a/arch/x86/kernel/sev-es.c +++ b/arch/x86/kernel/sev-es.c @@ -288,31 +288,44 @@ static enum es_result vc_write_mem(struc u16 d2; u8 d1; - /* If instruction ran in kernel mode and the I/O buffer is in kernel space */ - if (!user_mode(ctxt->regs) && !access_ok(target, size)) { - memcpy(dst, buf, size); - return ES_OK; - } - + /* + * This function uses __put_user() independent of whether kernel or user + * memory is accessed. This works fine because __put_user() does no + * sanity checks of the pointer being accessed. All that it does is + * to report when the access failed. + * + * Also, this function runs in atomic context, so __put_user() is not + * allowed to sleep. The page-fault handler detects that it is running + * in atomic context and will not try to take mmap_sem and handle the + * fault, so additional pagefault_enable()/disable() calls are not + * needed. + * + * The access can't be done via copy_to_user() here because + * vc_write_mem() must not use string instructions to access unsafe + * memory. The reason is that MOVS is emulated by the #VC handler by + * splitting the move up into a read and a write and taking a nested #VC + * exception on whatever of them is the MMIO access. Using string + * instructions here would cause infinite nesting. + */ switch (size) { case 1: memcpy(&d1, buf, 1); - if (put_user(d1, target)) + if (__put_user(d1, target)) goto fault; break; case 2: memcpy(&d2, buf, 2); - if (put_user(d2, target)) + if (__put_user(d2, target)) goto fault; break; case 4: memcpy(&d4, buf, 4); - if (put_user(d4, target)) + if (__put_user(d4, target)) goto fault; break; case 8: memcpy(&d8, buf, 8); - if (put_user(d8, target)) + if (__put_user(d8, target)) goto fault; break; default: @@ -343,30 +356,43 @@ static enum es_result vc_read_mem(struct u16 d2; u8 d1; - /* If instruction ran in kernel mode and the I/O buffer is in kernel space */ - if (!user_mode(ctxt->regs) && !access_ok(s, size)) { - memcpy(buf, src, size); - return ES_OK; - } - + /* + * This function uses __get_user() independent of whether kernel or user + * memory is accessed. This works fine because __get_user() does no + * sanity checks of the pointer being accessed. All that it does is + * to report when the access failed. + * + * Also, this function runs in atomic context, so __get_user() is not + * allowed to sleep. The page-fault handler detects that it is running + * in atomic context and will not try to take mmap_sem and handle the + * fault, so additional pagefault_enable()/disable() calls are not + * needed. + * + * The access can't be done via copy_from_user() here because + * vc_read_mem() must not use string instructions to access unsafe + * memory. The reason is that MOVS is emulated by the #VC handler by + * splitting the move up into a read and a write and taking a nested #VC + * exception on whatever of them is the MMIO access. Using string + * instructions here would cause infinite nesting. + */ switch (size) { case 1: - if (get_user(d1, s)) + if (__get_user(d1, s)) goto fault; memcpy(buf, &d1, 1); break; case 2: - if (get_user(d2, s)) + if (__get_user(d2, s)) goto fault; memcpy(buf, &d2, 2); break; case 4: - if (get_user(d4, s)) + if (__get_user(d4, s)) goto fault; memcpy(buf, &d4, 4); break; case 8: - if (get_user(d8, s)) + if (__get_user(d8, s)) goto fault; memcpy(buf, &d8, 8); break;