From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from NAM01-SN1-obe.outbound.protection.outlook.com (mail-sn1nam01on0078.outbound.protection.outlook.com [104.47.32.78]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id BA5E821E25721 for ; Fri, 28 Jul 2017 08:58:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amdcloud.onmicrosoft.com; s=selector1-amd-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=bS4wJpso2BpWCClsv+XHHPKQaUMEMA9nYnSneyucpcI=; b=Xspcphcrb8eBKus2QxVqbLrVBk3UNN+RFZ9bw/+SaKUkYsJNIpuRqxS3aX60juqVV/FXLzc1ivvPG/WFkxT9CGT56h4A/UGDgwymt1p3s6SPgFQ06HaVC7WRAuQAm7nx+9DeVkPuO9W+RzeuENwSN4LqaKW6Kom9AoOVykhBHXc= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=brijesh.singh@amd.com; Received: from [10.236.136.62] (165.204.77.1) by SN1PR12MB0158.namprd12.prod.outlook.com (10.162.3.145) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1282.10; Fri, 28 Jul 2017 16:00:36 +0000 Cc: brijesh.singh@amd.com, "edk2-devel@lists.01.org" , Tom Lendacky , Jordan Justen , Jason Wang , "Michael S . Tsirkin" , Gerd Hoffmann To: Laszlo Ersek , Ard Biesheuvel References: <1500502151-13508-1-git-send-email-brijesh.singh@amd.com> <841bec5f-6f6e-8b1f-25ba-0fd37a915b72@redhat.com> <4e2fc623-3656-eea7-09a8-b5c6d2f694e1@amd.com> <4071596d-32c9-e6d9-8c93-0d43d28e9b5a@redhat.com> From: Brijesh Singh Message-ID: <217545ac-962d-089f-9c9a-d2bbfca6427e@amd.com> Date: Fri, 28 Jul 2017 11:00:30 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: X-Originating-IP: [165.204.77.1] X-ClientProxiedBy: MWHPR2201CA0060.namprd22.prod.outlook.com (10.172.59.34) To SN1PR12MB0158.namprd12.prod.outlook.com (10.162.3.145) X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 1835448f-fc22-4d6f-39a1-08d4d5d1c9ba X-MS-Office365-Filtering-HT: Tenant X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(48565401081)(300000503095)(300135400095)(201703131423075)(201703031133081)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:SN1PR12MB0158; X-Microsoft-Exchange-Diagnostics: 1; SN1PR12MB0158; 3:W38LBI+wnU9rvtC0mRKwlj861fO6vRHHEdP9XZxKevn8fBAC+InlfGwIKr38CvvgyPvgrQP7RO8zTfJ15+2Q6krXbTzMwqP46zdrIMMAZhmUM6xsHUwJhAHtz+n+SmPPDHFp7ylNPgkcs/WySNJYdzp4+U+baPk/4eLHWxBPi9yCz0YyYXgJaJfO7238JA7X1EzpGvbA07c37OIXkp9b63hVkZijIDWPRDGjL5Af3caHj3XxpY2oZ7KzmA4uQqCCDTx409Lyc9dI4CNawPbeYCxAbcnMXeeFZKW8/JeEaiDpmIiV7i8NbDyy3B5tVetlETUrxchGtKu1a/SY4g6Ko7hXAy2QoyPupK5SlVcy8rN/YcJvAAsQfGFQpwQZRd0MPs3WQLRFQkk8tvcLt1XUpfQm7EuJHisI0oP/tQdGqJ+Bv/u2LFkeuj/Zq44UlqH5c5FmlwN0p7WlVH2r/6Bm3+Np+ced2K+5sTTpBQNWn9ruxq/YjM3eYCHtXFftyrQ7iI8ps2vgOMQaH80NoprkwOaCUHqqooSvqb5iRMC7uhi2AgREAJTpxVgbON5Dx0kYKt8VnpGdesjl7MKlrdbvKxq4jDLwRaCx7sj3ttCMCIS1Jl55BrNVROm8tB1Z4MhIua1CIy05TsLAjsTBZqjZqdD6cK9bmxDpKnv95ro2yNCXGWIwOKkwa/QO/LZxmobPAdjLN931qBkIMyQhwEB1nQofdGYAXJpBMQhNdCTs+/mzBjl0zjIh7L1azaBCZQdcPl0xNorDPxG230y2xeWCfQ== X-MS-TrafficTypeDiagnostic: SN1PR12MB0158: X-Microsoft-Exchange-Diagnostics: 1; SN1PR12MB0158; 25:uV3zkxgAqQKYwxtg8IJuXcQePUwDhEspkZ97pAmJVhAqd6gjr432y0I+/iC41lozgnQDX0AchRM7yzT5JBhYPlWbd7qWjFgtKYf1yPh4D6cx50jdW1QRwSAiuco1RpiRZoS1Iuh18w0O4GJIN+7chjKt2u9sufpop4wP4vVzkF3D6UPAV/17TynqA0A3gVWI3YAvEegnmKcVY027BZOoESaFfkCU3kKxA7GlqwxtG9/We5EB5LZWNn/hiUJD2fEZAlCBUMazTTWK7xmdTSbYz3fBC9ymv5jg/x2Kf8pslzgpY1SCpcXyuV2cOwNjLyokKis3U9eOzOp0h+dM0okz4QmXWPLbDg4XFXm2ZJRAHN4R/OKo2QYKG9NygzkELuMMgP1Zbp7vRHITlJfSkiu/wfUZ6mZdC2OzQQPP7xAoos39i3HBo5WPFAXmsNv7N9Y0J8CCwRT6tg/663KokV9EOcA3Q9kHSXwTkUY2UmdX0EBYaVeSNM/LbTQ/P7TaVeC0QLa1wev0FeGrluBxQ31V8wa2p2WeK83dMl5bJAf5jAOzfN1t8ROqFzbo8nS2nCoONyZWT0kSimp0Uktt2HjcJKjap3iL7hgO/6VID0ZdlIc+tRK31A8PxIg4Wm+CtEGdNkj72czzhpIIVB6f4KxYFYwiFBhCoJ37Vlgy8RqnuOX1QrnH3TY4lJysnT/wix/KTnvEyFJTuf46tITt7tG12d8fOa7OKgiVmM/Fkdl6GNqHTRzSix8ckTPfPQpkOcTMIuPcNQTCImV/Vnx71Ht1cZvLr8Oq/bnu7pY6YuMhv9VNru6QzI8gQ1cNI/+yj0SQlOg8H1j3DIc1xj49scXlykPsxbnRgSvpU0g+B/UPOePl6cvwUpV1lZCCEygtwi3Xl3Za0c85RxagEC8C/kLeTJ0hBqN0TsxNyAAYhwk1nPk= X-Microsoft-Exchange-Diagnostics: 1; SN1PR12MB0158; 31:DuaZaFJAJeC1kMH395+UMA749MSxFvFg3tdw/myzkeBQptLlFEgeHMjLRdH1jj7QhIeDQxEHwJfX5ixcQ1GETkjSzqvNuMkoOou378Om3QrUv5UVh3yVVDDVPOIkcMWGel+Z6xfwTZxidtlBAHi9tLPRbkIeVWy03/TVfh51MmhRUCdm0WtENPmTSvCjdEvyGXgL7tJEgDB0gUaLxTCac0faHHXydY+hYIRe8y68lhuHeW5o+rItVGXrsun1zkOmRH5q5+RTxALij99IJPgj69bkNAAWzY752h2kFvo2eGfhHnKcu3/qefhN0q/1l5r3v6RZ9FpJOOFnvUTUCFwcwl/AC1JZoybr5IG/9oTC8A9EWVaZK0V/+c7GQNbU12RPs9kQVAt4cJeFMFHNNboZYVJimlsgepkCVqK1hx+EtpnY6seYI5A1Jo1XU90bme1Vmm399cCSj0qoXOn0zx+EzvHuQCr1mNTgr4IWCKJ8uaXcBGrS0CbA2exwjb/VCTKtNO4PcWkub/60Ug+ejwDvFuJdYEL7vK2SolZ03lOISSFiIyMSXIAAshPvQbNdZSltmCokWdhHeCxqjaDMGm897FmFLQlkhQ2L0opWKoWAyItyD/09ApxqoEEFC87umWZIhEyfp5pysuJVehKbc34MJsGbzcIt1y5icE2muqTVU7Y= X-Microsoft-Exchange-Diagnostics: 1; SN1PR12MB0158; 20:aOsgzX1LCbERaAZ2XaBLZOKWU8PXg/PQvaUpvOJ9Kwz6Nl9au2fGacEmqKGhV2rX/6DCtYRIwWODfKf2csjDIp10O1uUuaGRGnN4dDtX/Xo4cM9oxgXg/7jVcvd4RjChlhiEUxevDV1sngcbidqJtG4cRoC/9bpr35viqasudQcraleC45HZK5+IQzK/GWFfN8Vaq9ciJOaW2NRKaV31ierjAfHaJEsPpjtY7NMxvbmsLcjL2S0TJQ7WkpcnYbhGPn8Yc1GEttZx3j0TlcYd/XOx9WmJD/rxvu6hQudsI59sBL+PwJ4kycKu4cEXPeikf8Fg3xkRVQBHIMRROcxBPVy3Gbr4rnmu4TJE2R3fEgSF0ylH3plmlMiK8oxSQo41kJidTawv7/56CTrfIfwAIOJPyD6vJbPxcCJvTwlpTaRtBOK0O7W+y9cnp5ydGEuS4lZn/PnpWPcA8XRnQUTbK8qvTB0+M6sY9stsHjFbCnllH4aC4Lmi18Z3GjBlwsVf X-Exchange-Antispam-Report-Test: UriScan:(166708455590820); X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(8121501046)(5005006)(10201501046)(93006095)(93001095)(3002001)(100000703101)(100105400095)(6055026)(6041248)(20161123555025)(20161123560025)(20161123564025)(20161123558100)(20161123562025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:SN1PR12MB0158; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:SN1PR12MB0158; X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtTTjFQUjEyTUIwMTU4OzQ6STBCN0d6NHZKbDJ2dnM0ck5IMnFtWUR2Z1dV?= =?utf-8?B?MHBnb1BIbCtIWFFMbHQ0aTdVbTZUS01ENWc4allVSmRtWkY5dEk1RG1SaDk1?= =?utf-8?B?NXZ2cW1rNmhYYnNGM2dZUzVHNitYZUNLbEk2TzN2WWlYWWhsbjM5TDhVdXI1?= =?utf-8?B?ZFhKakxCRVZXdm8wT0tXb1diUEN3RTlZM3QrZVFxekZQTE5mWERWdTBDSHZU?= =?utf-8?B?RVBjS2Q1TG9hRmVsYXZUUERSdU1IM0JNVkFzVXF4ZEZlWmxOcFdIcG02c3Rm?= =?utf-8?B?eG9naGdnRGJLVG1IWEtUMEZGK1J1SFczWkxDOXdqMXUyVmUxTmY1b29zNHNX?= =?utf-8?B?V1VHd2tKR3UvRFBaeHdrUzJDTGJBcWdEMDE5OTV2WmRSVTAxMkxGVGQ1d0Zx?= =?utf-8?B?Sml1alFTa2FlMWFYb3F1cTdST2VOVjNxMGN0K1V6NXhwS3htVlRKR2FmNjd5?= =?utf-8?B?SUVvWGpoSG5kbWtqcnZRa0VrSFFjNnYyMXI0SkRKR3o0aEFxY3FFdEZ0ak1o?= =?utf-8?B?U21DSzFQTngzR29EaUtTR216L0JMMGRFRG90MS9aR2FTb0RWL1NhOTJGSTV4?= =?utf-8?B?emVEbUhHaVJZVkRrYW9TT1EwVVFWUS9SL2JpUEtBWWJ1VHZrS3JXY3pMYitD?= =?utf-8?B?RGNoNytsSnh4eDdEeUZNOTI1ZE1IakdsLzJrTU9IZDZGL1JyVlhzU3l2Tk5B?= =?utf-8?B?S2FBL1M0aWZ6TVc2ZnVYY09yMnhoWXpHUXJBaXMxY0J3ZGdvWERlbXlhMmlq?= =?utf-8?B?ZUwrVFBJSXFkWjVEREpwZS9nZnNwaUF5MW5EREkvanNpZ2ZrbmYxc1NrTzlQ?= =?utf-8?B?VzVyVGdNUFpNTGlvMzNBZmZNS2Jmb0ZYRVkydzdsUFJhYzhJMHN1WHhVVDBT?= =?utf-8?B?clpQaGYrOC92enRjVU1BbTBVdWxoTG83dEszd3dNdEtpYjdZc1J0L0JwNTg4?= =?utf-8?B?RUdkMyswWVRDbk5VTFRrb1dPeFZhaGRrRm1WcGRyZVZhL1RJalF4ZTYxSWg2?= =?utf-8?B?d291eG1TcGIrUWx6K1NJMlZ0alEydXhaQ2lTUkljRHFZOHU0Q2dKSHFBVUdi?= =?utf-8?B?RE5MVWRUclVHNGp0WnlKOFhJVVYrTnk1SmdWR20zVkNHbERGVkRSbnlpZ1dJ?= =?utf-8?B?WUxnNnNGcGR0dDRXWWxFeXdQVkFiV0NScXFYYnBka1ZhTGhmNFBJaDVNUVM2?= =?utf-8?B?dmhTb1NUYml4QnFacVBKZXNtNVJWYzYxVFJyc25Pb3kzdDRWTDczdVRCb3Ja?= =?utf-8?B?UGNmcGMvUFF3MjRnWXdyS0FEbitQQkpmNUVZUXAwSzN6ZE10Q1B6V3JJeHdX?= =?utf-8?B?TEIwQ2U4RFpmTm9PdmJHQ0twUEV2SE1kSmlLS0RRamNFdGd0ZGVFVndYRG5i?= =?utf-8?B?aDdaMVFtclNPd25VTUwyeDJHcFhibkRhYVZHSE1iV0RwU3VUWVRJaXlZTU40?= =?utf-8?B?ZFhjcXEwUzNDY1E5YUtjYXRRVGpveHlqcXh2NHp6MlNCODJjQ1piM2lxc3V5?= =?utf-8?B?U2hZczRqM3NCaHNLdXdNTHFSZGlpVC9xTkJIS2ZOd3pRcU0yTkJiclVRR1J2?= =?utf-8?B?K2ZHZjRCQ1c5a216Z1B3aUd1a3ZTODV2YmJ3NnkwVkI3b2ZYMWxYeVlTbm01?= =?utf-8?Q?8PxM0HImayRvmYojYm/?= X-Forefront-PRVS: 03827AF76E X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10009020)(4630300001)(7370300001)(6009001)(6049001)(39410400002)(39850400002)(39860400002)(39400400002)(39450400003)(39840400002)(57704003)(189002)(377454003)(24454002)(199003)(81166006)(81156014)(53546010)(101416001)(8676002)(31696002)(2906002)(68736007)(54906002)(6306002)(86362001)(25786009)(551934003)(6666003)(345774005)(83506001)(2950100002)(4326008)(7736002)(6246003)(53936002)(33646002)(42186005)(38730400002)(105586002)(106356001)(305945005)(6116002)(65826007)(5660300001)(478600001)(966005)(47776003)(93886004)(66066001)(65956001)(65806001)(36756003)(3846002)(31686004)(97736004)(64126003)(90366009)(4001350100001)(229853002)(23676002)(189998001)(77096006)(50466002)(6486002)(7350300001)(54356999)(76176999)(50986999)(230700001)(134034003); DIR:OUT; SFP:1101; SCL:1; SRVR:SN1PR12MB0158; H:[10.236.136.62]; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Received-SPF: None (protection.outlook.com: amd.com does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtTTjFQUjEyTUIwMTU4OzIzOlVWZGNTeXBnaTYxMlk4OFZlWnIvMEFPa2c5?= =?utf-8?B?UWFhcGY1VmJiNGxrQVMrVmdOU0JxUXhUcHZyZy8vUkRtS2F1YXV2WEM0RGsx?= =?utf-8?B?MmxHTW53NUZsWFpqUXBnUVpraGU1YWpvNll5WUVCMjNwMmFCQ2dZYVJJSUhh?= =?utf-8?B?SFNXV3BEVUdEaDA1bENjTmtkUTlKV3FMaTBTMEJFdXg3N3hvRkZDcHlrWlQ0?= =?utf-8?B?YWZKQ2lWVER1Zk00eG9SVUwxNmd5dVlWRGpZbkh5OXhtSWlJWTIyRnlWdy9w?= =?utf-8?B?NFphUFFBcm9nbXVzT1hOdUc2UFBiQ2Z1VXJKUmZ4UXZlNlpPdE9sbjdUYjVD?= =?utf-8?B?Z1AvOXVBOE54SHBGRWFpNmFidHV6OVhuS0xMZTN0RWt1bXNDOVljMlo5Q3cv?= =?utf-8?B?UVFOT0lHZWVNWTlPWVhFMy90dWNGd3AzeTgzUUZZSTFpQ0hvT2hpQTc4OTRS?= =?utf-8?B?cFdZbklqVnJGOUtzQWJyM0IrQkE4TmRXZC8vVEMrbGErcGJhaG91ZUV2U1Qr?= =?utf-8?B?TTRJczd4cExhZGN0VEE1R3VHVDJWcVFVT0hmZUlmV2RjY1EzK09haVBidUJY?= =?utf-8?B?dmNBYlVuaXM1NmZBMGFVMVVsMENEMnlCTndJK21HQTBBY2xLek1ROGRQT00y?= =?utf-8?B?WHF2ZzVWdlZWRm9MRjlxQjFSOHUxV2NNdkwwTDNWdFo4Q3ZSN1JlU1kwZkc1?= =?utf-8?B?WjZRNmFhYTVtNWVOdHN3SnNHbUZyN3JlZUtzQzBCMXpSNnBWWCtqbVUvSVVH?= =?utf-8?B?THEvRy9PaHZ5L3NoS0dBdFkrbHhYTi85djd1dnNBYi9mNlZETEtXdjljaEdk?= =?utf-8?B?R1l6elBjbG9UK1I4aXR1QlNNNjVnTWxYNEx1RXZ0bG16dFp5cFJKZGZJOFNK?= =?utf-8?B?cllBclA4K1R2OG81OHJwNW5WMXRQUERYWllTOUNJSzJRMlQ4ZzlVNlJpaVZo?= =?utf-8?B?czFuY3paWjFhWkd4SENEL3ozZGR2NWRwSTFPcXhaUmFxYzFLTER1UUp6TjRn?= =?utf-8?B?YW1ZdDBkVDlqY1ZGNlpNc1ZRS21wSVgxR2FFNCtwOSsyWmZCWVZibUI3NVRz?= =?utf-8?B?MHBnamFxUWg3dFc4ZWppTm9jZDhPTlBSVmh3ZVhJVVZZM2E5d2xSN0ZWWmVv?= =?utf-8?B?UFhxQ3pHRWF0eVN2WnVaUmg5RE9PY3hqUkZJYnZ6Q2kxUys5TWt0dlluaXBq?= =?utf-8?B?MDRNQ3RvQWhSTjFuYkZob3IxZ2dxa2E0WCtJaWlmSlR6amNvVzhtSDFNZ3N4?= =?utf-8?B?THJZbyt3emxpb3Z0UkMweHlodWtQSm53UUpnTEdTSW5VcDZKempFczFtN3JI?= =?utf-8?B?dkFWZmNKV2NjVjRLbDlSK2tCREtkb1NVVGg5UGVsbFpQNVZMWVFORWc0Ui9D?= =?utf-8?B?NmQ5SjRXY2gxVDlzeXI0aFhWQlZwVFI2K1ozN01QaWFxazhERVZFS2M4a1FX?= =?utf-8?B?c3NkYTZYZ0pZVTJkN2xSMjhrS3k5aWNKRHc3K2EvSlZjeXFBOVM5SW9NVkh3?= =?utf-8?B?RFlhMkttaElyam9IajZ1YzlCKzVzRlN4OTRlNjlOTDJFSzNNemdoMzNTVjFP?= =?utf-8?B?TmJENFBpMnRSUVBLWE1xRTJia1Y1QlpDKzJZUGxZR2NmQ0FQNHdhbDcrQnZw?= =?utf-8?B?ZlkzczJXS0RBQ2NxU1FLSTEzVlFWREVFRk9ZekFRSU1BUnZRUStVNWxnOHQy?= =?utf-8?B?VDVXb1pvUTV4RTJIWHZUZjFkVzQveVAyaE1HNmdjZ1pFQmZxNnJkNzlMRlMr?= =?utf-8?B?TGtsSllYL0l1U2hoYm9uVm1ORzgzRXRwajB6Z1JoTk9WWHEwL3JUTXFYSjlY?= =?utf-8?B?aUt0Qzl3d0NVT21ZT0IvVnRabDhGNUxTcWZpNFFEaW41YWhnWW1Ia09NQ0Va?= =?utf-8?B?Q1BNNVFhdSt1dVR2ekFMd1cvbXFMa1ArbkZ0V29uNStZdkJxTzhrUjJTU3U0?= =?utf-8?B?aXRzQllTNHlhdnREbnpBZ2tSUTIvVWdsY21ZYUxqOVZId2U2d2MzdXFiLzBr?= =?utf-8?B?dUdEeHVPUnhsTFVhODVhN3lIMnRjaCtXN1R5c091Q1NIUlJKejZ1TUdGWWZm?= =?utf-8?B?cFFDc3BBRkJFVXh2Q1FSdW5zM3k2UmhzSHhnREZGZVpaVDQxYUFBem81SE9K?= =?utf-8?B?Qk5NRFU3YVA3NXhZL0tVOXF1MWx4U21XTGZ3eVNtL0NSNEdybTdqS0JaWFhn?= =?utf-8?B?dEdOZlZhY3Y5VFhVdTlic3N4RUhDWmxaR0NrM1ErV1NDb1hOSGk2cFl3d3hj?= =?utf-8?B?dkRLUnBWQU1IbkZHcHRqWUZPZEJPUzYveTV2Qklta0VpNmZwa0RrdFBYWWFD?= =?utf-8?Q?5WWSt6WpgzbEMJBU=3D?= X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtTTjFQUjEyTUIwMTU4OzY6UDJpbk5NWjhITkh5R041S2t3Mi9GclFsWWJj?= =?utf-8?B?T2FCTEFnL3VhbG1BL1pUV21BWUtwdTFtM09XeTJqa29LNjR0NHB0UWJyVEQv?= =?utf-8?B?NzN3eGNUQVUvT3dEMFFjSnFzNjFoZGpPanJDRlQyTjdONXI2OFFlT2h0ZzY0?= =?utf-8?B?Z3A3RkhibnJMTUJoNTJhSEdBdkJKeW1iK011NC85NmduT1JmVWdvQTNQK2lI?= =?utf-8?B?MEI4aUFhRkVWRm1KRC9ydE1hSGFlRnlBL3F1dDc1ZlVSN0ZFNnpSbnNiQUtm?= =?utf-8?B?SUQxU0d6QVYxRVoxbEFYOHV5WGg2QkxEcEQ3Y3IyTmdTc2NYdTFreXB3OHBr?= =?utf-8?B?M2UwQ3hSR1F3MEdwcU9KZWFGRG5YZzVWbWQyZm5BZTFWUVp2K29iRENDTTZU?= =?utf-8?B?a3Z6TmtVc0srR1dlZG5LNUszQkRQY0ZML1dTU0tCVlZOY3Zxc2V4dmoyaks0?= =?utf-8?B?NW5jbDNyenN6VCtkdnRWYUg4ZzgyWU9MdVNCd2I0QUs4UFJqeVBMMWtuNVlP?= =?utf-8?B?Z281bzhMd3p3WU5HbTNhM1p0ZGlsc0MxWXc4QzRRWjg0NnRaVnBzeHVDMExs?= =?utf-8?B?TlRuQkhLTDh3UHozVlB1S2ZDK0pWOEtoSGFlcEZ5TVd6YlAwZmNjdW9OYXll?= =?utf-8?B?VEwvTWh2U3o2UnZQSlNNLzRIVHhkcEx4dHJEN0U1QTBmOG9odE5abHFWOU1x?= =?utf-8?B?S0FTYWVVVkNRVmFBZ2RtWm5CTzdtQmFIZkdIUHRhU3NpMGY2RUtzMGNCRE9S?= =?utf-8?B?Q3NpU0tJWGEraTI0MWltajdQN2svZU1FemVDNnFUeGI2bm1sM3JSWHlvNmlv?= =?utf-8?B?em5uM3lycU5QTmd5M20remppT3Q2T0xuUnFMRytFUnp6eU1MM094Q2tlc2sx?= =?utf-8?B?dU9SMFpXOVdpSHk4alJJVXhDRWZKWWZVWGNUMEJ0UCtHKzM5UDBGNWg4TWhv?= =?utf-8?B?eFFtdDRZSGZLRnp6WCtjTEVDeFVjOTlSeFJ0L2x2UU4rNWc1cXBCSThIYjMw?= =?utf-8?B?dEt2aWdITzRpQUxnWElWNXBGQ2E4M3NKeWtXLzhtUHJSRXJjdHNweTVGOTRG?= =?utf-8?B?YWJEaE54K0gvWHdMQmVvaUM5c3hJUmpuVDloTytMdHF5MU51VkhZY3FaQ0xB?= =?utf-8?B?d0pTMDI5cjg0TE82UURlTkhoNFV2aG1YRSt6UHQ0cmxGT2xqdEFtZXd3Um56?= =?utf-8?B?WVR5TmVncVRBcHNqSXZrSnJ4c001ZzNEVzhGdEU4eTZ0WnNlb3k0ellMb2No?= =?utf-8?B?NVhZV0doVk1tL0V4RFBRN0FnWmo2a1gzQkJQLzRxZVlhWkt0VVZ0UllJbDln?= =?utf-8?B?UXVENzdPbVhqMTJSSTV4RUNSWEJPNGRpVHBIY2FTZnkxVjVnVDN1bTIvNjlU?= =?utf-8?Q?zS0VDVT?= X-Microsoft-Exchange-Diagnostics: 1; SN1PR12MB0158; 5:OK5et4WE7NTw72GFE85hZcKC7JBfuBv8nqcmrmu/IRW9DY2iHOOopsFWxyPVPGqLiGFrZ42K5Lc9LlJ/jj5gMqyKo+US98UYyGTOn3HnEvQQSdWibCoVaggXZESlkHUvGD6ONtJKYn4RUKZlCgK0Q5CAtLjmQqJLxXRNNRkp13eTvJLKESoZJ84HU15/FZMcVDp35Fllcj7h34Pg0o0ojv+54XMuWq8mYk7JLZeqON29cnrxzClm9YXaEqgsfRBnMfH7gosITQB2FjBpw6AqWNSBFskWimbgqib+d+dRms0OA4Wwk09IX5SPdqF/5azXciulvJ+6cV+6Efz4KxkF/CXl7Roh+vVfv+0SH83+zFpXHJ/j/i12EcanzLRLNSyrEg27TOVG3K/8sSHqWQRqXHRiCOfYJv2oU13e2XH9u71IVCYtVN7G0GAvGnUKZCcj+oS2AfJZYbdZrMDJLgbDtgyc0Y4YeEC6Hvep6BrEo0CU+PgTf48CUsZ1mLwnhzcO; 24:jStudweNKTDq26+PgfYyOls5IL1bSfZn0+2SJlPGw2HAOB3Nf1YMqfGvrNHq2V6BDk1UTC70o/IcRAJx5KfcojcOy0o1tGAPzlkO/9oQS54= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; SN1PR12MB0158; 7:66bACUBmrEBbUB25xqj0Zr8c5J/RrHljvnmQLKYR/Z1MC/TWHgDZjsuXp/E6L3Z2dRG0ipUiEt/XczAO7PccyQTtIvtM1hSPPVBDh+i5tNNh5F4Ce2gX2cp+kJWs/29dtxzHHqtjeIgscNeG7uYRDk/VlmxhunAf+MrvOyrCK8IQriTUnRQb1XS9Co3S9N6h/yaGCzFdTGY5/CuU3eD+LIJV1mh5cuI40VGdPksG3wifjuPCRSj6xmwIc1UjJ/lvLkEtn2CK1JxdQsLquG7cy+wnCAAcwQsmtw4CZSNsDaN4Jr0msX2eoL5P6JF9Wmi7HmpRo6oz9yjVBenC0ZNxSDYzwWDS5ANPFHOwAuDVUlVJ7MzinVzYPgLeLeWQq26VTFUizGtdBcCOhTZi1Aad/OFjussqv/DWUVOZOGq+hHC9XT4tFBZ0n005UMg95DV6O2FBwepL6RRf7pk2o3lASLO8Mhdzso/GoQ+YPXt6lQBnWG2HRXVOuSvjlJwkRJv1EQDPbt9EtzZmNXxEiObyj02HNNv/SqdiIHWgZy4aFsPKuj1nkbhEaasmmaiHnEzBzhaOTzTXP9ZQzTbvBIEdBC+k0dg/RuQh0H4Qv5KzlPdQA39LR0u4wYJsKZn5pf6edCdn0FXbXE8l/b1dOzErkcYFre4+5emNkrvbFTodqU0/Jyq9To6LTZUNo4LeI0cwct9a8sjBo8iu5viswfAyyNiop93Qo0Jr9uKT+ys9+MqMBMcB6ybrJhii+gqKWTtrm976u/onBHieGhJ9T3z1brvQVmzBHDEpd6j7fADw2uM= X-Microsoft-Exchange-Diagnostics: 1; SN1PR12MB0158; 20:+AfNplIX7A+LffNGzx52qckUb6gVTkUla/4SUMqk6HmJ3t4EhUOaoKLnlAqUkUnjTm8gQGuD0IpzWgu9JdmmI3m5bp0eKqZH4YIi7Fc7nIMU8naf/5pXW/aWzUYJeb5oo1VBpio6Z0XksXzy0yBwcpP3vx6R81CTLHjAajVj/kq1hYiW2xUd2mdag9cf04CVixyDSDiL8dd9V7zlNCBCz56+wcaMh1LFIQ6Wc1WKOq1NP8GgfQ20asFu5M277RNa X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 28 Jul 2017 16:00:36.2888 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1PR12MB0158 Subject: Re: [RFC v1 0/3] Add VIRTIO_F_IOMMU_PLATFORM support X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jul 2017 15:58:36 -0000 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit On 07/28/2017 08:38 AM, Laszlo Ersek wrote: > On 07/27/17 21:00, Brijesh Singh wrote: >> On 07/27/2017 12:56 PM, Ard Biesheuvel wrote: >>> On 27 July 2017 at 18:16, Laszlo Ersek wrote: > >>>> Normally, Map allocates the bounce buffer internally, and Unmap >>>> releases the bounce buffer internally (for BusMasterRead and >>>> BusMasterWrite), which is not right here. If you use >>>> AllocateBuffer() separately, then Map() -- with >>>> BusMasterCommonBuffer -- will not allocate internally, and Unmap() >>>> will also not deallocate internally. So, in the ExitBootServices() >>>> callback, you will be able to call Unmap() only, and then *not* call >>>> FreeBuffer() at all. >>>> >>>> This is why I suggest introducing all four functions (Allocate, >>>> Free, Map, Unmap) to the VIRTIO_DEVICE_PROTOCOL, and why all virtio >>>> drivers should use all four functions explicitly, not just Map and >>>> Unmap. >>>> >>>> ... Actually, I think there is a bug in >>>> "OvmfPkg/IoMmuDxe/AmdSevIoMmu.c". You have the following >>>> distribution of operations at the moment: >>>> >>>> - IoMmuAllocateBuffer() allocates pages and clears the memory >>>> encryption mask >>>> >>>> - IoMmuFreeBuffer() re-sets the memory encryption mask, and >>>> deallocates pages >>>> >>>> - IoMmuMap() does nothing at all when BusMasterCommonBuffer is >>>> requested (and IoMmuAllocateBuffer() was called previously). >>>> Otherwise, IoMmuMap() allocates pages, allocates MAP_INFO, and >>>> clears the memory encryption mask. >>>> >>>> - IoMmuUnmap() does nothing when cleaning up a BusMasterCommonBuffer >>>> operation (--> NO_MAPPING). Otherwise, IoMmuUnmap() clears the >>>> encryption mask, and frees both the pages and MAP_INFO. >>>> >> >> I agree with you, there is a bug in AmdSevIoMmu.c. I will fix it. And >> introduce list to track if the buffer was allocated by us. If buffer >> was allocated by us then we can safely say that it does not require a >> bounce buffer. While implementing the initial code I was not able to >> see BusMasterCommonBuffer usage. But with virtio things are getting a >> bit more clear in my mind. > > The purpose of the internal list is a little bit different -- it is a > "free list", not a tracker list. > > Under the proposed scheme, a MAP_INFO structure will have to be > allocated for *all* mappings: both for CommonBuffer (where the actual > pages come from the caller, who retrieved them earlier with an > AllocateBuffer() call), and for Read/Write (where the actual pages will > be allocated internally to Map). Allocating the MAP_INFO structure in > Map() is necessary in *both* cases because the Unmap() function can > *only* consult this MAP_INFO structure to learn the address and the size > at which it has to re-set the memory encryption mask. This is because > the Unmap() function gets no other input parameter. > > Then, regardless of the original operation (CommonBuffer vs. > Read/Write), the MAP_INFO structure has to be recycled in Unmap(). (For > CommonBuffer, the actual pages are owned by the caller, so we don't free > them here; for Read/Write, the actual pages are owned by Map/Unmap, so > we free them in Unmap() *in addition* to recycling MAP_INFO.) The main > point is that MAP_INFO cannot be released with FreePool() because that > could change the UEFI memmap during ExitBootServices() processing. So > MAP_INFO has to be "released" to an internal *free* list. > > And since we have an internal free list, the original MAP_INFO > allocation in Map() should consult the free list first, and only if it > is empty should it fall back to AllocatePool(). > > Whether the actual pages tracked by MAP_INFO were allocated internally > by Map(), or externally by the caller (via AllocateBuffer()) is an > independent question. (And it can be seen from the MAP_INFO.Operation > field.) > > Does this make it clearer? > It makes sense. thanks One question, do we need to return EFI_NOT_SUPPORTED error when we get request to map a buffer with CommonBuffer but the buffer was not allocated using "EFI_PCI_IO_PROTOCOL->AllocateBuffer (...)"? At least as per spec, it seems if caller wants to map a buffer with CommonBuffer then it must have called "EFI_PCI_IO_PROTOCOL->AllocateBuffer (...)" >> >>>> This distribution of operations seems wrong. The key point is that >>>> AllocateBuffer() *need not* result in a buffer that is immediately >>>> usable, and that client code is required to call Map() >>>> *unconditionally*, even if BusMasterCommonBuffer is the desired >>>> operation. Therefore, the right distribution of operations is: >>>> >>>> - IoMmuAllocateBuffer() allocates pages and does not touch the >>>> encryption mask.. >>>> >>>> - IoMmuFreeBuffer() deallocates pages and does not touch the >>>> encryption mask. >>>> >> >> Actually one of main reason why we cleared and restored the memory >> encryption mask during allocate/free is because we also consume the >> IOMMU protocol in QemuFwCfgLib as a method to allocate and free a DMA >> buffer. I am certainly open to suggestions. > > Argh. That's again my fault then, I should have noticed it. :( I > apologize, the Map/Unmap/AllocateBuffer/FreeBuffer APIs are a "first" > for me as well. > > As discussed earlier (and confirmed by Ard), calling *just* > AllocateBuffer() is never enough, Map()/Unmap() are always necessary. > > So here's what I suggest (to keep the changes localized): > > - Extend the prototype of InternalQemuFwCfgSevDmaAllocateBuffer() > function to output a "VOID *Mapping" parameter as well, in addition to > the address. > > - Modify the prototype of the InternalQemuFwCfgSevDmaFreeBuffer() > function to take a "VOID *Mapping" parameter in addition to the buffer > address. > > - In the DXE implementation of InternalQemuFwCfgSevDmaAllocateBuffer(), > keep the current IOMMU AllocateBuffer() call, but also call IOMMU > Map(), with CommonBuffer. Furthermore, propagate the Mapping output of > Map() outwards. (Note that Map() may have to be called in a loop, > dependent on "NumberOfBytes".) > > - In the DXE implementation of InternalQemuFwCfgSevDmaFreeBuffer(), call > the IOMMU Unmap() function first (using the new Mapping parameter). > I will update the code and send patch for review. thanks >> >> [1] >> https://github.com/tianocore/edk2/blob/master/OvmfPkg/Library/QemuFwCfgLib/QemuFwCfgDxe.c#L159 >> >> [2] >> https://github.com/tianocore/edk2/blob/master/OvmfPkg/Library/QemuFwCfgLib/QemuFwCfgDxe.c#L197 >> >> >>>> - IoMmuMap() does not allocate pages when BusMasterCommonBuffer is >>>> requested, and it allocates pages (bounce buffer) otherwise. >>>> >> >> I am trying to wrap my head around how we can support >> BusMasterCommonBuffer when buffer was not allocated by us. Changing >> the memory encryption mask in a page table will not update the >> contents. > > Thank you for the clarification. I've now tried to review the current > code for a better understanding. Are the below statements correct? > > - For the guest, guest memory is always readable transparently. > - For the host, guest memory is always readable *as it was written > last*. > - If the guest memory was last written with the C bit clear, then the > host can read it as plaintext (regardless of the current state of the > C bit). > - If the guest memory was last written with the C bit set, then the host > can only read garbage (regardless of the current state of the C bit). > Your understanding is correct. > *If* this is the case, then: > > (a) We already have a sort of guest->host information leak. Namely, in > IoMmuFreeBuffer() [OvmfPkg/IoMmuDxe/AmdSevIoMmu.c], the C bit is > restored, and the pages are released with gBS->FreePages(). However, the > pages being released are not rewritten in place (they are not actually > re-encrypted, only marked for encryption whenever they are next written > to). This means that pages released like this remain readable to the > hypervisor for an unpredictable time. > > This is not necessarily a critical problem (after all the contents of > those pages were visible to the hypervisor at some point anyway!); but > in the longer term, such pages could accumulate, and if the hypervisor > is compromised later, it could potentially read an unbounded amount of > "past guest data" as plain-text. > Very good catch, I can *zero* the pages. IIRC, I did not consider doing so because it may introduce unnecessary perform hit (mainly when dealing with larger pages). I think when we load kernel or initrd using QemuFwCfg DMA interface we allocate large buffers. I will still go ahead and experiment *zeroing* page and measure the performance impact before we integrate the solution. > (b) Plus, approaching the question from the Map() direction, we need to > consider two scenarios: > > - Client code calls AllocateBuffer(), then Map(), and it writes to the > buffer only then. This should be safe. > - client code calls AllocateBuffer(), writes to it, and then calls > Map(). This will result in memory contents that look like garbage to > the hypervisor. Bad. > > I can imagine the following to handle these cases: in the Map() and > Unmap() functions, we have to decrypt and encrypt the memory contents > in-place, after changing the C bit (without allocating additional > memory). Introduce a static UINT8 array with EFI_PAGE_SIZE bytes (this > will always remain in encrypted memory). Update the C bit with a single > function call for the entire range (like now) -- this will not affect > the guest-readability of the pages --, then bounce each page within the > range to the static buffer and back to its original place. In effect > this will in-place encrypt or decrypt the memory, and will be faster > than a byte-wise rewrite. > > * BusMasterRead (host will want to read guest memory): > - Client calls Map() without calling AllocateBuffer() first. Map() > allocates an internal bounce buffer, clears the C bit, and does the > copying. > - Client fires off the PCI transaction. > - Client calls Unmap(), without calling FreeBuffer() later. Unmap() > restores the C-bit, *zeros* the pages, and releases the pages. > Yes this will work just fine (see my previous comments on *zeroing* pages) > * BusMasterWrite (host will want to write to guest memory): > - Client calls Map() without calling AllocateBuffer() first. Map() > allocates an internal bounce buffer and clears the C bit. > - Client fires off the PCI transaction. > - Client calls Unmap(), without calling FreeBuffer() later. Unmap() > copies the bounce buffer to crpyted (client-owned) memory, restores > the C-bit, *zeros* the pages, and releases the pages. > Yes, this will work just fine (see my previous comments on *zeroing* pages) > * BusMasterCommonBuffer: > - Client calls AllocateBuffer(), and places some data in the returned > memory. > - Client calls Map(). Map() clears the C bit in one fell swoop, and > then decrypts the buffer in-place (by bouncing it page-wise to the > static array and back). > - Client communicates with the device. > - Client calls Unmap(). Unmap() restores the C bit in one fell swoop, > and encrypts the buffer in-place (by bouncing it page-wise to the > static array and back). > - Client reads some residual data from the buffer. > - Client calls FreeBuffer(). FreeBuffer() relases the pages. > Yes this works fine as long as the client uses EFI_PCI_IO_PROTOCOL.AllocateBuffer() to allocate the buffer. > This is suitable for the discussed ExitBootServices() callback update > too, where the callback will reset the virtio device (like now) and then > call Unmap() for all shared areas, without calling FreeBuffer() on them. > The above logic will re-encrypt the contents without affecting the UEFI > memmap. > >> Also since the memory encryption mask works on PAGE_SIZE hence >> changing the encryption mask on not our allocated buffer could mess >> things up (e.g if NumberOfBytes is not PAGE_SIZE aligned). > > This is not a problem for BusMasterRead and BusMasterWrite because for > those operations, Map() allocates the internal bounce buffer. Also not a > problem for BusMasterCommonBuffer, because then the client first calls > AllocateBuffer (whole number of pages), and so Map() can round up the > number of bytes and de-crypt full pages in-place (see above). > >> >>>> *Regardless* of BusMaster operation, the following actions are >>>> carried out unconditionally: >>>> >>>> . the memory encryption mask is cleared in this function (and in >>>> this function only), >>>> >>>> . An attempt is made to grab a MAP_INFO structure from an >>>> internal free list (to be introduced!). The head of the list is >>>> a new static variable. If the free list is empty, then a >>>> MAP_INFO structure is allocated with AllocatePool(). The >>>> NO_MAPPING macro becomes unused and can be deleted from the >>>> source code. >>>> >>>> - IoMmuUnmap() clears the encryption mask unconditionally. (For >>>> this, it has to consult the MAP_INFO structure that is being >>>> passed in from the caller.) In addition: >>>> >>>> . If MapInfo->Operation is BusMasterCommonBuffer, then we know >>>> the allocation was done separately in AllocateBuffer, so we do >>>> not release the pages. Otherwise, we do release the pages. >>>> >>>> . MapInfo is linked back on the internal free list (see above). >>>> It is *never* released with FreePool(). >>>> >>>> This approach guarantees that IoMmuUnmap() can de-program the >>>> IOMMU (= re-set the memory encryption mask) without changing the >>>> UEFI memory map. (I trust that MemEncryptSevSetPageEncMask() will >>>> not split page tables internally when it *re*sets the encryption >>>> mask -- is that correct?) >> >> Yes, MemEncryptSevSetPageEncMask() will not split pages when it >> restores mask. > > Great, thanks. > Laszlo >