[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: explicit_bzero and -std=c99
From: |
Paul Eggert |
Subject: |
Re: explicit_bzero and -std=c99 |
Date: |
Sun, 27 Nov 2022 10:05:42 -0800 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.4.2 |
On 2022-11-27 03:27, Simon Josefsson via Gnulib discussion list wrote:
1) Does gnulib support building with gcc -std=c99? I think we should,
but it could have documented missing functionality or breakage.
It should, yes. That's a reasonable portability test, so long as Gnulib
continues to support C99.
2) It seems explicit_bzero.c in gnulib fall backs to using 'asm' for
GCC, which isn't working in non-GNU modes of gcc. Further wondering:
I hope I fixed this particular problem by installing the attached.
Perhaps Gnulib's other uses of asm should also be changed?
1) The reason for having explicit_bzero is read_file, which needs it
for reading sensitive files, a feature we don't use. Uncoupling this
unnecessary dependency would have been nice.
In the long run it should be OK; see below.
2) Is there no other way to implement explicit_bzero without 'asm'?
There is a another fallback code using volatile pointers, but I'm not
sure it really has the same semantics.
That fallback should work, though it's a bit slower.
3) Is there a way to detect if the compiler supports 'asm'? The
current test 'defined __GNUC__ && !defined __clang__' is what is
really failing here.
We could add a configure-time test. Not sure it's worth the hassle.
3) Is the idiom of using separate functions bzero() vs explicit_bzero()
to avoid security-problematic compiler optimization still a good one?
Yes, though we should switch to memset_explicit as that's the name C23
has standardized on. I.e., create a memset_explicit module, have other
modules use that instead of explicit_bzero. No rush, but that's the way
to proceed.
0001-explicit_bzero-work-with-gcc-std-c99.patch
Description: Text Data