[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH 2/2] x86/vmx: implement Notify VM Exit
- To: Jan Beulich <jbeulich@xxxxxxxx>
- From: Andrew Cooper <Andrew.Cooper3@xxxxxxxxxx>
- Date: Thu, 19 May 2022 09:20:48 +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=xX+CmuWrdjZ3pZxe86LUf+HCDOnuKvTuKvSKG1d6y/4=; b=QztCRGiwAJy29VxXlqylV41J0rYw7qvwvWPhmbKn+ztatlFhF48Yw/2dNOjmNq0vGsPRx+pI3HA2aCycXy4NEastW44OlELul9RgL1JyZzcACCf+4IvUDQAOmuh81dtz1jDltqCxDvTNv21BNneuzYSOh3UcRjFEskLr4Ol+yVY4Uqm24HbRnlG97bQ5Zjrvl6mmFEvNSn6Xu+9EKvFzpgz3EFSQcNR//mdYyl5uOlKHzkMB7zgCaEcRSBWLmGHjkzLbKnyRTrNdACUi5lnkeVQSTMJI5wAbXFtcJoYUkvztVWoLzvhzNT3izjdLayS4CiS2xVJmB9gOdSANEBlIOQ==
- Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Frg66Mmbbb6XL3x/n3Q/F4eBVC2eh5Ohr288BmZQIMAoP5MmwVCWDZ8/ERhDzb99vcByxG3nNw8gJy9WJRKWv8flxgVguBZf/1Q+PwnmQLVuMT2BqET5d2B/m+BQqTPXaT50bzDIUPHVt/dvnC6E8IOECg/wbT2IEvXZh6/Afqba+FjXpLa2AncduUT9ZiBSYCkCdJdh/6aRXGb3Glx+aJjKFVeCHcDMMZSOsVr4s9soBsoPtCvKsuY8m4vzhOA4E9eRqaxudiJEO9bPfjwm1CdmtE224I5iVRmQS8WXREC54fZLBcy7z3VF40gvWEh9zH3yEqaUFEiJrZGIz14jqg==
- Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com;
- Cc: George Dunlap <George.Dunlap@xxxxxxxxxx>, Julien Grall <julien@xxxxxxx>, Stefano Stabellini <sstabellini@xxxxxxxxxx>, Wei Liu <wl@xxxxxxx>, Jun Nakajima <jun.nakajima@xxxxxxxxx>, Kevin Tian <kevin.tian@xxxxxxxxx>, Roger Pau Monne <roger.pau@xxxxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxxx>
- Delivery-date: Thu, 19 May 2022 09:21:13 +0000
- Ironport-data: A9a23:xyqpJ6CiFum6KRVW/+Diw5YqxClBgxIJ4kV8jS/XYbTApDsihmQHy 2sYDG+FbPnfMzT9c99wbI2wp05XuJCHy4diQQY4rX1jcSlH+JHPbTi7wuYcHM8wwunrFh8PA xA2M4GYRCwMZiaA4E/raNANlFEkvU2ybuOU5NXsZ2YgHGeIdA970Ug5w7Ng09Yx6TSEK1jlV e3a8pW31GCNg1aYAkpMg05UgEoy1BhakGpwUm0WPZinjneH/5UmJMt3yZWKB2n5WuFp8tuSH I4v+l0bElTxpH/BAvv9+lryn9ZjrrT6ZWBigVIOM0Sub4QrSoXfHc/XOdJFAXq7hQllkPgh+ PFsp6GgFzsPM4PGxPs6Cz1RHSthaPguFL/veRBTsOS15mifKT7A5qsrC0s7e4oF5uxwHGdCs +QCLywAZQyCgOTwx6+nTu5rhYIoK8yD0IE34yk8i22GS6t3B8mcH80m5vcBtNs0rulIEezTe Iwybj13YQ6bSxZOJk0WGNQ1m+LAanzXLGcA9wjM9ftfD277ziBLzafDCNjsfMGjf+lwv2i3v 0LJ1jGsav0dHJnFodafyVqujOLSmSLwWKoJCaa1sPVthTW7xHEXCRAQfUu2p7++kEHWc8lEN 0Ue9y4qrK4z3E+mVN/wW1u/unHslgEYc8pdFas98g7l4qjJ5UCfD2sNTD9EYfQnstM7QXoh0 Vrht9DkGz1p9qGUQHS197GIoDf0Mi8QRUcSaClBQQYb7t3LpIAokgmJXttlCLSyjND+BXf32 T/ikcQlr7AajMpO26Dl+1nC2miovsKQEVJz4RjLVGW46A8/fJSie4Gj9Vnc67BHMZqdSV6C+ nMDnqBy8dwzMH1ErwTVKM1lIV1jz6zt3OH06bK3I6Qcyg==
- Ironport-hdrordr: A9a23:wrt5Hq7ul50P1tvqhgPXwZeCI+orL9Y04lQ7vn2ZFiY5TiXIra qTdaogviMc0AxhI03Jmbi7Scq9qeu1z+873WBjB8bZYOCAghrnEGgC1/qv/9SEIUHDH4FmpM BdmsRFaeEYSGIK9foSgzPIUurIouP3lpxA7N22pxgCcegpUdAY0+4TMHf4LqQCfngjOXNPLu v42iMonVqdUEVSSv7+KmgOXuDFqdGOvonhewQ6Cxku7xTLpS+06ZbheiLonSs2Yndq+/MP4G LFmwv26uGIqPeg0CLR0GfV8tB/hMbh8N1eH8aB4/JlaAkEyzzYIbiJaYfy+wzdk9vfrmrCV+ O8+ivICv4Dr085uFvF+ScFlTOQiwrGoEWStGNwyUGT3fARAghKS/apzLgpDCcwoSAbza5B+b MO0GSDu5VNCxTc2Cz7+tjTThlv0lG5uHw4jIco/jdiuCQlGc1sRKEkjQpo+a07bWrHAUEcYZ xTJdCZ4OwTfUKRbnjfsGUqyNuwXm4rFhPDRkQZoMSa3zVfgXg8liIjtYEit2ZF8Ih4R4hP5u zCPKgtnLZSTtUOZaY4AOsaW8O4BmHEXBqJOmOPJlbsEr0BJhv22tTKyaRw4PvvdI0DzZM0lp iEWFREtXQqc0arEsGK1I0jyGG6fIx8Z0Wb9ihz3ekIhlSnfsubDcSqciFcr+Kw5/MCH8bcR/ G/fJpLHv6LFxqbJbp0
- List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
- Thread-index: AQHYafEfUx0WfCMplEq6U+wPIyhlOa0lVccAgAByO4CAACeOgA==
- Thread-topic: [PATCH 2/2] x86/vmx: implement Notify VM Exit
On 19/05/2022 07:59, Jan Beulich wrote:
> On 19.05.2022 02:10, Andrew Cooper wrote:
>> On 17/05/2022 14:21, Roger Pau Monne wrote:
>>> Under certain conditions guests can get the CPU stuck in an infinite
>>> loop without the possibility of an interrupt window to occur.
>> instruction boundary.
>>
>> It's trivial to create an infinite loop without an interrupt window :)
>>
>> Also, I'd probably phrase that as an unbounded loop, because not all
>> problem cases are truly infinite.
>>
>>> This
>>> was the case with the scenarios described in XSA-156.
>> Case in point, both of these can be broken by something else (another
>> vCPU, or coherent DMA write) editing the IDT and e.g. making the #AC/#DB
>> vectors not present, which will yield #NP instead.
> "Can be broken" as in "the loop can be forced to be exited"? If so, how
> would a remote CPU / agent become aware of the situation, and know what
> the cause is (and hence know which IDT entry to clobber)? After all it's
> guest state, which we wouldn't want to alter for no reason. Nor should
> we put a guest in a state where #DF might eventually result.
Well quite... "Can be broken" does not mean that this approach is a
viable security defence.
It does highlight that the loop only continues while there is no
perturbation to the memory accesses involved.
~Andrew
|
