* [dm-crypt] unsafe??? use of memset
@ 2014-12-30 13:57 .. ink ..
2014-12-30 14:26 ` Milan Broz
2014-12-30 16:38 ` Arno Wagner
0 siblings, 2 replies; 4+ messages in thread
From: .. ink .. @ 2014-12-30 13:57 UTC (permalink / raw)
To: dm-crypt@saout.de
[-- Attachment #1: Type: text/plain, Size: 372 bytes --]
a lot of people like this one[2] advises against the use of memset to clear
memory but crypsetup seems to
ignore this advice and use memset a lot like in[1].
Any reason why cryptseup is ignoring this advice?
[1]
https://code.google.com/p/cryptsetup/source/browse/lib/tcrypt/tcrypt.c#272
[2]
http://edc.tversu.ru/elib/inf/0088/0596003943_secureprgckbk-chp-13-sect-2.html
[-- Attachment #2: Type: text/html, Size: 646 bytes --]
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [dm-crypt] unsafe??? use of memset
2014-12-30 13:57 [dm-crypt] unsafe??? use of memset .. ink ..
@ 2014-12-30 14:26 ` Milan Broz
2014-12-30 16:47 ` Arno Wagner
2014-12-30 16:38 ` Arno Wagner
1 sibling, 1 reply; 4+ messages in thread
From: Milan Broz @ 2014-12-30 14:26 UTC (permalink / raw)
To: .. ink .., dm-crypt@saout.de
On 12/30/2014 02:57 PM, .. ink .. wrote:
>
> a lot of people like this one[2] advises against the use of memset to clear memory but crypsetup seems to
> ignore this advice and use memset a lot like in[1].
>
> Any reason why cryptseup is ignoring this advice?
Why ignore? It worked with old compilers (and VC is not the issue here).
This is opensource, so I usually respond with "send a patch" to these messages...
But actually I have patch for that for weeks. I have just another issues which have
unfortunately much higher priority in my life and I am not going commit half-baked patch.
FYI:
I fixed it is kernel dmcrypt, there we can use memzero_explicit()
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/drivers/md/dm-crypt.c?id=1a71d6ffe18c0d0f03fc8531949cc8ed41d702ee
Cryptsetup will follow (hopefully soon with other fixes).
And it is nothing critical.
There is a nice description of problem
https://cryptocoding.net/index.php/Coding_rules#Prevent_compiler_interference_with_security-critical_operations
Actually I want to replace zero memset with zero it with code used in BLAKE2.
It is simple and should work.
static inline void secure_zero_memory(void *v, size_t n)
{
volatile uint8_t *p = (volatile uint8_t *)v;
while(n--) *p++ = 0;
}
Milan
>
> [1] https://code.google.com/p/cryptsetup/source/browse/lib/tcrypt/tcrypt.c#272
> [2] http://edc.tversu.ru/elib/inf/0088/0596003943_secureprgckbk-chp-13-sect-2.html
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [dm-crypt] unsafe??? use of memset
2014-12-30 13:57 [dm-crypt] unsafe??? use of memset .. ink ..
2014-12-30 14:26 ` Milan Broz
@ 2014-12-30 16:38 ` Arno Wagner
1 sibling, 0 replies; 4+ messages in thread
From: Arno Wagner @ 2014-12-30 16:38 UTC (permalink / raw)
To: dm-crypt
Interesting question. I think it is not relevant for most
Linux scenarios, as memset() comes precompiled as part of
a binary library, and the compiler has no clue what it
does and hence cannot optimize it away.
If memset is compiled together with the code using it,
this would be a problem, but also one anybody writing
secure code should be aware of. I am not aware of any
normal Linux scenarios where that could happen.
Still, soemthing low-priority to fix eventually, as
it cannot be ruled out that it may some day be compiled
in a dangerous fashion or memset() may be made a macro
or some other bizarre circumstances.
BTW, with GCC, there is also the possibility to locally
prohibit optimization with something like:
#pragma GCC push_options
#pragma GCC optimize ("O0")
code
#pragma GCC pop_options
I needed that some time ago, but do not remember for what.
Anyways, this is an area where recipes do not cut it. For
secure code you have to understand how it gets compiled
on the specific target platform and what the issues there
are.
Arno
On Tue, Dec 30, 2014 at 14:57:56 CET, .. ink .. wrote:
> a lot of people like this one[2] advises against the use of memset to clear
> memory but crypsetup seems to
> ignore this advice and use memset a lot like in[1].
>
> Any reason why cryptseup is ignoring this advice?
>
> [1]
> https://code.google.com/p/cryptsetup/source/browse/lib/tcrypt/tcrypt.c#272
> [2]
> http://edc.tversu.ru/elib/inf/0088/0596003943_secureprgckbk-chp-13-sect-2.html
> _______________________________________________
> dm-crypt mailing list
> dm-crypt@saout.de
> http://www.saout.de/mailman/listinfo/dm-crypt
--
Arno Wagner, Dr. sc. techn., Dipl. Inform., Email: arno@wagner.name
GnuPG: ID: CB5D9718 FP: 12D6 C03B 1B30 33BB 13CF B774 E35C 5FA1 CB5D 9718
----
A good decision is based on knowledge and not on numbers. -- Plato
If it's in the news, don't worry about it. The very definition of
"news" is "something that hardly ever happens." -- Bruce Schneier
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [dm-crypt] unsafe??? use of memset
2014-12-30 14:26 ` Milan Broz
@ 2014-12-30 16:47 ` Arno Wagner
0 siblings, 0 replies; 4+ messages in thread
From: Arno Wagner @ 2014-12-30 16:47 UTC (permalink / raw)
To: dm-crypt
On Tue, Dec 30, 2014 at 15:26:02 CET, Milan Broz wrote:
> On 12/30/2014 02:57 PM, .. ink .. wrote:
> >
> > a lot of people like this one[2] advises against the use of memset to clear memory but crypsetup seems to
> > ignore this advice and use memset a lot like in[1].
> >
> > Any reason why cryptseup is ignoring this advice?
>
> Why ignore? It worked with old compilers (and VC is not the issue here).
>
> This is opensource, so I usually respond with "send a patch" to these messages...
>
> But actually I have patch for that for weeks. I have just another issues which have
> unfortunately much higher priority in my life and I am not going commit half-baked patch.
>
> FYI:
> I fixed it is kernel dmcrypt, there we can use memzero_explicit()
> http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/drivers/md/dm-crypt.c?id=1a71d6ffe18c0d0f03fc8531949cc8ed41d702ee
>
> Cryptsetup will follow (hopefully soon with other fixes).
>
> And it is nothing critical.
>
> There is a nice description of problem
> https://cryptocoding.net/index.php/Coding_rules#Prevent_compiler_interference_with_security-critical_operations
Interessting! So the problem is that memset() may not even be called.
That would be bad. In that case the compiler would need to know that
there are no volatile variables used inside memset(), which again,
I think it should not be able to on Linux as gcc does not look
at the libraries before linking. Apparently MS Visual C++ 2010
knows more about the libraries than is good for it.
My take would be that this is a legal optimization (with regard to
the C standard), but one that needs some hidden special treatment
of memset(). Of course I could be wrong.
Arno
> Actually I want to replace zero memset with zero it with code used in BLAKE2.
> It is simple and should work.
>
> static inline void secure_zero_memory(void *v, size_t n)
> {
> volatile uint8_t *p = (volatile uint8_t *)v;
> while(n--) *p++ = 0;
> }
>
> Milan
>
> >
> > [1] https://code.google.com/p/cryptsetup/source/browse/lib/tcrypt/tcrypt.c#272
> > [2] http://edc.tversu.ru/elib/inf/0088/0596003943_secureprgckbk-chp-13-sect-2.html
> _______________________________________________
> dm-crypt mailing list
> dm-crypt@saout.de
> http://www.saout.de/mailman/listinfo/dm-crypt
--
Arno Wagner, Dr. sc. techn., Dipl. Inform., Email: arno@wagner.name
GnuPG: ID: CB5D9718 FP: 12D6 C03B 1B30 33BB 13CF B774 E35C 5FA1 CB5D 9718
----
A good decision is based on knowledge and not on numbers. -- Plato
If it's in the news, don't worry about it. The very definition of
"news" is "something that hardly ever happens." -- Bruce Schneier
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2014-12-30 16:47 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2014-12-30 13:57 [dm-crypt] unsafe??? use of memset .. ink ..
2014-12-30 14:26 ` Milan Broz
2014-12-30 16:47 ` Arno Wagner
2014-12-30 16:38 ` Arno Wagner
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.