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 83F16FA373D for ; Thu, 27 Oct 2022 23:25:34 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id F1C7C6B0072; Thu, 27 Oct 2022 19:25:33 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id EA4826B0073; Thu, 27 Oct 2022 19:25:33 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id D6C556B0074; Thu, 27 Oct 2022 19:25:33 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id C49856B0072 for ; Thu, 27 Oct 2022 19:25:33 -0400 (EDT) Received: from smtpin05.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 9BC7FC1145 for ; Thu, 27 Oct 2022 23:25:33 +0000 (UTC) X-FDA: 80068313346.05.BC30D70 Received: from mail-yb1-f180.google.com (mail-yb1-f180.google.com [209.85.219.180]) by imf21.hostedemail.com (Postfix) with ESMTP id 5AE501C0019 for ; Thu, 27 Oct 2022 23:25:32 +0000 (UTC) Received: by mail-yb1-f180.google.com with SMTP id j130so4263203ybj.9 for ; Thu, 27 Oct 2022 16:25:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=U3Byo6DTMlo6Jt8yL6f7ACFRU3q1j3diDDzmPUKHU5k=; b=E/+fYpPFt183h3xeXmVGJHzY/XkJfR5adPubVtmrTnRjKdl6blRarOiXfSvnoJVMWO e5rpaYh5594QcsiV1+RDiL2HzBs413Q6R1sG5U2xpob0TyOlNfeqOmcTDLdl52EUrK42 3t9ufy0Lglh2L8nyGnnslh6Ur35XG9VMj6u1qs9XSObn5ZBaGhdkS7neLztuLfQZF/ol svSETPZICFFDZhfxP/b4hIkbL8FMpwiYF8wGyiBii4k0iEsMRGhEWFi+rSWMIotWfMfe i7Qu4UOfN8pBY1tGPXDK0rMZbbaSSoBsUt6RLOCrTQw3sSU6nTvasy3NQozyRbJKBkgs BPnA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=U3Byo6DTMlo6Jt8yL6f7ACFRU3q1j3diDDzmPUKHU5k=; b=hTCaVJ8NUhezMV/giWUDer3+E86RMsj3EvekpfeeFXXUqNLq2T/U/QxVsvt4NCCnTh kt0ww+j0Xr2ni4VtVl7CkWPBCQfIBFduXlnMfkB92wuju7ykUOd1gH2OzwURFJ8aCZ8F Ej+2bOk47CRBNqbG3i7opR/Infj889Jo0Gkxu8P89JrjjrLz0N7qPHBparsREv1kWSBP cSzJbh4PvWtJ6EjTRHm20ZvNXsJUqynz9TxzTVxNYKQS714kLV08ShEc+7EAXN8LOfYb 1+tWgkCMO97rz1knwqeGfNgzoT+4Pda9E6hRIzhklrlKnASrCl5XxyjyBnlJTjh1qmri 7Udg== X-Gm-Message-State: ACrzQf3ugy1LnS0UHZdhovfQMKDTOeP4QnRecr6Vt6XtCb18jMG0lTX1 ZeaFodxRqwYfMQ4vbxYva4MI6apuj/Te2SnKAxB56A== X-Google-Smtp-Source: AMsMyM6GLtSYbTHSUfM6xVMU0IYuYtA1g9ueGfmppuuROyJL0q9lHQot+gix8SB49FhnNhQJWnJ1xbgbZlTY7SowUZ8= X-Received: by 2002:a25:9b43:0:b0:6b3:9cc2:a651 with SMTP id u3-20020a259b43000000b006b39cc2a651mr45710151ybo.485.1666913131361; Thu, 27 Oct 2022 16:25:31 -0700 (PDT) MIME-Version: 1.0 References: <20221025221755.3810809-1-glider@google.com> <202210271155.33956B1@keescook> In-Reply-To: <202210271155.33956B1@keescook> From: Alexander Potapenko Date: Thu, 27 Oct 2022 16:24:55 -0700 Message-ID: Subject: Re: [PATCH] x86/uaccess: instrument copy_from_user_nmi() To: Kees Cook Cc: Peter Zijlstra , Marco Elver , linux-kernel@vger.kernel.org, linux-mm@kvack.org, Andrew Morton , Dave Hansen , x86@kernel.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable ARC-Authentication-Results: i=1; imf21.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b="E/+fYpPF"; spf=pass (imf21.hostedemail.com: domain of glider@google.com designates 209.85.219.180 as permitted sender) smtp.mailfrom=glider@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1666913132; a=rsa-sha256; cv=none; b=zBAcpV+IGaTN5gnRpkgdh772BMlGJgo5WSMeQJOcRAaaXCaoEAVdxD2LwBYMulsjtXf34n 5TcA9qNVg40rKCvvaMR0e5MqcIaL7UWOkjQLWk1QSZXssvmtIvVTHJYDPE/FdIQyALX/4z F1OV+cumxiWCO0DhLNvjaT0+OxLuv4M= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1666913132; 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:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=U3Byo6DTMlo6Jt8yL6f7ACFRU3q1j3diDDzmPUKHU5k=; b=QnApcvriTUp/1glZMPVmv828C1JEIM/JnloIuwe7IE5F+7yBwZAWOReTY07+D77h4FgSfC VFpnBfzPbfSEhvY4DjNJzzfZRztNTOD3JD0yhYXUo9BI/4Fm2DKEs+nWmegjznrpSA4DUS rKZbHJfXQQPCtvQnF1RWNu9sXxhq2O4= X-Rspam-User: X-Rspamd-Queue-Id: 5AE501C0019 Authentication-Results: imf21.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b="E/+fYpPF"; spf=pass (imf21.hostedemail.com: domain of glider@google.com designates 209.85.219.180 as permitted sender) smtp.mailfrom=glider@google.com; dmarc=pass (policy=reject) header.from=google.com X-Stat-Signature: uwwxw5e6gjxxpf33dgowyxhk8b3yu5xa X-Rspamd-Server: rspam10 X-HE-Tag: 1666913132-659320 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, Oct 27, 2022 at 11:58 AM Kees Cook wrote: > > On Thu, Oct 27, 2022 at 11:26:50AM -0700, Alexander Potapenko wrote: > > On Thu, Oct 27, 2022 at 1:05 AM Peter Zijlstra w= rote: > > > > > > On Wed, Oct 26, 2022 at 11:38:53AM -0700, Alexander Potapenko wrote: > > > > A bigger issue from the NMI perspective is probably > > > > having __msan_poison_alloca() inserted in every non-noinstr kernel > > > > function, because that hook may acquire the stackdepot lock. > > > > > > *urgghhh* that's broken, that must not be. There is a *TON* of NMI > > > functions that are non-noinstr. > > > > __msan_poison_alloca() is guarded by kmsan_in_runtime(), which is > > currently implemented as: > > > > static __always_inline bool kmsan_in_runtime(void) > > { > > if ((hardirq_count() >> HARDIRQ_SHIFT) > 1) > > return true; > > return kmsan_get_context()->kmsan_in_runtime; > > } > > > > I think the easiest way to fix the NMI situation would be adding "if > > in_nmi() return true"? > > It might help to look through these threads: > > https://lore.kernel.org/lkml/20220916135953.1320601-1-keescook@chromium.o= rg/ > https://lore.kernel.org/all/20220919201648.2250764-1-keescook@chromium.or= g/ Sorry, I missed that letter, should have responded earlier. > I wandered around attempting to deal with in_nmi(), etc. And in > the end just drop the attempt to cover it. It's worth noting that > copy_from_user_nmi() exists on 1 architecture and has exactly 1 > call-site... It doesn't really matter for KASAN, because a missing addressability check is a matter of missing some (possibly rare) bugs. For KMSAN a missing initialization will result in false positives, and we already started seeing them: show_opcodes() copies data to a local and prints it, but without a call to kmsan_unpoison_memory() it will result in error reports about opcodes[] being uninitialized. So for this particular case I want to ensure kmsan_unpoison_memory() can be called from NMI context (by removing the kmsan_in_runtime() check from it), but to be on the safe side we'll also have to do nothing in __msan_poison_alloca() under in_nmi(). > -- > Kees Cook -- Alexander Potapenko Software Engineer Google Germany GmbH Erika-Mann-Stra=C3=9Fe, 33 80636 M=C3=BCnchen Gesch=C3=A4ftsf=C3=BChrer: Paul Manicle, Liana Sebastian Registergericht und -nummer: Hamburg, HRB 86891 Sitz der Gesellschaft: Hamburg