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