From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) by finch.gentoo.org (Postfix) with ESMTP id EB806138A1F for ; Mon, 14 Apr 2014 00:11:47 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 95091E0B10; Mon, 14 Apr 2014 00:11:39 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id A2356E0AEB for ; Mon, 14 Apr 2014 00:11:38 +0000 (UTC) Received: from [192.168.1.111] (unknown [114.91.182.254]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: patrick) by smtp.gentoo.org (Postfix) with ESMTPSA id 797B033FF89 for ; Mon, 14 Apr 2014 00:11:37 +0000 (UTC) Message-ID: <534B2900.504@gentoo.org> Date: Mon, 14 Apr 2014 08:17:04 +0800 From: Patrick Lauer User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org MIME-Version: 1.0 To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] Akamai secure memory allocator for OpenSSL? References: <534AF6A8.6070001@gentoo.org> In-Reply-To: <534AF6A8.6070001@gentoo.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Archives-Salt: beb4f68e-fc67-4fb7-8967-a899f668f480 X-Archives-Hash: 43ceba77d1b7885d1df2c69876227c1a On 04/14/2014 04:42 AM, Joshua Kinard wrote: > > So one of the side-discussions happening after Heartbleed was the fact that > OpenSSL has its own memory allocator code that effectively mitigates any C > library-provided exploit mitigations (as discussed on the openbsd-misc ML at > [1] and Ted Unangst's blogs at [2] and [3]). [snip good explanation] > It basically provides a secure memory area protected by guard pages for > sensitive data, like RSA private keys, so that if another Heartbleed-like > event occurs, things won't be as bad. Hopefully... http://lekkertech.net/akamai.txt > Is this something we want to look at adding to our openssl copy via an > optional USE flag (default off)? At this point in time I'd say we better wait for the storm to settle down - apparently the akamai patches are only fixing a small part of the problem. I don't have a strong opinion as I haven't had to think about the internals of crypto software in a while, but hastily adding not-well-reviewed code might not be the best strategy. Have fun, Patrick