Received: by 2002:ac0:b08d:0:0:0:0:0 with SMTP id l13csp4666850imc; Mon, 25 Feb 2019 08:50:00 -0800 (PST) X-Google-Smtp-Source: AHgI3IbxtCql9Z1Dd6lb+904OD3A80Ui2xDnHb0FxIDdfLLvLXsBXcHH3i/utg2Hr0p4YtqvuG5p X-Received: by 2002:a63:f453:: with SMTP id p19mr18941841pgk.232.1551113400719; Mon, 25 Feb 2019 08:50:00 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1551113400; cv=none; d=google.com; s=arc-20160816; b=fF0UpK1hwb7eCawHRlUAey8Y/rgswmo428Li8fJJWvFkhcm44B4SZe/52nyUzjdO6D IpxNOokneg/wOij4b1P6UwVnwaG9zTz7R1c+oJhcLNl5a7m+pJcc33YgqEQL9rGHBlIg IpOTIdvohjCvmS7TRTCVWJMxr8Ql03FJs6sRNsHZLwCZ8U/JkPgLruGkjNfvMVcJUmZH BEh0lxBzF/GMwB5k5agp4ig7itujtCGGhDj+sxO6AkkTmkPFl0eYAwIT6LfD1YgGkE+b be4OMXgQX2FXcU6YmNtdxmLw77QseKLFT0viFLSzbSWhIolvguZC+CrQp/b97U8gBP9n DTFg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:cc:to:subject :message-id:date:from:in-reply-to:references:mime-version :dkim-signature; bh=4ICyyEuXtQI+MawbJuu1orpW3Az4vFEkdJMDzqtki2E=; b=OHRt8HK1tloNKbmBl20DUnCj+4uR4BXq3KKtDUYkQp6307e5lCMAStpeL/6WhQTgoc DJGOoq9McWRQEMXCn4k/EWCUGLMwkEnBLkZqLi9zfM+mZT6yOObuP2ch8ghGfofAfjLt JmWH1stP+TVKej7KSRXo4OlSQY7VV5j/kWL62CDf7JjPZZ5Li2wASgwQbFw6HiSHHoPM zcdFYBgmG58iMExnudJ4130hSOGCHGFkUQulynJRdnrUw6R3Vgbn9Y1zYdLcnQFKPuwN 7Ze12KUtbqBMTjuq0RiVip/6zqKc6X8T2jce+3+rsmYZ3SlknIfpNYOhzstrOxqojegS mR4Q== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b="pQDD/m7u"; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id l186si9354675pgd.67.2019.02.25.08.49.45; Mon, 25 Feb 2019 08:50:00 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b="pQDD/m7u"; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728404AbfBYQtW (ORCPT + 99 others); Mon, 25 Feb 2019 11:49:22 -0500 Received: from mail.kernel.org ([198.145.29.99]:46238 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728070AbfBYQtV (ORCPT ); Mon, 25 Feb 2019 11:49:21 -0500 Received: from mail-wr1-f41.google.com (mail-wr1-f41.google.com [209.85.221.41]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 33AD1217F9 for ; Mon, 25 Feb 2019 16:49:20 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1551113360; bh=YkmCLQ46XZh+uU13TXxK6DhZ2lx6FqSkZE+J66zFURU=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=pQDD/m7uaoVfcyABw+RzmkVi/ik7DF6YiygqXb0KZUKODgtN8jsh/OWiTeVsXH2IK VqBckzz8gYSyoDsbwitSNmPla0o50PLhNfAwPLn1DGv3MnHsA0tKcdI5udbuVnlr4L mw2Nrn27ioEwDMWyX8JmUf4T8gMpBcNJJR1Hn1ck= Received: by mail-wr1-f41.google.com with SMTP id n2so10701856wrw.8 for ; Mon, 25 Feb 2019 08:49:20 -0800 (PST) X-Gm-Message-State: AHQUAuaXccQMUE6kBiO4J4FPvc5qhN2Gq2rx6saSgT6GIHXpafg5pOIl pSj3fdetiVPmMnfnzsMaZvIsqSpJxbPnpQGTkvaR+Q== X-Received: by 2002:adf:8061:: with SMTP id 88mr12653798wrk.77.1551113358560; Mon, 25 Feb 2019 08:49:18 -0800 (PST) MIME-Version: 1.0 References: <20190225124330.613028745@infradead.org> <20190225125231.936952143@infradead.org> <20190225161003.GL32477@hirez.programming.kicks-ass.net> <3F83AE74-3F9E-42BB-8F9C-3033F72B3EF5@amacapital.net> <20190225163745.GF32494@hirez.programming.kicks-ass.net> In-Reply-To: <20190225163745.GF32494@hirez.programming.kicks-ass.net> From: Andy Lutomirski Date: Mon, 25 Feb 2019 08:49:06 -0800 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH 2/6] x86/ia32: Fix ia32_restore_sigcontext AC leak To: Peter Zijlstra Cc: Linus Torvalds , Thomas Gleixner , "H. Peter Anvin" , Julien Thierry , Will Deacon , Ingo Molnar , Catalin Marinas , James Morse , valentin.schneider@arm.com, Brian Gerst , Josh Poimboeuf , Andrew Lutomirski , Borislav Petkov , Denys Vlasenko , LKML Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Feb 25, 2019 at 8:37 AM Peter Zijlstra wrote= : > > On Mon, Feb 25, 2019 at 08:29:12AM -0800, Andy Lutomirski wrote: > > > > diff --git a/arch/x86/ia32/ia32_signal.c b/arch/x86/ia32/ia32_signal.= c > > > index 321fe5f5d0e9..e04eeeddcc35 100644 > > > --- a/arch/x86/ia32/ia32_signal.c > > > +++ b/arch/x86/ia32/ia32_signal.c > > > @@ -53,17 +53,16 @@ > > > #define GET_SEG(seg) ({ \ > > > unsigned short tmp; \ > > > get_user_ex(tmp, &sc->seg); \ > > > - tmp; \ > > > + tmp | 3; \ > > > }) > > > > > > > Drop this part. > > > > > #define COPY_SEG_CPL3(seg) do { \ > > > - regs->seg =3D GET_SEG(seg) | 3; \ > > > + regs->seg =3D GET_SEG(seg); \ > > > } while (0) > > > > And this. > > > > Unfortunately, whether we want the | 3 varies by segment. For FS and > > GS, we definitely don=E2=80=99t want it, since 0 is a common and import= ant > > value, and 3 is a deeply screwed up value. (3 is legal to *write* to > > GS, and it sticks, but IRET silently changes it to 0, because the > > original 386 designers (I assume) confused themselves. > > > > > > > #define RELOAD_SEG(seg) { \ > > > - unsigned int pre =3D GET_SEG(seg); \ > > > + unsigned int pre =3D (seg); \ > > > unsigned int cur =3D get_user_seg(seg); \ > > > - pre |=3D 3; \ > > And here ? > > > > if (pre !=3D cur) \ > > > set_user_seg(seg, pre); \ > > > } > > Thing is; afaict the current code _always_ does |3 on any GET_SET() > result. > > If you want to change that; I'm fine with that, but lets not do that in > this same patch. Ugh, you're right. I bet I can come up with some awful case involving ptrace and sigreturn where this causes problems. I have a patch series I need to dust off that deletes this entire file. It's this and its parents: https://git.kernel.org/pub/scm/linux/kernel/git/luto/linux.git/commit/?h=3D= execve&id=3D0618fe90d8224979f70b15d33dcae75a403592e5 > > So then? > > diff --git a/arch/x86/ia32/ia32_signal.c b/arch/x86/ia32/ia32_signal.c > index 321fe5f5d0e9..4d5fcd47ab75 100644 > --- a/arch/x86/ia32/ia32_signal.c > +++ b/arch/x86/ia32/ia32_signal.c > @@ -61,9 +61,8 @@ > } while (0) > > #define RELOAD_SEG(seg) { \ > - unsigned int pre =3D GET_SEG(seg); \ > + unsigned int pre =3D (seg) | 3; \ > unsigned int cur =3D get_user_seg(seg); \ > - pre |=3D 3; \ > if (pre !=3D cur) \ > set_user_seg(seg, pre); \ > } > @@ -72,6 +71,7 @@ static int ia32_restore_sigcontext(struct pt_regs *regs= , > struct sigcontext_32 __user *sc) > { > unsigned int tmpflags, err =3D 0; > + u16 gs, fs, es, ds; > void __user *buf; > u32 tmp; > > @@ -79,16 +79,10 @@ static int ia32_restore_sigcontext(struct pt_regs *re= gs, > current->restart_block.fn =3D do_no_restart_syscall; > > get_user_try { > - /* > - * Reload fs and gs if they have changed in the signal > - * handler. This does not handle long fs/gs base changes= in > - * the handler, but does not clobber them at least in the > - * normal case. > - */ > - RELOAD_SEG(gs); > - RELOAD_SEG(fs); > - RELOAD_SEG(ds); > - RELOAD_SEG(es); > + gs =3D GET_SEG(gs); > + fs =3D GET_SEG(fs); > + ds =3D GET_SEG(ds); > + es =3D GET_SEG(es); > > COPY(di); COPY(si); COPY(bp); COPY(sp); COPY(bx); > COPY(dx); COPY(cx); COPY(ip); COPY(ax); > @@ -106,6 +100,17 @@ static int ia32_restore_sigcontext(struct pt_regs *r= egs, > buf =3D compat_ptr(tmp); > } get_user_catch(err); > > + /* > + * Reload fs and gs if they have changed in the signal > + * handler. This does not handle long fs/gs base changes in > + * the handler, but does not clobber them at least in the > + * normal case. > + */ > + RELOAD_SEG(gs); > + RELOAD_SEG(fs); > + RELOAD_SEG(ds); > + RELOAD_SEG(es); > + > err |=3D fpu__restore_sig(buf, 1); > > force_iret(); Looks good to me. The order of the restores shouldn't matter at all.