Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S261429AbVEPLEP (ORCPT ); Mon, 16 May 2005 07:04:15 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S261478AbVEPLEO (ORCPT ); Mon, 16 May 2005 07:04:14 -0400 Received: from colin.muc.de ([193.149.48.1]:51983 "EHLO mail.muc.de") by vger.kernel.org with ESMTP id S261429AbVEPLEB (ORCPT ); Mon, 16 May 2005 07:04:01 -0400 Date: 16 May 2005 13:04:00 +0200 Date: Mon, 16 May 2005 13:03:59 +0200 From: Andi Kleen To: "Eric W. Biederman" Cc: Andy Isaacson , "Richard F. Rebel" , Gabor MICSKO , linux-kernel@vger.kernel.org, mpm@selenic.com, tytso@mit.edu Subject: Re: Hyper-Threading Vulnerability Message-ID: <20050516110359.GA70871@muc.de> References: <1115963481.1723.3.camel@alderaan.trey.hu> <1116009483.4689.803.camel@rebel.corp.whenu.com> <20050513190549.GB47131@muc.de> <20050513212620.GA12522@hexapodia.org> <20050515094352.GB68736@muc.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1611 Lines: 33 > The only solution I have seen proposed so far that seems to work > is to not schedule untrusted processes simultaneously with > the security code. With the current API that sounds like > a root process killing off, or at least stopping all non-root > processes until the critical process has finished. With virtualization and a hypervisor freely scheduling it is quite impossible to guarantee this. Of course as always the signal is quite noisy so it is unclear if it is exploitable in practical settings. On virtualized environments you cannot use ps to see if a crypto process is running. > And those same processors will have the same problem if the share > significant cpu resources. Ideally the entire problem set > would fit in the cache and the cpu designers would allow cache > blocks to be locked but that is not currently the case. So a shared > L3 cache with dual core processors will have the same problem. At some point the signal gets noisy enough and the assumptions an attacker has to make too great for it being an useful attack. For me it is not even clear it is a real attack on native Linux, at least the setup in the paper looked highly artifical and quite impractical. e.g. I suppose it would be quite difficult to really synchronize to the beginning and end of the RSA encryptions on a server that does other things too. -Andi - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/