From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753574AbcD0UKe (ORCPT ); Wed, 27 Apr 2016 16:10:34 -0400 Received: from mail-bl2on0087.outbound.protection.outlook.com ([65.55.169.87]:46523 "EHLO na01-bl2-obe.outbound.protection.outlook.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1752352AbcD0UK2 (ORCPT ); Wed, 27 Apr 2016 16:10:28 -0400 Authentication-Results: amd.com; dkim=none (message not signed) header.d=none;amd.com; dmarc=none action=none header.from=amd.com; Subject: Re: [RFC PATCH v1 00/18] x86: Secure Memory Encryption (AMD) To: Andy Lutomirski References: <20160426225553.13567.19459.stgit@tlendack-t1.amdoffice.net> CC: linux-arch , "linux-efi@vger.kernel.org" , kvm list , "linux-doc@vger.kernel.org" , X86 ML , "linux-kernel@vger.kernel.org" , kasan-dev , "linux-mm@kvack.org" , , =?UTF-8?B?UmFkaW0gS3LEjW3DocWZ?= , Arnd Bergmann , Jonathan Corbet , Matt Fleming , Joerg Roedel , Konrad Rzeszutek Wilk , "Paolo Bonzini" , Ingo Molnar , "Borislav Petkov" , "H. Peter Anvin" , Andrey Ryabinin , Alexander Potapenko , "Thomas Gleixner" , Dmitry Vyukov From: Tom Lendacky Message-ID: <57211CAB.9040902@amd.com> Date: Wed, 27 Apr 2016 15:10:19 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Originating-IP: [165.204.77.1] X-ClientProxiedBy: SN1PR12CA0019.namprd12.prod.outlook.com (10.162.96.157) To DM3PR1201MB1117.namprd12.prod.outlook.com (10.164.198.17) X-MS-Office365-Filtering-Correlation-Id: 2ddf09c4-ea76-4424-1fb2-08d36ed7f7d7 X-Microsoft-Exchange-Diagnostics: 1;DM3PR1201MB1117;2:+yIeywZnqv2sGeKbc0H//imzCpy/caszutIjfCQ2j7AeGKQmyi9YkHjW6kBSlEpdgR+NS7VGjUYpYhQXPv7bsVNv40Uj2yJxuiDb7z72Z5e2Z5/egtXHJ2Y6Mf9T3i61P7Jn0Shk+Y7LD8KYY7QDoXtHb6w5kHu7Ec9y4S12x8+g4UhIXY9hdvpygYmVoVY1;3:3ujIiN8Dys0FiGzh5NZGbs0W97FFyyCUTofqF6sIwTYwfbWe6pHb0k8gWPHBU31hmzuz01cxcssWcibjugvECujT8f+N6egCzK/7A0TCgZpyo1BzXLx+7A76Kk3wQTc/ X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DM3PR1201MB1117; X-Microsoft-Exchange-Diagnostics: 1;DM3PR1201MB1117;25:4XmJpu5XPNiAwnP0JU2b8eDrRIz2jOGVAwwv3wLhmqhGZ8KIaEViys380g3hnTclyzC1TaE5ZMotQreo6IMGeC3kNPdC7kL3DxuEIGhgPigIR9q/oHWCi+bDIWFxNLvxultjDIHtpFD0VnbQ5CXfzP9DShvI+Qc9X8a1ozeEKXxAwIMi9Of8UfrGGUQ7Rn6iNwmxj1WcW85Y3K4Rq/4AmuM5GqwG/FSzUEj7DmBb50I7IJeMtcVqCCKznqfGG+P/+D5umjH4k7USEq91wtQf7Cv6k3ohjD+wszFnSlU0fpKsvlBcyTNnkmb1zE809k5YMXeCnRU2l9tIrE+ZvujcZsXSPsqT6d2NITj+kJY4HtPMDsu/YZ7CoXbYPCInIouF3aHq5zYT8BGSqalDVnZKnxKeCH55Bip3aPRgXM+lFRwAWMxRK8jm3YsdREpFNnN+SjGNRrrVUDtKydK6QNNUJDztvhret8L0vlvgNOvN9znO7HT2yvgJB9qTAgzui+saJwVDkAjya01sFRm0swrMU1VcS8w1t3FWFsDTBIqUL8oy4DLXRDtt+eun8FaIMgu9aukFZDNsQuJ7Pb4s4Kc3hXLlljoHsk+QA6KyX1eoI3p/IAPqhoJ/XNtvz495Gy2g+gvwAOY2TF9/L60Kn94epRYGAZE8+utj4Kqn8nAcmfo= X-Microsoft-Exchange-Diagnostics: 1;DM3PR1201MB1117;20:PK+bWkZorwB4zaE/XyNMVk9LsT1OzRvLEI9XN9WYZC6QoPWLzDYGfykyZ939pPvcx25WQRALX5JcVNGx9HcKJuUekAFMHAW4KXqrutMZfVzxraHvf029nd9QXOl6YNVDqc+17MVfiUd4OHzShK+x9jrFRtGoROpygPMR+IbdWrC+BbcHfYY+pZHLxJd9jqnzShyu4nQa75SoRWRtqWw2j93RzPbKeyL7XjwIpJnhysLQp8yws3JlfnNyo+KVluZ9sSOzJym+fMj9dVAtbVprj5DGj86Mef4LmtSbLUIyPjwRQSztWk61NlNv/NhOEXzz5KYv2fOi3Wcu+sMUAxzkd/q23TXEaJa0fi5Sv5aV5a43znVOEKqrMDhf+rRfq3caxN6afC1SA956uhj/2RX/tgSxgUT3+ZZQJIbt71HIwWlfE5a27mUccnX2LbCzdns3f44s3wnFReVQ3HS349tvETlcZ6pFDdiXNMe4tOakE39DK2WyZlN3AumyGT80wGE3;4:fjhuQKsuPq+WoX646LWElnJQXcBew3FznGwVLgR5bAQEjyM8x0IJyhoyObna+skIepKxOOM3Bm9SD9uSTHNB6X676ieLpu8BkzBh9F0sZNM9ys+MFnx90SjJaMUue4DI0MNHJAsGRaspxDg7MtCuJOYo7vUcy77FH7Gi/mFl27G1GkbQFdN6h9AU4/mb2P6MVW56n/OiRA/oz8XKViAbMbeq3RwVQ7fR89f1PvwfQwWqc+hHA2zIx9n/uLpGbqq5fjFYUjtQK0qFBrZinUnHrsopLcpukknfgvHdgFbbSLNLpHMEaVk6tuNLgg9R/h5zcBof0TAFbxQXkTgqcCCOGgQ5zjx+IlERFSTKON/ri7k30SfYgBBQyUmjT5b0l8MnyWPM+W6/Dn8ljdvB10tidHJhJa6sddXVcEE7ZOXbLxY= X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:(9101521072)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026);SRVR:DM3PR1201MB1117;BCL:0;PCL:0;RULEID:;SRVR:DM3PR1201MB1117; X-Forefront-PRVS: 0925081676 X-Forefront-Antispam-Report: SFV:NSPM;SFS:(10009020)(4630300001)(6009001)(6049001)(24454002)(377454003)(66066001)(19580395003)(19580405001)(4001350100001)(86362001)(92566002)(65956001)(110136002)(1096002)(23676002)(65806001)(2906002)(586003)(189998001)(47776003)(6116002)(3846002)(4326007)(54356999)(87266999)(76176999)(83506001)(42186005)(5004730100002)(5008740100001)(65816999)(33656002)(64126003)(50986999)(77096005)(81166005)(230700001)(2950100001)(36756003)(217873001);DIR:OUT;SFP:1101;SCL:1;SRVR:DM3PR1201MB1117;H:[10.236.18.82];FPR:;SPF:None;MLV:sfv;LANG:en; X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtETTNQUjEyMDFNQjExMTc7MjM6Z3E3ZDJiYnAxaG9vVUg0dnU1a3V6YVd2?= =?utf-8?B?K3FaRE8wUThqdmtPSE0wcEtFUkJEOFFIN3VuRkMrMkkzTW43aUZJRVFjMk1B?= =?utf-8?B?WXVIdlpIZDNBbEJ0N2FPV2haUjkrUHBlamxYcEp3c1ZLbUFQb1hqeEJSd2pn?= =?utf-8?B?amhoZWhDVS9oSXRERVdLMitBRkNGbHpRdW9YWWhQamx3OGNZQk52UEJOYVBq?= =?utf-8?B?d05WYmQzVHVGYjBlNkVHUVhnRTFMZ0d3TTVSR3hFQWZlam83bkFXdUR5WnJZ?= =?utf-8?B?UWU2MzFKTGFPbVl1M2xCbjhTdmZ5Q1dHNWQybHhMZXlxUEJDNllxNmowTVM4?= =?utf-8?B?ZHMwVjAyRXFLSHQ4MGVBT3dGcEV1c2FnMEFISmF0WXJkTGRTUXRuOE5MSmM0?= =?utf-8?B?TnhwNHRUYTB3REJsLzJhTThqd1E3U1FEZlNLZ3E1QWJkZXBHWjRUbU42Wmti?= =?utf-8?B?clhkZ1lxNnJERzN5L1FnQmRndW8yWWNSZENHbzhuQ0tZd2lGcHRjZmlWVzEr?= =?utf-8?B?NUhzbXhUbStPRTBMOHJjWFQ1ZTJTdXRndEFwbUJsVXZ5bVQyNG1rUXo2UW1i?= =?utf-8?B?cmlDUEpFemtkajFRcmZ1S3Y2cGxwZ3FsWDZPZWIvRkVzbXc0cUJpM1VRZUdx?= =?utf-8?B?YnQzSzRBeWtNa2FVNWlzK2pVOGp1WGs2Q2I5eWVQZS9sRHVNQmtVM2pjejdO?= =?utf-8?B?cHhlZ0s2TWlXNS9CNTFUVjRGbnkrb3h3enFaNml6amtkSnJmTkFCYVRnbzdo?= =?utf-8?B?dGNNRG93UnVVNWZLaW1wRHQ1amV2Y2wzWWhpVDVLZkZNZVlaUDRsTmJmUk5W?= =?utf-8?B?c1JoN2s2aW4xcThqV1hjVUFnV0IwVzB5K2VFeUFMNndTL1pBZEIxdnhwZTIz?= =?utf-8?B?c1F1enMwYURkSCtMaG91R2NIcVFxNmZSclM0cFBLbzNMcWdlODlnVXZaYmxE?= =?utf-8?B?RU5IZGhoZlRNVnpPZFA1T0ovR2lrZTdlZ2ZlZkhmblc3L2tiMzNjTmFOUnQ0?= =?utf-8?B?eGxrdkw5Mmc0UExKZE9KMkdLWEZDVW5PenN4b1VGMm0ySTNQQmZZcUwxYi9i?= =?utf-8?B?MjFqUXNNWElCM0lyemkrNUxORk15cVdKb3BxUkhTSWdyTTdIMnJIdCtLWEFm?= =?utf-8?B?TGk1NHpPbGQwWllFY1I3S3BtY3p5V09wRCs0RS9tMktYamxyNURvMG8wR1R1?= =?utf-8?B?ZkRZd01lbytYV2UyRGRjbVZkNmRLQlhOVlhaSGVmY3RGejVPUWY3ZHRxOWxz?= =?utf-8?B?ckorYTlvVmlRczd3azVod0NQdmtnTTgxU2ZVVDdIQkRzSEU2bm02eHN4OWtv?= =?utf-8?B?L05NUXErTHZ0aE1kM29PLzJzN0J6SlBpdHJuS0UrNGRnQTh1L1BiTVgvZjNi?= =?utf-8?B?cUM5Ykpla1R4NXFrN2ZUYUdWMDhtOUlqcGRQd1RvSExwN01MYU41WU11TWtC?= =?utf-8?Q?gozTp+Fs=3D?= X-Microsoft-Exchange-Diagnostics: 1;DM3PR1201MB1117;5:NCkF1JkZ4RXsohCnOKsPWaAMKGArXNjDbs1vi8LnnOQU+VQTMbWIMqwCaBneWCw53428w2uud7VviryV+aUUTo2XTRQ8GuoGFuyTQeEjFXH5SfzSo/ArZ9HcIy8YE3b0vzk5CJGsXoemf82vCigR3w==;24:Ecl96aTOmiYWz4QqnQfDXG48HYVUYvlVY11ex8cXy+DBfzLLZmc12sNrd0q3R8nMYV3qayUI9ctj/OZOb3yQHygSJhMALchZXX3d1hns6BU=;7:s/x4v7ZgKpVL0E+5T0M3dugggwiT/OxqBBJ2VwVWmySuu2H9XPWSkKpshaWqrb9K939jo1202WnIEA2vsYWM/c9sGnyMzuYYktDE9mWHj/WqUGFXT2SIqAmFqkzuCSQn3lsx2/WFIPE3BwDqZbjocd9IMX4QEIWOOCkgmT4gIKw=;20:B5/hhZ4lvuhi+eF3SpYGypJX9iRB11Qn23kfMNCyErBrXtGuqmnBBocfPyv30kWF2ebQYX+136IcVWkPmtHLtJ2plT4hJ50EIIESjx/8MRWtdQgN0emFDOwUinoK0T4lJtMTqf4SJzflHWQmwAN0YfzzI2spxGSIeUDRdgDa4Iuuzw+Bco+++VijGib4bgCpr3LrWzmaFkhWNqc0uvzwtuFkFVVPk8ZNLq28xSH/eRzp2qlINcwux6I5di5tdAbI X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 27 Apr 2016 20:10:23.3216 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM3PR1201MB1117 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 04/27/2016 09:39 AM, Andy Lutomirski wrote: > On Tue, Apr 26, 2016 at 3:55 PM, Tom Lendacky wrote: >> This RFC patch series provides support for AMD's new Secure Memory >> Encryption (SME) feature. >> >> SME can be used to mark individual pages of memory as encrypted through the >> page tables. A page of memory that is marked encrypted will be automatically >> decrypted when read from DRAM and will be automatically encrypted when >> written to DRAM. Details on SME can found in the links below. > > Having read through the docs briefly, some questions: > > 1. How does the crypto work? Is it straight AES-ECB? Is it a > tweakable mode? If so, what does into the tweak? For example, if I > swap the ciphertext of two pages, does the plaintext of the pages get > swapped? If not, why not? The AES crypto uses a tweak such that two identical plaintexts at different locations will have different ciphertext. So swapping the ciphertext of two pages will not result in the plaintext being swapped. > > 2. In SEV mode, how does the hypervisor relocate a physical backing > page? Does it simple move it and update the 2nd-level page tables? > If so, is the result of decryption guaranteed to be garbage if it > relocates a page and re-inserts it at the wrong guest physical > address? For SEV mode, relocating a physical backing page takes extra steps. There are APIs that are used to have the AMD Secure Processor create a transportable encrypted page that can then be moved to a new location in memory. After moving it to the new location the APIs are used to haves the AMD Secure Processor re-encrypt the page for use with the guests SEV key. Based on #1 above, just moving a page without invoking the necessary APIs will result in the decryption returning garbage. > > 3. In SEV mode, does anything prevent the hypervisor from resuming a > guest with the wrong ASID, or is this all relying on the resulting > corruption of the guest code and data to cause a crash? There is nothing that prevents resuming a guest with the wrong ASID. This relies on the resulting corruption of the guest code/data to cause a crash. > > 4. As I understand it, the caches are all unencrypted, and they're > tagged with the physical address, *including* the SME bit (bit 47). > In SEV mode, are they also tagged with the ASID? I.e. if I have a > page in cache for ASID 1 and I try to read it with ASID 2, will I get > a fresh copy decrypted with ASID 2's key? If so, will the old ASID 1 > copy be evicted, or will it stay in cache and be non-coherent? In SEV mode, the caches are tagged with the ASID. So if you try to read a cached page with a different ASID, it would result in a cache miss for that ASID and will instead fetch from memory and decrypt using the that ASID's key. Thanks, Tom > > --Andy > From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tom Lendacky Subject: Re: [RFC PATCH v1 00/18] x86: Secure Memory Encryption (AMD) Date: Wed, 27 Apr 2016 15:10:19 -0500 Message-ID: <57211CAB.9040902@amd.com> References: <20160426225553.13567.19459.stgit@tlendack-t1.amdoffice.net> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: Sender: owner-linux-mm@kvack.org To: Andy Lutomirski Cc: linux-arch , "linux-efi@vger.kernel.org" , kvm list , "linux-doc@vger.kernel.org" , X86 ML , "linux-kernel@vger.kernel.org" , kasan-dev , "linux-mm@kvack.org" , iommu@lists.linux-foundation.org, =?UTF-8?B?UmFkaW0gS3LEjW3DocWZ?= , Arnd Bergmann , Jonathan Corbet , Matt Fleming , Joerg Roedel , Konrad Rzeszutek Wilk , Paolo Bonzini , Ingo Molnar , Borislav Petkov , "H. Peter Anvin" , Andrey Ryabinin , Alexander Potapenko , Thomas Gleixner List-Id: linux-efi@vger.kernel.org On 04/27/2016 09:39 AM, Andy Lutomirski wrote: > On Tue, Apr 26, 2016 at 3:55 PM, Tom Lendacky wrote: >> This RFC patch series provides support for AMD's new Secure Memory >> Encryption (SME) feature. >> >> SME can be used to mark individual pages of memory as encrypted through the >> page tables. A page of memory that is marked encrypted will be automatically >> decrypted when read from DRAM and will be automatically encrypted when >> written to DRAM. Details on SME can found in the links below. > > Having read through the docs briefly, some questions: > > 1. How does the crypto work? Is it straight AES-ECB? Is it a > tweakable mode? If so, what does into the tweak? For example, if I > swap the ciphertext of two pages, does the plaintext of the pages get > swapped? If not, why not? The AES crypto uses a tweak such that two identical plaintexts at different locations will have different ciphertext. So swapping the ciphertext of two pages will not result in the plaintext being swapped. > > 2. In SEV mode, how does the hypervisor relocate a physical backing > page? Does it simple move it and update the 2nd-level page tables? > If so, is the result of decryption guaranteed to be garbage if it > relocates a page and re-inserts it at the wrong guest physical > address? For SEV mode, relocating a physical backing page takes extra steps. There are APIs that are used to have the AMD Secure Processor create a transportable encrypted page that can then be moved to a new location in memory. After moving it to the new location the APIs are used to haves the AMD Secure Processor re-encrypt the page for use with the guests SEV key. Based on #1 above, just moving a page without invoking the necessary APIs will result in the decryption returning garbage. > > 3. In SEV mode, does anything prevent the hypervisor from resuming a > guest with the wrong ASID, or is this all relying on the resulting > corruption of the guest code and data to cause a crash? There is nothing that prevents resuming a guest with the wrong ASID. This relies on the resulting corruption of the guest code/data to cause a crash. > > 4. As I understand it, the caches are all unencrypted, and they're > tagged with the physical address, *including* the SME bit (bit 47). > In SEV mode, are they also tagged with the ASID? I.e. if I have a > page in cache for ASID 1 and I try to read it with ASID 2, will I get > a fresh copy decrypted with ASID 2's key? If so, will the old ASID 1 > copy be evicted, or will it stay in cache and be non-coherent? In SEV mode, the caches are tagged with the ASID. So if you try to read a cached page with a different ASID, it would result in a cache miss for that ASID and will instead fetch from memory and decrypt using the that ASID's key. Thanks, Tom > > --Andy > -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-yw0-f197.google.com (mail-yw0-f197.google.com [209.85.161.197]) by kanga.kvack.org (Postfix) with ESMTP id 03B716B0253 for ; Wed, 27 Apr 2016 16:10:27 -0400 (EDT) Received: by mail-yw0-f197.google.com with SMTP id l137so131574843ywe.0 for ; Wed, 27 Apr 2016 13:10:26 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0078.outbound.protection.outlook.com. [157.56.110.78]) by mx.google.com with ESMTPS id j93si3203725qkh.239.2016.04.27.13.10.26 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 27 Apr 2016 13:10:26 -0700 (PDT) Subject: Re: [RFC PATCH v1 00/18] x86: Secure Memory Encryption (AMD) References: <20160426225553.13567.19459.stgit@tlendack-t1.amdoffice.net> From: Tom Lendacky Message-ID: <57211CAB.9040902@amd.com> Date: Wed, 27 Apr 2016 15:10:19 -0500 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Sender: owner-linux-mm@kvack.org List-ID: To: Andy Lutomirski Cc: linux-arch , "linux-efi@vger.kernel.org" , kvm list , "linux-doc@vger.kernel.org" , X86 ML , "linux-kernel@vger.kernel.org" , kasan-dev , "linux-mm@kvack.org" , iommu@lists.linux-foundation.org, =?UTF-8?B?UmFkaW0gS3LEjW3DocWZ?= , Arnd Bergmann , Jonathan Corbet , Matt Fleming , Joerg Roedel , Konrad Rzeszutek Wilk , Paolo Bonzini , Ingo Molnar , Borislav Petkov , "H. Peter Anvin" , Andrey Ryabinin , Alexander Potapenko , Thomas Gleixner , Dmitry Vyukov On 04/27/2016 09:39 AM, Andy Lutomirski wrote: > On Tue, Apr 26, 2016 at 3:55 PM, Tom Lendacky wrote: >> This RFC patch series provides support for AMD's new Secure Memory >> Encryption (SME) feature. >> >> SME can be used to mark individual pages of memory as encrypted through the >> page tables. A page of memory that is marked encrypted will be automatically >> decrypted when read from DRAM and will be automatically encrypted when >> written to DRAM. Details on SME can found in the links below. > > Having read through the docs briefly, some questions: > > 1. How does the crypto work? Is it straight AES-ECB? Is it a > tweakable mode? If so, what does into the tweak? For example, if I > swap the ciphertext of two pages, does the plaintext of the pages get > swapped? If not, why not? The AES crypto uses a tweak such that two identical plaintexts at different locations will have different ciphertext. So swapping the ciphertext of two pages will not result in the plaintext being swapped. > > 2. In SEV mode, how does the hypervisor relocate a physical backing > page? Does it simple move it and update the 2nd-level page tables? > If so, is the result of decryption guaranteed to be garbage if it > relocates a page and re-inserts it at the wrong guest physical > address? For SEV mode, relocating a physical backing page takes extra steps. There are APIs that are used to have the AMD Secure Processor create a transportable encrypted page that can then be moved to a new location in memory. After moving it to the new location the APIs are used to haves the AMD Secure Processor re-encrypt the page for use with the guests SEV key. Based on #1 above, just moving a page without invoking the necessary APIs will result in the decryption returning garbage. > > 3. In SEV mode, does anything prevent the hypervisor from resuming a > guest with the wrong ASID, or is this all relying on the resulting > corruption of the guest code and data to cause a crash? There is nothing that prevents resuming a guest with the wrong ASID. This relies on the resulting corruption of the guest code/data to cause a crash. > > 4. As I understand it, the caches are all unencrypted, and they're > tagged with the physical address, *including* the SME bit (bit 47). > In SEV mode, are they also tagged with the ASID? I.e. if I have a > page in cache for ASID 1 and I try to read it with ASID 2, will I get > a fresh copy decrypted with ASID 2's key? If so, will the old ASID 1 > copy be evicted, or will it stay in cache and be non-coherent? In SEV mode, the caches are tagged with the ASID. So if you try to read a cached page with a different ASID, it would result in a cache miss for that ASID and will instead fetch from memory and decrypt using the that ASID's key. Thanks, Tom > > --Andy > -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org