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

Re: [PATCH 1/2] x86/vmx: implement Bus Lock detection


  • To: Roger Pau Monne <roger.pau@xxxxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxxx>
  • From: Andrew Cooper <Andrew.Cooper3@xxxxxxxxxx>
  • Date: Wed, 18 May 2022 22:50:02 +0000
  • Accept-language: en-GB, en-US
  • 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-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=Zg+5Mucm0RhLHOcRpNOWbQI15SNxs3X3X6BztpDjvw8=; b=HiQZJYKpK4xHxEMHomcY9mrHik/I96apXn095GfsMH3xqA0mW29EdpCqK3QKLYdSULPuf22yzkY1t3mj6H89t7GWDwE1DRrZNPKnxcfYEYw4Tt7yGj8jAZqpJfRHoTXseeC8gfdw/y8W3ApQXCoI3+eiemZLa+953NrOc7uxG9bzAYnBjpq0IqJ98nH9GB5fOMPPznuY56rgzhRuUB6sqZthqkdlt7pHsxkNpnhSCRERqMDP5Gq+v2QzU3v9iCTCFrE4JyTpzxftFD5f1LoUcwZFGQKfUJkEjoA2Flm/n6uv1FwqKM0dcO0RfPHXFFj7ecl6fk31Ccc4b8Uofsl4nQ==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=aFgI8S5cW9e9OB7BTm3fzFJbLWJhq+Nr/boavF2w+0/skqZu/xI2vBVKYJTWnNbWjOceIbH9OzeagaL4RTL4VnVCA6s3vWx2u3kMi1i5zcK37Om2/6h2p1yDplEMA26iCq4AWk3Fn/YMeFguWyVBQpJ7WwpnWnolvsIHf87WhnPwDsM1PIi+M2MDMvZC+SIberimek6qmIr1HD2r3kTcW80wtyUCxhO7hiG5k+Wh/CxCgVzkHsvwc82ENhjxwMCJzsW1ReSRZN5//aw4S1Iyd+r0klTtMQS18jS8waewqy3zVDqFHsS6vI096MRV4al1zT4Qdvdu2KvkXKJYBn4R0A==
  • Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com;
  • Cc: Jun Nakajima <jun.nakajima@xxxxxxxxx>, Kevin Tian <kevin.tian@xxxxxxxxx>, Jan Beulich <jbeulich@xxxxxxxx>, Wei Liu <wl@xxxxxxx>
  • Delivery-date: Wed, 18 May 2022 22:50:33 +0000
  • Ironport-data: A9a23:46+Q6a0cvFB4wagj5/bD5fJwkn2cJEfYwER7XKvMYLTBsI5bp2EBz TAYCGmHP6zbYzD0etpyaoTn9E4DvZeByoIwGwE9pC1hF35El5HIVI+TRqvS04J+DSFhoGZPt Zh2hgzodZhsJpPkjk7xdOCn9xGQ7InQLlbGILes1htZGEk1EU/NtTo5w7Rj2tMx0YDja++wk YiaT/P3aQfNNwFcagr424rbwP+4lK2v0N+wlgVWicFj5DcypVFMZH4sDfjZw0/DaptVBoaHq 9Prl9lVyI97EyAFUbtJmp6jGqEDryW70QKm0hK6UID66vROS7BbPg/W+5PwZG8O4whlkeydx /1osIKMSAsFDpHOmco9cz5XUAtzPa1ZreqvzXiX6aR/zmXgWl61mrBFKxhzOocVvOFqHWtJ6 PoUbigXaQyOjP63x7T9TfRwgsMkL4/gO4Z3VnNIlGmFS6p5B82dBfyVuLe03x9p7ixKNd/Ya 9AUdnxEaxPYbgcUElwWFIg/jKGjgXyXnzhw9wjN/vtvvDS7IApZ8+TfGcD8W4ezfOp7nRudu GDrrm3YK0RPXDCY4X/fmp62vcffkCW+VI8MGbmQ8v9xnEbV1mEVEAcRV1awvb++kEHWc9BCL QoS8yknr6k3/WSqSMXwW1uzp3vslh0RRdtWVfE74Qely6zI7gLfDW8BJhZDYtE7sM49RRQxy 0SE2djuAFRHr7m9WX+bsLCOoluP1TM9KGYDYWoPSlID6ty6+YUr1EuQE5BkDbK/icDzFXfo2 TeWoSMihrIVy8kWy6G8+lOBiDWpznTUcjMICszsdjrNxmtEiESNPeRENXCzAS58Ebuk
  • Ironport-hdrordr: A9a23:Wav+760d/ZDqV0exkB8nRQqjBe1xeYIsimQD101hICG9Lfb0qy n+pp4mPEHP4wr5AEtQ4uxpOMG7MBDhHQYc2/hfAV7QZnidhILOFvAt0WKC+UytJ8SazIJgPM hbAs9D4bHLbGSSyPyKmDVQcOxQgeVvkprY49s2pk0FJW4FV0gj1XYBNu/xKDwVeOAyP+tcKH Pq3Lsjm9PPQxQqR/X+IkNAc/nIptXNmp6jSwUBHQQb5A6Hii7twKLmEjCDty1uEA9n8PMHyy zoggb57qKsv7WQ0RnHzVLe6JxQhZ/I1sZDPsqRkcIYQw+cyDpAJb4RHoFqjgpF591H22xa1u UkZC1QZvib3kmhOl1dZyGdgzUIngxesEMKgmXo/EcL6faJOA7STfAxxb6xOyGplXbJ9rtHod 129nPcuJxNARzamiPho9DOShFxj0Kx5WEviOgJkhVkIMAjgRBq3P4iFW5uYd499RjBmcga+S hVfbThzecTdUnfY2HSv2FpztDpVnMvHg2eSkxHvsCOyTBZkH1w0kNdnaUk7zo93YN4T4MB6/ XPM6xumr0LRsgKbbhlDONERcesEGTCTR/FLWrXK1X6E6MMPW7LtvfMkf8IzfDvfIZNwIo5mZ zHXl8dvWkue1j2AcnLx5FP+gClehTKYd0s8LAo23FUgMyNeFOwC1zzdLkHqbrSn9wPRsvGRv 20JJVaR/f+MGqGI/c84zHD
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
  • Thread-index: AQHYafEbc73MBdU1ZE2y9t/J11ujK60lP1UA
  • Thread-topic: [PATCH 1/2] x86/vmx: implement Bus Lock detection

On 17/05/2022 14:21, Roger Pau Monne wrote:
> Add support for enabling Bus Lock Detection on Intel systems.  Such
> detection works by triggering a vmexit, which is enough of a pause to
> prevent a guest from abusing of the Bus Lock.

"which is enough of a" is a bit firmer than ideal.  "which Andy says
will be ok" is perhaps more accurate.

Perhaps "which ought to be enough" ?

A buslock here or there is no problem, and non-malicious software
appears to be devoid of buslocks (hardly surprising - it would be a hard
error on other architectures), but a malicious piece of userspace can
trivially cripple the system.

Forcing a vmexit on every buslock limits an attacker to one buslock per
however long a vmentry/exit cycle takes.

> Add an extra perf counter to track the number of Bus Locks detected.

extra Xen perf counter.

Because other hypervisors use actual perf counters to emulate this
ability on current hardware.  Maybe something we should consider...

> diff --git a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c
> index d03e78bf0d..02cc7a2023 100644
> --- a/xen/arch/x86/hvm/vmx/vmx.c
> +++ b/xen/arch/x86/hvm/vmx/vmx.c
> @@ -4053,6 +4053,16 @@ void vmx_vmexit_handler(struct cpu_user_regs *regs)
>  
>      if ( unlikely(exit_reason & VMX_EXIT_REASONS_FAILED_VMENTRY) )
>          return vmx_failed_vmentry(exit_reason, regs);
> +    if ( unlikely(exit_reason & VMX_EXIT_REASONS_BUS_LOCK) )
> +    {
> +        /*
> +         * Delivery of Bus Lock VM exit was pre-empted by a higher priority 
> VM
> +         * exit.
> +         */
> +        exit_reason &= ~VMX_EXIT_REASONS_BUS_LOCK;
> +        if ( exit_reason != EXIT_REASON_BUS_LOCK )
> +            perfc_incr(buslock);

I'm pretty sure you can drop the if, and do the perfc_incr()
unconditionally.  You won't get EXIT_REASON_BUS_LOCK |
VMX_EXIT_REASONS_BUS_LOCK given that wording in the ISE.

To test, Intel has PENDING_DBG which interferes with most easy attempts
to create the condition, but how about this.

Load an LDT, misaligned across a cacheline boundary, and set #DB's %cs
to LDT[0] with a clear access bit, then execute an `icebp` instruction. 
The atomic write to set the access bit is a 4-byte access typically.

This should cause the #DB intercept to trigger on the same instantaneous
boundary that generated the buslock.

Otherwise, LGTM.

~Andrew

 


Rackspace

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