Received: by 2002:a05:6a10:5bc5:0:0:0:0 with SMTP id os5csp692973pxb; Wed, 27 Oct 2021 10:30:39 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzpVJsBXEDdXXhxe4qoGEHXZ5dHAf6euSwqdaVflmzYT1YpTRwFIjIjNAunKY9R7pXD+6Fd X-Received: by 2002:a50:e006:: with SMTP id e6mr2766223edl.344.1635355838777; Wed, 27 Oct 2021 10:30:38 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1635355838; cv=none; d=google.com; s=arc-20160816; b=VG8fbIq/jFDRCDzCUJMh7it2HwSyP/Zdt6jFjSwawb07p8YLNsgKlPvKDphhQwS85Z kqQmep7CgMcZNCJZlascWd4cnUpdMtE9ueoLzAxnJLcqzGGSnROZ8KnhIyAU1Rr6ra6T IpHXh9Pn4RGyCooRryCkCxfE3nDuLAtAW0ifj7tk9mgJRNm1yNZovg3Yfh3soWAveVpf YlASZo6nVYHcCj6hIYThs9Cw3tcNgjaUEO6662HTDDAgGi5KRQ1vpl8yWHP7WU7/GQBU tncApiECvg7vZq/WSNfDL0YLLHrTK7v+JXoZK0IAOtzr9l8t/bVUiNJm6/3Kwf+Hij1I 875A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from :dkim-signature; bh=LTVtpyKftoE0IH0g/BXOTfVkolo16F3nizMPYgvUIg8=; b=JNVCmuGdQrQbJvHpNq/i4tpxbm1Pao4AT1sme/GtBkJz2Q+1j3eaNxmjnDkMt90S1a oDhdspUWovQ0GM/seg3DaY80yn67lknhxCvsmqZiswHdnt/DOSf7OlUdA5wBDSSF/4mt ZWPSRe4TEtnUnh3m2R9SQWHLPpWJlfNJlLJglTJybBkcuJJ044rXglOWrG5Oz8hfkh9P hvu6hO8aGmcfYQwkxHKZSAyBvX9rjPO2jWaiPogDXH3VQj1bZp63HImjJAo10ovUVvLI 27a8LCXoaqhwDwQOKFud3NRXbKVld5T8eSrQmUCappmcg13woZLEBD/82SqlcaUpF+DY HKBA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@canonical.com header.s=20210705 header.b=c1yrvb6R; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=canonical.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id f26si476645edr.613.2021.10.27.10.30.02; Wed, 27 Oct 2021 10:30:38 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@canonical.com header.s=20210705 header.b=c1yrvb6R; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=canonical.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S238002AbhJ0FCQ (ORCPT + 99 others); Wed, 27 Oct 2021 01:02:16 -0400 Received: from smtp-relay-internal-1.canonical.com ([185.125.188.123]:33060 "EHLO smtp-relay-internal-1.canonical.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230349AbhJ0FCO (ORCPT ); Wed, 27 Oct 2021 01:02:14 -0400 Received: from mail-wr1-f69.google.com (mail-wr1-f69.google.com [209.85.221.69]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by smtp-relay-internal-1.canonical.com (Postfix) with ESMTPS id 1FB6C40277 for ; Wed, 27 Oct 2021 04:59:49 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=canonical.com; s=20210705; t=1635310789; bh=LTVtpyKftoE0IH0g/BXOTfVkolo16F3nizMPYgvUIg8=; h=From:To:Cc:Subject:Date:Message-Id:In-Reply-To:References: MIME-Version; b=c1yrvb6RM5aoDZ7D5pEMLP2ieBb2cD0sHvRMkAiXJGIzQAm3xDgdaNUAvgyNsKSEm eYo9XDtPGsV+g8xB5RFyCkYkuOgAOVvPyPJM+Y+hKl3O1Tx2oa982/qwvoReEtd4pR sPBbxycUgUHN9AGe1H5vuVTbrk735Q1ekWwRTA/0TJdMv3kOKF4V0vQR3J5wbf3IAq Vyhkugrijtk1LRwF+lSut6SleKQrFiSC4eFtDVMZhveDfakGz1u7MaacxIIYlps0Vu h8ETJLhKVnFr2+z1D/R3XWKvZL7oR18uegrFNYETIySQlG6YZLx0gJB/1fTGmUuar8 kHUwLqV761OsQ== Received: by mail-wr1-f69.google.com with SMTP id d13-20020adf9b8d000000b00160a94c235aso258517wrc.2 for ; Tue, 26 Oct 2021 21:59:49 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=LTVtpyKftoE0IH0g/BXOTfVkolo16F3nizMPYgvUIg8=; b=oyf3unfRGMrP+QhmRlcCXFGKUYf/1jU8SbWngF9MUDBrYAWIyUW1iH+XVt/RnWlemP 1Le9c4I/hYGzTY6s88T2gWxfbf6cFpszRItcegWRPvwADJ/qTiiZdVjVoeTOAC12hhpt m+RJ70k+yjc4OLjbJWvIqxKl2cwnYVrUWzpHvi3Ap1K2v0KSlDnKOF+2S7wX/kDaJT2D g4cDhUpPwhR4Ok1+Je/Y83kygGQl/8VXzGXOD4OqYxjO8yj3xfZvdufjMmA0ZBUcKkZ4 SH/9VQ674I5T3UNiTxNfQe2vpVErUR7pHMxQt8z+AQjqROhn9OCLvkWSvrVp1J65ytB1 GuhQ== X-Gm-Message-State: AOAM5339F4jMHS8yNx7jTZc4qPmoBxXfVpsib7w1z98xpteGHjM1ytTG ma3bsqubKIm+oXY+OfoImQf2Zn5k3IN+lwioaq64g4VR4EBQSSTjVpqPXmPGoIy9EuaFen0TWTL aHD14TSvMGGjZtu13rFmSvljOVuatn30HQTFBNZcfRw== X-Received: by 2002:a7b:ce93:: with SMTP id q19mr3460074wmj.98.1635310788755; Tue, 26 Oct 2021 21:59:48 -0700 (PDT) X-Received: by 2002:a7b:ce93:: with SMTP id q19mr3460062wmj.98.1635310788623; Tue, 26 Oct 2021 21:59:48 -0700 (PDT) Received: from alex.home (lfbn-lyo-1-470-249.w2-7.abo.wanadoo.fr. [2.7.60.249]) by smtp.gmail.com with ESMTPSA id c15sm20432877wrs.19.2021.10.26.21.59.48 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 26 Oct 2021 21:59:48 -0700 (PDT) From: Alexandre Ghiti To: Paul Walmsley , Palmer Dabbelt , Albert Ou , Andrey Ryabinin , Alexander Potapenko , Andrey Konovalov , Dmitry Vyukov , linux-riscv@lists.infradead.org, linux-kernel@vger.kernel.org, kasan-dev@googlegroups.com Cc: Alexandre Ghiti Subject: [PATCH 2/2] riscv: Fix CONFIG_KASAN_STACK build Date: Wed, 27 Oct 2021 06:58:43 +0200 Message-Id: <20211027045843.1770770-2-alexandre.ghiti@canonical.com> X-Mailer: git-send-email 2.30.2 In-Reply-To: <20211027045843.1770770-1-alexandre.ghiti@canonical.com> References: <20211027045843.1770770-1-alexandre.ghiti@canonical.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Now that CONFIG_KASAN_SHADOW_OFFSET is correctly defined, the boot hung while populating the shadow memory right after the call to kasan_populate_early_shadow: when calling this function, all the shadow memory is already populated with kasan_early_shadow_pte which has PAGE_KERNEL protection. kasan_populate_early_shadow write-protects the mapping of the range of addresses passed in argument in zero_pte_populate, which actually write-protects all the shadow memory mapping since kasan_early_shadow_pte is used for all the shadow memory at this point. And then when using memblock API to populate the shadow memory, the first write access to the kernel stack triggers a trap. We already manually populate all the shadow memory in kasan_early_init and we write-protect kasan_early_shadow_pte at the end of kasan_init which makes the call to kasan_populate_early_shadow superfluous so we can remove it. Signed-off-by: Alexandre Ghiti --- arch/riscv/mm/kasan_init.c | 7 ------- 1 file changed, 7 deletions(-) diff --git a/arch/riscv/mm/kasan_init.c b/arch/riscv/mm/kasan_init.c index 8175e98b9073..8df937902630 100644 --- a/arch/riscv/mm/kasan_init.c +++ b/arch/riscv/mm/kasan_init.c @@ -175,13 +175,6 @@ void __init kasan_init(void) phys_addr_t p_start, p_end; u64 i; - /* - * Populate all kernel virtual address space with kasan_early_shadow_page - * except for the linear mapping and the modules/kernel/BPF mapping. - */ - kasan_populate_early_shadow((void *)KASAN_SHADOW_START, - (void *)kasan_mem_to_shadow((void *) - VMEMMAP_END)); if (IS_ENABLED(CONFIG_KASAN_VMALLOC)) kasan_shallow_populate( (void *)kasan_mem_to_shadow((void *)VMALLOC_START), -- 2.30.2