| 1 |
On 13/11/17 09:17, Jorge Almeida wrote: |
| 2 |
> On Sun, Nov 12, 2017 at 7:03 PM, Mart Raudsepp <leio@g.o> wrote: |
| 3 |
>> On L, 2017-11-11 at 00:10 +0000, Jorge Almeida wrote: |
| 4 |
>>> Well, most programmers probably won't care about this stuff anyway, |
| 5 |
>>> and people who deal with cryptography tend to be more cautious than |
| 6 |
>>> average. But I'm not really making a case for safe versions of known |
| 7 |
>>> functions. After all, the usual functions do fine for most |
| 8 |
>>> applications. memset() would be enough to clear RAM with sensitive |
| 9 |
>>> data if we had a pragma (or equivalent) to convince the compiler to |
| 10 |
>>> not ignore it (I mean a pragma to invoke on a particular function |
| 11 |
>>> definition when the programmer feels that a black box behaviour is |
| 12 |
>>> undesirable). Of course, solving the problem of the compiler copying |
| 13 |
>>> stuff around might be harder nut to crack. |
| 14 |
>> |
| 15 |
>> Sounds like you want explicit_bzero from libbsd? |
| 16 |
>> |
| 17 |
> According to their man page, yes. I'll have to [try to] check the |
| 18 |
> source. I wonder how they do it? Even the volatile modifier doesn't |
| 19 |
> solve the problem, according to the link in previous post. |
| 20 |
|
| 21 |
explicit_bzero() is available in glibc. It's in <string.h>. |
Archives