1 |
On Fri, Nov 10, 2017 at 2:09 PM, Jorge Almeida <jjalmeida@×××××.com> wrote: |
2 |
> On Fri, Nov 10, 2017 at 4:25 PM, R0b0t1 <r030t1@×××××.com> wrote: |
3 |
>> Hello, |
4 |
>> |
5 |
> |
6 |
>> |
7 |
>> I'm having trouble finding the article again, but these functions look |
8 |
>> very similar to Microsoft's extensions to the C standard. There is a |
9 |
>> good case to be made that they are counterproductive. |
10 |
> |
11 |
> Yes, it looks like it. No wonder, if it's MS inspired. But what I care |
12 |
> about is the fact that it's not optimized away, not the boundaries |
13 |
> checking stuff. It's hard to believe that it is practically impossible |
14 |
> to clean up a buffer, unless one is willing to forego all |
15 |
> optimizations: |
16 |
> |
17 |
> http://www.daemonology.net/blog/2014-09-04-how-to-zero-a-buffer.html |
18 |
> |
19 |
|
20 |
I really think there is a deeper issue here then, which is that the |
21 |
compiler takes a lot of liberties when translating a program |
22 |
description into machine code. There have been suggestions made that |
23 |
this makes very nearly all compilers unsuitable for high reliability |
24 |
purposes. Cryptographic or user security code is likely a candidate |
25 |
for the label "high reliability." |
26 |
|
27 |
To further explain why the additions are counterproductive: the |
28 |
programmer still has to remember to use them. It is just as likely |
29 |
that the programmer will forget to use memset_s properly as any of the |
30 |
other functions in string.h (possibly by forgetting to sanitize input |
31 |
i.e. the memory segment boundaries). |
32 |
|
33 |
> |
34 |
>>> Of course, what would really solve the optimize-into-oblivion problem |
35 |
>>> is a pragma that when invoked on a particular block of code (maybe |
36 |
>>> only a function definition) would tell the compiler to do what the |
37 |
>>> programmer says rather than viewing a function as a kind of black box. |
38 |
>>> |
39 |
>> |
40 |
>> This would probably be useful. It may be wise to reimplement important |
41 |
>> functionality. |
42 |
>> |
43 |
> No idea how difficult it would be to implement, of course. There might |
44 |
> even exist a C keyword for that. After all, the C standard states the |
45 |
> "as-if" rule, it might as well establish such an exception. |
46 |
> |
47 |
|
48 |
Sorry, I misrepresented what I meant. I meant to suggest |
49 |
reimplementing, apart from a standard library, any critical code. This |
50 |
is generally recommended against but unless there is a hand-tuned |
51 |
version that has been guaranteed to work around quirks in your |
52 |
compiler, you are now the person who has to write and maintain that |
53 |
hand-tuned version. |
54 |
|
55 |
If you don't mind I might post this concern to the GCC mailing list, |
56 |
or you can take it up if you want. |
57 |
|
58 |
Cheers, |
59 |
R0b0t1 |