On Wed, Mar 9, 2016 at 2:09 PM, Segher Boessenkool
wrote:
> [ Please don't top-post. ]
>
> On Wed, Mar 09, 2016 at 11:23:22AM -0300, Andres Tiraboschi wrote:
>> We are developing this feature for x86_64
>> I want to see which registers are being used by the current function
>> for returning a valu
[ Please don't top-post. ]
On Wed, Mar 09, 2016 at 11:23:22AM -0300, Andres Tiraboschi wrote:
> We are developing this feature for x86_64
> I want to see which registers are being used by the current function
> for returning a value or as arguments.
> I traverse the rtl looking for clobbered regis
We are developing this feature for x86_64
I want to see which registers are being used by the current function
for returning a value or as arguments.
I traverse the rtl looking for clobbered registers, but I don't know
how to find which registers are arguments from the current function
and which ar
On Tue, Mar 01, 2016 at 10:27:00AM +0100, Richard Biener wrote:
> > We were thinking on making a function attribute that ensures that non
> > necessary registers, or stack frames used by the function will be correctly
> > cleared before returning.
> > We think in implementing for x86_64 as a firs
On Mon, Feb 29, 2016 at 10:14 PM, Marcos Diaz
wrote:
> Hi, we are facing the same issue. This bugzilla was opened:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69976
>
> We were thinking on making a function attribute that ensures that non
> necessary registers, or stack frames used by the func
Hi, we are facing the same issue. This bugzilla was opened:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69976
We were thinking on making a function attribute that ensures that non necessary
registers, or stack frames used by the function will be correctly cleared
before returning.
We think in i
On Wed, Sep 9, 2015 at 6:36 PM, Zack Weinberg wrote:
> The first, simpler problem is strictly optimization. explicit_bzero
> can be optimized to memset followed by a vacuous use of the memory
> region (generating no machine instructions, but preventing the stores
> from being deleted as dead); th
On Wed, Sep 9, 2015 at 10:26 PM, Szabolcs Nagy wrote:
> * Zack Weinberg [2015-09-09 15:03:50 -0400]:
>> On 09/09/2015 02:02 PM, paul_kon...@dell.com wrote:
>> >> On Sep 9, 2015, at 1:54 PM, David Edelsohn
>> >> wrote:
>> >>
>> >> What level of erasure of sensitive data are you trying to ensure?
* Zack Weinberg [2015-09-09 15:03:50 -0400]:
> On 09/09/2015 02:02 PM, paul_kon...@dell.com wrote:
> >> On Sep 9, 2015, at 1:54 PM, David Edelsohn
> >> wrote:
> >>
> >> What level of erasure of sensitive data are you trying to ensure?
> >> Assuming that overwriting values in the ISA registers a
On Wed, Sep 09, 2015 at 02:48:22PM -0400, Zack Weinberg wrote:
> On 09/09/2015 01:13 PM, Rich Felker wrote:
> > On Wed, Sep 09, 2015 at 12:47:10PM -0400, Zack Weinberg wrote:
> >> On Wed, Sep 9, 2015 at 12:42 PM, Rich Felker wrote:
> >>> You're making this harder than it needs to be. The "m" const
On 09/09/2015 02:02 PM, paul_kon...@dell.com wrote:
>> On Sep 9, 2015, at 1:54 PM, David Edelsohn
>> 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 d
On 09/09/2015 01:13 PM, Rich Felker wrote:
> On Wed, Sep 09, 2015 at 12:47:10PM -0400, Zack Weinberg wrote:
>> On Wed, Sep 9, 2015 at 12:42 PM, Rich Felker wrote:
>>> You're making this harder than it needs to be. The "m" constraint is
>>> the wrong thing to use here. Simply use:
>>>
>>> _
On Wed, Sep 9, 2015 at 2:02 PM, wrote:
>
>> On Sep 9, 2015, at 1:54 PM, David Edelsohn wrote:
>>
>> On Wed, Sep 9, 2015 at 12:36 PM, Zack Weinberg wrote:
>>
>>> The ABI dictates basically everything you see. The call to
>>> explicit_bzero has forced the compiler to *create* a second copy of
>>
> On Sep 9, 2015, at 1:54 PM, David Edelsohn wrote:
>
> On Wed, Sep 9, 2015 at 12:36 PM, Zack Weinberg wrote:
>
>> The ABI dictates basically everything you see. The call to
>> explicit_bzero has forced the compiler to *create* a second copy of
>> the variable `k` on the stack, just so it can
On Wed, Sep 9, 2015 at 12:36 PM, Zack Weinberg wrote:
> The ABI dictates basically everything you see. The call to
> explicit_bzero has forced the compiler to *create* a second copy of
> the variable `k` on the stack, just so it can be erased -- and the
> copy in registers survives (at least for
On Wed, Sep 09, 2015 at 12:58:36PM -0400, Zack Weinberg wrote:
> On 09/09/2015 12:52 PM, paul_kon...@dell.com wrote:
> > Then again, suppose all you had is explicit_bzero, and an annotation
> > on the data saying it's sensitive. Can static code analyzers take
> > care of the rest? If so, this sor
On Wed, Sep 09, 2015 at 12:47:10PM -0400, Zack Weinberg wrote:
> On Wed, Sep 9, 2015 at 12:42 PM, Rich Felker wrote:
> > You're making this harder than it needs to be. The "m" constraint is
> > the wrong thing to use here. Simply use:
> >
> > __asm__(""::"r"(ptr):"memory");
>
> Please rev
On 09/09/2015 12:52 PM, paul_kon...@dell.com wrote:
> Then again, suppose all you had is explicit_bzero, and an annotation
> on the data saying it's sensitive. Can static code analyzers take
> care of the rest? If so, this sort of thing doesn't need to be in
> the compiler.
The thing that absolu
> On Sep 9, 2015, at 12:36 PM, Zack Weinberg wrote:
>
> ...
> I think the ideal feature addition to address this would be
>
>void safe(void)
>{
>struct key __attribute__((sensitive)) k = get_key();
>use_key(k);
>}
That certainly is a cleaner answer. What is attract
On Wed, Sep 9, 2015 at 12:42 PM, Rich Felker wrote:
> You're making this harder than it needs to be. The "m" constraint is
> the wrong thing to use here. Simply use:
>
> __asm__(""::"r"(ptr):"memory");
Please review my earlier conversation with Adhemerval on exactly this point.
zw
On Wed, Sep 09, 2015 at 12:36:01PM -0400, Zack Weinberg wrote:
> The first, simpler problem is strictly optimization. explicit_bzero
> can be optimized to memset followed by a vacuous use of the memory
> region (generating no machine instructions, but preventing the stores
> from being deleted as
OK, I have now failed to find the LLVM development list twice in a
row. Could some kind soul please forward the message to whereever the
heck the proper address is?
zw
[Sorry for the double-post, but I got the LLVM mailing list address wrong,
and I want to make sure that everyone sees the entire conversation.]
Over the past couple months I have been working on adding a function to
glibc for erasure of sensitive data after it's used. This function
already exists
Over the past couple months I have been working on adding a function to
glibc for erasure of sensitive data after it's used. This function
already exists in various other libraries under various names --
explicit_bzero, explicit_memset, SecureZeroMemory, memset_s,
OPENSSL_cleanse, etc -- and the pr
24 matches
Mail list logo
