Re: [PATCH] Enable reset attack mitigation

On Fri, Aug 18, 2017 at 12:08:34PM -0700, Matthew Garrett wrote: > On Fri, Aug 18, 2017 at 11:52 AM, Ard Biesheuvel > wrote: > > So how would that work with, e.g., the keys for your encrypted file > > system? Surely, you can't expect the kernel to drop that secret when

Re: [PATCH] Enable reset attack mitigation

On Fri, Aug 18, 2017 at 12:08:34PM -0700, Matthew Garrett wrote: > On Fri, Aug 18, 2017 at 11:52 AM, Ard Biesheuvel > wrote: > > So how would that work with, e.g., the keys for your encrypted file > > system? Surely, you can't expect the kernel to drop that secret when > > userland asks it to,

Re: [PATCH] Enable reset attack mitigation

On Fri, Aug 18, 2017 at 1:19 PM, Ard Biesheuvel wrote: > OK. I will get it queued. No need to resend, I can apply the fixes locally. Thanks!

Re: [PATCH] Enable reset attack mitigation

On Fri, Aug 18, 2017 at 1:19 PM, Ard Biesheuvel wrote: > OK. I will get it queued. No need to resend, I can apply the fixes locally. Thanks!

Re: [PATCH] Enable reset attack mitigation

On 18 August 2017 at 20:57, Matthew Garrett wrote: > On Fri, Aug 18, 2017 at 12:29 PM, Ard Biesheuvel > wrote: >> On 18 August 2017 at 20:08, Matthew Garrett wrote: >>> If the kernel doesn't synchronously zero the key when dm-crypt

Re: [PATCH] Enable reset attack mitigation

On 18 August 2017 at 20:57, Matthew Garrett wrote: > On Fri, Aug 18, 2017 at 12:29 PM, Ard Biesheuvel > wrote: >> On 18 August 2017 at 20:08, Matthew Garrett wrote: >>> If the kernel doesn't synchronously zero the key when dm-crypt is torn >>> down, that feels like a bug? >> >> Of course it

Re: [PATCH] Enable reset attack mitigation

On Fri, Aug 18, 2017 at 12:29 PM, Ard Biesheuvel wrote: > On 18 August 2017 at 20:08, Matthew Garrett 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

Re: [PATCH] Enable reset attack mitigation

On Fri, Aug 18, 2017 at 12:29 PM, Ard Biesheuvel wrote: > On 18 August 2017 at 20:08, Matthew Garrett 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

Re: [PATCH] Enable reset attack mitigation

On 18 August 2017 at 20:08, Matthew Garrett wrote: > On Fri, Aug 18, 2017 at 11:52 AM, Ard Biesheuvel > wrote: >> On 4 August 2017 at 22:20, Matthew Garrett wrote: >>> + * Enable reboot attack mitigation. This requests that the

Re: [PATCH] Enable reset attack mitigation

On 18 August 2017 at 20:08, Matthew Garrett wrote: > On Fri, Aug 18, 2017 at 11:52 AM, Ard Biesheuvel > wrote: >> On 4 August 2017 at 22:20, Matthew Garrett wrote: >>> + * Enable reboot attack mitigation. This requests that the firmware clear >>> the >>> + * RAM on next reboot before

Re: [PATCH] Enable reset attack mitigation

On Fri, Aug 18, 2017 at 11:52 AM, Ard Biesheuvel wrote: > On 4 August 2017 at 22:20, Matthew Garrett wrote: >> + * Enable reboot attack mitigation. This requests that the firmware clear >> the >> + * RAM on next reboot before proceeding with boot,

Re: [PATCH] Enable reset attack mitigation

On Fri, Aug 18, 2017 at 11:52 AM, Ard Biesheuvel wrote: > On 4 August 2017 at 22:20, Matthew Garrett wrote: >> + * Enable reboot attack mitigation. This requests that the firmware clear >> the >> + * RAM on next reboot before proceeding with boot, ensuring that any secrets >> + * are cleared.

Re: [PATCH] Enable reset attack mitigation

On 4 August 2017 at 22:20, Matthew Garrett wrote: > If a machine is reset while secrets are present in RAM, it may be > possible for code executed after the reboot to extract those secrets > from untouched memory. The Trusted Computing Group specified a mechanism > for

Re: [PATCH] Enable reset attack mitigation

On 4 August 2017 at 22:20, Matthew Garrett wrote: > If a machine is reset while secrets are present in RAM, it may be > possible for code executed after the reboot to extract those secrets > from untouched memory. The Trusted Computing Group specified a mechanism > for requesting that the

Re: [PATCH] Enable reset attack mitigation

On Sat, Aug 5, 2017 at 10:34 AM, Lukas Wunner wrote: > Just an innocent question from a bystander, what's the downside of > unconditionally requesting that memory be overwritten? Does it > prolong reboot noticeably? Yes, it's just to avoid stalling reboot for as long as it

Re: [PATCH] Enable reset attack mitigation

On Sat, Aug 5, 2017 at 10:34 AM, Lukas Wunner wrote: > Just an innocent question from a bystander, what's the downside of > unconditionally requesting that memory be overwritten? Does it > prolong reboot noticeably? Yes, it's just to avoid stalling reboot for as long as it takes to clear RAM.

Re: [PATCH] Enable reset attack mitigation

On Sat, Aug 05, 2017 at 09:35:22AM -0700, Matthew Garrett wrote: > On Sat, Aug 5, 2017 at 2:50 AM, Ard Biesheuvel > wrote: > > On 4 August 2017 at 22:20, Matthew Garrett wrote: > > > If a machine is reset while secrets are present in RAM, it may be >

Re: [PATCH] Enable reset attack mitigation

On Sat, Aug 05, 2017 at 09:35:22AM -0700, Matthew Garrett wrote: > On Sat, Aug 5, 2017 at 2:50 AM, Ard Biesheuvel > wrote: > > On 4 August 2017 at 22:20, Matthew Garrett wrote: > > > If a machine is reset while secrets are present in RAM, it may be > > > possible for code executed after the

Re: [PATCH] Enable reset attack mitigation

On Sat, Aug 5, 2017 at 2:50 AM, Ard Biesheuvel wrote: > On 4 August 2017 at 22:20, Matthew Garrett wrote: >> If a machine is reset while secrets are present in RAM, it may be >> possible for code executed after the reboot to extract those secrets >>

Re: [PATCH] Enable reset attack mitigation

On Sat, Aug 5, 2017 at 2:50 AM, Ard Biesheuvel wrote: > On 4 August 2017 at 22:20, Matthew Garrett wrote: >> If a machine is reset while secrets are present in RAM, it may be >> possible for code executed after the reboot to extract those secrets >> from untouched memory. The Trusted Computing

Re: [PATCH] Enable reset attack mitigation

On 4 August 2017 at 22:20, Matthew Garrett wrote: > If a machine is reset while secrets are present in RAM, it may be > possible for code executed after the reboot to extract those secrets > from untouched memory. The Trusted Computing Group specified a mechanism > for

Re: [PATCH] Enable reset attack mitigation

On 4 August 2017 at 22:20, Matthew Garrett wrote: > If a machine is reset while secrets are present in RAM, it may be > possible for code executed after the reboot to extract those secrets > from untouched memory. The Trusted Computing Group specified a mechanism > for requesting that the

[PATCH] Enable reset attack mitigation

If a machine is reset while secrets are present in RAM, it may be possible for code executed after the reboot to extract those secrets from untouched memory. The Trusted Computing Group specified a mechanism for requesting that the firmware clear all RAM on reset before booting another OS. This is

[PATCH] Enable reset attack mitigation

If a machine is reset while secrets are present in RAM, it may be possible for code executed after the reboot to extract those secrets from untouched memory. The Trusted Computing Group specified a mechanism for requesting that the firmware clear all RAM on reset before booting another OS. This is