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=-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 DECC4C433E0 for ; Wed, 3 Feb 2021 11:59:57 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 4544A64F6A for ; Wed, 3 Feb 2021 11:59:57 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 4544A64F6A 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 87E6A6B0071; Wed, 3 Feb 2021 06:59:56 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 857676B0072; Wed, 3 Feb 2021 06:59:56 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 794856B0073; Wed, 3 Feb 2021 06:59:56 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0007.hostedemail.com [216.40.44.7]) by kanga.kvack.org (Postfix) with ESMTP id 64FA46B0071 for ; Wed, 3 Feb 2021 06:59:56 -0500 (EST) Received: from smtpin19.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id 2535B3635 for ; Wed, 3 Feb 2021 11:59:56 +0000 (UTC) X-FDA: 77776812792.19.car00_5d0aaae275d3 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin19.hostedemail.com (Postfix) with ESMTP id F34681AD1B0 for ; Wed, 3 Feb 2021 11:59:55 +0000 (UTC) X-HE-Tag: car00_5d0aaae275d3 X-Filterd-Recvd-Size: 4952 Received: from mail-pf1-f182.google.com (mail-pf1-f182.google.com [209.85.210.182]) by imf07.hostedemail.com (Postfix) with ESMTP for ; Wed, 3 Feb 2021 11:59:55 +0000 (UTC) Received: by mail-pf1-f182.google.com with SMTP id y205so16499065pfc.5 for ; Wed, 03 Feb 2021 03:59:55 -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=4uA7JS93JPw+++xZutM775VMPEwshLnvxHWwIlWPugU=; b=d2+USt6GcAhvlOc8tGw3hsChBNWfxsSnLznhf7fC6VHAyqS/x37U9wf21RzuKaqpEc Gu0rihcnDrxrnxt7uXUJl7jBPFQtpBns9Hw96l3h5hWQzQWSyLODxP1tOdU1uv+uslnQ P5cHSHV0uzntCFocPks3q0MkcoC4SwzEGPyBo= 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=4uA7JS93JPw+++xZutM775VMPEwshLnvxHWwIlWPugU=; b=iHs87lEJm9ZzVowLQq3IXqscD3cNSnQVfvvpo00ZsiowgmZz5ExHf73PtRfBZ7Hg3s PSQzevIeEUXYmNBOm65deBFeNWp671bGXR8HZj7TarKc8Wc5fWDSat4kPUeOR7QOzo9O Ruki/xKvc+NYqPZHxsJEpZTw46UrVPimr0ZpJeNQtJAN5VCIKzkOyyZHUFZ+Iqn5zp1W ZTJrwN1j/JmlXv+kl1CvNLUwK6gJwDO49woc3773tRICN+oCtVF/aYzt77l65T5XIidj RtCL4N8pw0eRK7uaRyGPZ0QqH3cBApMc+6u9E2rRLJN81Bibc9xHHKz4PgJe5+Fxcaqe 7X+Q== X-Gm-Message-State: AOAM532JH01T3m9wziR2yC2/5NYP3YVz7L9rxHmuxb6YHJIhnQEzw0hB cI7ako9gzHAF08vFbJ4HSMGSow== X-Google-Smtp-Source: ABdhPJytDZ4HM1r1NSCsMK44ojj+trhGOJ6I1kDuMv1LN3tUVACngwIVni/g2RNcS/9H77+1iU6anA== X-Received: by 2002:a63:ca51:: with SMTP id o17mr3244885pgi.314.1612353594659; Wed, 03 Feb 2021 03:59:54 -0800 (PST) Received: from localhost (2001-44b8-1113-6700-1c59-4eca-f876-fd51.static.ipv6.internode.on.net. [2001:44b8:1113:6700:1c59:4eca:f876:fd51]) by smtp.gmail.com with ESMTPSA id h190sm2196512pfe.158.2021.02.03.03.59.53 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 03 Feb 2021 03:59:54 -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@csgroup.eu, aneesh.kumar@linux.ibm.com, bsingharora@gmail.com Cc: Daniel Axtens Subject: [PATCH v10 0/6] KASAN for powerpc64 radix Date: Wed, 3 Feb 2021 22:59:40 +1100 Message-Id: <20210203115946.663273-1-dja@axtens.net> X-Mailer: git-send-email 2.27.0 MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable 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. 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. It does not apply to powerpc/next, sorry: there are conflicting kasan changes staged in next. 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 r= un 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 a= nd by excluding larger quantites of arch code from instrumentation. The upsi= de 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 thi= s 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, thin= gs will go boom. Kind regards, Daniel