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=-1.1 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_PASS, URIBL_BLOCKED autolearn=ham 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 0E3EDC4151A for ; Tue, 12 Feb 2019 01:08:47 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id C615D217FA for ; Tue, 12 Feb 2019 01:08:46 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=axtens.net header.i=@axtens.net header.b="jtkrfv5h" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727919AbfBLBIp (ORCPT ); Mon, 11 Feb 2019 20:08:45 -0500 Received: from mail-pg1-f194.google.com ([209.85.215.194]:43865 "EHLO mail-pg1-f194.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727178AbfBLBIo (ORCPT ); Mon, 11 Feb 2019 20:08:44 -0500 Received: by mail-pg1-f194.google.com with SMTP id v28so393352pgk.10 for ; Mon, 11 Feb 2019 17:08:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=axtens.net; s=google; h=from:to:cc:subject:in-reply-to:references:date:message-id :mime-version:content-transfer-encoding; bh=WfZyIsccqWR3lZErvejq0nP1VhlSzDJCMVE8xMZxBo4=; b=jtkrfv5h0Z5ESOjhOeJ+kwO2Ti2RhZaG9kOTT32sBA33x6st698ZR104Kzny8NB9Gg 8BBn24As3ax0MfwHfqh03vMdOsNkun4gA5eQAn+8U0jrslgVwBGMd/XTec5AbF37LhYW YoRYcglS/a37IsHlilhe4vSt8Gq0twliHzroY= 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:in-reply-to:references:date :message-id:mime-version:content-transfer-encoding; bh=WfZyIsccqWR3lZErvejq0nP1VhlSzDJCMVE8xMZxBo4=; b=Yh8hLMnoy9B092jR9WmurZNdUys7nNlRkNQditzbzG8k1YgDqDEuKAV1w47zwbTd0c Hwcc65iZvXarcCajjpmITQQ7E7mInuCp0VekLFK5NpqV+L4V8c0tWN6GFwemkxzLTZeN HFO56WSDRsUJupMSXMG9O0fxwFjBJjw242IQFPOeXcAoDlJeOvSx6HL2Zi0x/zrNxi5q XYFIKAyHl+ih5yQTqYHQgYrAOeWRec3iI/8EE/JlUKm1t7Bigp/cMuEyTl3tTJrwTrjM qG0A4yQmAoykmH1AmuHelucyJUJoO1PuIOv6AaUzCsOUJE997GKjPSxQ+jh8V/P+153l wyNA== X-Gm-Message-State: AHQUAuabQ/cJLevV6vVmx5VXiS358s0u81aN8uYZpSRWhqMqvXfC0ns0 0rWb0cx8hhQ2hNbGyFiGpY7Haw== X-Google-Smtp-Source: AHgI3IYwyw2dUTqU1GUA+O3qTH7XPl2tZBiWgJCD013uPJgIBjqRK0tLqD7dhhCkrMJ3SKiUfeDYFw== X-Received: by 2002:a62:ca03:: with SMTP id n3mr1216531pfg.241.1549933723290; Mon, 11 Feb 2019 17:08:43 -0800 (PST) Received: from localhost (124-171-97-196.dyn.iinet.net.au. [124.171.97.196]) by smtp.gmail.com with ESMTPSA id o126sm7732968pfb.126.2019.02.11.17.08.41 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Mon, 11 Feb 2019 17:08:42 -0800 (PST) From: Daniel Axtens To: Andrey Ryabinin , Andrey Konovalov , christophe leroy Cc: Benjamin Herrenschmidt , Paul Mackerras , Michael Ellerman , Nicholas Piggin , "Aneesh Kumar K.V" , Alexander Potapenko , Dmitry Vyukov , Linux Memory Management List , PowerPC , LKML , kasan-dev Subject: Re: [PATCH v4 3/3] powerpc/32: Add KASAN support In-Reply-To: <805fbf9d-a10f-03e0-aa52-6f6bd16059b9@virtuozzo.com> References: <1f5629e03181d0e30efc603f00dad78912991a45.1548166824.git.christophe.leroy@c-s.fr> <87ef8i45km.fsf@dja-thinkpad.axtens.net> <69720148-fd19-0810-5a1d-96c45e2ec00c@c-s.fr> <805fbf9d-a10f-03e0-aa52-6f6bd16059b9@virtuozzo.com> Date: Tue, 12 Feb 2019 12:08:36 +1100 Message-ID: <87imxpak4r.fsf@linkitivity.dja.id.au> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Andrey Ryabinin writes: > On 2/11/19 3:25 PM, Andrey Konovalov wrote: >> On Sat, Feb 9, 2019 at 12:55 PM christophe leroy >> wrote: >>> >>> Hi Andrey, >>> >>> Le 08/02/2019 =C3=A0 18:40, Andrey Konovalov a =C3=A9crit : >>>> On Fri, Feb 8, 2019 at 6:17 PM Christophe Leroy wrote: >>>>> >>>>> Hi Daniel, >>>>> >>>>> Le 08/02/2019 =C3=A0 17:18, Daniel Axtens a =C3=A9crit : >>>>>> Hi Christophe, >>>>>> >>>>>> I've been attempting to port this to 64-bit Book3e nohash (e6500), >>>>>> although I think I've ended up with an approach more similar to Anee= sh's >>>>>> much earlier (2015) series for book3s. >>>>>> >>>>>> Part of this is just due to the changes between 32 and 64 bits - we = need >>>>>> to hack around the discontiguous mappings - but one thing that I'm >>>>>> particularly puzzled by is what the kasan_early_init is supposed to = do. >>>>> >>>>> It should be a problem as my patch uses a 'for_each_memblock(memory, >>>>> reg)' loop. >>>>> >>>>>> >>>>>>> +void __init kasan_early_init(void) >>>>>>> +{ >>>>>>> + unsigned long addr =3D KASAN_SHADOW_START; >>>>>>> + unsigned long end =3D KASAN_SHADOW_END; >>>>>>> + unsigned long next; >>>>>>> + pmd_t *pmd =3D pmd_offset(pud_offset(pgd_offset_k(addr), addr)= , addr); >>>>>>> + int i; >>>>>>> + phys_addr_t pa =3D __pa(kasan_early_shadow_page); >>>>>>> + >>>>>>> + BUILD_BUG_ON(KASAN_SHADOW_START & ~PGDIR_MASK); >>>>>>> + >>>>>>> + if (early_mmu_has_feature(MMU_FTR_HPTE_TABLE)) >>>>>>> + panic("KASAN not supported with Hash MMU\n"); >>>>>>> + >>>>>>> + for (i =3D 0; i < PTRS_PER_PTE; i++) >>>>>>> + __set_pte_at(&init_mm, (unsigned long)kasan_early_shad= ow_page, >>>>>>> + kasan_early_shadow_pte + i, >>>>>>> + pfn_pte(PHYS_PFN(pa), PAGE_KERNEL_RO), 0); >>>>>>> + >>>>>>> + do { >>>>>>> + next =3D pgd_addr_end(addr, end); >>>>>>> + pmd_populate_kernel(&init_mm, pmd, kasan_early_shadow_= pte); >>>>>>> + } while (pmd++, addr =3D next, addr !=3D end); >>>>>>> +} >>>>>> >>>>>> As far as I can tell it's mapping the early shadow page, read-only, = over >>>>>> the KASAN_SHADOW_START->KASAN_SHADOW_END range, and it's using the e= arly >>>>>> shadow PTE array from the generic code. >>>>>> >>>>>> I haven't been able to find an answer to why this is in the docs, so= I >>>>>> was wondering if you or anyone else could explain the early part of >>>>>> kasan init a bit better. >>>>> >>>>> See https://www.kernel.org/doc/html/latest/dev-tools/kasan.html for an >>>>> explanation of the shadow. >>>>> >>>>> When shadow is 0, it means the memory area is entirely accessible. >>>>> >>>>> It is necessary to setup a shadow area as soon as possible because all >>>>> data accesses check the shadow area, from the begining (except for a = few >>>>> files where sanitizing has been disabled in Makefiles). >>>>> >>>>> Until the real shadow area is set, all access are granted thanks to t= he >>>>> zero shadow area beeing for of zeros. >>>> >>>> Not entirely correct. kasan_early_init() indeed maps the whole shadow >>>> memory range to the same kasan_early_shadow_page. However as kernel >>>> loads and memory gets allocated this shadow page gets rewritten with >>>> non-zero values by different KASAN allocator hooks. Since these values >>>> come from completely different parts of the kernel, but all land on >>>> the same page, kasan_early_shadow_page's content can be considered >>>> garbage. When KASAN checks memory accesses for validity it detects >>>> these garbage shadow values, but doesn't print any reports, as the >>>> reporting routine bails out on the current->kasan_depth check (which >>>> has the value of 1 initially). Only after kasan_init() completes, when >>>> the proper shadow memory is mapped, current->kasan_depth gets set to 0 >>>> and we start reporting bad accesses. >>> >>> That's surprising, because in the early phase I map the shadow area >>> read-only, so I do not expect it to get modified unless RO protection is >>> failing for some reason. >>=20 >> Actually it might be that the allocator hooks don't modify shadow at >> this point, as the allocator is not yet initialized. However stack >> should be getting poisoned and unpoisoned from the very start. But the >> generic statement that early shadow gets dirtied should be correct. >> Might it be that you don't use stack instrumentation? >>=20 > > Yes, stack instrumentation is not used here, because shadow offset which = we pass to > the -fasan-shadow-offset=3D cflag is not specified here. So the logic in = scrpits/Makefile.kasan > just fallbacks to CFLAGS_KASAN_MINIMAL, which is outline and without stac= k instrumentation. > > Christophe, you can specify KASAN_SHADOW_OFFSET either in Kconfig (e.g. x= 86_64) or > in Makefile (e.g. arm64). And make early mapping writable, because compil= er generated code will write > to shadow memory in function prologue/epilogue. Hmm. Is this limitation just that compilers have not implemented out-of-line support for stack instrumentation, or is there a deeper reason that stack/global instrumentation relies upon inline instrumentation? I ask because it's very common on ppc64 to have the virtual address space split up into discontiguous blocks. I know this means we lose inline instrumentation, but I didn't realise we'd also lose stack and global instrumentation... I wonder if it would be worth, in the distant future, trying to implement a smarter scheme in compilers where we could insert more complex inline mapping schemes. Regards, Daniel