From patchwork Fri Mar 19 14:40:52 2021 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Daniel Axtens X-Patchwork-Id: 12151195 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=-6.6 required=3.0 tests=BAYES_00,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 ECC43C433DB for ; Fri, 19 Mar 2021 14:41:09 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 8EDEA64F18 for ; Fri, 19 Mar 2021 14:41:09 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 8EDEA64F18 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 1A8F46B006E; Fri, 19 Mar 2021 10:41:09 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 1329A6B0070; Fri, 19 Mar 2021 10:41:09 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id EC76D6B0072; Fri, 19 Mar 2021 10:41:08 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0202.hostedemail.com [216.40.44.202]) by kanga.kvack.org (Postfix) with ESMTP id CCD936B006E for ; Fri, 19 Mar 2021 10:41:08 -0400 (EDT) Received: from smtpin14.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id 917961730845 for ; Fri, 19 Mar 2021 14:41:08 +0000 (UTC) X-FDA: 77936886216.14.D19F832 Received: from mail-pj1-f54.google.com (mail-pj1-f54.google.com [209.85.216.54]) by imf29.hostedemail.com (Postfix) with ESMTP id 9CA8CF9 for ; Fri, 19 Mar 2021 14:41:05 +0000 (UTC) Received: by mail-pj1-f54.google.com with SMTP id a22-20020a17090aa516b02900c1215e9b33so6817977pjq.5 for ; Fri, 19 Mar 2021 07:41:05 -0700 (PDT) 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=JMTZPdTE/aMUDIoULLEYEVVyeOj9JMcW8Ag8gkApcG8=; b=GYlAFBv2hVH9zVW7eDuOt74/YKU618uB0XcxKKzYydhK/xHH6uRUbGe/+odzkPTFKW hEszJNjv6g5hyao1Oqax0qywro1jPO+BgzYqshqU6Bem1v5HUynvd0jTgbEgvgUBrI1S 5BG6Uwvk0JFWd8hod3flUFu8OHPeXrqrC9pew= 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=JMTZPdTE/aMUDIoULLEYEVVyeOj9JMcW8Ag8gkApcG8=; b=E9oKkwsy7rIAsnzEqfV3D09acU8KHTDSjIyN4I0qUq/iulyCOABtPJ/6Y6O6+ZUByx 785w9XgkHyZ1Z7FB9EgQjkinubCe2prqDp9V3k9qLZJy6ZsL2RSoMlU0McWNOS0FCIBO hOL9dLHjqX7Shvrp439KKEyxuXCu8WtCVTptRwMES/5HJhsRR6oVIYe5E/9eAQhR6Mbf 620ZrYSZu8Qah66OfvxfILExudGYuG4+2w2GOkNUaRi1p2P456wR/PAJlgMnueSp65Lu K4rqkJRw7xaSc4YiurFTg/I0IfomkRC0qkBi5/pJiiHehKroKR1mVi2BZa8ACjH4Exhr 8ELg== X-Gm-Message-State: AOAM530jezZhn+4K8QVPzzZar+0D8tK6r7QjIQPLjK2Yah2ZelyG8LD+ nSgOGgq6xIRQNr2AYPYnmBM12g== X-Google-Smtp-Source: ABdhPJxlMSF9N8TsI+7JmybLd20c1cK01aJvUVhZRerB4UyQEjpJ8VtHIcBPF1ZR8qLARnh3lMogvw== X-Received: by 2002:a17:90a:516:: with SMTP id h22mr9634409pjh.222.1616164864070; Fri, 19 Mar 2021 07:41:04 -0700 (PDT) Received: from localhost (2001-44b8-111e-5c00-674e-5c6f-efc9-136d.static.ipv6.internode.on.net. [2001:44b8:111e:5c00:674e:5c6f:efc9:136d]) by smtp.gmail.com with ESMTPSA id l4sm5692224pgn.77.2021.03.19.07.41.03 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 19 Mar 2021 07:41:03 -0700 (PDT) From: Daniel Axtens To: linux-kernel@vger.kernel.org, linux-mm@kvack.org, linuxppc-dev@lists.ozlabs.org, kasan-dev@googlegroups.com, christophe.leroy@csgroup.eu, aneesh.kumar@linux.ibm.com, bsingharora@gmail.com Cc: Daniel Axtens Subject: [PATCH v11 0/6] KASAN for powerpc64 radix Date: Sat, 20 Mar 2021 01:40:52 +1100 Message-Id: <20210319144058.772525-1-dja@axtens.net> X-Mailer: git-send-email 2.27.0 MIME-Version: 1.0 X-Stat-Signature: bfw9khf6xmrjopcs5tbgmt9f5x6qywqm X-Rspamd-Server: rspam01 X-Rspamd-Queue-Id: 9CA8CF9 Received-SPF: none (axtens.net>: No applicable sender policy available) receiver=imf29; identity=mailfrom; envelope-from=""; helo=mail-pj1-f54.google.com; client-ip=209.85.216.54 X-HE-DKIM-Result: pass/pass X-HE-Tag: 1616164865-644100 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: Building on the work of Christophe, Aneesh and Balbir, I've ported KASAN to 64-bit Book3S kernels running on the Radix MMU. v11 applies to next-20210317. I had hoped to have it apply to powerpc/next but once again there are changes in the kasan core that clash. Also, thanks to mpe for fixing a build break with KASAN off. I'm not sure how best to progress this towards actually being merged when it has impacts across subsystems. I'd appreciate any input. Maybe the first four patches could go in via the kasan tree, that should make things easier for powerpc in a future cycle? v10 rebases on top of next-20210125, fixing things up to work on top of the latest changes, and fixing some review comments from Christophe. I have tested host and guest with 64k pages for this spin. There is now only 1 failing KUnit test: kasan_global_oob - 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.) (The previously failing stack tests are now skipped due to more accurate configuration settings.) Details from v9: This is a significant reworking of the previous versions. Instead of the previous approach which supported inline instrumentation, this series provides only outline instrumentation. To get around the problem of accessing the shadow region inside code we run with translations off (in 'real mode'), we we restrict checking to when translations are enabled. This is done via a new hook in the kasan core and by excluding larger quantites of arch code from instrumentation. The upside is that we no longer require that you be able to specify the amount of physically contiguous memory on the system at compile time. Hopefully this is a better trade-off. More details in patch 6. kexec works. Both 64k and 4k pages work. Running as a KVM host works, but nothing in arch/powerpc/kvm is instrumented. It's also potentially a bit fragile - if any real mode code paths call out to instrumented code, things will go boom. Kind regards, Daniel Daniel Axtens (6): kasan: allow an architecture to disable inline instrumentation kasan: allow architectures to provide an outline readiness check kasan: define and use MAX_PTRS_PER_* for early shadow tables kasan: Document support on 32-bit powerpc powerpc/mm/kasan: rename kasan_init_32.c to init_32.c powerpc: Book3S 64-bit outline-only KASAN support