Received: by 10.223.164.202 with SMTP id h10csp911170wrb; Thu, 23 Nov 2017 08:09:46 -0800 (PST) X-Google-Smtp-Source: AGs4zMatHCZtXlJQ6wzJEbat5w6Rk6I1UH/lxiPlwW5oEMvBYEJs7K4H1MkP2V4YWpisz4vXwJAL X-Received: by 10.84.233.72 with SMTP id k8mr8172700plt.420.1511453386393; Thu, 23 Nov 2017 08:09:46 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1511453386; cv=none; d=google.com; s=arc-20160816; b=Apb/4R8K6R/MlKMHGDnThKAlK1P9RpS4oh0kMP1jCgzvnCjqgwaBRPof6aH5aw7mma oYc0SYVPnMJ5SDctYL14YYaAOvE95ld/ncm2bMHhK8W+yvrcyYJ8U5cOEU872DiHDE9H SqIBvz73vJ3Vy/dks8UatHIeahaLB5XGDq7yKC9VX1zJknQmyuvny1BWWKlU6q9PLdo0 8NlJ9zKRYnDl2qPXJ4Xffhxe28baXtnyss6Lik43l1yxTRYSXbNA9TsfELP+sY9rOXwF Ecn3YHwJFTH5uNX69B8EcAiNxxmlbNJmJVGAzw9Y+k3QE2aBWAtJYKIABZ/WAoJBGjIw JKAA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:message-id:content-transfer-encoding :mime-version:organization:references:in-reply-to:subject:cc:to:from :date:arc-authentication-results; bh=sGutBXWflhtmov0HDBogzb/+dHrCQ9pd/eFW4QdpIF8=; b=tdvViflc+VT2BEG8s1LItRlDhcdWwZ6ymmLaT8xkDCvcU1JqK2QijTrjuCk8fKdr1Q AdVmGoftswceOJht6S40ak3kz5vrKSjha9YSh5L0kd8GKYhmWX8IGgyV1ziN40e+OXAZ 7IRc17iIbkC8Wv3vaka/Uqd03XBb08h1muwUCcInReZfFV+pzfV8XvwQXtnnlyfLgjFy uUikB1RLAj6esO67H1BclVa3XnbpFqVOWMlfxY5/WGv75bygE5864xBCNYCfQiKktOqO 0pG4dojHATE3SepBXyxSK9AYe9od8zQlhzKBP90bYqVD6MjjmpoecgUyVZVes2922ET2 YJPQ== ARC-Authentication-Results: i=1; mx.google.com; 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=fail (p=NONE sp=NONE dis=NONE) header.from=ibm.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id k3si16228739pld.688.2017.11.23.08.09.34; Thu, 23 Nov 2017 08:09:46 -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; 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=fail (p=NONE sp=NONE dis=NONE) header.from=ibm.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752946AbdKWQI5 (ORCPT + 76 others); Thu, 23 Nov 2017 11:08:57 -0500 Received: from mx0b-001b2d01.pphosted.com ([148.163.158.5]:51052 "EHLO mx0a-001b2d01.pphosted.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1752611AbdKWQIz (ORCPT ); Thu, 23 Nov 2017 11:08:55 -0500 Received: from pps.filterd (m0098414.ppops.net [127.0.0.1]) by mx0b-001b2d01.pphosted.com (8.16.0.21/8.16.0.21) with SMTP id vANG8s9V030544 for ; Thu, 23 Nov 2017 11:08:55 -0500 Received: from e06smtp12.uk.ibm.com (e06smtp12.uk.ibm.com [195.75.94.108]) by mx0b-001b2d01.pphosted.com with ESMTP id 2ee0mrjs90-1 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=NOT) for ; Thu, 23 Nov 2017 11:08:54 -0500 Received: from localhost by e06smtp12.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Thu, 23 Nov 2017 16:08:48 -0000 Received: from b06cxnps4075.portsmouth.uk.ibm.com (9.149.109.197) by e06smtp12.uk.ibm.com (192.168.101.142) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Thu, 23 Nov 2017 16:08:44 -0000 Received: from d06av24.portsmouth.uk.ibm.com (d06av24.portsmouth.uk.ibm.com [9.149.105.60]) by b06cxnps4075.portsmouth.uk.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id vANG8hc343057356; Thu, 23 Nov 2017 16:08:43 GMT Received: from d06av24.portsmouth.uk.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id B00E742045; Thu, 23 Nov 2017 16:03:26 +0000 (GMT) Received: from d06av24.portsmouth.uk.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 655DB42041; Thu, 23 Nov 2017 16:03:26 +0000 (GMT) Received: from TP-holzheu (unknown [9.152.212.222]) by d06av24.portsmouth.uk.ibm.com (Postfix) with ESMTP; Thu, 23 Nov 2017 16:03:26 +0000 (GMT) Date: Thu, 23 Nov 2017 17:08:42 +0100 From: Michael Holzheu To: Kees Cook Cc: Tycho Andersen , Arnd Bergmann , Greg Kroah-Hartman , LKML , Heiko Carstens , Martin Schwidefsky , Vasily Gorbik Subject: Re: Does CONFIG_HARDENED_USERCOPY break /dev/mem? In-Reply-To: References: <20171110164529.14db25d6@TP-holzheu> <20171113111938.6c222a81@TP-holzheu> <20171122102829.0cbfcc8e@TP-holzheu> Organization: IBM X-Mailer: Claws Mail 3.9.3 (GTK+ 2.24.23; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-TM-AS-GCONF: 00 x-cbid: 17112316-0008-0000-0000-000004AEE3BF X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 17112316-0009-0000-0000-00001E41B2C5 Message-Id: <20171123170842.043c5ca4@TP-holzheu> X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2017-11-23_06:,, signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1709140000 definitions=main-1711230220 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Am Wed, 22 Nov 2017 09:43:19 -0800 schrieb Kees Cook : > On Wed, Nov 22, 2017 at 1:28 AM, Michael Holzheu > wrote: > > Am Mon, 13 Nov 2017 11:19:38 +0100 > > schrieb Michael Holzheu : > > > >> Am Fri, 10 Nov 2017 10:46:49 -0800 > >> schrieb Kees Cook : > >> > >> > On Fri, Nov 10, 2017 at 7:45 AM, Michael Holzheu > >> > wrote: > >> > > Hello Kees, > >> > > > >> > > When I try to run the crash tool on my s390 live system I get a kernel panic > >> > > when reading memory within the kernel image: > >> > > > >> > > # uname -a > >> > > Linux r3545011 4.14.0-rc8-00066-g1c9dbd4615fd #45 SMP PREEMPT Fri Nov 10 16:16:22 CET 2017 s390x s390x s390x GNU/Linux > >> > > # crash /boot/vmlinux-devel /dev/mem > >> > > # crash> rd 0x100000 > >> > > > >> > > usercopy: kernel memory exposure attempt detected from 0000000000100000 () (8 bytes) > >> > > ------------[ cut here ]------------ > >> > > kernel BUG at mm/usercopy.c:72! > >> > > illegal operation: 0001 ilc:1 [#1] PREEMPT SMP. > >> > > Modules linked in: > >> > > CPU: 0 PID: 1461 Comm: crash Not tainted 4.14.0-rc8-00066-g1c9dbd4615fd-dirty #46 > >> > > Hardware name: IBM 2827 H66 706 (z/VM 6.3.0) > >> > > task: 000000001ad10100 task.stack: 000000001df78000 > >> > > Krnl PSW : 0704d00180000000 000000000038165c (__check_object_size+0x164/0x1d0) > >> > > R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:0 AS:3 CC:1 PM:0 RI:0 EA:3 > >> > > Krnl GPRS: 0000000012440e1d 0000000080000000 0000000000000061 00000000001cabc0 > >> > > 00000000001cc6d6 0000000000000000 0000000000cc4ed2 0000000000001000 > >> > > 000003ffc22fdd20 0000000000000008 0000000000100008 0000000000000001 > >> > > 0000000000000008 0000000000100000 0000000000381658 000000001df7bc90 > >> > > Krnl Code: 000000000038164c: c020004a1c4a larl %r2,cc4ee0 > >> > > 0000000000381652: c0e5fff2581b brasl %r14,1cc688 > >> > > #0000000000381658: a7f40001 brc 15,38165a > >> > > >000000000038165c: eb42000c000c srlg %r4,%r2,12 > >> > > 0000000000381662: eb32001c000c srlg %r3,%r2,28 > >> > > 0000000000381668: c0110003ffff lgfi %r1,262143 > >> > > 000000000038166e: ec31ff752065 clgrj %r3,%r1,2,381558 > >> > > 0000000000381674: a7f4ff67 brc 15,381542 > >> > > Call Trace: > >> > > ([<0000000000381658>] __check_object_size+0x160/0x1d0) > >> > > [<000000000082263a>] read_mem+0xaa/0x130. > >> > > [<0000000000386182>] __vfs_read+0x42/0x168. > >> > > [<000000000038632e>] vfs_read+0x86/0x140. > >> > > [<0000000000386a26>] SyS_read+0x66/0xc0. > >> > > [<0000000000ace6a4>] system_call+0xc4/0x2b0. > >> > > INFO: lockdep is turned off. > >> > > Last Breaking-Event-Address: > >> > > [<0000000000381658>] __check_object_size+0x160/0x1d0 > >> > > > >> > > Kernel panic - not syncing: Fatal exception: panic_on_oops > >> > > > >> > > With CONFIG_HARDENED_USERCOPY copy_to_user() checks in __check_object_size() > >> > > if the source address is within the kernel image: > >> > > > >> > > - __check_object_size() -> check_kernel_text_object(): > >> > > > >> > > /* Is this address range in the kernel text area? */ > >> > > static inline const char *check_kernel_text_object(const void *ptr, > >> > > unsigned long n) > >> > > { > >> > > unsigned long textlow = (unsigned long)_stext; > >> > > unsigned long texthigh = (unsigned long)_etext; > >> > > unsigned long textlow_linear, texthigh_linear; > >> > > > >> > > if (overlaps(ptr, n, textlow, texthigh)) > >> > > return ""; > >> > > > >> > > When the crash tool reads from 0x100000, this check leads to the kernel BUG() > >> > > in drivers/char/mem.c: > >> > > > >> > > 144 } else { > >> > > 145 /* > >> > > 146 * On ia64 if a page has been mapped somewhere as > >> > > 147 * uncached, then it must also be accessed uncached > >> > > 148 * by the kernel or data corruption may occur. > >> > > 149 */ > >> > > 150 ptr = xlate_dev_mem_ptr(p); > >> > > 151 if (!ptr) > >> > > 152 return -EFAULT; > >> > > 153 > >> > > 154 remaining = copy_to_user(buf, ptr, sz); <<<---- BUG > >> > > 155 > >> > > 156 unxlate_dev_mem_ptr(p, ptr); > >> > > 157 } > >> > > > >> > > Here the reporting function in mm/usercopy.c: > >> > > > >> > > 61 static void report_usercopy(const void *ptr, unsigned long len, > >> > > 62 bool to_user, const char *type) > >> > > 63 { > >> > > 64 pr_emerg("kernel memory %s attempt detected %s %p (%s) (%lu bytes)\n", > >> > > 65 to_user ? "exposure" : "overwrite", > >> > > 66 to_user ? "from" : "to", ptr, type ? : "unknown", len); > >> > > 67 /* > >> > > 68 * For greater effect, it would be nice to do do_group_exit(), > >> > > 69 * but BUG() actually hooks all the lock-breaking and per-arch > >> > > 70 * Oops code, so that is used here instead. > >> > > 71 */ > >> > > 72 BUG(); > >> > > 73 } > >> > > > >> > > Shouldn't we skip the kernel address check for /dev/mem - at least when > >> > > CONFIG_STRICT_DEVMEM is not enabled? > >> > > >> > Some kind of better interaction is needed here, I agree. The prior > >> > discussions around this basically resulted in declaring that > >> > HARDENED_USERCOPY without STRICT_DEVMEM didn't make a lot of sense. > >> > i.e. HARDENED_USERCOPY should maybe require STRICT_DEVMEM, etc. Tycho > >> > wrote this up after some back-and-forth: > >> > > >> > https://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git/commit/?h=kspp/kconfig&id=ae98b44ceb338ae165a7f18f29f6244893712da3 > >> > > >> > In the end, I was still uncomfortable with it because the usercopy > >> > protection is wider than just the kernel text, so it seemed strange to > >> > force it off when not using STRICT_DEVMEM. > >> > > >> > What's the use-case here where you've got hardened usercopy without > >> > strict devmem? > >> > >> We use that configuration for development and test. We disabled STRICT_DEVMEM > >> for debugging the live system with crash. We enabled HARDENED_USERCOPY for > >> finding user-copy bugs. > > > > So what's your plan now? How will you fix this issue? > > I think the best plan here would be to use the Kconfig "imply > STRICT_DEVMEM" in HARDENED_USERCOPY. That would make STRICT_DEVMEM > enabled by default but still configurable. Then the kernel-text check > in hardened usercopy could be skip when !STRICT_DEVMEM. > > My primary concern is with failing closed. If someone is only paying > attention to choosing HARDENED_USERCOPY, it should not be possible to > read out kernel memory unless they specifically try to unset something > else (in this case, STRICT_DEVMEM). > > How does that sound? Looks ok to me. Michael From 1584789920460534607@xxx Wed Nov 22 17:57:24 +0000 2017 X-GM-THRID: 1583694540722198621 X-Gmail-Labels: Inbox,Category Forums,HistoricalUnread