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 6FDA6C7619A for ; Wed, 12 Apr 2023 14:39:46 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id C0B64900002; Wed, 12 Apr 2023 10:39:45 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id BBB0F6B0075; Wed, 12 Apr 2023 10:39:45 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id A82E3900002; Wed, 12 Apr 2023 10:39:45 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id 99BA56B0074 for ; Wed, 12 Apr 2023 10:39:45 -0400 (EDT) Received: from smtpin13.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id 6457040110 for ; Wed, 12 Apr 2023 14:39:45 +0000 (UTC) X-FDA: 80672997930.13.DCEBF2A Received: from mail-yb1-f179.google.com (mail-yb1-f179.google.com [209.85.219.179]) by imf27.hostedemail.com (Postfix) with ESMTP id 95C1B40028 for ; Wed, 12 Apr 2023 14:39:43 +0000 (UTC) Authentication-Results: imf27.hostedemail.com; dkim=pass header.d=google.com header.s=20221208 header.b=tz7PxQgn; spf=pass (imf27.hostedemail.com: domain of glider@google.com designates 209.85.219.179 as permitted sender) smtp.mailfrom=glider@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1681310383; 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=1pKFL1ied8XK1n0xf5sr2x4G8CCMOMqbda58ygnphsg=; b=rZlOSLTHmRNOKHNoDqoY/GDSU81nBRmYQaQSgJrdsqChJVcNp6s3Ap7Lpv5rG7cdm99m61 22vh1aCj/NSp4JDNUVkndgnZVMxyNJcLBauZVtomoZcltjr6m4njc14I92nOIbHDjBtVTy K9jx9oX1lQ8ReRUmjNIbuqMdVWAWUVI= ARC-Authentication-Results: i=1; imf27.hostedemail.com; dkim=pass header.d=google.com header.s=20221208 header.b=tz7PxQgn; spf=pass (imf27.hostedemail.com: domain of glider@google.com designates 209.85.219.179 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=1681310383; a=rsa-sha256; cv=none; b=XgewnQi/K2w5GwWOnkYIO7WHxyB3Nd6ywo4MNDIx63w3IZH/v3SCA/pSY/TH4MqoVNF+1m kXvN8DriEFPeNLwaT5kYr00RcPzGVLfzVupWGptKqRRBego4n+V1qB90I9nszqtkGEl3jr UiH697lCUGgVoZGwhRjoIl4ya/aZ1+o= Received: by mail-yb1-f179.google.com with SMTP id y186so12004840yby.13 for ; Wed, 12 Apr 2023 07:39:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20221208; t=1681310382; 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=1pKFL1ied8XK1n0xf5sr2x4G8CCMOMqbda58ygnphsg=; b=tz7PxQgn6gzQz8HEG3T6gvJ1HxHfF3bb8fwFZIv6Cn/XdL2siEFBe9pzWmztQ8VsoO +9lTgLTZPHW5NhSVSX33SjwYogn7QD4PDjD7d874V8InAIaf+8PLFCxl5L/cxX5/Herq M8BKWoAUmKF5bMqjjiKWYA6tDGpJDEa7WBTjQtRL6VZ3lm5EI8Msj33G6WJgVRw5IdEf Z+WUOexqL5HPy+trtcMaB+LyVliDjjquWbzM50gPknAA004/W4eIlAisQ/57c+cefLNr b195g1wLW7xO3QCNuthF0ycpEYOLhZlgMJVVNB+ImGcQGiBT6b/zyu6PfTMWwEI+2TqK sicA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1681310382; 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=1pKFL1ied8XK1n0xf5sr2x4G8CCMOMqbda58ygnphsg=; b=Ban1WH0djinwe4GUGx9vzpjynt9487pFYAVl0A34QbcoN3iT9kqw7d/3OD9LEukurT D45MrVrd8gnsLb/8BeSg98W75FiUZlbZFseb9BIdQDrc8YEIGjtpUigq/Q7d3ZymaH1q E7J0L1nmqaSYQ0LpR1rzWe6VXgPemd9OCTmZFykfloMQRX1SRTTrHAStnlv8RQvsh1P5 Uzc/14xOF6eFHcqJlPVYE4mLc6HH4Tt/XB3hTdRhA1dCGDm4ubH/UrRnUhrmEAU8RnRa TlCNQU4c4ni1i29vQrV9r03qfGyC0bgLAkp1d3OXtcX7OrrqYLs7mI5T2tx0FoaaVNUr VH2Q== X-Gm-Message-State: AAQBX9cDiJEwMQpKo7/ZImXDzdBaHXcxr70i11SRAzP+qcTnqUtD09HF OZKFjTJ+fIVguBWtT6uLPaR1QRmhBdZGWHJbX39eXw== X-Google-Smtp-Source: AKy350bM2d+cGoRLEt4LS9dBT2iR+dDtIsW8oTA5rF12QIkmhn/JAZ3KqEkmO1U+uTtlgBXN4JBf6viLTfXuUR782MA= X-Received: by 2002:a25:ada1:0:b0:b67:412e:a81e with SMTP id z33-20020a25ada1000000b00b67412ea81emr16250857ybi.17.1681310382532; Wed, 12 Apr 2023 07:39:42 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Alexander Potapenko Date: Wed, 12 Apr 2023 16:39:05 +0200 Message-ID: Subject: Re: Possible incorrect handling of fault injection inside KMSAN instrumentation To: Dipanjan Das Cc: Marco Elver , Dmitry Vyukov , Andrew Morton , kasan-dev@googlegroups.com, linux-mm@kvack.org, Linux Kernel Mailing List , syzkaller , Marius Fleischer , Priyanka Bose Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspam-User: X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: 95C1B40028 X-Stat-Signature: r3kaewa4tjx8f7zn3s8nzhcgzy4ma1sf X-HE-Tag: 1681310383-801660 X-HE-Meta: U2FsdGVkX19yXfS5B/Sv7tyMRRA78IgOfUM+DM1Y4ZIxnQ8JWbCm63iwpkTL90a+NTMQVvJZPIjXX1Mym4e30lKNO2l8y6hrJ4fVNWD+FT0ktq9iaqT156MiHmHTaADSu7qcGA5L3QzfMD5WSEAWJUOsTAh4LTBTv45K6id2YebNKyeuuzcxwIUSNG0wnwWk+meqra67geizut5jJUMmhDe25T26X6biJJJVmQnPfqXsYzIF3BtgnZLMk1hRlSv8VoHi2Z8GG5xVkUseY+gvuCki04B6Cyge+ll2ZBoaCfTrrslpEykluWT0xZ1JoPzdVHf6DdMjhQAC9uLkHhuF2tGUulEY4G+JMDL3qC8TWRnX3MG/36HvUN/IcNfpKmyyMdnzM8TlGdcHM0n4RvZIPFOMrbWA5YHLu8KhtHZ/0m0f4AXjipKzoj+L+ILI8nQAzjuVgP5Q2DNo8+17wJkaVAXKayncd09KrrSWSioIiWLREmv6XSyF6sgCb7DXtxis288vqmdkY91K5MwyIVKZ6jt4kqWYiQjxEH1PZOQ75llxyBxJ/e5AfBqf+Wr/9qK9qMadAL8Fgmfjh4hXOFacLvIfFLoCK5wn3f8nxx20d/N4etk3uamjr227HU6FGWMTjIKoORtlcX5vIGMZM4gLIdduNDsAJdFE6FptecrKuqpy5mO3IzYYiVcUFqc0iWSfxpjfM5NurIALs4ZY0caiOjjeALykgAytrG5lPz1z0Cf3Tnv5+pTX3/WNl01RdNQFJnY+KKSe3Csfgt5iZzgs15uo8ESF0uhHfIMqh03O1P7DQvbp+7BHE2OKID0rY3WK5yFchC3W+Jiy2+ROr38D6KEO5DLSyevEHzDRRyx+BFrGMrZslbKvACsNB/b4K9yF7sqLcq/ADtAf+EwXHoafEExQ7rbZkLLqG1V4UlKL/Ro/B4PKIxzVVyYmEpoBpDZd3k0tFnRiJO/x3LsvvxY aVLVw9nZ mODPkY8Y0Uw1yDp81MsEXn+CZtE+o4Mw0QMU3Rh2VqJyQMqnF4xWs2DoO0tTSgll4GcPKWlTdV4q2/yfbgWSP2dYIeEfwM5WJ906s4vDDxjj9nzDCp4jSzOBsOIuDzi/VCXtA8eh/DAceKp3DFSWPXYqzzzIWlYHWQpsaDmiMDxa/jtxLYohK5hDqY+oXt1xek79fOLWBpg5CYld8sP1WQbAoFT/myh0JeXQOhehYunbJB2Ob6tUJjZpw2t87MCMY9C9IqEhKQOFCiKX4ZlYOc7ieA/jRa3XyhLcskQUlysF5eyW1QyHD3nT3GypkkC7iCFJCUP0zMkZHdtE0M4PzMx9191Hdp8mxPd1XKHh6NEPXHAI= X-Bogosity: Ham, tests=bogofilter, spamicity=0.009684, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Sat, Apr 8, 2023 at 5:51=E2=80=AFPM Dipanjan Das wrote: > > Hi, Hi Dipanjan, thanks a lot for the elaborate analysis! > kmsan's allocation of shadow or origin memory in > kmsan_vmap_pages_range_noflush() fails silently due to fault injection > (FI). KMSAN sort of =E2=80=9Cswallows=E2=80=9D the allocation failure, an= d moves on. > When either of them is later accessed while updating the metadata, > there are no checks to test the validity of the respective pointers, > which results in a page fault. You are absolutely right. > Our conclusions/Questions: > > - Should KMSAN fail silently? Probably not. Otherwise, the > instrumentation always needs to check whether shadow/origin memory > exists. KMSAN shouldn't fail silently in any case. kmsan_vmap_pages_range_noflush() used to have KMSAN_WARN_ON() to catch such cases, but unfortunately I've failed to check the return values of the kcalloc() calls. > - Should KMSAN even be tested using fault injection? We are not sure. At least our deployment of KMSAN on syzbot uses fault injection, so having the two play well together is important. > On one hand, the primary purpose of FI should be testing the > application code. But also, inducing faults inside instrumentation > clearly helps to find mistakes in that, too. At first I had an idea of having a special GFP flag that prohibits fault injections for the tool's allocations. But this would just shift the allocations failures right, making them harder to detect, because they will occur less often. We'd better handle the failures properly instead. > - What is a fix for this? Should a failure in the KMSAN > instrumentation be propagated up so that the kernel allocator > (vzalloc() in this case) can =E2=80=9Cpretend=E2=80=9D to fail, too? Yes, I think so. Here are two patches that fix the problem: - https://github.com/google/kmsan/commit/b793a6d5a1c1258326b0f53d6e3ac8aa3= eeb3499 - for kmsan_vmap_pages_range_noflush(); - https://github.com/google/kmsan/commit/cb9e33e0cd7ff735bc302ff69c02274f2= 4060cff - for kmsan_ioremap_page_range() Can you please try them out? Alex