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, so
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!
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 shou
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 i
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 proceeding
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. If
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 firmware
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.
>
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 rebo
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 Gr
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 firmware
11 matches
Mail list logo
