From: Nikos Chantziaras <realnc@gmail.com>
To: gentoo-user@lists.gentoo.org
Subject: [gentoo-user] Re: memset_s
Date: Wed, 15 Nov 2017 12:31:17 +0200 [thread overview]
Message-ID: <ouh513$98f$1@blaine.gmane.org> (raw)
In-Reply-To: <CAKpSnpKrD8O6+zQ0azFxiJFrB6xGFMe5--h-NcXR9Am_PceSyw@mail.gmail.com>
On 15/11/17 11:05, Jorge Almeida wrote:
> On Wed, Nov 15, 2017 at 12:54 AM, Nikos Chantziaras <realnc@gmail.com> wrote:
>> On 14/11/17 19:36, Jorge Almeida wrote:
>>>
>>> On Fri, Nov 10, 2017 at 12:09 PM, Jorge Almeida <jjalmeida@gmail.com>
>>> wrote:
>>>
>
>>
>> Unless you look at the assembly output, you can't be sure. Some optimization
>> is done even at -O0.
>>
>> I'd stick to using explicit_bzero() which is safe regardless of compiler
>> vendor *and* version.
>>
> But what about overwriting with random bytes? Having "explicit-*"
> versions of whatnot seems madness. BTW, I checked the assemby,
> memset() is there. But there should be way to tell the compiler "do
> what I say".
Writing random bytes isn't going to help. If the compiler can deduce
that the random bytes aren't being used and that not writing anything
will not change the observable behavior of the code, the write might not
happen. And even if you do use the random bytes (like writing them to
/dev/null,) the write might still not happen. The compiler might have
marked another memory location as "hot" (in cache terms) and safe to
write to, and use that instead.
The only sure way to do this I can think of, is to require the caller to
use volatile and implement your own memset(). This is obviously prone to
error. To fix that, you could enforce your own volatile pointer with
something like:
typedef struct passwd_t {
volatile char* data;
} passwd_t;
passwd_t* alloc_passwd(int len);
void free_passwd(passwd_t* passwd);
However, since explicit_bzero() is something several other people have
come up as the solution to the problem, it's what I recommend. It's been
tested already by other people on multiple platforms and compilers. Have
a configure check for it, and if not found, try again with -lbsd. Or
have a configure switch for it. These tests are easy to do with CMake or
Autoconf.
Trying to reinvent the wheel, especially when it comes to security,
doesn't sound like a good idea. It's easy to get it wrong.
next prev parent reply other threads:[~2017-11-15 10:31 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-11-10 9:54 [gentoo-user] memset_s Jorge Almeida
2017-11-10 10:52 ` Marc Joliet
2017-11-10 11:34 ` Jorge Almeida
2017-11-10 16:25 ` R0b0t1
2017-11-10 18:20 ` Alexander Kapshuk
2017-11-10 20:09 ` Jorge Almeida
2017-11-10 23:19 ` R0b0t1
2017-11-11 0:10 ` Jorge Almeida
2017-11-13 3:03 ` Mart Raudsepp
2017-11-13 7:17 ` Jorge Almeida
2017-11-13 10:44 ` [gentoo-user] memset_s Nikos Chantziaras
2017-11-13 11:16 ` Jorge Almeida
2017-11-13 11:38 ` Mart Raudsepp
2017-11-13 14:26 ` Nikos Chantziaras
2017-11-14 17:36 ` [gentoo-user] memset_s Jorge Almeida
2017-11-15 4:42 ` R0b0t1
2017-11-15 7:22 ` Jorge Almeida
2017-11-15 15:28 ` [gentoo-user] memset_s Grant Edwards
2017-11-15 15:41 ` R0b0t1
2017-11-15 15:48 ` R0b0t1
2017-11-15 21:42 ` Grant Edwards
2017-11-16 0:19 ` R0b0t1
2017-11-15 15:50 ` Jorge Almeida
2017-11-15 17:39 ` Michael Orlitzky
2017-11-15 8:54 ` Nikos Chantziaras
2017-11-15 9:05 ` Jorge Almeida
2017-11-15 10:31 ` Nikos Chantziaras [this message]
2017-11-10 11:38 ` Nikos Chantziaras
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='ouh513$98f$1@blaine.gmane.org' \
--to=realnc@gmail.com \
--cc=gentoo-user@lists.gentoo.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox