From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1758064AbcIWHnM (ORCPT ); Fri, 23 Sep 2016 03:43:12 -0400 Received: from thejh.net ([37.221.195.125]:47943 "EHLO thejh.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753578AbcIWHnL (ORCPT ); Fri, 23 Sep 2016 03:43:11 -0400 Date: Fri, 23 Sep 2016 09:43:06 +0200 From: Jann Horn To: Andy Lutomirski Cc: Linus Torvalds , Kees Cook , Andy Lutomirski , X86 ML , Borislav Petkov , "linux-kernel@vger.kernel.org" , Brian Gerst Subject: Re: [PATCH 09/12] x86/process: Pin the target stack in get_wchan() Message-ID: <20160923074306.GE20504@pc.thejh.net> References: <20160917020051.GD2543@pc.thejh.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="maH1Gajj2nflutpK" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org --maH1Gajj2nflutpK Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Sep 22, 2016 at 03:44:37PM -0700, Andy Lutomirski wrote: > On Fri, Sep 16, 2016 at 7:00 PM, Jann Horn wrote: > > On Tue, Sep 13, 2016 at 02:29:29PM -0700, Andy Lutomirski wrote: > >> This will prevent a crash if get_wchan() runs after the task stack > >> is freed. > > > > I think I found some more stuff. Have a look at KSTK_EIP() and KSTK_ESP= (), I think > > they read from the saved userspace registers area at the top of the ker= nel stack? > > > > Used on remote processes in: > > vma_is_stack_for_task() (via /proc/$pid/maps) >=20 > This isn't used in /proc/$pid/maps -- it's only used in > /proc/$pid/task/$tid/maps. I wonder if anyone actually cares about it > -- it certainly won't work reliably. >=20 > I could pin the stack in vma_is_stack_for_task, but it seems > potentially better to me to change it to vma_is_stack_for_current() > and remove the offending caller in /proc, replacing it with "return > 0". Thoughts? I just scrolled through the debian codesearch results for "\[stack\]" - there seem to only be 105 across all of debian's packages, many of them duplicates - and I didn't see any that looked like they used the tid map. So I think this might work. ( https://codesearch.debian.net/search?q=3D%22%5C%5Bstack%5C%5D%22 ) > > do_task_stat() (/proc/$pid/stat) >=20 > Like this: >=20 > mm =3D get_task_mm(task); > if (mm) { > vsize =3D task_vsize(mm); > if (permitted) { > eip =3D KSTK_EIP(task); > esp =3D KSTK_ESP(task); > } > } >=20 > Can we just delete this outright? It seems somewhere between mostly > and entirely useless, and it also seems dangerous. Until very > recently, on x86_64, this would have been a potential info leak, as > SYSCALL followed closely by a hardware interrupt would cause *kernel* > values to land in task_pt_regs(). I don't even want to think about > what this code does if the task is in vm86 mode. I wouldn't be at all > surprised if non-x86 architectures have all kinds of interesting > thinks happen if you do this to a task that isn't running normal > non-atomic kernel code at the time. >=20 > I would advocate for unconditionally returning zeros in these two stat fi= elds. I'd like that a lot. I guess the two things that might theoretically use it are ptrace users and (very theoretically) sampling profiling stuff or so? In gdb, the only code I can find that reads this is in gdb/linux-nat.c, but it's behind an "#ifdef 0": #if 0 /* Don't know how architecture-dependent the rest is... Anyway the signal bitmap info is available from "status". */ if (fscanf (procfile, "%lu ", <mp) > 0) /* FIXME arch? */ printf_filtered (_("Kernel stack pointer: 0x%lx\n"), ltmp); if (fscanf (procfile, "%lu ", <mp) > 0) /* FIXME arch? */ printf_filtered (_("Kernel instr pointer: 0x%lx\n"), ltmp); [...] strace and ltrace don't seem to be using it. --maH1Gajj2nflutpK Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBAgAGBQJX5N0KAAoJED4KNFJOeCOo6yIP/0HAgq2YiTZe2pEL4v3Z89qW oM2kfj9rBIZwEZ7p/9rMixGGUI66DP7fKPGjUp4voxU8EP8RBeYGLVwfID1Hg4Cz WB1h6rbylAejp0DEHZ3qgkZAjoa7RKw9brxN2u3C06Ud8MOFQ8SU0NsOt0EUzyM+ NAlwyAta+r9M3cW7mhDpaGEWjblyd/Qw+CXxQPcC6Z8qdoMYDpqZbCaCVPWuvTox Z+6OAUBhnkllaCR1FK59UQX2ONU6HPkfJrTyni0lMVMDElNOzJ0+WTF89rkJEtLW nYLfUIbdeBG3WUWY1bF5N16fucQhnRjtQoX824Rv9MmvQ8WvlAqahMxiz+EYcLPK 38T0ZsgyYZP8to2xWx9/V5KXlE49WOr8Un13FGfhjmApU3bJd2ROMXQ9VZMeOW8k ejjcxUbqyC5kt6vsjb3+Tloiy957ba+fE3h7J4f5lv/if8VQtd+n4AChVcvGv5Tp dS9CtrvDnKsL/7yVVKbaTZFx39V5Ar4HzmooFObsH0FI3/eCYv9OaUwhG9MDbDa/ NXH/4/otfof0Wyyr6r+pJMKxGblwjrl1o/7q+82uQ5KQz/W1c8nceKizyzTYfa2F H43DzVywyrhYzmcG89OhLb0q6ypNHdS/GdClBeWkFsOSZc/2mu0k6+X/aggrJBWI LPovuL4TbdxjXr/Sf0aC =8qPb -----END PGP SIGNATURE----- --maH1Gajj2nflutpK--