From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752491AbcDCIHy (ORCPT ); Sun, 3 Apr 2016 04:07:54 -0400 Received: from mail.skyhub.de ([78.46.96.112]:40846 "EHLO mail.skyhub.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751723AbcDCIHo (ORCPT ); Sun, 3 Apr 2016 04:07:44 -0400 Date: Sun, 3 Apr 2016 10:07:37 +0200 From: Borislav Petkov To: Andy Lutomirski , "H. Peter Anvin" Cc: Andy Lutomirski , X86 ML , Paolo Bonzini , Peter Zijlstra , KVM list , Arjan van de Ven , xen-devel , "linux-kernel@vger.kernel.org" , Linus Torvalds , Andrew Morton Subject: Re: [PATCH v5 4/9] x86/traps: Enable all exception handler callbacks early Message-ID: <20160403080737.GA19007@pd.tnic> References: <20fc047d926150cb08cb9b9f2923519b07ec1a15.1459605520.git.luto@kernel.org> <20160402185227.GB2538@pd.tnic> <20160402205248.GD2538@pd.tnic> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20160402205248.GD2538@pd.tnic> User-Agent: Mutt/1.5.24 (2015-08-30) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sat, Apr 02, 2016 at 10:52:48PM +0200, Borislav Petkov wrote: > On Sat, Apr 02, 2016 at 01:16:07PM -0700, Andy Lutomirski wrote: > > I have no idea why it was explicitly unsupported, but I'm guessing it > > was just to avoid duplicating the code. Early "ext" uaccess failures > > are certainly not going to work, but I don't think this is a problem > > -- there's no userspace before trap_init runs, so how exactly is an > > "ext" uaccess going to happen in the first place? > > > > In any event, if it did happen in older kernels, it would have > > immediately panicked due to that code. At least with my code it just > > might manage to EFAULT correctly. > > Yeah, I was wondering what that early thing meant. > > Linus or tip guys probably remember what this whole deal with early > uaccess was about. I'll try to do some git archeology tomorrow. Yep, just as I suspected: 6a1ea279c210 ("x86, extable: Add early_fixup_exception()") Apparently, thread_info might not have been setup yet. I'm guessing the intention behind this no-uaccess-fixup-early is to not even attempt any fixup due to stuff *probably* not initialized yet and so the safer thing would be to panic instead. I'm wondering whether making it try to EFAULT correctly is the right thing to do... We're certainly more conservative if we panic and not allow some silently failed attempt at recovery which looks successful, to continue. hpa, thoughts? -- Regards/Gruss, Boris. ECO tip #101: Trim your mails when you reply.