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 F3FC3FA3742 for ; Thu, 27 Oct 2022 18:27:29 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 6ACC46B0071; Thu, 27 Oct 2022 14:27:29 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 65CE96B0073; Thu, 27 Oct 2022 14:27:29 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 54BA96B0074; Thu, 27 Oct 2022 14:27:29 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id 48C626B0071 for ; Thu, 27 Oct 2022 14:27:29 -0400 (EDT) Received: from smtpin10.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 25F8A160620 for ; Thu, 27 Oct 2022 18:27:29 +0000 (UTC) X-FDA: 80067562218.10.9D2232F Received: from mail-yb1-f170.google.com (mail-yb1-f170.google.com [209.85.219.170]) by imf22.hostedemail.com (Postfix) with ESMTP id D191FC0018 for ; Thu, 27 Oct 2022 18:27:27 +0000 (UTC) Received: by mail-yb1-f170.google.com with SMTP id j7so3232360ybb.8 for ; Thu, 27 Oct 2022 11:27:27 -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=YkJRbeGgCZ6+aMV/WWBwtp3wD8MemKx2tm5yGavxfGs=; b=exIXHtdRfzzsFRcp4FGWpq1DR6KLkeXjaQaTyKUdQ4f4sosd+iXNOq3j73Dg0cZoxM p1t1ekHRKjr4sh7Gp9G4Mz92tFIq/yhByogz5OMhL+iVMwuLX4SgyN69cOBEaAZxW//j BlmyS40kXaXJvZPeoQCJ/u5DN/r0U+45qYkz+IZItOKKW8S/Y07ooZYpzl5XkItHYIRZ 9LygTaawMypWQf4GJbhWp6I8vrPk44YaSBDUwlkildjWblqyXVSSKMSj7kOqV1ZUBqKt Bo83E8OzkmVACCE5OSD87R76OnrgmasUeZL74EEHgW68EhmQIudY3vNdqy5a8vYEg26K yN1g== 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=YkJRbeGgCZ6+aMV/WWBwtp3wD8MemKx2tm5yGavxfGs=; b=BfvkyF6WCzy7Z5Y9ntW4c0DeCOjRMbbcRWv4zNlTJsYctH1JzdqPKAoGLnTH/Av1iw eoetV35ASdMiWV+mUUydvaRlL6Ai9vH7Oq54L6xcMZbDH7N/Y0g8POWvKwc095Wc+F6f xH9+tMUUXlZCeBGz9V7gzE5niybhc0rwfgLe5h0Q1lDimu7/yOl/XWcluDYGm0Wy/wDh sfuzUnTKth7LB7oy2PPxxn4oG6ZJfWb0+YX+UZ1LQiVl0+X0vzMDKiJDv6uHJSfnsXfe 62pwoVqT2h8RsuF+KECvF+fZbwl1n/aNlCfiAOzDM3elmRZbY8HQk83uJsabj8B4a6nC kF+A== X-Gm-Message-State: ACrzQf36c5o2OfpWxE1eXTYMkKhJea/NL8jM9CYz/j3ZCIiuaplsPxUu h6EKzkLwZxFqBnmOTeas9duXdnNbn2VBifwMFcKylA== X-Google-Smtp-Source: AMsMyM6O+LHzKzlgQsz+mKKGATNtn6T0dtBZB5DMyNFEPw8k9BzX0+L51VgYG8H7AWbW2yhNb/EIaj2sX5Kkc0PfnvA= X-Received: by 2002:a25:e80d:0:b0:6cb:a59c:541b with SMTP id k13-20020a25e80d000000b006cba59c541bmr8461132ybd.388.1666895246845; Thu, 27 Oct 2022 11:27:26 -0700 (PDT) MIME-Version: 1.0 References: <20221025221755.3810809-1-glider@google.com> In-Reply-To: From: Alexander Potapenko Date: Thu, 27 Oct 2022 11:26:50 -0700 Message-ID: Subject: Re: [PATCH] x86/uaccess: instrument copy_from_user_nmi() To: Peter Zijlstra Cc: Marco Elver , linux-kernel@vger.kernel.org, linux-mm@kvack.org, Andrew Morton , Dave Hansen , Kees Cook , x86@kernel.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1666895247; 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=YkJRbeGgCZ6+aMV/WWBwtp3wD8MemKx2tm5yGavxfGs=; b=67qkWA8EhH7L+CIYh49W9Y0ugLNW1bw0sgC3JgzV+IMXoGoL6hgG1whdJkqDUytAPmE1x0 c23fa77d8B8/rWPZUco3PMnT+5luJxfPew17nZEnvKw6CN4EVnB8YtK42k05r2sbbOrwfV vjXVg26bO8XVgnlSQexrcfPHpHPEEdw= ARC-Authentication-Results: i=1; imf22.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=exIXHtdR; spf=pass (imf22.hostedemail.com: domain of glider@google.com designates 209.85.219.170 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=1666895247; a=rsa-sha256; cv=none; b=59+r0DPPTiyxRo2fYZ5h1y1jIMrCkVuh+pbQynG5mOip1UqgmU7W8WxZA8d9VHdoZ3STSF o1hAyI+9p2bxU8Z4u06BNofvk81TO/cY4k45XkHtRdwWcAJ00PDuD3u3aWJGJYZryeNd5Q QH0ALmqPRr/dM3D+K6fVWf1wVdwDxHg= Authentication-Results: imf22.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=exIXHtdR; spf=pass (imf22.hostedemail.com: domain of glider@google.com designates 209.85.219.170 as permitted sender) smtp.mailfrom=glider@google.com; dmarc=pass (policy=reject) header.from=google.com X-Rspam-User: X-Rspamd-Queue-Id: D191FC0018 X-Rspamd-Server: rspam03 X-Stat-Signature: od3y667gaaf136kzq75nzny37qegde1e X-HE-Tag: 1666895247-610394 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 1:05 AM Peter Zijlstra wrote= : > > 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"? Currently that will render kmsan_unpoison_memory() useless in NMI context, but I think we don't need a check for kmsan_in_runtime() there, because unpoisoning is self-contained and normally does not recurse (guess we can tolerate a pr_err() on the rare assertion violation path?) > What's worse, it seems to do a memory allocation as well, and that's out > the window with PREEMPT_RT where you can't do even GFP_ATOMIC from > regular IRQ context. Yes, there's a lazy call to alloc_pages() in lib/stackdepot.c that is done when we run out of storage space. It would be a pity to ignore everything that is happening inside regular IRQs (by making kmsan_in_runtime() bail out on in_irq()) - I think we occasionally see errors from there, e.g. https://syzkaller.appspot.com/bug?id=3D233563e79a8e00f86412eb3d2fb4eb1f425e= 70c3 We could make stackdepot avoid allocating memory in IRQs/NMIs and hope that calls to __msan_poison_alloca() from regular contexts keep up with draining the storage from interrupts. Another option would be to preallocate a very big chunk of memory for stackdepot and never do allocations again. These tricks won't however save us from acquiring depot_lock from lib/stackdepot.c every time we want to create a new origin. But that should not be a problem by itself, because we always do kmsan_enter_runtime() before accessing the stack depot - i.e. it won't be taken recursively. Given that PREEMPT_RT is not the default at the moment, shall we make KMSAN incompatible with it for the time being? > That function is wholly unacceptable to be added to every kernel > function. > --=20 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