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 X-Spam-Level: X-Spam-Status: No, score=-3.8 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id A489EC433B4 for ; Wed, 7 Apr 2021 21:43:15 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 4399C610A6 for ; Wed, 7 Apr 2021 21:43:15 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 4399C610A6 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=intel.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id C86246B0073; Wed, 7 Apr 2021 17:43:14 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id C35346B0078; Wed, 7 Apr 2021 17:43:14 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id AFE826B007D; Wed, 7 Apr 2021 17:43:14 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0070.hostedemail.com [216.40.44.70]) by kanga.kvack.org (Postfix) with ESMTP id 92B2E6B0073 for ; Wed, 7 Apr 2021 17:43:14 -0400 (EDT) Received: from smtpin06.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id 48EC78248047 for ; Wed, 7 Apr 2021 21:43:14 +0000 (UTC) X-FDA: 78006897108.06.19D2721 Received: from mga09.intel.com (mga09.intel.com [134.134.136.24]) by imf14.hostedemail.com (Postfix) with ESMTP id D099DC0007C0 for ; Wed, 7 Apr 2021 21:43:08 +0000 (UTC) IronPort-SDR: S2Uvf+Q0oFlRQQCvH+mrOBhbBRwvECyl32OFSd6R4taKtcVS8ov/OZCP/FL/VYxWC187hLEnoo f9wkhZG/R+Fw== X-IronPort-AV: E=McAfee;i="6000,8403,9947"; a="193519467" X-IronPort-AV: E=Sophos;i="5.82,204,1613462400"; d="scan'208";a="193519467" Received: from orsmga008.jf.intel.com ([10.7.209.65]) by orsmga102.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 07 Apr 2021 14:43:12 -0700 IronPort-SDR: QXjxlGXW0x+9VPgS+tegkonZbDPU2J2BJiJlpNhJ738dpvwQA4hc+Qp14IZ42BoOBbh9NQt5ii 6zwasOPyz85g== X-IronPort-AV: E=Sophos;i="5.82,204,1613462400"; d="scan'208";a="421890534" Received: from agluck-desk2.sc.intel.com (HELO agluck-desk2.amr.corp.intel.com) ([10.3.52.146]) by orsmga008-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 07 Apr 2021 14:43:11 -0700 Date: Wed, 7 Apr 2021 14:43:10 -0700 From: "Luck, Tony" To: Borislav Petkov Cc: x86@kernel.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, Andy Lutomirski , Aili Yao , HORIGUCHI =?utf-8?B?TkFPWUEoIOWggOWPo+OAgOebtOS5nyk=?= Subject: Re: [PATCH 3/4] mce/copyin: fix to not SIGBUS when copying from user hits poison Message-ID: <20210407214310.GA479383@agluck-desk2.amr.corp.intel.com> References: <20210326000235.370514-1-tony.luck@intel.com> <20210326000235.370514-4-tony.luck@intel.com> <20210407211816.GP25319@zn.tnic> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20210407211816.GP25319@zn.tnic> X-Rspamd-Server: rspam03 X-Rspamd-Queue-Id: D099DC0007C0 X-Stat-Signature: npgannxa1edorsjkyfmet5pzjzadserg Received-SPF: none (intel.com>: No applicable sender policy available) receiver=imf14; identity=mailfrom; envelope-from=""; helo=mga09.intel.com; client-ip=134.134.136.24 X-HE-DKIM-Result: none/none X-HE-Tag: 1617831788-717693 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 Wed, Apr 07, 2021 at 11:18:16PM +0200, Borislav Petkov wrote: > On Thu, Mar 25, 2021 at 05:02:34PM -0700, Tony Luck wrote: > > Andy Lutomirski pointed out that sending SIGBUS to tasks that > > hit poison in the kernel copying syscall parameters from user > > address space is not the right semantic. > > What does that mean exactly? Andy said that a task could check a memory range for poison by doing: ret = write(fd, buf, size); if (ret == size) { memory range is all good } That doesn't work if the kernel sends a SIGBUS. It doesn't seem a likely scenario ... but Andy is correct that the above ought to work. > > From looking at the code, that is this conditional: > > if (t == EX_HANDLER_UACCESS && regs && is_copy_from_user(regs)) { > m->kflags |= MCE_IN_KERNEL_RECOV; > m->kflags |= MCE_IN_KERNEL_COPYIN; > > so what does the above have to do with syscall params? Most "copy from user" instances are the result of a system call parameter (e.g. "buf" in the write(2) example above). > If it is about us being in ring 0 and touching user memory and eating > poison in same *user* memory while doing so, then sure, that makes > sense. Yes. This is for kernel reading memory belongng to "current" task. > > So stop doing that. Add a new kill_me_never() call back that > > simply unmaps and offlines the poison page. > > Right, that's the same as handling poisoned user memory. Same in that the page gets unmapped. Different in that there is no SIGBUS if the kernel did the access for the user. -Tony