From patchwork Thu Feb 22 02:10:02 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: "Edgecombe, Rick P" X-Patchwork-Id: 20765 Return-Path: Delivered-To: ouuuleilei@gmail.com Received: by 2002:a05:693c:2685:b0:108:e6aa:91d0 with SMTP id mn5csp1419851dyc; Wed, 21 Feb 2024 18:11:17 -0800 (PST) X-Forwarded-Encrypted: i=3; AJvYcCVw72OllFqM1OaaRUmkckWpOApX12psrNxzH3NLnVUW/2SOA93VQEjVKjx1CmuZbGl8bz/D5QgXt4282y5fJUvFZQ6Nww== X-Google-Smtp-Source: AGHT+IFYlqRGMQjWBZchYEhKr5GMFLLjGwP7BUh/AgRQUP57+gZgO8/ufT4ioOPEJu3fLDHUHSm/ X-Received: by 2002:a05:620a:d86:b0:787:7381:c9d6 with SMTP id q6-20020a05620a0d8600b007877381c9d6mr10774103qkl.39.1708567877256; Wed, 21 Feb 2024 18:11:17 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1708567877; cv=pass; d=google.com; s=arc-20160816; b=jqaof/+gdBhwKf5VUoeI9kY2nNZ5qjSZGX+GlSxF8TLp6YL5iTrge92CDYwXXbj2Ej gi9N+NNw+StlSWR9kdSXlFijDtBP+ducm8HelveeTTMQnrQ8ctfy5QyNEXWfxsJ36sY9 YaSeOebEBb68hBtnq8UbJtdLVbsyS9TBMz1ST4Cvgn/G6sG2/I8c0fCrilOLdooNcYJb 4GLtcotW9n0wMAyFe+9PDs9Yw0tWEOsk26guxmQBqVBfR6QdrELhcmlkObqcITCcu0SS bveWZw+KTLgYqk6Rud1lbW/ehPxRt7MuQHk1XK+9ND81qEaPlmmFTZvph0EN1F7x3T9W GdKQ== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:mime-version:list-unsubscribe :list-subscribe:list-id:precedence:message-id:date:subject:cc:to :from:dkim-signature; bh=BeqSrTVny53EcfGYjRsj4EwVNgwhBhptGcn4R2D8eKo=; fh=X9TPmIV9GEMYfi6LJ1MW90VgoxzHHuSuntmVoL+fRLI=; b=P8Zx91pyWE4IeKQQCIiK0zAynqvOsTF9vX8hmwC9Hn9E1TCRjkaUC7wuj7aoFHjECy diDLC1/s1FNaaZlkt5/FzhDj/K5g5ch5N3YQhOxBrSH+C3l5WJ/4l6PbWjQOpZfpDf6C H06k3VuNPRos0evKXvIgkyv9uVJ9IoMkh1irGAaOgMjKXFAiOHY/1+pQ3oY263/G/UyV Muu2xYq1kDTfT7WFriEkGmEOe325kWpr0dZrihya3CLIv9hOqWJqUtTSgKL7DVF16php oANd9q5yyNUCMf7+c3mhgDo6XUsxv9xa3vx/7V1yQ1Zg9Oecke9oiuxJs18BtfVye4/x WR3w==; dara=google.com ARC-Authentication-Results: i=2; mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=anjfdKKI; arc=pass (i=1 spf=pass spfdomain=intel.com dkim=pass dkdomain=intel.com dmarc=pass fromdomain=intel.com); spf=pass (google.com: domain of linux-kernel+bounces-75789-ouuuleilei=gmail.com@vger.kernel.org designates 2604:1380:45d1:ec00::1 as permitted sender) smtp.mailfrom="linux-kernel+bounces-75789-ouuuleilei=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: from ny.mirrors.kernel.org (ny.mirrors.kernel.org. [2604:1380:45d1:ec00::1]) by mx.google.com with ESMTPS id x17-20020a05620a0ed100b0078563c00b74si11362396qkm.548.2024.02.21.18.11.17 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 21 Feb 2024 18:11:17 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel+bounces-75789-ouuuleilei=gmail.com@vger.kernel.org designates 2604:1380:45d1:ec00::1 as permitted sender) client-ip=2604:1380:45d1:ec00::1; Authentication-Results: mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=anjfdKKI; arc=pass (i=1 spf=pass spfdomain=intel.com dkim=pass dkdomain=intel.com dmarc=pass fromdomain=intel.com); spf=pass (google.com: domain of linux-kernel+bounces-75789-ouuuleilei=gmail.com@vger.kernel.org designates 2604:1380:45d1:ec00::1 as permitted sender) smtp.mailfrom="linux-kernel+bounces-75789-ouuuleilei=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ny.mirrors.kernel.org (Postfix) with ESMTPS id 107891C21D34 for ; Thu, 22 Feb 2024 02:11:17 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 8685117983; Thu, 22 Feb 2024 02:10:47 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b="anjfdKKI" Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.19]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 9826EF516; Thu, 22 Feb 2024 02:10:42 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=192.198.163.19 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1708567844; cv=none; b=fR8rhRa0/VQH2yqE4eVUNv4lgy1EWX1nzVi+zPjaDi5oaMLM3O7oxbnJ+Zu33sBArQ5Ak6nYJIl5QASejkqjT98Mvdx38EgfSTN5KqUc5R4EWBRx01ks3dysFCwECQGjwZ7B65hwoBelEq80hWkqVI0T+ddqq7R3QZGgrbHe20U= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1708567844; c=relaxed/simple; bh=2iQQTy6WCqwTsssftJv4V810WwcqtAi5jWn3NTRwc/I=; h=From:To:Cc:Subject:Date:Message-Id:MIME-Version:Content-Type; b=ILmJbVai9ZBt/gl3j1vODghXBmv+DwSfat9Ae5tIBdDigo2L3eyj7wThXOE9wpfpJXgqLXDkCAcaTaNcbVcxsXCVTiTdmpKMpZ4OIvhW7SwS43G3dD0GJH9BMYG3ROTdlMWg0dylNxtpPz919HAHeffzxiihrkWB/njv5C4+zPY= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=intel.com; spf=pass smtp.mailfrom=intel.com; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b=anjfdKKI; arc=none smtp.client-ip=192.198.163.19 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=intel.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=intel.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1708567843; x=1740103843; h=from:to:cc:subject:date:message-id:mime-version: content-transfer-encoding; bh=2iQQTy6WCqwTsssftJv4V810WwcqtAi5jWn3NTRwc/I=; b=anjfdKKIfaGiJAvsvXZylhvpcPYtpl5cqauJJRpzyItSzB+0k/elbVkz MmsnEyYMsH8ZDe68tPvPHHlXpSQj9oPA422Vi40Mz/AK4QByWz0RXHMYD baW5mIlQPIfT0jK761P/5r3R91r6+LAlazzRDZpv0V7rqnxM6184rsMQE q52rp53T0rU2doVhpUUUCxxRaCNEHZu+cwFjZHvFttW7/pHQAuEw0NSD+ Ep4ez98OBZQOHl5ptw0w2IzFM1WVNTpPGXEUGtZ/bq21WovfrOr+yUjFs NCxLC6dkhs505kn5qtDyjBW8AkGmoCxBKJ9cvxX70kLmmi+RA7XmkskMB w==; X-IronPort-AV: E=McAfee;i="6600,9927,10991"; a="2641006" X-IronPort-AV: E=Sophos;i="6.06,177,1705392000"; d="scan'208";a="2641006" Received: from fmviesa007.fm.intel.com ([10.60.135.147]) by fmvoesa113.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 21 Feb 2024 18:10:42 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.06,177,1705392000"; d="scan'208";a="5226882" Received: from nlokaya-mobl1.amr.corp.intel.com (HELO rpedgeco-desk4.intel.com) ([10.209.62.65]) by fmviesa007-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 21 Feb 2024 18:10:41 -0800 From: Rick Edgecombe To: kys@microsoft.com, haiyangz@microsoft.com, wei.liu@kernel.org, decui@microsoft.com, mhklinux@outlook.com, linux-hyperv@vger.kernel.org, gregkh@linuxfoundation.org, davem@davemloft.net, edumazet@google.com, kuba@kernel.org, pabeni@redhat.com, netdev@vger.kernel.org, kirill.shutemov@linux.intel.com, dave.hansen@linux.intel.com, linux-coco@lists.linux.dev, linux-kernel@vger.kernel.org Cc: sathyanarayanan.kuppuswamy@linux.intel.com, elena.reshetova@intel.com, rick.p.edgecombe@intel.com Subject: [RFC RFT PATCH 0/4] Handle set_memory_XXcrypted() errors in hyperv Date: Wed, 21 Feb 2024 18:10:02 -0800 Message-Id: <20240222021006.2279329-1-rick.p.edgecombe@intel.com> X-Mailer: git-send-email 2.34.1 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1791563270739014509 X-GMAIL-MSGID: 1791563270739014509 Shared (decrypted) pages should never return to the page allocator, or future usage of the pages may allow for the contents to be exposed to the host. They may also cause the guest to crash if the page is used in way disallowed by HW (i.e. for executable code or as a page table). Normally set_memory() call failures are rare. But on TDX set_memory_XXcrypted() involves calls to the untrusted VMM, and an attacker could fail these calls such that: 1. set_memory_encrypted() returns an error and leaves the pages fully shared. 2. set_memory_decrypted() returns an error, but the pages are actually full converted to shared. This means that patterns like the below can cause problems: void *addr = alloc(); int fail = set_memory_decrypted(addr, 1); if (fail) free_pages(addr, 0); And: void *addr = alloc(); int fail = set_memory_decrypted(addr, 1); if (fail) { set_memory_encrypted(addr, 1); free_pages(addr, 0); } Unfortunately these patterns appear in the kernel. And what the set_memory() callers should do in this situation is not clear either. They shouldn’t use them as shared because something clearly went wrong, but they also need to fully reset the pages to private to free them. But, the kernel needs the VMMs help to do this and the VMM is already being uncooperative around the needed operations. So this isn't guaranteed to succeed and the caller is kind of stuck with unusable pages. The only choice is to panic or leak the pages. The kernel tries not to panic if at all possible, so just leak the pages at the call sites. Separately there is a patch[0] to warn if the guest detects strange VMM behavior around this. It is stalled, so in the mean time I’m proceeding with fixing the callers to leak the pages. No additional warnings are added, because the plan is to warn in a single place in x86 set_memory() code. This series fixes the cases in the hyperv code. IMPORTANT NOTE: I don't have a setup to test tdx hyperv changes. These changes are compile tested only. Previously Michael Kelley suggested some folks at MS might be able to help with this. [0] https://lore.kernel.org/lkml/20240122184003.129104-1-rick.p.edgecombe@intel.com/ Rick Edgecombe (4): hv: Leak pages if set_memory_encrypted() fails hv: Track decrypted status in vmbus_gpadl hv_nstvsc: Don't free decrypted memory uio_hv_generic: Don't free decrypted memory drivers/hv/channel.c | 11 ++++++++--- drivers/hv/connection.c | 11 +++++++---- drivers/net/hyperv/netvsc.c | 7 +++++-- drivers/uio/uio_hv_generic.c | 12 ++++++++---- include/linux/hyperv.h | 1 + 5 files changed, 29 insertions(+), 13 deletions(-)