[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH v7 4/8] AMD/IOMMU: check IVMD ranges against host implementation limits


  • To: Jan Beulich <jbeulich@xxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxxx>
  • From: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
  • Date: Thu, 26 Aug 2021 14:16:17 +0100
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=citrix.com; dmarc=pass action=none header.from=citrix.com; dkim=pass header.d=citrix.com; arc=none
  • Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=vHzgO/6JE3l3+82E9BaHeYvUwNiG1G76LyDzdfqGIWM=; b=lsayYQoSfhZu9Ia8QF59EKDtZoO43q/qpMtiMgK2gG7fYel+w5bSbJnB8oqXHJKVpIcz7XBoo7id69F6UryvUQ8VTXOpXZsH29hPNmQh/yiglCVdW62XBgb5TRfZkAbxSREJeXB3qeYgGv58NERy78IgHswXPrQq5glATaI+i0ygOuDVoLl8r/7dEmzJofw1KBqPPukBLf+EKKe4rnD/WxHNNqQRgRH56r8npgn/KaX2JXipO+sXoHn2LjZzu+SzuuF+gCXiu6gXrWTsrbld8Q7YF0OSQ/OUCT2FxCHgh40vuGPVVI7RSajiOj4fHoGn3HwdO+csGJJug2n1HGMuCg==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=ZuNyuCz5LlOgMY8bSRsUS+K1+8AP9FMtNc1KE2c8QmFoGpWJW6wY0agC5Am1l6wlnwyX2QGajp7QbAeXBQ4EDv06Eo+urYPDn4KnYEPp54dbo9176z74FRQ+1BMZCsMaIzrCQbdh+1sclDiGQ9t3a9k2S/HKyRQ+7ThUvUV2rrXej5Dyl7yaqvjxWFlafAEKE7LGbo/5uN7h3ERb2/PGbiqMug7sySG0nEgf/w1Gf07A8POz1fK4hoVHOphtYlSwG1Neemgzzd0HdzFUrNN7MTht6CK6WaeTBCF/KtQp7lBkT3750+OdeX0o/vePtw8twKqTgLGx1f3wr0/ZVzCljw==
  • Authentication-results: esa3.hc3370-68.iphmx.com; dkim=pass (signature verified) header.i=@citrix.onmicrosoft.com
  • Cc: Paul Durrant <paul@xxxxxxx>
  • Delivery-date: Thu, 26 Aug 2021 13:16:34 +0000
  • Ironport-hdrordr: A9a23:UX13VaqKKxQNQklXIBe2FlsaV5rPeYIsimQD101hICG9Kvbo4v xG785roSMc6QxhEE3I9urwSZVoLUmsk6KdpLNhT4tKUTOW31dAT7sSprcKoQeQaxEWn9Q1vc 0QFtkbeaSAdSkA/LzHCUuDYqUdKbG8m5xA7t2us0uFODsaFZ2ImD0JdTpzfHcGOTWvi/ICea Z19aF8ywZIMk5nGfhTTkN1KdQqpbbw+64ONiRpO/Z+gjPusduug4SbL/CftS1uMA+mxdwZgA r4eiLCl+yej80=
  • Ironport-sdr: m5KXhnJnuiawheZYWHygA26z/jvThByX2YBA1/HzTy7W3uOtEAsSb1FI7GaUGBwplnexj0Ktc+ eDxRHp+h/G/uwJO7w5OpiQAvdGaoTFpUTLCxvVlpXITumEjRErzSqTa9RmPvKlv1GW9WVWUfrz jtj84kk1flIQMtFFFTtQNnUdoW7dp/6SyNwMpzfCNnX1bLbVQervnfkaYeRRuIA8COHvGYGFh1 MeYxeF7LMXsM1T17DzFvp72in4PNV21b4NirH4wS+Tg1ZTk17hw92Ap253tmd5R+B+6rdMmthj KNYcgoYaOok1gzG8RMB5fu35
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On 26/08/2021 08:24, Jan Beulich wrote:
> When such ranges can't be represented as 1:1 mappings in page tables,
> reject them as presumably bogus. Note that when we detect features late
> (because of EFRSup being clear in the ACPI tables), it would be quite a
> bit of work to check for (and drop) out of range IVMD ranges, so IOMMU
> initialization gets failed in this case instead.
>
> Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
> Reviewed-by: Paul Durrant <paul@xxxxxxx>

I'm not certain this is correct in combination with memory encryption.

The upper bits are the KeyID, but we shouldn't find any of those set in
an IVMD range.  I think at a minimum, we need to reduce the address
check by the stolen bits for encryption, which gives a lower bound.

~Andrew




 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.