From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 5E8B9C04A95 for ; Tue, 25 Oct 2022 08:40:41 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id B7C458E0002; Tue, 25 Oct 2022 04:40:40 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id B2C668E0001; Tue, 25 Oct 2022 04:40:40 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id A1CFD8E0002; Tue, 25 Oct 2022 04:40:40 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id 93B6A8E0001 for ; Tue, 25 Oct 2022 04:40:40 -0400 (EDT) Received: from smtpin14.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 5BDD8AB363 for ; Tue, 25 Oct 2022 08:40:40 +0000 (UTC) X-FDA: 80058825840.14.F8161F2 Received: from smtp-out2.suse.de (smtp-out2.suse.de [195.135.220.29]) by imf12.hostedemail.com (Postfix) with ESMTP id BC5FB4000F for ; Tue, 25 Oct 2022 08:40:39 +0000 (UTC) Received: from relay2.suse.de (relay2.suse.de [149.44.160.134]) by smtp-out2.suse.de (Postfix) with ESMTP id 195331F74A; Tue, 25 Oct 2022 08:40:38 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1666687238; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=0fvfKX4zW0ea1QU1UhyN499kdzLJCK0LcIjY28CE2+g=; b=JogF0gqmtvMcCJ1EfisBNF/pR4anb/hP0BCY68OvOPdlf8p8muBqD/OvwarfT/JsqGvtVc YUXs93uLYDlX0wiKzoS84UVbbwtZT2qjCNC7U+K1ExP0iWtaXQT8OP3VNEHwqiZ5OB/TGo rN4QOsGK6oziPJvJVwAURB6xI1l+9n8= Received: from suse.cz (unknown [10.100.208.146]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by relay2.suse.de (Postfix) with ESMTPS id 86A9F2C141; Tue, 25 Oct 2022 08:40:37 +0000 (UTC) Date: Tue, 25 Oct 2022 10:40:37 +0200 From: Petr Mladek To: Andy Shevchenko Cc: Konrad Rzeszutek Wilk , Jane Chu , rostedt@goodmis.org, senozhatsky@chromium.org, linux@rasmusvillemoes.dk, linux-mm@kvack.org, linux-kernel@vger.kernel.org, wangkefeng.wang@huawei.com, haakon.bugge@oracle.com, john.haxby@oracle.com Subject: Re: [PATCH v3 1/1] vsprintf: protect kernel from panic due to non-canonical pointer dereference Message-ID: References: <20221019194159.2923873-1-jane.chu@oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1666687240; a=rsa-sha256; cv=none; b=aFWBAO4t3Q9Y+z+hW5aQygL1inEKahA1xdGRGoVWg8q5GX/dN8D3dBacVcSw7E1oOEWIn/ Z2nQXnlP2s7PUy/QMNH3k3ww47guQd8JVlMQW4aVlNuHFY2dpzfK5+A8usCYxUmjpPCVoo fhg4XDYt6suP4my8jzaUWMqrJQfZzCc= ARC-Authentication-Results: i=1; imf12.hostedemail.com; dkim=pass header.d=suse.com header.s=susede1 header.b=JogF0gqm; dmarc=pass (policy=quarantine) header.from=suse.com; spf=pass (imf12.hostedemail.com: domain of pmladek@suse.com designates 195.135.220.29 as permitted sender) smtp.mailfrom=pmladek@suse.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1666687240; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=0fvfKX4zW0ea1QU1UhyN499kdzLJCK0LcIjY28CE2+g=; b=vGidr0EBclbl4r/4tUJpYJBkOZFyLod7ZEYDY42FlAY8md4s6fp2hVZYsv8H0nBzGB6lf/ BASX+4a23vGzYVN3s74Jg7xCJ5BLPZ2KS9GuUlJC+n71bE8fBsMS1QejzZCBySCqxGOI3A mOYGwQ8noq7OJx3vJp5JrdngYWLEy+Y= X-Stat-Signature: hw1wpj4x7h9tz8s5hq9feznjero5htep X-Rspam-User: X-Rspamd-Server: rspam08 X-Rspamd-Queue-Id: BC5FB4000F Authentication-Results: imf12.hostedemail.com; dkim=pass header.d=suse.com header.s=susede1 header.b=JogF0gqm; dmarc=pass (policy=quarantine) header.from=suse.com; spf=pass (imf12.hostedemail.com: domain of pmladek@suse.com designates 195.135.220.29 as permitted sender) smtp.mailfrom=pmladek@suse.com X-HE-Tag: 1666687239-145604 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Thu 2022-10-20 19:03:23, Andy Shevchenko wrote: > On Thu, Oct 20, 2022 at 10:52:03AM -0400, Konrad Rzeszutek Wilk wrote: > > On Wed, Oct 19, 2022 at 11:33:47PM +0300, Andy Shevchenko wrote: > > > On Wed, Oct 19, 2022 at 01:41:59PM -0600, Jane Chu wrote: > > > > Having stepped on a local kernel bug where reading sysfs has led to > > > > out-of-bound pointer dereference by vsprintf() which led to GPF panic. > > > > And the reason for GPF is that the OOB pointer was turned to a > > > > non-canonical address such as 0x7665645f63616465. > > > > > > > > vsprintf() already has this line of defense > > > > if ((unsigned long)ptr < PAGE_SIZE || IS_ERR_VALUE(ptr)) > > > > return "(efault)"; > > > > Since a non-canonical pointer can be detected by kern_addr_valid() > > > > on architectures that present VM holes as well as meaningful > > > > implementation of kern_addr_valid() that detects the non-canonical > > > > addresses, this patch adds a check on non-canonical string pointer by > > > > kern_addr_valid() and "(efault)" to alert user that something > > > > is wrong instead of unecessarily panic the server. > > > > > > > > On the other hand, if the non-canonical string pointer is dereferenced > > > > else where in the kernel, by virtue of being non-canonical, a crash > > > > is expected to be immediate. > > > > > > What if there is no other dereference except the one happened in printf()? > > > > > > Just to point out here, that I formally NAKed this on the basis that NULL > > > and error pointers are special, for the bogus pointers we need crash ASAP, > > > no matter what the code issues it. I.o.w. printf() is not special for that > > > kind of pointers (i.e. bogus pointers, but not special). > > > > Hey Andy, > > > > Do we want to have user space programs crash the kernel? > > > > This patch leads to making the kernel more harden so that we do > > not crash when there are bugs but continue on. > > Fine, how to push a user to report a bug in the kernel if for them > there is no bug? > > OK, let's assume user recognizes this as a bug, what should they do in order > to provide a better description of the bug, so developer can easily debug > and fix it? WARN() would provide similar information as panic() without actually crashing the kernel. > > Would we not want that experience for users ? > > Yes, if it is a bug in the kernel we want to know it with all possible details. > Hiding bugs is a way to nowhere. I agree but we should always distinguish between fatal problems where the system could hardly continue working and unexpected behavior that is not critical. Many error code paths handle unexpected situations. Some problems are caused by users and some by bugs in the code. The kernel could always refuse doing some operation rather than crash. People will report it because it does not work. And there are non-destructive ways how to show useful debugging information. Best Regards, Petr