[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAK1hOcOLaxe_=WJ0G90di4_0vR+J3tRfPJZJBO4jdjtAgoKYkQ@mail.gmail.com>
Date: Thu, 22 Oct 2015 18:02:05 +0200
From: Denys Vlasenko <vda.linux@...glemail.com>
To: musl <musl@...ts.openwall.com>, Zack Weinberg <zackw@...ix.com>, Paul_Koning@...l.com,
dje.gcc@...il.com, gcc@....gnu.org, libc-alpha@...rceware.org
Subject: Re: Re: Compiler support for erasure of sensitive data
On Wed, Sep 9, 2015 at 10:26 PM, Szabolcs Nagy <nsz@...t70.net> wrote:
> * Zack Weinberg <zackw@...ix.com> [2015-09-09 15:03:50 -0400]:
>> On 09/09/2015 02:02 PM, Paul_Koning@...l.com wrote:
>> >> On Sep 9, 2015, at 1:54 PM, David Edelsohn <dje.gcc@...il.com>
>> >> wrote:
>> >>
>> >> What level of erasure of sensitive data are you trying to ensure?
>> >> Assuming that overwriting values in the ISA registers actually
>> >> completely clears and destroys the values is delusionally naive.
>> >
>> > Could you point to some references about that?
>>
>> I *assume* David is referring to register renaming, which is not
>> architecturally visible...
>>
>
> or async signal handler copying all the register state on sigaltstack
> or internal counters and debug features making sensitive info observable
> or timing/cache-effect side channels that let other processes get info
> or compiling to a highlevel language (js) with different kind of leaks
> or running under emulator/debugger that can make secrets visible
> or...
I think if attacker got that much control of the machine that he can
get, for example, signals to reach your sensitive process, you already lost.
Ditto for running under emulator.
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
