From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933564AbcIEQ1q (ORCPT ); Mon, 5 Sep 2016 12:27:46 -0400 Received: from one.firstfloor.org ([193.170.194.197]:49953 "EHLO one.firstfloor.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932301AbcIEQ1n (ORCPT ); Mon, 5 Sep 2016 12:27:43 -0400 Date: Mon, 5 Sep 2016 09:27:39 -0700 From: Andi Kleen To: Jiri Olsa Cc: Andi Kleen , Jiri Olsa , lkml , Kees Cook , Ingo Molnar , Adrian Hunter , KAMEZAWA Hiroyuki , Linus Torvalds Subject: Re: [PATCH] fs/proc/kcore.c: Omit kernel text area for hardened usercopy feature Message-ID: <20160905162739.GO5871@two.firstfloor.org> References: <1472819145-27260-1-git-send-email-jolsa@kernel.org> <20160902151713.GM5871@two.firstfloor.org> <20160905084722.GA3134@krava> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160905084722.GA3134@krava> 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 Mon, Sep 05, 2016 at 10:47:22AM +0200, Jiri Olsa wrote: > On Fri, Sep 02, 2016 at 08:17:13AM -0700, Andi Kleen wrote: > > On Fri, Sep 02, 2016 at 02:25:45PM +0200, Jiri Olsa wrote: > > > One of the bullets for hardened usercopy feature is: > > > - object must not overlap with kernel text > > > > > > which is what we expose via /proc/kcore. We can hit > > > this check and crash the system very easily just by > > > reading the text area in kcore file: > > > > > > usercopy: kernel memory exposure attempt detected from ffffffff8179a01f () (4065 bytes) > > > kernel BUG at mm/usercopy.c:75! > > > > > > Omitting kernel text area from kcore when there's > > > hardened usercopy feature is enabled. > > > > That will completely break PT decoding, which relies on looking > > at the kernel text in /proc/kcore. > > > > Need a different fix here, perhaps some special copy function > > that is not hardened. > > how about something like this Looks good to me, but you would need the *_nocheck variant for non x86 architectures too of course. -Andi