Received-SPF: pass (google.com: domain of linux-crypto-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Message-ID: <763bddd2-2fc3-a857-0dff-a5ae4ae1f298@intel.com>
Date:   Wed, 24 Aug 2022 15:20:59 -0700
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
 Thunderbird/91.13.0
Subject: Re: [PATCH v5 07/12] x86/cpu/keylocker: Load an internal wrapping key
 at boot-time
Content-Language: en-CA
To:     Evan Green <evgreen@chromium.org>
CC:     <linux-crypto@vger.kernel.org>, <dm-devel@redhat.com>,
        <herbert@gondor.apana.org.au>, Eric Biggers <ebiggers@kernel.org>,
        "Ard Biesheuvel" <ardb@kernel.org>, <x86@kernel.org>,
        <luto@kernel.org>, "Thomas Gleixner" <tglx@linutronix.de>,
        <bp@suse.de>, <dave.hansen@linux.intel.com>, <mingo@kernel.org>,
        LKML <linux-kernel@vger.kernel.org>,
        Dan Williams <dan.j.williams@intel.com>,
        <charishma1.gairuboyina@intel.com>,
        <kumar.n.dwarakanath@intel.com>, <ravi.v.shankar@intel.com>
References: <20220112211258.21115-1-chang.seok.bae@intel.com>
 <20220112211258.21115-8-chang.seok.bae@intel.com>
 <CAE=gft4P2iGJDiYJccZFR1VnNomQB7Uo522r2gvrfNY9oKz5jg@mail.gmail.com>
From:   "Chang S. Bae" <chang.seok.bae@intel.com>
In-Reply-To: <CAE=gft4P2iGJDiYJccZFR1VnNomQB7Uo522r2gvrfNY9oKz5jg@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: 7bit
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?Q3RqUVRMSEVEeVdlNi9BRnBPa1U0bFd5YTN5MlY4T2JXaU1jMWZKQ01LN2c5?=
 =?utf-8?B?Sm1QdXBEN2x5bDBlRUJZSnE5NXl0LzIxd0c2VitMcWlaSWNaRUhCUDMrS3Bk?=
 =?utf-8?B?ZlQzWi80VXl5bjRrRDVnWmsxMG95dlVwUjNUdTk2Rm93MGFGdjg1MmdrQ3ZL?=
 =?utf-8?B?WnNuWjY5ZDZKMGZmNUppaUVNSnYyN2QwU0ZQNXp1a2NvTDdxZXpVQmk5a3cx?=
 =?utf-8?B?M01NSlNDSGJOc25jY0dLVmRUZlpBbVRPcy9KQVpZNjI1TTVHbTVxSFYzL1hi?=
 =?utf-8?B?L1hDTXNza2pLaVIyTFlDS0hBR3ZFZDdNNlJ3VHVhSlFzZGxDU1FvNHBwRjRK?=
 =?utf-8?B?TEMwcXE2bzQ2cEU3L2RkWVN5SXRUSk1NdjZGVFh0QWtwQUpERkNFZ3JoV1Fw?=
 =?utf-8?B?V3dHSCtDM25IeFFnRTFXQlYzM2YveGVheXcxaTB1MkpaazV4VlVwRUJkeTg4?=
 =?utf-8?B?cm1XZVp2cXVmMTFFaTg4WXM5SDRzMU5VMlFMcVB2cG52MTMyLzM4d1A3c3JQ?=
 =?utf-8?B?OXJsaWVnUDlhYzJGNzYvUVI0b1VRRk5IbEw5TkxHMzRCR2ltajNmNjRlakRx?=
 =?utf-8?B?NDVoNmR2cDE0eGhERjc0THA4MUJaalhvVGNULzlsbTRESFFjMVpDWHhGR2hU?=
 =?utf-8?B?L3JubXVxaExjTDNiSEQzb0FGamZ0Z2ZTaVUxNzNwcjdvai9CYmwwSHFkb09H?=
 =?utf-8?B?aEdQVmNoKzZ5dEZ3VGVRMHdMOGV2ZDdwa2xOZFFMVy8wVXIvQkg4cEJ2RVVr?=
 =?utf-8?B?Wk1jZzZwcjgvL3pTUlZkUzh6bkd5bS9na3VKeTdLTFBIVnVsZ1htck5VVDVx?=
 =?utf-8?B?ejJzVEltcUVzNVEzeEZlMHE1MmV2TXFOdzhENGtsTTBObGpTYStUUi96Y0oy?=
 =?utf-8?B?TzVIeHo2MzBKVVJ4cVNKUWo3SVIrWG4xdmkxUFd2NHloTFJSRUE0b01mRkVY?=
 =?utf-8?B?bVRzYTc3ODlkZHEvTStncGNYRGFZYUU1TGlVblhzYmQvUTZSdjRwMGNmNUZq?=
 =?utf-8?B?S3I5MVM0elkxK0RxTG1MMWU5SVQ5VjBEMVhzK01kbTVlckhLWE1NeWpLa3Bk?=
 =?utf-8?B?VUlJSmhwTTErdmZkRGVWWStneEJmRTFqMm53SlN3dEJ1S2hlRlBObHlia1ZZ?=
 =?utf-8?B?Nkt0NmtHb282L2wvaEVBa0lGOTRESWdjTGFWQ05xN2E2WU1MWFg2WlM4c2Rx?=
 =?utf-8?B?T0VRNkhnaXlGOTEwWllrTi80cEdONURka3NJOHR3aDhCTU8xRkh3Tlh6aURy?=
 =?utf-8?B?NE5DRTdPSjZzQm9OdENCQmY3b3ZPeTZEcW4yY01MYmxxRG9jUWtvTGM5Yk9O?=
 =?utf-8?B?T3hSWGJHVXF6M3Z4Yk9qUjc1Z1dkUE00d0sycjZ0Y0puZ2d2d1M1Y0pGTjZl?=
 =?utf-8?B?VGFvdXRodTBGc29XTWF0aWo1aVY2V2h2bm5ZekFVeUNTeElMTDYxL3RXc0RF?=
 =?utf-8?B?WUZzOXp0eHVLM3dxZVhCVCtHQTlGVWNYSEUvbkNJWmIvVzZYZEZ1MitxNmdQ?=
 =?utf-8?B?T2o2V01XSjZtTXp0OVZvcFhqSkdsbWFnSEx0UGxzeWZtS1QwelpCVFNZK254?=
 =?utf-8?B?cS9YR1dzVmtBNWlCZ0ZlcFQ5SWwwK3lOOU94N2U1U2tPY3kxT1g3RTk0RHdT?=
 =?utf-8?B?Z1lrZFVLZkpWUmdVVVZVTVFJK0tZTnp4bjY1MjFXdG8vZ3ZBWjFHa0Q1ZC9G?=
 =?utf-8?B?UVFnNzJqdHNKckNLUFpVd3RYdlBBTmFTRC94SmhIL1d3Z2hDdnBzbnc3S0lt?=
 =?utf-8?B?Q21HR25WdHlXZTVmak9iQUpPQjkvTmVNeklERXloa2oxdEhvS2RKb2d5eGZX?=
 =?utf-8?B?TXNkbGNXa3FiUUhBYit1MWRwdVdRQXU3SHRjbWd0V3pZZHVUNWN4cFFXRmF5?=
 =?utf-8?B?alU1dUJ4bXlrSXVPQzl3ck9XamJMOWl4R3R4dDJVdkR4YlU3RkpRcnU4cXhM?=
 =?utf-8?B?MEN6OHlMNW4ySHJ3a0swUWRZVUd6WWlxOTh0azQvM1JBMWxWWVBZQTlMWlRR?=
 =?utf-8?B?WDVFMmdhY1UxYWVpUjNTYzVoVVZJS2hKcHlzVE9FclhHbFB0dnEzemoyYTd5?=
 =?utf-8?B?N0tsSkpVU3VjWmF5ZHFHVmF0K09uZXI1WGNaSDRXY2pQWUM2TGRzT1lOc29U?=
 =?utf-8?B?dU5QcFNpaTV6VC8xM1dtVHVia2RVNmIwd2xCeXMvL3JQcFkrUXhhN0lkUVFW?=
 =?utf-8?B?M0E9PQ==?=
X-MS-Exchange-CrossTenant-Network-Message-Id: c3cb0346-b3a8-445e-8472-08da861eed45
X-MS-Exchange-CrossTenant-AuthSource: PH0PR11MB4855.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 24 Aug 2022 22:21:01.6118
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 46c98d88-e344-4ed4-8496-4ed7712e255d
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: vcCcTEI7cMUws4TlHhO74zZOltu5KUbRvZeQqHmorTsD7cjaP3g7DT7kkXLgO1Q7INPEBEUH3bT5QG2095GV3NnWC/4TF3VJP+XkbobV0nM=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR11MB2025
X-OriginatorOrg: intel.com
X-Spam-Status: No, score=-4.4 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,
        DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,NICE_REPLY_A,
        RCVD_IN_DNSWL_MED,SPF_HELO_NONE,SPF_NONE,T_SCC_BODY_TEXT_LINE,
        URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on
        lindbergh.monkeyblade.net
Precedence: bulk
List-ID: <linux-crypto.vger.kernel.org>
X-Mailing-List: linux-crypto@vger.kernel.org

On 8/23/2022 8:49 AM, Evan Green wrote:
> On Wed, Jan 12, 2022 at 1:21 PM Chang S. Bae <chang.seok.bae@intel.com> wrote:
>>
<snip>
>> +
>> +static void __init load_keylocker(void)
> 
> I am late to this party by 6 months, but:
> load_keylocker() cannot be __init, as it gets called during SMP core onlining.

Yeah, it looks like the case with this patch only.

But the next patch [1] limits the call during boot time only:

	if (c == &boot_cpu_data) {
		...
		load_keylocker();
		...
	} else {
		...
		if (!kl_setup.initialized) {
			load_keylocker();
		} else if (valid_kl) {
			rc = copy_keylocker();
			...
		}
	}

kl_setup.initialized is set by native_smp_cpus_done() -> 
destroy_keylocker_data() when CPUs are booted. Then load_keylocker() is 
not called because the root key (aka IWKey) is no longer available in 
memory.

Now this 'valid_kl' flag should be always on unless the root key backup 
is corrupted. Then copy_keylocker() loads the root key from the backup 
in the platform state.

So I think the onlining CPU won't call it.

Maybe this bit can be much clarified in a separate (new) patch, instead 
of being part of another like [1].

Thanks,
Chang

[1]: 
https://lore.kernel.org/lkml/20220112211258.21115-9-chang.seok.bae@intel.com/