From owner-freebsd-current@FreeBSD.ORG Sun Jun 13 21:35:29 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EDC7A106564A for ; Sun, 13 Jun 2010 21:35:28 +0000 (UTC) (envelope-from ticso@cicely7.cicely.de) Received: from raven.bwct.de (raven.bwct.de [85.159.14.73]) by mx1.freebsd.org (Postfix) with ESMTP id C4D2C8FC08 for ; Sun, 13 Jun 2010 21:35:27 +0000 (UTC) Received: from mail.cicely.de ([10.1.1.37]) by raven.bwct.de (8.13.4/8.13.4) with ESMTP id o5DLZObU017309 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sun, 13 Jun 2010 23:35:24 +0200 (CEST) (envelope-from ticso@cicely7.cicely.de) Received: from cicely7.cicely.de (cicely7.cicely.de [10.1.1.9]) by mail.cicely.de (8.14.3/8.14.3) with ESMTP id o5DLZESZ071010 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 13 Jun 2010 23:35:14 +0200 (CEST) (envelope-from ticso@cicely7.cicely.de) Received: from cicely7.cicely.de (localhost [127.0.0.1]) by cicely7.cicely.de (8.14.2/8.14.2) with ESMTP id o5DLZEqD004190; Sun, 13 Jun 2010 23:35:14 +0200 (CEST) (envelope-from ticso@cicely7.cicely.de) Received: (from ticso@localhost) by cicely7.cicely.de (8.14.2/8.14.2/Submit) id o5DLZCqu004189; Sun, 13 Jun 2010 23:35:12 +0200 (CEST) (envelope-from ticso) Date: Sun, 13 Jun 2010 23:35:12 +0200 From: Bernd Walter To: Andrew Milton Message-ID: <20100613213512.GG87112@cicely7.cicely.de> References: <20100611162118.GR39829@acme.spoerlein.net> <867hm5tl6u.fsf@ds4.des.no> <20100612153526.GA3632@acme.spoerlein.net> <20100612163208.GS87112@cicely7.cicely.de> <864oh86tnl.fsf@ds4.des.no> <20100612225216.GT87112@cicely7.cicely.de> <86k4q33pk2.fsf@ds4.des.no> <20100613160035.GD87112@cicely7.cicely.de> <20100613162026.GQ40531@camelot.theinternet.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20100613162026.GQ40531@camelot.theinternet.com.au> X-Operating-System: FreeBSD cicely7.cicely.de 7.0-STABLE i386 User-Agent: Mutt/1.5.11 X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED=-1, BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01 autolearn=unavailable version=3.3.0 X-Spam-Checker-Version: SpamAssassin 3.3.0 (2010-01-18) on spamd.cicely.de Cc: ticso@cicely.de, current@freebsd.org Subject: Re: Cleanup for cryptographic algorithms vs. compiler optimizations X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ticso@cicely.de List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Jun 2010 21:35:29 -0000 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.