Received: by 2002:ac0:946b:0:0:0:0:0 with SMTP id j40csp3251439imj; Mon, 11 Feb 2019 17:09:07 -0800 (PST) X-Google-Smtp-Source: AHgI3IaJVikF6GKytArQ4YaGQ9Xgn8o8qoweuXi5mw4IUm6/xwk1L8ezOKEtN+S0559J5Wmq/t7S X-Received: by 2002:a63:1063:: with SMTP id 35mr1108287pgq.133.1549933747298; Mon, 11 Feb 2019 17:09:07 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1549933747; cv=none; d=google.com; s=arc-20160816; b=s5uxkOdrTi6mbHpAqUilcP1FFQF0gtGwssGSjBXWuokvtG3/94mdn5QLi02ZNFr9Q2 NkoE4po3yQNdOhl8Um57J8oJSlsa4UJecZgIL+ndS/CgXD01OeSb8hU5PpGj1O4jLnMy hPCbS5EfTN4A0M796ljTki2rzqk6gXMJAHo9faStjIF/BBfruTIMiWPBTT8BVLPhzKLB XszwXxL8+KX+3AbgV5knJgSE6XbD2jDVE6IRo6Jc/VAlTL0jgnOMNzMcww/hVC9nGMlS aotm8oZrMfeGxVEvhYZw0RD79uSinc0HmU/UP951MhCfACSErbcgv59eDRU211Rkbblr WoFg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :message-id:date:references:in-reply-to:subject:cc:to:from :dkim-signature; bh=WfZyIsccqWR3lZErvejq0nP1VhlSzDJCMVE8xMZxBo4=; b=VzQvkxmqVyPZgFIc4R7ko2sN9Eyh9KJIlIcbqXAA4VyHJ4+IQRKfR/1ItnmqZzUoRS 2GdWY1Ton9YipTFY1h33QgMKrXAeKAoIpxQBdPzQiTfzJGZy8oPt+fo1qwmlCdJWwrqr xEV1OMsFJXe7FNQcOGB0x/UHWg4fAIn3VDMINy4SLjJajOv9DYxnZUrAP9bwcbLAB9Lt Jx5NFNxQfinFt9Qk3Ji4+E3yVCsOa4cW9BEV5QG/rfbFN5qyGXudyEljnCi7cF6LrWO3 Au4HFPh7V29mCMhg2vsEnOJ7zzO38OxDdntRFkg78NJpkCXjgQlma4zfNQYunKBzPSLw xu5A== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@axtens.net header.s=google header.b=jtkrfv5h; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id d14si339480pgi.158.2019.02.11.17.08.50; Mon, 11 Feb 2019 17:09:07 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@axtens.net header.s=google header.b=jtkrfv5h; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727903AbfBLBIp (ORCPT + 99 others); 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-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