Re: [PATCH] Enable reset attack mitigation

[Ard Biesheuvel]

On 18 August 2017 at 20:57, Matthew Garrett <mjg59@xxxxxxxxxx> wrote:
> On Fri, Aug 18, 2017 at 12:29 PM, Ard Biesheuvel
> <ard.biesheuvel@xxxxxxxxxx> wrote:
>> On 18 August 2017 at 20:08, Matthew Garrett <mjg59@xxxxxxxxxx> wrote:
>>> If the kernel doesn't synchronously zero the key when dm-crypt is torn
>>> down, that feels like a bug?
>>
>> Of course it should. But that is not the point. The point is that
>> userland is in no position to decide whether or not memory has been
>> sufficiently cleaned so that the firmware can omit wiping all of it
>> (in case you care enough about your secrets to enable that feature in
>> the first place).
>
> The kernel is in no position to decide whether or not userland has
> disposed of secrets either - at some point you need to trust a
> component, and I have more faith that the kernel will do the right
> thing. The only other option here seems to be a double opt-in (ie,
> have userland assert that it's cleaned up, have the kernel set the
> flag at reset time) but we're still assuming that the kernel is
> behaving correctly, and if we assume that the kernel is behaving
> correctly then we can just let userland set the flag anyway.
>

OK, fair enough.

>> Given that the string 'MemoryOverWriteRequest' does not appear in
>> today's EDK2, I don't suppose there is any urgency wrt getting this
>> queued for v4.14?
>
> It's not implemented in EDK2, but it's in pretty much every vendor
> implementation. All the machines I have here support this already.

OK. I will get it queued. No need to resend, I can apply the fixes locally.