Re: Cleanup for cryptographic algorithms vs. compiler optimizations
On Friday 11 June 2010 23:31:57 Dag-Erling Smørgrav wrote: > Tijl Coosemans writes: >> Dag-Erling Smørgrav writes: >>> #define FORCE_ASSIGN(type, var, value) \ >>> *(volatile type *)&(var) = (value) >> memset can be optimised away as well. The only way is to declare >> those variables volatile. > > Assigning through a volatile pointer, as in FORCE_ASSIGN(), also > works, even if the variable itself is not volatile. Just thought of problem with this macro when var is a pointer. Then volatile applies to the referenced memory and not the variable. So you should move the volatile keyword, like so: #define FORCE_ASSIGN(type, var, value) \ *(type volatile *)&(var) = (value) And if you can use GNU extensions this can be simplified to: #define FORCE_ASSIGN(var, value) \ *(typeof(var) volatile *)&(var) = (value) ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Cleanup for cryptographic algorithms vs. compiler optimizations
Bernd Walter writes: > Dag-Erling Smørgrav writes: > > Those are freestanding environments, where printf() and puts() don't > > exist as far as the C standard is concerned. > Most controller environments have some kind of libc. They are still freestanding environments. Can we agree not to discuss this any further until you've read chapters 1 through 5 of the C standard? > Anyway - printf=>puts isn't scarying as such, it is more that this > might happen in other cases as well. Yes, it might, and if you run into trouble because of it, it means you've broken the rules somewhere. DES -- Dag-Erling Smørgrav - d...@des.no ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Protecting sensitive data [was Re: Cleanup for cryptographic algorithms vs. compiler optimizations]
2010/6/14 Peter Jeremy : > On 2010-Jun-13 10:07:15 +0200, Dag-Erling Smørgrav wrote: >>You always overwrite passphrases, keys etc. as soon as you're done with >>them so they don't end up in a crash dump or on a swap disk or >>something. > > Which brings up an associated issue: By default, mlock(2) can only be > used by root processes. It would be really handy if non-privileged > processes could lock small amounts of VM so they can securely handle > passwords, passphrases, keys, etc. MAC offers the option of allowing > non-root processes access to mlock() but doesn't provide any > restrictions on the amount of memory they can lock. Interesting! >From an admin point of view, this behavior could them be enabled or disabled via sysctl(8), and this sysctl variable could define what "small" means exactly (#nr of pages per process maybe?) Another sysctl variable should probably define how many pages can be locked in general by all non-privileged processes, to prevent malicious programs like fork bombs to mlock the whole memory. > Peter Jeremy -cpghost. -- Cordula's Web. http://www.cordula.ws/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Cleanup for cryptographic algorithms vs. compiler optimizations
On Sun, Jun 13, 2010 at 11:35 PM, Bernd Walter wrote: > Crypto code wasn't aware of this problem and this is a way more > obviuous optimization than function exchange. > And I do believe that the programmers were clever people. > Alarming, isn't it? > Maybe paranoid users might consider compiling their OS with -O0, but > I don't think this is the right way. I think that most crypto code isn't compiled with strong optimizations anyway, even when the rest of the OS or program is (or can be). After all, we do have separate compilation units... as long as you don't enable LTO, of course. Turning off strong optimizations for crypto code may seem paradoxical, but since most performance-critical routines often contain hand-optimized assembly anyway, and compiler-optimizations may be counter-productive here, the point is rather moot, usually. > It is amazing how strong the influence of optimization is and how weak > the programmers assumptions are. Indeed. That's a classic trap that trips a lot of crypto programmers in particular, and even seasoned C programmers occasionally. -cpghost. -- Cordula's Web. http://www.cordula.ws/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Protecting sensitive data [was Re: Cleanup for cryptographic algorithms vs. compiler optimizations]
On 2010-Jun-13 10:07:15 +0200, Dag-Erling Smørgrav wrote: >You always overwrite passphrases, keys etc. as soon as you're done with >them so they don't end up in a crash dump or on a swap disk or >something. Which brings up an associated issue: By default, mlock(2) can only be used by root processes. It would be really handy if non-privileged processes could lock small amounts of VM so they can securely handle passwords, passphrases, keys, etc. MAC offers the option of allowing non-root processes access to mlock() but doesn't provide any restrictions on the amount of memory they can lock. -- Peter Jeremy pgp2LOL7MFufA.pgp Description: PGP signature
Re: Cleanup for cryptographic algorithms vs. compiler optimizations
On Sun, Jun 13, 2010 at 11:41:03PM +0200, Dag-Erling Smørgrav wrote: > Bernd Walter writes: > > Dag-Erling Smørgrav writes: > > > The only way you can tell that gcc did it is if you break the rules, > > > such as by defining your own version of printf() or puts(). > > Our loader stages do this for good reasons. And in microcontroller > > programming (surely out of FreeBSD scope) it is done very regulary. > > Those are freestanding environments, where printf() and puts() don't > exist as far as the C standard is concerned. Most controller environments have some kind of libc. We even have devel/avr-libc and devel/msp430-libc in ports. Anyway - printf=>puts isn't scarying as such, it is more that this might happen in other cases as well. -- B.Walter http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Cleanup for cryptographic algorithms vs. compiler optimizations
Le Sun, 13 Jun 2010 23:35:12 +0200, Bernd Walter a écrit : > Go back to the originating mail. > Crypto code wasn't aware of this problem and this is a way more > obviuous optimization than function exchange. > And I do believe that the programmers were clever people. > Alarming, isn't it? The removal of dead store by gcc is recent. There was a discussion about this problem on the linux crypto mailing list, see: http://www.mail-archive.com/linux-cry...@vger.kernel.org/msg04229.html If i remember well, they have introduced a secure_memset() function or something like that, but I do not find this piece of code any more. Regards. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Cleanup for cryptographic algorithms vs. compiler optimizations
Bernd Walter writes: > Dag-Erling Smørgrav writes: > > The only way you can tell that gcc did it is if you break the rules, > > such as by defining your own version of printf() or puts(). > Our loader stages do this for good reasons. And in microcontroller > programming (surely out of FreeBSD scope) it is done very regulary. Those are freestanding environments, where printf() and puts() don't exist as far as the C standard is concerned. DES -- Dag-Erling Smørgrav - d...@des.no ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Cleanup for cryptographic algorithms vs. compiler optimizations
On Mon, Jun 14, 2010 at 02:20:26AM +1000, Andrew Milton wrote: > +---[ Bernd Walter ]-- > | On Sun, Jun 13, 2010 at 05:44:29PM +0200, Dag-Erling Smørgrav wrote: > | > Bernd Walter writes: > | > > Amazing - this is one of the things which can get nasty if you try some > | > > kind of microtuning. > | > > | > Only if you break the rules. Bad code is always bad, even if it > | > sometimes works by accident. > | > | To expect that function calls are replaced with other functions isn't a > | very obvious rule. > > Don't turn on compiler optimisation then. You're explicitly telling > the compiler to make your code better/faster/smaller. Optimisation > flags always come with the caveat that your code may not work exactly > the same... This isn't helpfull at all. Yes - we can disable everything and have nothing after all including nothing unexpected. In Germany we say "Kind mit dem Bade auschütten". With other words you throw all the good things away just to catch a single bad point. Optimization isn't bad as such, but it is influencing more and more things, which could be considered save before. It is important to know which parts can be considered save in future and how it can be ensured. And don't tell me in the early/mid 90th anyone has ever expected compilers to optimize at the same level they do today. LTO was a very interesting new area because before that compilers never touched anything outside it's own scope. printf => puts isn't that amazing if you consider printf to be a puts consumer which is just shrink to nothing, but I understood Dags point that this was not the end of function exchange to expect. Volatile is also a very strong mechanism and often it is enough to just cast a variable volatile in a specific context as done in the macro of this thread - instead of just defining it volatile for every use as was suggested as well. Compilier optimization is even required in many cases to get decent performance or in small environments to get it small enough to fit into memory at all, but this doesn't mean it is what you want in every case. The wish to wipe out sensitive data in crypto code is very reasonable, but this doesn't mean disabling optimzation is the way to go. So far there isn't a save solution to use memset to wipe out a whole block of memory. Go back to the originating mail. Crypto code wasn't aware of this problem and this is a way more obviuous optimization than function exchange. And I do believe that the programmers were clever people. Alarming, isn't it? Maybe paranoid users might consider compiling their OS with -O0, but I don't think this is the right way. It is amazing how strong the influence of optimization is and how weak the programmers assumptions are. The thread is about how to handle optimization in corner cases and not to disable it. -- B.Walter http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Cleanup for cryptographic algorithms vs. compiler optimizations
On Sun, Jun 13, 2010 at 06:14:11PM +0200, Dag-Erling Smørgrav wrote: > Bernd Walter writes: > > Dag-Erling Smørgrav writes: > > > Bernd Walter writes: > > > > Amazing - this is one of the things which can get nasty if you try > > > > some kind of microtuning. > > > Only if you break the rules. Bad code is always bad, even if it > > > sometimes works by accident. > > To expect that function calls are replaced with other functions isn't a > > very obvious rule. > > You don't need to know that gcc replaces printf() with puts(). That's > the whole point of the as-if rule: the compiler can only modify the > program in ways that do not change observable behavior. Well in ways the compiler _thinks_ it is not observeable. I'm not saying that it is doing wrong per definition, but if it is really not observeable and obvious we wouldn't need to talk about it. > The only way you can tell that gcc did it is if you break the rules, > such as by defining your own version of printf() or puts(). Our loader stages do this for good reasons. And in microcontroller programming (surely out of FreeBSD scope) it is done very regulary. All I say is that the rules are not obvious in many cases. Most people using compilers don't have the deep knowledge as you have. Of course we are talking about corner cases which most people also never have to face. In any case - I've learned something new. -- B.Walter http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Cleanup for cryptographic algorithms vs. compiler optimizations
+---[ Bernd Walter ]-- | On Sun, Jun 13, 2010 at 05:44:29PM +0200, Dag-Erling Smørgrav wrote: | > Bernd Walter writes: | > > Amazing - this is one of the things which can get nasty if you try some | > > kind of microtuning. | > | > Only if you break the rules. Bad code is always bad, even if it | > sometimes works by accident. | | To expect that function calls are replaced with other functions isn't a | very obvious rule. Don't turn on compiler optimisation then. You're explicitly telling the compiler to make your code better/faster/smaller. Optimisation flags always come with the caveat that your code may not work exactly the same... -- Andrew Milton a...@theinternet.com.au ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Cleanup for cryptographic algorithms vs. compiler optimizations
Bernd Walter writes: > Dag-Erling Smørgrav writes: > > Bernd Walter writes: > > > Amazing - this is one of the things which can get nasty if you try > > > some kind of microtuning. > > Only if you break the rules. Bad code is always bad, even if it > > sometimes works by accident. > To expect that function calls are replaced with other functions isn't a > very obvious rule. You don't need to know that gcc replaces printf() with puts(). That's the whole point of the as-if rule: the compiler can only modify the program in ways that do not change observable behavior. The only way you can tell that gcc did it is if you break the rules, such as by defining your own version of printf() or puts(). DES -- Dag-Erling Smørgrav - d...@des.no ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Cleanup for cryptographic algorithms vs. compiler optimizations
On Sun, Jun 13, 2010 at 05:44:29PM +0200, Dag-Erling Smørgrav wrote: > Bernd Walter writes: > > Amazing - this is one of the things which can get nasty if you try some > > kind of microtuning. > > Only if you break the rules. Bad code is always bad, even if it > sometimes works by accident. To expect that function calls are replaced with other functions isn't a very obvious rule. -- B.Walter http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Cleanup for cryptographic algorithms vs. compiler optimizations
Bernd Walter writes: > Amazing - this is one of the things which can get nasty if you try some > kind of microtuning. Only if you break the rules. Bad code is always bad, even if it sometimes works by accident. DES -- Dag-Erling Smørgrav - d...@des.no ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Cleanup for cryptographic algorithms vs. compiler optimizations
On Sun, Jun 13, 2010 at 12:44:03PM +0200, Matthias Andree wrote: > Am 13.06.2010, 00:52 Uhr, schrieb Bernd Walter: > > >>In more general terms, the compiler is allowed to make any changes it > >>likes to the program as long as the end result behaves exactly like it > >>would if it hadn't been changed. This is called the "as if" rule. For > >>instance, if you call printf() or fprintf() with a format string that > >>does not contain any conversion specifiers, gcc will call gets() or > >>fgets() instead. > > > >Amazing - this is one of the things which can get nasty if you try some > >kind of microtuning. > >Recently I had to implement my own atoi on a controller because using the > >library one magically had blown my RAM usage by 1k on a controller with > >just 8k RAM. > > There are certain compiler flags to affect that. For GCC, -Os is one > (which doesn't necessarily work in FreeBSD though, on some versions the > compiler would go into unterminated loop, leak memory and ultimately fail > with OOM), flags to tell the compiler that the implementation is > freestanding, and attributes to select builtins and the likes. I know -Os - the problem was more complicated and at linker stage. It was because atoi sucked more hardly related library parts in, of which one had 1k static RAM requirement. Quite surprising outcome from using atoi. But this isn't related to FreeBSD at all, since it happened with newlibc. -- B.Walter http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Cleanup for cryptographic algorithms vs. compiler optimizations
Am 13.06.2010, 00:52 Uhr, schrieb Bernd Walter: In more general terms, the compiler is allowed to make any changes it likes to the program as long as the end result behaves exactly like it would if it hadn't been changed. This is called the "as if" rule. For instance, if you call printf() or fprintf() with a format string that does not contain any conversion specifiers, gcc will call gets() or fgets() instead. Amazing - this is one of the things which can get nasty if you try some kind of microtuning. Recently I had to implement my own atoi on a controller because using the library one magically had blown my RAM usage by 1k on a controller with just 8k RAM. There are certain compiler flags to affect that. For GCC, -Os is one (which doesn't necessarily work in FreeBSD though, on some versions the compiler would go into unterminated loop, leak memory and ultimately fail with OOM), flags to tell the compiler that the implementation is freestanding, and attributes to select builtins and the likes. -- Matthias Andree ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Cleanup for cryptographic algorithms vs. compiler optimizations
On Sun, Jun 13, 2010 at 12:17:50AM +, Bruce Cran wrote: > On Sun, Jun 13, 2010 at 12:52:16AM +0200, Bernd Walter wrote: > > I'm at least sure that the compiler can't if it is linked from another > > object file. > > Is that still true if LTO is enabled? Good question - I wasn't aware of LTO. My precondition was that the function doesn't see what is done with the result and LTO invalidates this. -- B.Walter http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Cleanup for cryptographic algorithms vs. compiler optimizations
Bernd Walter writes: > Dag-Erling Smørgrav writes: > > Bernd Walter writes: > > > I'm not sure when removing a memset is allowed. > > Always, if the compiler can determine that the data will not be used > > later. > I'm at least sure that the compiler can't if it is linked from another > object file. When running in hosted mode, the compiler can *always* inline a memset() call or eliminate it if it can determine that the result is not used. > The problem with memset is that the compiler has an internal > implementation. That's a feature, not a problem. > On the other hand I wonder what the deep sense is to clear memory > which is unused later. I know that crypto code can be tricky > sometimes, but if someone is willing to explain the specific reason my > curiosity would be satified. You always overwrite passphrases, keys etc. as soon as you're done with them so they don't end up in a crash dump or on a swap disk or something. DES -- Dag-Erling Smørgrav - d...@des.no ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Cleanup for cryptographic algorithms vs. compiler optimizations
On Sun, Jun 13, 2010 at 12:52:16AM +0200, Bernd Walter wrote: > I'm at least sure that the compiler can't if it is linked from another > object file. Is that still true if LTO is enabled? -- Bruce Cran ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Cleanup for cryptographic algorithms vs. compiler optimizations
Bernd Walter wrote: > But calling my_abolsutely_not_inlineable_memset should work IMHO. Try gcc -fno-builtin-memset ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Cleanup for cryptographic algorithms vs. compiler optimizations
On Sat, Jun 12, 2010 at 07:35:26PM +0200, Dag-Erling Smørgrav wrote: > Bernd Walter writes: > > I'm not sure when removing a memset is allowed. > > Always, if the compiler can determine that the data will not be used > later. I'm at least sure that the compiler can't if it is linked from another object file. The problem with memset is that the compiler has an internal implementation. On the other hand I wonder what the deep sense is to clear memory which is unused later. I know that crypto code can be tricky sometimes, but if someone is willing to explain the specific reason my curiosity would be satified. > In more general terms, the compiler is allowed to make any changes it > likes to the program as long as the end result behaves exactly like it > would if it hadn't been changed. This is called the "as if" rule. For > instance, if you call printf() or fprintf() with a format string that > does not contain any conversion specifiers, gcc will call gets() or > fgets() instead. Amazing - this is one of the things which can get nasty if you try some kind of microtuning. Recently I had to implement my own atoi on a controller because using the library one magically had blown my RAM usage by 1k on a controller with just 8k RAM. > > Maybe passing volatile pointers might be enough. > > You can't pass a volatile pointer to memset. Of course not - my fault - it takes non volatile pointers per definition. -- B.Walter http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Cleanup for cryptographic algorithms vs. compiler optimizations
Bernd Walter writes: > I'm not sure when removing a memset is allowed. Always, if the compiler can determine that the data will not be used later. In more general terms, the compiler is allowed to make any changes it likes to the program as long as the end result behaves exactly like it would if it hadn't been changed. This is called the "as if" rule. For instance, if you call printf() or fprintf() with a format string that does not contain any conversion specifiers, gcc will call gets() or fgets() instead. > Maybe passing volatile pointers might be enough. You can't pass a volatile pointer to memset. DES -- Dag-Erling Smørgrav - d...@des.no ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Cleanup for cryptographic algorithms vs. compiler optimizations
On Sat, Jun 12, 2010 at 05:35:28PM +0200, Ulrich Spörlein wrote: > On Fri, 11.06.2010 at 21:37:29 +0200, Dag-Erling Smørgrav wrote: > > Ulrich Spörlein writes: > > > optimizing compilers have a tendency to remove assignments that have > > > no side effects. The code in sys/crypto/sha2/sha2.c is doing a lot of > > > zeroing variables, which is however optimized away. [...] Is there a > > > canonical way to zero those variables and should we use them (memset > > > perhaps? what are the performance implications?) > > > > If you stick these variables in a struct, you can memset the struct to > > zero them; if there are many of them, it may be faster than zeroing them > > individually. > > > > Alternatively, you can use something like this: > > > > #define FORCE_ASSIGN(type, var, value) \ > > *(volatile type *)&(var) = (value) > > Interesting trick, thanks. I'll try this ... I'm not sure when removing a memset is allowed. Maybe passing volatile pointers might be enough. And I'm happy to be corrected from in deep experts - my knowledge is more from practical microcontroller programming. The problem with memset is that is is inlined by at least gcc and inlined functions are included in the optimizations. But calling my_abolsutely_not_inlineable_memset should work IMHO. In other words: declare a local memset function, which is declared (in compiler specific words) as not being inlineable, which itself calls memset you should be safe, since the function doesn't know why it does the memset it can't be removed and the caller doesn't know anything about the called function. A portible way would be to have this function in a separate .c file, which prohibits inlining. C++ has the concept of volatile member functions, but this is a slightly different thing. -- B.Walter http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Cleanup for cryptographic algorithms vs. compiler optimizations
On Fri, 11.06.2010 at 21:37:29 +0200, Dag-Erling Smørgrav wrote: > Ulrich Spörlein writes: > > optimizing compilers have a tendency to remove assignments that have > > no side effects. The code in sys/crypto/sha2/sha2.c is doing a lot of > > zeroing variables, which is however optimized away. [...] Is there a > > canonical way to zero those variables and should we use them (memset > > perhaps? what are the performance implications?) > > If you stick these variables in a struct, you can memset the struct to > zero them; if there are many of them, it may be faster than zeroing them > individually. > > Alternatively, you can use something like this: > > #define FORCE_ASSIGN(type, var, value) \ > *(volatile type *)&(var) = (value) Interesting trick, thanks. I'll try this ... Uli ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Cleanup for cryptographic algorithms vs. compiler optimizations
Tijl Coosemans writes:
> Dag-Erling Smørgrav writes:
> > #define FORCE_ASSIGN(type, var, value) \
> > *(volatile type *)&(var) = (value)
> memset can be optimised away as well. The only way is to declare those
> variables volatile.
Assigning through a volatile pointer, as in FORCE_ASSIGN(), also works,
even if the variable itself is not volatile. Unfortunately, you can't
trick the compiler into not optimizing away memset(), since you can't
pass a volatile pointer to memset().
% cat >zero.c <
int
main(void)
{
char a, b, c;
a = 1;
memset(&b, 2, sizeof b);
*(volatile char *)&c = 3;
return 0;
}
EOF
% for O in 0 1 2 ; do c99 -O$O -o zero-O$O zero.c ; done
% for O in 0 1 2 ; do echo disassemble main | gdb -batch -x /dev/stdin -q
zero-O$O ; done
Dump of assembler code for function main:
0x00400560 :push %rbp
0x00400561 :mov%rsp,%rbp
0x00400564 :sub$0x10,%rsp
0x00400568 :movb $0x1,0x(%rbp)
0x0040056c : lea0xfffe(%rbp),%rdi
0x00400570 : mov$0x1,%edx
0x00400575 : mov$0x2,%esi
0x0040057a : callq 0x40042c
0x0040057f : lea0xfffd(%rbp),%rax
0x00400583 : movb $0x3,(%rax)
0x00400586 : mov$0x0,%eax
0x0040058b : leaveq
0x0040058c : retq
0x0040058d : nop
0x0040058e : nop
0x0040058f : nop
End of assembler dump.
Dump of assembler code for function main:
0x00400520 :movb $0x3,0x(%rsp)
0x00400525 :mov$0x0,%eax
0x0040052a : retq
0x0040052b : nop
End of assembler dump.
Dump of assembler code for function main:
0x00400520 :xor%eax,%eax
0x00400522 :movb $0x3,0x(%rsp)
0x00400527 :retq
End of assembler dump.
In the -O0 case, all three assignments are carried out. In the -O1 and
-O2 cases, the first two assignments and the corresponding variables are
optimized away, while the third (which uses the volatile pointer trick)
is not.
Clang produces significantly worse code than gcc in all cases:
% for O in 0 1 2 ; do clang -O$O -o zero-O$O zero.c ; done
% for O in 0 1 2 ; do echo disassemble main | gdb -batch -x /dev/stdin -q
zero-O$O ; done
Dump of assembler code for function main:
0x00400550 :push %rbp
0x00400551 :mov%rsp,%rbp
0x00400554 :movl $0x0,0xfffc(%rbp)
0x0040055b : movb $0x1,0xfffb(%rbp)
0x0040055f : movb $0x2,0xfffa(%rbp)
0x00400563 : movb $0x3,0xfff9(%rbp)
0x00400567 : movl $0x0,0xfffc(%rbp)
0x0040056e : mov0xfffc(%rbp),%eax
0x00400571 : pop%rbp
0x00400572 : retq
0x00400573 : nop
End of assembler dump.
Dump of assembler code for function main:
0x00400550 :push %rbp
0x00400551 :mov%rsp,%rbp
0x00400554 :movb $0x3,0x(%rbp)
0x00400558 :xor%eax,%eax
0x0040055a : pop%rbp
0x0040055b : retq
End of assembler dump.
Dump of assembler code for function main:
0x00400550 :push %rbp
0x00400551 :mov%rsp,%rbp
0x00400554 :movb $0x3,0x(%rbp)
0x00400558 :xor%eax,%eax
0x0040055a : pop%rbp
0x0040055b : retq
End of assembler dump.
DES
--
Dag-Erling Smørgrav - d...@des.no
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Cleanup for cryptographic algorithms vs. compiler optimizations
On Friday 11 June 2010 21:37:29 Dag-Erling Smørgrav wrote: > Ulrich Spörlein writes: >> optimizing compilers have a tendency to remove assignments that have >> no side effects. The code in sys/crypto/sha2/sha2.c is doing a lot >> of zeroing variables, which is however optimized away. [...] Is >> there a canonical way to zero those variables and should we use them >> (memset perhaps? what are the performance implications?) > > If you stick these variables in a struct, you can memset the struct > to zero them; if there are many of them, it may be faster than > zeroing them individually. > > Alternatively, you can use something like this: > > #define FORCE_ASSIGN(type, var, value) \ > *(volatile type *)&(var) = (value) memset can be optimised away as well. The only way is to declare those variables volatile. None of the assignments below are removed for instance: volatile int a = 0; a = 1; a = 2; ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Cleanup for cryptographic algorithms vs. compiler optimizations
Ulrich Spörlein writes: > optimizing compilers have a tendency to remove assignments that have > no side effects. The code in sys/crypto/sha2/sha2.c is doing a lot of > zeroing variables, which is however optimized away. [...] Is there a > canonical way to zero those variables and should we use them (memset > perhaps? what are the performance implications?) If you stick these variables in a struct, you can memset the struct to zero them; if there are many of them, it may be faster than zeroing them individually. Alternatively, you can use something like this: #define FORCE_ASSIGN(type, var, value) \ *(volatile type *)&(var) = (value) DES -- Dag-Erling Smørgrav - d...@des.no ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Cleanup for cryptographic algorithms vs. compiler optimizations
Hello, optimizing compilers have a tendency to remove assignments that have no side effects. The code in sys/crypto/sha2/sha2.c is doing a lot of zeroing variables, which is however optimized away. I haven't looked close enough to see if all these vars happen to fit into the registers, but a nice overview can be had here: https://www.spoerlein.net/scan-build/freebsd-head/sbin.gbde/2010-06-05-1/ Compiling the code with/without those assignment results in the same object code. Is there a canonical way to zero those variables and should we use them (memset perhaps? what are the performance implications?) Regards, Uli ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
