From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1763260AbcINOLg (ORCPT ); Wed, 14 Sep 2016 10:11:36 -0400 Received: from mail-bn3nam01on0087.outbound.protection.outlook.com ([104.47.33.87]:25632 "EHLO NAM01-BN3-obe.outbound.protection.outlook.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1761527AbcINOLa (ORCPT ); Wed, 14 Sep 2016 10:11:30 -0400 Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=Thomas.Lendacky@amd.com; Subject: Re: [RFC PATCH v2 10/20] x86: Insure that memory areas are encrypted when possible To: Borislav Petkov References: <20160822223529.29880.50884.stgit@tlendack-t1.amdoffice.net> <20160822223722.29880.94331.stgit@tlendack-t1.amdoffice.net> <20160909155305.bmm2fvw7ndjjhqvo@pd.tnic> <23855fb4-05b0-4c12-d34f-4d5f45f3b015@amd.com> <20160912163349.exnuvr7svsq7fmui@pd.tnic> CC: , , , , , , , , , =?UTF-8?B?UmFkaW0gS3LEjW3DocWZ?= , Arnd Bergmann , Jonathan Corbet , Matt Fleming , Joerg Roedel , Konrad Rzeszutek Wilk , Andrey Ryabinin , Ingo Molnar , Andy Lutomirski , "H. Peter Anvin" , Paolo Bonzini , Alexander Potapenko , Thomas Gleixner , Dmitry Vyukov From: Tom Lendacky Message-ID: <74d7fcd4-18e6-a81c-2510-bf0fe8a08a53@amd.com> Date: Wed, 14 Sep 2016 09:11:13 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <20160912163349.exnuvr7svsq7fmui@pd.tnic> Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Originating-IP: [165.204.77.1] X-ClientProxiedBy: BLUPR0401CA0029.namprd04.prod.outlook.com (10.162.114.167) To CY4PR12MB1143.namprd12.prod.outlook.com (10.168.164.135) X-MS-Office365-Filtering-Correlation-Id: 63a5fa56-cd5f-44e9-35d6-08d3dca90417 X-Microsoft-Exchange-Diagnostics: 1;CY4PR12MB1143;2:CrqjXAReqyXQvbcfjB0AdFHopu2yMvyAjbjOyNWpWs22UKV5cx7nxOmlUAfLs8wAN8nKKOkvK7N0x05aLmDz02Y/BHcu4LMOekRsW41dKwXgSHoTA9MVXBAsyLKYDOK7stPXYy8tLl55PV4LHfE6HQpxVUQc//uM/nhd35aibesxv3satqwjpMNY/VIHfoR5;3:q4ruzkotO+xn+g1gptMaftzAEcJMJg56hMksC23LvI+5MdwdGkniJXy72fuH66id9vqn98Z0luUx3ln7MmIMzDxKJKYUrzqENLHTjUkyQ8uXfoEoQkW73+Jvvose/dfA;25:zRZ4NHs+ly9OHxg7fdQYGJX3s/z9zHrqs5UnrTrJu1d9FHja16bVNfS3ieJ2NaN8WuLP9ZGliUk8PF8n8CYlh+lTVTbfZhU2iA+YPCp2TnqFHmgQyXRwWmP0LuR+CdD8P+JJPB9DpoKsy+BsXxqHB1s8Mc4Qk3g9h0b4mOjjPQi3esbvVSEk+vmwtOKhlAJAf3sKRmPe2KHq0hiDuswwAsXmLccUCKlh2Qtxj9BDbWJM6jyiepUwxZ7/urj/WqJtxWfwlRLI/exgk5RM0LXcKoWNN4oKhNaN9Ka+3blpR64W/v5SQZ3ifmFXtolcrwRkbqKFXJMQN5y1+mpZv5yUnTZQY9kKeSooLLQmglvWxjmJk/RES6eoelskCIjsp5Sh6puS/k4vK2X+6jouSbdVVemkHGGI+uxT1BoD3LWNRbo= X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY4PR12MB1143; X-Microsoft-Exchange-Diagnostics: 1;CY4PR12MB1143;31:MVF+/USbEp9XARIGC+b2JzXYmHXqPTuoaTBCX/00iZuPVqhfTLzGWq2/NRLYRkuu9wO5fPGeCkBL+U0LArfhosezNpbhWanl47PD4MMmd3TBIZ6EUT7SmAyfyVJs7TtyM2IkkogJwSYOXGfHo6V0iAE8PZSjCb8b30lU4tpspsoMOnZKtsgBPyAz4B/qzyDGNQmay58UBSbu2M5Vyk9Dh+WQXVPd1gptweJwHwh0yfY=;20:pLLpRtBiLfUj+fEpHC4dOmoLfw/26H6mhIB/ybAcKt83KzCPnW7PXpyK9THf4aOE3t3plTDEpVlPi4fRWR0K67k16C+XZKEX3+uJj5C4+IFmTn/kUiW4A31tHHMnrCpEwVY8a7I6yur7jZzU5lEcbernzFek0fcIZn8llVNiW6FNTSVVfwRWObw9bphzQquc8dK5finAdk+bNdcu4mOeaq4WVvcrB+PWpiN/LMM6+76ev13OwHjQpRKE5U/mrLIh6T93vl/yWouIPET+KgmLyHtuDCpnftXppMkx0YHKOF1qA7Mvd0NeN4p4NSavaipRxpCFhdNw+tWS+tbJzYOQGwKv9zE7phypxBnyuTrLoT27UeHSRfRSMpaoFEvBQgGGbABRQCWUcdhYNuwHPM/UE18BK2q76P/mruuaPgymqMsH96z+xTe4u4PjqfLj3/LNQakaB9Bh5TPGS4ddSwapId7/ejTq7lI8JahvLWmduibGkN38us2aDBu/9cISSl0E X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:(6040176)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026);SRVR:CY4PR12MB1143;BCL:0;PCL:0;RULEID:;SRVR:CY4PR12MB1143; X-Microsoft-Exchange-Diagnostics: 1;CY4PR12MB1143;4:nKkUBTkLIm5bB+lDQi/kraZv6EmcZODt/xBunkhumYOPGzwdqitMnBanJIeRe3qzaL3fbe36qbrAkyrXM8LDvtO8SvcfBiN4IMzc0G3GuymDsq1uDOQf9mTmufSfkA1M/BK1CbljEdXeJWEW07X3Y060B0Rt9ud/SJyLc0ITUFGK9RJRgEcshti8hpbQ3CiR3b5FssqRIecj/o/ZvDwGraNfhVu6LgyJmwodcxK1dwd0y41gZLGg1XjKCIJJiel8E1eMEuAhSNxu8B86NijcCSM9fqiVehiD34bke1MbwEypJKMrO9eUJMKxf3VwnIpJvwnUXyY5SCH+XUqfm83A99YtdnZPm00XJQkXj35LS3ezMd9OY/xG0iFl9v1M8NoUSHQprj6T07GZe6pxAPKtPA== X-Forefront-PRVS: 006546F32A X-Forefront-Antispam-Report: SFV:NSPM;SFS:(10009020)(4630300001)(6009001)(6049001)(7916002)(199003)(24454002)(189002)(377454003)(189998001)(50466002)(3846002)(83506001)(305945005)(101416001)(77096005)(76176999)(64126003)(54356999)(586003)(50986999)(230700001)(5660300001)(68736007)(7416002)(4326007)(65826007)(23676002)(93886004)(81166006)(42186005)(66066001)(65956001)(8676002)(65806001)(81156014)(110136003)(6116002)(2906002)(7736002)(92566002)(7846002)(86362001)(31686004)(33646002)(2950100001)(105586002)(47776003)(97736004)(4001350100001)(36756003)(31696002)(106356001)(217873001);DIR:OUT;SFP:1101;SCL:1;SRVR:CY4PR12MB1143;H:[10.236.18.82];FPR:;SPF:None;PTR:InfoNoRecords;A:1;MX:1;LANG:en; X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtDWTRQUjEyTUIxMTQzOzIzOkcxYmRkMC8yb0gxNzFmZVorZXIySlBFb0JH?= =?utf-8?B?OVFuVDVNZys2RkNDd256ZHB1M0FEbGUzR0FCa2xmZHYvRkdKMUxsMlFnNFdR?= =?utf-8?B?ZDNTcXIzL3dYaGRXMHpya3Ric3RXV3VOUUlDWXpVVTlBa0swSUs2Z3FyU2Rw?= =?utf-8?B?L1BuMVc4SDJzdU1HZnk2RFh5aEhQRHM1WEY5cjNWaHFSbytFV1hmNjRoVGJP?= =?utf-8?B?akZxSUp2VEVKY3NnU3JaYUZiQ3BvZ0hVL2xNeVgrV01ZM1JQT0RoSEduWFhM?= =?utf-8?B?ZVZqWHduMmZKOEU1NjJoelhHclplSStBczJPNHRpMG03cVpSR2MwYktoVjFw?= =?utf-8?B?U2JZcXNRNlZOSm9icTdvRzRYQ2lsbC9RZlJuY0VPWnp4M0FaUEtpSGZEakRP?= =?utf-8?B?bnRVd1ZjY2JmRHRTWjRTYzBKNjE1TEpZeFpjTG1xcVY3ZENKeDJyRWdDUTBt?= =?utf-8?B?SVp0bGVyM3REcjI1M1Q5MWhDWTBtNW1rRXAvWVhhNzcxaUVRQTZNTkRJanpN?= =?utf-8?B?V3VHMWxXTDNvekNyODV2M0ZVZEo1V3ZXWWh2WTFYVkZUdGV6dnBXenJUeTdu?= =?utf-8?B?R3pUbU4xY3dpRU9rMlZsNXo2eTJGQ2ordGt0cVVmcXNndTkrVjBtK1lVbFo1?= =?utf-8?B?ZFJjdXdpZDdTUTUwUmFyTzRhcERDL0k0c2YzQUsxTGFFd0M1NGhVbC9FVUtN?= =?utf-8?B?NytBWWQ5dEl5SkkzQ0V5enoxVzZMRVNKTlFodi9Pb2xpN1gwZU1CS0xWenYr?= =?utf-8?B?V1BHUGVlZi9sVUZkYWZ1dkpsMTdJanJrOGg1RlRYVE1SS1lBVGVnbDNzUllx?= =?utf-8?B?dzJCOVpici82enhPc1lGcFI5dk5WcHdFM1ZHR1lIV2swUmxNWGh6U0JXQzZw?= =?utf-8?B?UmlxS2g3MUhveXZRUkc5T3ZMNkZzK1pJaThBSTJ3a2JxRjZPSkVOb2pwY1Bv?= =?utf-8?B?c3F4ZVZKQkdwelpVV3FwRGJzTnhseDY3MjJ1MEpBcEh3M0ovcnpXNlFjQWl4?= =?utf-8?B?R2trdUNrU1BDbWZMYnQwWG45bTlBZ2RLMmhlbE0wY1E5K0V2dCtWdmJ3bHNJ?= =?utf-8?B?aDVRUDNYdy9CRm5uMjFPR3IyelgwVVpNZVBXTDIvaXlVWEt1QVB3QjNLNCtJ?= =?utf-8?B?bWtWTnkxYVE5ZHNjNzMwWWRGbytESjJ2K2UwYnlDVTFzNTdGaHdSb2pZWExJ?= =?utf-8?B?Q3dxQmdsMUtmalkyRnp4ZmpsVEt2Z2V0cXlnTW9FVll3bFBZbGdpNnRuQ2dh?= =?utf-8?B?bURsdlJUR3d1ZE1xKzgwZm5DYzgwN0xWM0VhV3NHeG1ZQmxVMWcycDFYdDM1?= =?utf-8?B?WDFFR3lPZmxCN1pBQjhSMnF1ektxSjRUSEFTeHdiR3dkYlVBelZaQTRMRnZN?= =?utf-8?B?azBLcUppNktHVmJueTRCRWdXZHFwYzN6ZTl0UWJEWWdGQ2VNUVJUYUxEaTlM?= =?utf-8?B?YmhJNGNvUVRnYlBlWnR4OUd1eFp1b25KcVAza241RFBxZEZSUENVZU9XbmZ5?= =?utf-8?B?RHcwWFVBd1B2Mko3VUZhb3dqVWgyamlsMkl3SmUzU0Mvd1UxNWYzaUNjTFJZ?= =?utf-8?B?bEJoQ2NiZDBZOHZ0UHoydGFBOTJmOWlBdE9sTVZrZTNjUUZWanpQeHFDUXRX?= =?utf-8?B?UnZzWWl1UVl1aVB6Ky91YVFkMTRQRldCTmx3UEpHR3RMajEveWJmRk94VmdX?= =?utf-8?B?Ykk3OHRFWWRLWkVBS1hnc3prUm5pbG1ONTBheDBteWNXVGkzN0JZaFBwKzE5?= =?utf-8?B?eWhxdkUyczRKWjJORFBVdz09?= X-Microsoft-Exchange-Diagnostics: 1;CY4PR12MB1143;6:ktKWXpPW3bBha1NvS1aemc3bQQgecF6L5j8poPPkYv87bgZ8tGn9hPPmdorC0rRYmFm7+ZhxroFLuerNwPMnBpk9y070ITG5Mc7qn6d73uMFoXqVZxtcyvEubilsRToIVP2CNXJNTRp9c5j1uJhinDZE6ECcDWG81LIo3Eu2zPEfV9HlfVblPxx6+c6F459W0CSPEkVRo91wjYkMU1OfX1Ox4E2Wir/67bf/PB37PRgjbdrmzm22EjvKXnDwgxTM83XB+VzkuVD1nTciNZFCyB7GDgwCPyJ16yJdxstLW3i50J18T2rqVx+JNINa4W8Z9dbSGGgLl1RvJkVwhPACuw==;5:pPZR8HxdLlhPNfG+40k6BcImDwac/Kf9HpqkEROpzSu/2FIIcQAj0hjOnNFfzuHBAAm740x0QJPlKhGE3t96bD20st4uTgzyz326icod90Fc+lwSFQt54XjStO9w6gBybi3glJJQTGpUHiBUA3biXA==;24:BXPyQ+C9OsG015ccIVEgK1vkmdEMPNWR+KBeeYFvCm15HIF585xrmppOpAwv40J8HOncrqakWao4uOpbLIR8L7wwAlWJWB8N4JaKw5h3cX8=;7:fo5bZaHmq1tDLTSY7QZ2k+y93iYiNF1Qy/daStHJJzY/jPNQzfuemdKNIZojfaQuxlmA872mJQsDIDuQReH6bAuCNoFqMFUZmvUlZdtgDIDZa/gpOPPm/Iv8aKVcuQsY+uPKmawaKYwJk9A/gRZbgp8t2QZZKEiybk/y3Ed3nkIV0OnIs1I2T06IFZLlCt/ipPGDw0MdGOBfLAsVj2GcC/o5xeM2GMa71Oexzm5DXO5sTJmILvzlmT1/EHNlQwyK SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1;CY4PR12MB1143;20:3GzXeHrTZCawMfJpgg17LdQ46YXlt5JRx260IbXOqK4LYvmkkNOZSTGLCOiP9EawI4wmi2OB8mzhbfQQrAYqPn4R0HM7bjUFEXvbpiNFNtbb0u3nYTGJsESGuCAtrjkLVTK6E2GkZ0WOxVZJ7S+oJbnQo1Vc07B/hd+Ds//9080Nbm7Z9S/H0pUVZouhGN+OKsbEnovSvx2wD6D/yn+z3ew9KEyUFZ/zcc44aABjzHXSd+EaYnFzO4MJ146dIQt8 X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 14 Sep 2016 14:11:24.1005 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR12MB1143 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 09/12/2016 11:33 AM, Borislav Petkov wrote: > On Mon, Sep 12, 2016 at 10:05:36AM -0500, Tom Lendacky wrote: >> I can look into that. The reason I put this here is this is all the >> early page fault support that is very specific to this file. I modified >> an existing static function to take advantage of the mapping support. > > Yeah, but all this code is SME-specific and doesn't belong there. > AFAICT, it uses global/public symbols so there shouldn't be a problem to > have it in mem_encrypt.c. Ok, I'll look into moving this into mem_encrypt.c. I'd like to avoid duplicating code so I may have to make that static function external unless I find a better way. Thanks, Tom > >> Hmmm, maybe... With the change to the early_memremap() the initrd is now >> identified as BOOT_DATA in relocate_initrd() and so it will be mapped >> and copied as non-encyrpted data. But since it was encrypted before the >> call to relocate_initrd() it will copy encrypted bytes which will later >> be accessed encrypted. That isn't clear though, so I'll rework >> reserve_initrd() to perform the sme_early_mem_enc() once at the end >> whether the initrd is re-located or not. > > Makes sense. > From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tom Lendacky Subject: Re: [RFC PATCH v2 10/20] x86: Insure that memory areas are encrypted when possible Date: Wed, 14 Sep 2016 09:11:13 -0500 Message-ID: <74d7fcd4-18e6-a81c-2510-bf0fe8a08a53@amd.com> References: <20160822223529.29880.50884.stgit@tlendack-t1.amdoffice.net> <20160822223722.29880.94331.stgit@tlendack-t1.amdoffice.net> <20160909155305.bmm2fvw7ndjjhqvo@pd.tnic> <23855fb4-05b0-4c12-d34f-4d5f45f3b015@amd.com> <20160912163349.exnuvr7svsq7fmui@pd.tnic> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20160912163349.exnuvr7svsq7fmui-fF5Pk5pvG8Y@public.gmane.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: iommu-bounces-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org Errors-To: iommu-bounces-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org To: Borislav Petkov Cc: linux-efi-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, kvm-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, =?UTF-8?B?UmFkaW0gS3LEjW3DocWZ?= , Matt Fleming , x86-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org, linux-mm-Bw31MaZKKs3YtjvyW6yDsg@public.gmane.org, Alexander Potapenko , "H. Peter Anvin" , linux-arch-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Jonathan Corbet , linux-doc-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, kasan-dev-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org, Ingo Molnar , Andrey Ryabinin , Arnd Bergmann , Andy Lutomirski , Thomas Gleixner , Dmitry Vyukov , linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org, Paolo Bonzini List-Id: linux-efi@vger.kernel.org On 09/12/2016 11:33 AM, Borislav Petkov wrote: > On Mon, Sep 12, 2016 at 10:05:36AM -0500, Tom Lendacky wrote: >> I can look into that. The reason I put this here is this is all the >> early page fault support that is very specific to this file. I modified >> an existing static function to take advantage of the mapping support. > > Yeah, but all this code is SME-specific and doesn't belong there. > AFAICT, it uses global/public symbols so there shouldn't be a problem to > have it in mem_encrypt.c. Ok, I'll look into moving this into mem_encrypt.c. I'd like to avoid duplicating code so I may have to make that static function external unless I find a better way. Thanks, Tom > >> Hmmm, maybe... With the change to the early_memremap() the initrd is now >> identified as BOOT_DATA in relocate_initrd() and so it will be mapped >> and copied as non-encyrpted data. But since it was encrypted before the >> call to relocate_initrd() it will copy encrypted bytes which will later >> be accessed encrypted. That isn't clear though, so I'll rework >> reserve_initrd() to perform the sme_early_mem_enc() once at the end >> whether the initrd is re-located or not. > > Makes sense. > From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qt0-f199.google.com (mail-qt0-f199.google.com [209.85.216.199]) by kanga.kvack.org (Postfix) with ESMTP id F23346B0038 for ; Wed, 14 Sep 2016 10:11:29 -0400 (EDT) Received: by mail-qt0-f199.google.com with SMTP id 16so31740708qtn.1 for ; Wed, 14 Sep 2016 07:11:29 -0700 (PDT) Received: from NAM01-BN3-obe.outbound.protection.outlook.com (mail-bn3nam01on0087.outbound.protection.outlook.com. [104.47.33.87]) by mx.google.com with ESMTPS id d4si3107165qkc.169.2016.09.14.07.11.29 for (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 14 Sep 2016 07:11:29 -0700 (PDT) Subject: Re: [RFC PATCH v2 10/20] x86: Insure that memory areas are encrypted when possible References: <20160822223529.29880.50884.stgit@tlendack-t1.amdoffice.net> <20160822223722.29880.94331.stgit@tlendack-t1.amdoffice.net> <20160909155305.bmm2fvw7ndjjhqvo@pd.tnic> <23855fb4-05b0-4c12-d34f-4d5f45f3b015@amd.com> <20160912163349.exnuvr7svsq7fmui@pd.tnic> From: Tom Lendacky Message-ID: <74d7fcd4-18e6-a81c-2510-bf0fe8a08a53@amd.com> Date: Wed, 14 Sep 2016 09:11:13 -0500 MIME-Version: 1.0 In-Reply-To: <20160912163349.exnuvr7svsq7fmui@pd.tnic> Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Sender: owner-linux-mm@kvack.org List-ID: To: Borislav Petkov Cc: linux-arch@vger.kernel.org, linux-efi@vger.kernel.org, kvm@vger.kernel.org, linux-doc@vger.kernel.org, x86@kernel.org, linux-kernel@vger.kernel.org, kasan-dev@googlegroups.com, linux-mm@kvack.org, iommu@lists.linux-foundation.org, =?UTF-8?B?UmFkaW0gS3LEjW3DocWZ?= , Arnd Bergmann , Jonathan Corbet , Matt Fleming , Joerg Roedel , Konrad Rzeszutek Wilk , Andrey Ryabinin , Ingo Molnar , Andy Lutomirski , "H. Peter Anvin" , Paolo Bonzini , Alexander Potapenko , Thomas Gleixner , Dmitry Vyukov On 09/12/2016 11:33 AM, Borislav Petkov wrote: > On Mon, Sep 12, 2016 at 10:05:36AM -0500, Tom Lendacky wrote: >> I can look into that. The reason I put this here is this is all the >> early page fault support that is very specific to this file. I modified >> an existing static function to take advantage of the mapping support. > > Yeah, but all this code is SME-specific and doesn't belong there. > AFAICT, it uses global/public symbols so there shouldn't be a problem to > have it in mem_encrypt.c. Ok, I'll look into moving this into mem_encrypt.c. I'd like to avoid duplicating code so I may have to make that static function external unless I find a better way. Thanks, Tom > >> Hmmm, maybe... With the change to the early_memremap() the initrd is now >> identified as BOOT_DATA in relocate_initrd() and so it will be mapped >> and copied as non-encyrpted data. But since it was encrypted before the >> call to relocate_initrd() it will copy encrypted bytes which will later >> be accessed encrypted. That isn't clear though, so I'll rework >> reserve_initrd() to perform the sme_early_mem_enc() once at the end >> whether the initrd is re-located or not. > > Makes sense. > -- 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