Received: by 2002:a05:6a10:206:0:0:0:0 with SMTP id 6csp1001147pxj; Wed, 2 Jun 2021 17:46:28 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzJ+aLZAa0SDbRBhFw9P/d3ACpSMfJ/PNFcEqA9HUskcpdVRNGQfTt0jwKlBHPwLrpPdOvB X-Received: by 2002:a05:6402:612:: with SMTP id n18mr27501241edv.83.1622681188480; Wed, 02 Jun 2021 17:46:28 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1622681188; cv=none; d=google.com; s=arc-20160816; b=ZTzk0mg8RvNbu4jnnA4Nq7M/UoAlXCw8dTo8T17KYsu13uP9dXOziAyIyxJ3pZJABY t4/XZsP8Yq8rzuWrQ+tHD3vlLKMjQzCnj400X+Elrn5YQ5U6PHaC5L+qsfnxRGNVOp3t oARthubrccVZhOUBQqxWwruWJatK3G1W0Qqe6m4CNSIi2RByHWQQvxaE6MoEIvit7vay /Pa6Jd5sZ69ZpeYbH+COkzWp8ThhFiETc4/9HVo7IZJ6fd58GdEb4OVqL/UWjOFluFqk WTgpNMBcn0HIlpSTzSGtnLb1vMTkJ/pUiFg0VV3d63QMkienTRiCjIxiJJG8S53FAmH/ kYWw== 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 :message-id:date:subject:cc:to:from:ironport-sdr:ironport-sdr; bh=9ut8BMwwx4bcpcCVvSDlqwuTYVSRaIhgLDjGVn/Zfj8=; b=AzpekRCnr3fS5ks+RK49u3xcRcBI4nPkN7jEjMw7SV71PFxAznp2azwQPD0T0q4oPm AmBNfWQLF0W0xpmEvKftTbCrhtpcLf1aYvAvFCZBZpATinmXy9t6Pa9j+5d6XeMxWtNJ SjzFTo0QgnmxW7SaDq5tmf7XJP2hsJOP9m9jwgL55cjKXBYRDlWvO0/YN7paLjFzxSHF QsBcPdDSLxzzde8wWFhnRMWT2MWPhCbK94HqizZJuQcY87LnaSYMsGPv902f4mNapaFn bJR25Y/3Kb0KfwIU9i+DkXzB1uYFhml8bI1EwWScuvXlfZsHJwxWUy09aXrvFQOSQw+G jqWQ== 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 t1si1116608edf.285.2021.06.02.17.46.06; Wed, 02 Jun 2021 17:46:28 -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 S229896AbhFCAnj (ORCPT + 99 others); Wed, 2 Jun 2021 20:43:39 -0400 Received: from mga04.intel.com ([192.55.52.120]:20968 "EHLO mga04.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229804AbhFCAna (ORCPT ); Wed, 2 Jun 2021 20:43:30 -0400 IronPort-SDR: NCunTLOx4NyE7SHArA4XT1iKjqRUyRIE39R3w0Vboz1m+giWuhkf0Qmj1lfw8OGzPoDfskapnI tkjdpCBgf9NA== X-IronPort-AV: E=McAfee;i="6200,9189,10003"; a="202075167" X-IronPort-AV: E=Sophos;i="5.83,244,1616482800"; d="scan'208";a="202075167" Received: from orsmga004.jf.intel.com ([10.7.209.38]) by fmsmga104.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 02 Jun 2021 17:41:46 -0700 IronPort-SDR: dhLv57dz9HwwibPiEYbHtPMONcCxCLxcsR6TEmsybaNnFlLNXLEmFLYBV1Mc+W09uoYz9GxbpY /iz4i02nlxTg== X-IronPort-AV: E=Sophos;i="5.83,244,1616482800"; d="scan'208";a="549686674" Received: from tassilo.jf.intel.com ([10.54.74.11]) by orsmga004-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 02 Jun 2021 17:41:44 -0700 From: Andi Kleen To: mst@redhat.com Cc: jasowang@redhat.com, virtualization@lists.linux-foundation.org, hch@lst.de, m.szyprowski@samsung.com, robin.murphy@arm.com, iommu@lists.linux-foundation.org, x86@kernel.org, sathyanarayanan.kuppuswamy@linux.intel.com, jpoimboe@redhat.com, linux-kernel@vger.kernel.org Subject: Virtio hardening for TDX Date: Wed, 2 Jun 2021 17:41:25 -0700 Message-Id: <20210603004133.4079390-1-ak@linux.intel.com> X-Mailer: git-send-email 2.25.4 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org [v1: Initial post] With confidential computing like TDX the guest doesn't trust the host anymore. The host is allowed to DOS of course, but it is not allowed to read or write any guest memory not explicitely shared with it. This has implication for virtio. Traditionally virtio didn't assume the other side of the communication channel is malicious, and therefore didn't do any boundary checks in virtio ring data structures. This patchkit does hardening for virtio. In a TDX like model the only host memory accesses allowed are in the virtio ring, as well as the (forced) swiotlb buffer. This patch kit does various changes to ensure there can be no access outside these two areas. It is possible for the host to break the communication, but this should result in a IO error on the guest, but no memory safety violations. virtio is quite complicated with many modes. To simplify the task we enforce that virtio is only in split mode without indirect descriptors, when running as a TDX guest. We also enforce use of the DMA API. Then these code paths are hardened against any corruptions on the ring. This patchkit has components in three subsystems: - Hardening changes to virtio, all in the generic virtio-ring - Hardening changes to kernel/dma swiotlb to harden swiotlb against malicious pointers. It requires an API change which needed a tree sweep. - A single x86 patch to enable the arch_has_restricted_memory_access for TDX It depends on Sathya's earlier patchkit that adds the basic infrastructure for TDX. This is only needed for the "am I running in TDX" part.