http://www.daemonology.net/blog/2014-09-06-zeroing-buffers-is-insufficient.html

D could incorporate something like this, no?

Am 07.09.2014 19:00, schrieb John Colvin:
> http://www.daemonology.net/blog/2014-09-06-zeroing-buffers-is-insufficient.html
>
>
> D could incorporate something like this, no?

There are some posts on the HN discussion, stating that the problem is not so easy to solve.

Even without the C compiler related issues, there is a whole OS and hardware stack where the data can be attacked at multiple levels.

--
Paulo

On Sunday, 7 September 2014 at 17:24:46 UTC, Paulo Pinto wrote:
> Am 07.09.2014 19:00, schrieb John Colvin:
>> http://www.daemonology.net/blog/2014-09-06-zeroing-buffers-is-insufficient.html
>>
>>
>> D could incorporate something like this, no?
>
> There are some posts on the HN discussion, stating that the problem is not so easy to solve.
>
> Even without the C compiler related issues, there is a whole OS and hardware stack where the data can be attacked at multiple levels.
>
> --
> Paulo

Every little helps?

This isn't my area, I just saw the article and thought it might be of interest.

Am 07.09.2014 19:30, schrieb John Colvin:
> On Sunday, 7 September 2014 at 17:24:46 UTC, Paulo Pinto wrote:
>> Am 07.09.2014 19:00, schrieb John Colvin:
>>> http://www.daemonology.net/blog/2014-09-06-zeroing-buffers-is-insufficient.html
>>>
>>>
>>>
>>> D could incorporate something like this, no?
>>
>> There are some posts on the HN discussion, stating that the problem is
>> not so easy to solve.
>>
>> Even without the C compiler related issues, there is a whole OS and
>> hardware stack where the data can be attacked at multiple levels.
>>
>> --
>> Paulo
>
> Every little helps?
>
> This isn't my area, I just saw the article and thought it might be of
> interest.

Sure, I fully agree with you. Already not having C's faults helps a lot.

This is the post I have read, maybe you saw it as well.

https://news.ycombinator.com/item?id=8279687

--
Paulo

John Colvin:

> http://www.daemonology.net/blog/2014-09-06-zeroing-buffers-is-insufficient.html
>
> D could incorporate something like this, no?

See:
https://d.puremagic.com/issues/show_bug.cgi?id=10661

Walter seems OK with adding something like that to the D intrinsics.

Bye,
bearophile

On Tuesday, 9 September 2014 at 07:09:52 UTC, bearophile wrote:
> John Colvin:
>
>> http://www.daemonology.net/blog/2014-09-06-zeroing-buffers-is-insufficient.html
>>
>> D could incorporate something like this, no?
>
> See:
> https://d.puremagic.com/issues/show_bug.cgi?id=10661
>
> Walter seems OK with adding something like that to the D intrinsics.
>
> Bye,
> bearophile

I am by no mean a security expert and this article scared me *a lot*. Are there any truly secure TLS implementation ?

There may be room for an @crypto attribute where the stack, the registers or the dynamically allocated memory would be zeroed out in the end ? But as stated in the comments, it's probably more of an OS job since a program may always crash.

On Tuesday, 9 September 2014 at 13:05:34 UTC, matovitch wrote:
> I am by no mean a security expert and this article scared me *a lot*. Are there any truly secure TLS implementation ?
>
> There may be room for an @crypto attribute where the stack, the registers or the dynamically allocated memory would be zeroed out in the end ? But as stated in the comments, it's probably more of an OS job since a program may always crash.

I'd say, it's easier to steal the entire key sitting in your heap (as heartbleed did it) than gather obscure traces from registers.

On Tuesday, 9 September 2014 at 07:09:52 UTC, bearophile wrote:
> John Colvin:
>
>> http://www.daemonology.net/blog/2014-09-06-zeroing-buffers-is-insufficient.html
>>
>> D could incorporate something like this, no?
>
> See:
> https://d.puremagic.com/issues/show_bug.cgi?id=10661
>
> Walter seems OK with adding something like that to the D intrinsics.

Nope, the article is about something different. Quote: "With a bit of care and a cooperative compiler, we can zero a buffer — but that's not what we need."

David

On Tuesday, 9 September 2014 at 14:42:14 UTC, David Nadlinger wrote:
> On Tuesday, 9 September 2014 at 07:09:52 UTC, bearophile wrote:
>> John Colvin:
>>
>>> http://www.daemonology.net/blog/2014-09-06-zeroing-buffers-is-insufficient.html
>>>
>>> D could incorporate something like this, no?
>>
>> See:
>> https://d.puremagic.com/issues/show_bug.cgi?id=10661
>>
>> Walter seems OK with adding something like that to the D intrinsics.
>
> Nope, the article is about something different. Quote: "With a bit of care and a cooperative compiler, we can zero a buffer — but that's not what we need."
>
Yeah. But volatileMemset() is a first step in the right direction.
Maybe we can have an attribute @local that advises the compiler not to do any optimization that copies stuff around and that it has to clear all used registers at function exit - that would be really secure and at the same time convenient for programming cryptography.

On 9/9/2014 7:42 AM, David Nadlinger wrote:
> On Tuesday, 9 September 2014 at 07:09:52 UTC, bearophile wrote:
>> John Colvin:
>>
>>> http://www.daemonology.net/blog/2014-09-06-zeroing-buffers-is-insufficient.html
>>>
>>> D could incorporate something like this, no?
>>
>> See:
>> https://d.puremagic.com/issues/show_bug.cgi?id=10661
>>
>> Walter seems OK with adding something like that to the D intrinsics.
>
> Nope, the article is about something different. Quote: "With a bit of care and a
> cooperative compiler, we can zero a buffer — but that's not what we need."

1. The compiler has -gx, which will "stomp" the stack upon function return.

2. A "volatileMemset" should be added to druntime, per 10661

3. A function, say, "clearRegisters" should be added to druntime that zeros out all scratch registers.

I know the ycombinator article says that is insufficient, but these are still things that people are going to ask for and we should provide.