Re: [PATCH 0/8] eMMC inline encryption support

Adrian Hunter
2020-11-23T07:05:00Z

On 20/11/20 9:44 pm, Eric Biggers wrote:
> Hi Adrian,
>
> On Fri, Nov 20, 2020 at 09:29:59PM +0200, Adrian Hunter wrote:
>> I haven't had a chance to look at it properly, but I do have a couple of
>> dumb questions. How do you ensure the host controller is not runtime
>> suspended when the key is programmed?
>
> This is handled by the block layer, in block/keyslot-manager.c. It ensures that
> the device is resumed before calling blk_ksm_ll_ops::keyslot_program() or
> blk_ksm_ll_ops::keyslot_evict(). See blk_ksm_hw_enter().

Cool, although cqhci is doing a lazy kind of resume, so maybe not be enabled
when a key is programmed? Would that be a problem?

>
>> Are the keys lost when the host controller is reset, and then how do you know
>> the host controller does not get reset after the key is programmed but before
>> the I/O is submitted?
>
> As with UFS, keys might be lost when the host controller is reset, so we're
> reprogramming all the keys when that happens. See patch 1:
>
> mmc_set_initial_state()
> mmc_crypto_set_initial_state()
> blk_ksm_reprogram_all_keys()
>
> (That's the intent, at least. For MMC, I'm not sure if resets were properly
> covered by the testing I've done so far. But the code looks right to me.)

After reset, cqhci will not necessarily be enabled at this point. Is that OK?