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.6 required=3.0 tests=DKIM_INVALID,DKIM_SIGNED, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, USER_AGENT_GIT 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 7CCEEC10F25 for ; Fri, 6 Mar 2020 13:33:56 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 4227D21775 for ; Fri, 6 Mar 2020 13:33:56 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (1024-bit key) header.d=axtens.net header.i=@axtens.net header.b="rEoA/mjy" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 4227D21775 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=axtens.net Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id CBC1F6B0005; Fri, 6 Mar 2020 08:33:55 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id C6C466B0006; Fri, 6 Mar 2020 08:33:55 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id B5A726B0007; Fri, 6 Mar 2020 08:33:55 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0148.hostedemail.com [216.40.44.148]) by kanga.kvack.org (Postfix) with ESMTP id 99FCE6B0005 for ; Fri, 6 Mar 2020 08:33:55 -0500 (EST) Received: from smtpin11.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id 3EE314DDE for ; Fri, 6 Mar 2020 13:33:55 +0000 (UTC) X-FDA: 76565030430.11.title40_5c61266f05215 X-HE-Tag: title40_5c61266f05215 X-Filterd-Recvd-Size: 5695 Received: from mail-pf1-f193.google.com (mail-pf1-f193.google.com [209.85.210.193]) by imf35.hostedemail.com (Postfix) with ESMTP for ; Fri, 6 Mar 2020 13:33:54 +0000 (UTC) Received: by mail-pf1-f193.google.com with SMTP id y21so1145586pfp.1 for ; Fri, 06 Mar 2020 05:33:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=axtens.net; s=google; h=from:to:cc:subject:date:message-id:mime-version :content-transfer-encoding; bh=gUiajEtqHykUipUDAxZZ8PHMye5BZieG1YJoiSofP8Y=; b=rEoA/mjylyn+XjZnbo+FAoZbkFtWsFbkdSAQ87jZimTL1ViuqtsI33f3HZK6q697az mfbqVVBYgm53l4l6EQheDkVMFMs5BXNELeZBYPanIK1Ndezd/vzOmFfitvCSNaMDlove v4zOTwlD21ftcc6NyuLL/kbWFhIQ/PZtj9iQI= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:mime-version :content-transfer-encoding; bh=gUiajEtqHykUipUDAxZZ8PHMye5BZieG1YJoiSofP8Y=; b=WrnBuT020v5P4s3lFyaYa1nbWYYpoZbfSsTp0z6hfTmYZzKF2sSEsDFymHSfk28EJx /ne7kNh/+AZa4BXHdEx8YwPnUWxd0bJ1GSDWUSDS6xX85RZddN0TDQLb51dThPHyTZF+ LlNOg4jSsV0RavFZ3PxBwEFKjXayd1/ByrzcPbnwxctZd5clkgTJVpFB6EK+CjQgjlgo NuuRoWyCEGxd4LcOpoX2wsX2MhH0RHS4etNeGCuENo17ou0bM4MV5bycH+czYWfw9BYT XaQuv93doln5IkHXyDcG4obKUFh+JFbh5AvwPLlv9x2tiONMd6JQvAUQ/WIaUquKw2iY 3gMQ== X-Gm-Message-State: ANhLgQ2KTREiHvBoUlevzBN2rgzZBspIUW60qcZcJTVChHqIj9VRXR6u ZQwHcBQc9bEPQMm+gfGx05xFIQ== X-Google-Smtp-Source: ADFU+vvO5wzGbikRf/3JIgJ1Nd5LTOFUYoD4F69O2BvMxCf9Cq3AzzEd/joqlTHvvgzbTOzmPlJzpg== X-Received: by 2002:a63:d845:: with SMTP id k5mr3272785pgj.183.1583501633687; Fri, 06 Mar 2020 05:33:53 -0800 (PST) Received: from localhost (2001-44b8-111e-5c00-b120-f113-a8cb-35fd.static.ipv6.internode.on.net. [2001:44b8:111e:5c00:b120:f113:a8cb:35fd]) by smtp.gmail.com with ESMTPSA id w195sm33586804pfd.65.2020.03.06.05.33.51 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 06 Mar 2020 05:33:52 -0800 (PST) From: Daniel Axtens To: linux-kernel@vger.kernel.org, linux-mm@kvack.org, linuxppc-dev@lists.ozlabs.org, kasan-dev@googlegroups.com, christophe.leroy@c-s.fr, aneesh.kumar@linux.ibm.com, bsingharora@gmail.com Cc: Daniel Axtens Subject: [PATCH v8 0/4] KASAN for powerpc64 radix Date: Sat, 7 Mar 2020 00:33:36 +1100 Message-Id: <20200306133340.9181-1-dja@axtens.net> X-Mailer: git-send-email 2.20.1 MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-Bogosity: Ham, tests=bogofilter, spamicity=0.000001, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: Building on the work of Christophe, Aneesh and Balbir, I've ported KASAN to 64-bit Book3S kernels running on the Radix MMU. This provides full inline instrumentation on radix, but does require that you be able to specify the amount of physically contiguous memory on the system at compile time. More details in patch 4. One quirk that I've noticed is that detection of invalid accesses to module globals are currently broken - everything is permitted. I'm sure this used to work, but it doesn't atm and this is why: gcc puts the ASAN init code in a section called '.init_array'. Powerpc64 module loading code goes through and _renames_ any section beginning with '.init' to begin with '_init' in order to avoid some complexities around our 24-bit indirect jumps. This means it renames '.init_array' to '_init_array', and the generic module loading code then fails to recognise the section as a constructor and thus doesn't run it. This hack dates back to 2003 and so I'm not going to try to unpick it in this series. (I suspect this may have previously worked if the code ended up in .ctors rather than .init_array but I don't keep my old binaries around so I have no real way of checking.) v8: Rejig patch 4 commit message, thanks Mikey. Various tweaks to patch 4: fix some potential hangs, clean up some code, fix a trivial bug, and also have another crack at correct stack-walking based on what other arches do. Some very minor tweaks, and a review from Christophe. v7: Tweaks from Christophe, fix issues detected by snowpatch. v6: Rebase on the latest changes in powerpc/merge. Minor tweaks to the documentation. Small tweaks to the header to work with the kasan_late_init() function that Christophe added for 32-bit kasan-vmalloc support. No functional change. v5: ptdump support. More cleanups, tweaks and fixes, thanks Christophe. Details in patch 4. I have seen another stack walk splat, but I don't think it's related to the patch set, I think there's a bug somewhere else, probably in stack frame manipulation in the kernel or (more unlikely) in the compiler. v4: More cleanups, split renaming out, clarify bits and bobs. Drop the stack walk disablement, that isn't needed. No other functional change. v3: Reduce the overly ambitious scope of the MAX_PTRS change. Document more things, including around why some of the restrictions apply. Clean up the code more, thanks Christophe. v2: The big change is the introduction of tree-wide(ish) MAX_PTRS_PER_{PTE,PMD,PUD} macros in preference to the previous approach, which was for the arch to override the page table array definitions with their own. (And I squashed the annoying intermittent crash!) Apart from that there's just a lot of cleanup. Christophe, I've addressed most of what you asked for and I will reply to your v1 emails to clarify what remains unchanged.