From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751119Ab2LSXzt (ORCPT ); Wed, 19 Dec 2012 18:55:49 -0500 Received: from mail.skyhub.de ([78.46.96.112]:55901 "EHLO mail.skyhub.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751062Ab2LSXzl (ORCPT ); Wed, 19 Dec 2012 18:55:41 -0500 Date: Thu, 20 Dec 2012 00:55:38 +0100 From: Borislav Petkov To: "H. Peter Anvin" Cc: Jacob Shin , Yinghai Lu , "H. Peter Anvin" , "Yu, Fenghua" , "mingo@kernel.org" , "linux-kernel@vger.kernel.org" , "tglx@linutronix.de" , "linux-tip-commits@vger.kernel.org" , Konrad Rzeszutek Wilk , Stefano Stabellini Subject: Re: [tip:x86/microcode] x86/microcode_intel_early.c: Early update ucode on Intel's CPU Message-ID: <20121219235537.GP24895@liondog.tnic> Mail-Followup-To: Borislav Petkov , "H. Peter Anvin" , Jacob Shin , Yinghai Lu , "H. Peter Anvin" , "Yu, Fenghua" , "mingo@kernel.org" , "linux-kernel@vger.kernel.org" , "tglx@linutronix.de" , "linux-tip-commits@vger.kernel.org" , Konrad Rzeszutek Wilk , Stefano Stabellini References: <50CD04F1.8020902@zytor.com> <0dcbce7a-d2ae-44fa-9658-81590f71ec47@email.android.com> <20121219220504.GA32212@jshin-Toonie> <50D23EE8.7030904@zytor.com> <20121219225155.GK24895@liondog.tnic> <20121219225941.GB2968@jshin-Toonie> <20121219230329.GM24895@liondog.tnic> <50D24C25.5050604@zytor.com> <20121219234054.GA6130@jshin-Toonie> <50D252B6.6050802@zytor.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <50D252B6.6050802@zytor.com> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Dec 19, 2012 at 03:50:14PM -0800, H. Peter Anvin wrote: > We are trying to discuss mitigation strategies with you, but you > haven't really given us any useful information, e.g. what happens near > the various boundaries of the hole, what could trigger prefeching into > the range, and what it would take to fix the BIOSes. Another thing we could do (I admit it is ugly) is to add a quirk to the #MC handler and detect that specific condition by looking at the address reported in MCi_ADDR and exit early by not panicking the system. Again, this is ugly but a possibility, still. -- Regards/Gruss, Boris. Sent from a fat crate under my desk. Formatting is fine. --