Received: by 2002:a05:6a10:c604:0:0:0:0 with SMTP id y4csp266877pxt; Wed, 4 Aug 2021 22:20:02 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyB3fB/llvCgMzkfqxOWB3Fr2AtNeXeGl0Pm6q1/x9wuzdFF/Nrr3ORVJs+fn6iDboWBia4 X-Received: by 2002:a92:b012:: with SMTP id x18mr89252ilh.255.1628140802265; Wed, 04 Aug 2021 22:20:02 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1628140802; cv=none; d=google.com; s=arc-20160816; b=zTCZ+CtThlpMI3pIbf59rn3Kz2GR+AiiwZQYIiAs9uNsWZKnnzdVoVi0DxxESsNJ1l b2myVJpZWUVK5EN55OFYcxlS3lE0b0IV5ojnlFPZwf1kgsj81SKK3BafAdqdyi8oltUE 7UamKiaFz9bznbW3RP++uBz6bT0kf0gIgefn8Guwxno0nUtMljuspwVLY6adEoaR4Um4 VbZ8jkZ4l+3frPPYNBX0typWHEuqUFLEidNV7cbvz7alh84Q46jBhRXMVPO/aO9Dq1r/ F8KPCwuUCJN4Z4oOX+qFWulvAajRocLnpsouEI+zWiOtFGeM/CFSSWcyN+OEGg2rLX5p htTA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-language:content-transfer-encoding :in-reply-to:mime-version:user-agent:date:message-id:from:references :cc:to:subject; bh=f7sDJMyHwhzlg8I40P+LcQCK+g+l2oe/Xv+WHL9tBF8=; b=vA4kmnpWw0arWF8WvXxhFvIs+DQe8/9G4ZNUerAJ+SPxrv3mm10PL2XqcpQ+NX0mcm hE30t+c0EHhRcZMdKoUaa3uQ4hqKbVFSzRztVv7iapxir691NZMUPhWQgQWO4AUOg2qv xh04HwEw+MvNsXahYxeOvW+1pmj/wgM5ojGE0mzAlrB2g+fUpcZWvCx0z7VTr7Vik6Ag 3NeOuHpjgWAkM2k+5TJK/DclvTIocoI6+CHFfiG1UegKk0f2RXivONKWcpDBowj3PULR 9ck1uixWqgACA+kfWuyhOlK50duYOGUJd0RnrL3k7KvKLq05mFVzOaP4t0r9BGYArHwP 5+OA== ARC-Authentication-Results: i=1; mx.google.com; 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=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id u11si4662680jak.14.2021.08.04.22.19.43; Wed, 04 Aug 2021 22:20:02 -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; 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=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231390AbhHEEqM (ORCPT + 99 others); Thu, 5 Aug 2021 00:46:12 -0400 Received: from mga06.intel.com ([134.134.136.31]:2899 "EHLO mga06.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231143AbhHEEqM (ORCPT ); Thu, 5 Aug 2021 00:46:12 -0400 X-IronPort-AV: E=McAfee;i="6200,9189,10066"; a="275119206" X-IronPort-AV: E=Sophos;i="5.84,296,1620716400"; d="scan'208";a="275119206" Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by orsmga104.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 04 Aug 2021 21:45:58 -0700 X-IronPort-AV: E=Sophos;i="5.84,296,1620716400"; d="scan'208";a="522336613" Received: from akleen-mobl1.amr.corp.intel.com (HELO [10.209.32.138]) ([10.209.32.138]) by fmsmga002-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 04 Aug 2021 21:45:57 -0700 Subject: Re: [PATCH v1] driver: base: Add driver filter support To: Dan Williams , Matthew Wilcox Cc: Greg Kroah-Hartman , Kuppuswamy Sathyanarayanan , "Rafael J . Wysocki" , Jonathan Corbet , Kuppuswamy Sathyanarayanan , Linux Kernel Mailing List , Linux Doc Mailing List References: <20210804174322.2898409-1-sathyanarayanan.kuppuswamy@linux.intel.com> From: Andi Kleen Message-ID: Date: Wed, 4 Aug 2021 21:45:56 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.12.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 8/4/2021 2:28 PM, Dan Williams wrote > The "hardware" in this case is virtual devices presented by the VMM to > the VM. So if a driver misbehaves in a useful way for an attacker to > exploit, they can stimulate that behavior with a custom crafted > virtual device, and that driver will autoload unaware of the threat > without this filter for vetted drivers. Another way to see it is: the confidential guest is protected against the host, except for the places where it chooses to communicate with the host through MMIOs, port IOs, some (not all) MSRs. It's somewhat analogous to a network server in a hostile network which can be attacked through network packets. We typically use a firewall to limit the network exposure only to especially hardened network services. Each low level MMIO etc. is like a network access communicating with a hostile network. The device filter is the firewall for these vulnerable low level interactions. It reduces the hardening problem from being completely infeasible to tractable. -Andi