Received: by 2002:a05:6602:18e:0:0:0:0 with SMTP id m14csp5696540ioo; Wed, 1 Jun 2022 10:33:16 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwzycMJTwtNPaNX0efu2yueUW1py43gdlCwXeM5VIpGUB/Qwby0o/XWPnmbvewtFsXCJ0AH X-Received: by 2002:a05:6a00:1707:b0:51b:bc58:193f with SMTP id h7-20020a056a00170700b0051bbc58193fmr634677pfc.52.1654104796636; Wed, 01 Jun 2022 10:33:16 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1654104796; cv=none; d=google.com; s=arc-20160816; b=BUfhAvDg37jhYTYNh7EV+CwxRwXHbBzZkbfEwFrkcxrsANgHj3qinGmSIsxFsMFKPG KVdnY/EEG6G87S/VO+/gcLqyt9rsAJq8qMxTlmePhlstFQL0OJhDOEqRZJYWd9onvPOc 6/M6YaLwU01iqrh3rS3JV21ASP39ld2Wc5VXJZ5r4FSvoCPhyQd6HpUzeC2G9ZSy69dU 7HuC95mkOV5Ml2pciJctYYxcq/vR/piprL4C05CrHXJSubBqwtyRVrAbNhuFNbaTdNRz 2U3GbXbJUkCM2bDXE/PZnVECW5oMB0AMwaG+PWD7ar3BT0XOBGhbYkZmEmRv/5gcAuo2 hIvQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=1ZeR0nN/1eFyuWwXvp0L7EiUsdKyoUpqzB7kyH/D/WM=; b=VxbRYiaS+FxcUWwRJQ/YJhcnRSPiCHVa93cufeICehFL9ide6GCfLdgSUlKlSHjG4N imw6ASc+LomzO+WYA5TK7rfrlqjAQPuRYVbRdhWydU2NeYuMI/LWcEAthHehQAmk3sSl VxvTYH+mHIHYAx+ciaUkXHFgNply3DQ6hTWb20rfkWg++j1u22Gk6etS5BiY/js+845i TTlhgbnhn/69VJ7medbZKs4jfg1aqf/DZvQNSuhKvR8krXzn8CtwGlviaGlhSaZUx1aS IE2kVRVyK0kQCeKiuP7HEMoNx+g72kTZrLNsu0DH44ohuoS0iSVLLXEAfLj3euPoDoe2 WRrA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20210112 header.b=GTWyyPNR; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id ng17-20020a17090b1a9100b001df621048f4si9439720pjb.10.2022.06.01.10.33.00; Wed, 01 Jun 2022 10:33:16 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20210112 header.b=GTWyyPNR; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S240255AbiE3SED (ORCPT + 99 others); Mon, 30 May 2022 14:04:03 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:35008 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S237939AbiE3SEA (ORCPT ); Mon, 30 May 2022 14:04:00 -0400 Received: from mail-il1-x134.google.com (mail-il1-x134.google.com [IPv6:2607:f8b0:4864:20::134]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id ACE6EA206A for ; Mon, 30 May 2022 11:03:58 -0700 (PDT) Received: by mail-il1-x134.google.com with SMTP id f7so1565701ilr.5 for ; Mon, 30 May 2022 11:03:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=1ZeR0nN/1eFyuWwXvp0L7EiUsdKyoUpqzB7kyH/D/WM=; b=GTWyyPNRACEttMtFjSJ8gUXIGRBmUXZBKEwGpHWqYbIHSfqlUiXqSzBt+r5ZE3DmjF AUV2Em9x+IZRGz4QfdnIc1mS7RwLGT8ZMTYS5JBM1oDAZx1BKBCSekGFONRhU+w/qUOo DWyUbkGNTcx8E/ASF0dmHm9B1CbjYIW99zv/TFXbZzv5LkCdfaaCIiTmT/Zo0fb5QDXw /FU7HR0av4bMFFJ5xR1yA2v91frTUAxaS2pWVoWv7SE1BKdxx5jQ32HzihvT6ZI4I1qi v2m0PzCHg12pUVrR5/Qh92oO7Ck/kW+eUVU0ZbgbVA0XIzsNXQzCl1Tg5SVAPuLaMG09 nUpw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=1ZeR0nN/1eFyuWwXvp0L7EiUsdKyoUpqzB7kyH/D/WM=; b=pab4aliOXWFW6kWLnYLaxllXLPtiUm/nxDPyaEImrNCazJGZFwi5O7BqmXNiF2nxbL 7jtK2XY+Prlz47vTKDroEiznlg2VmLOifDoUXO8HC//KQOqlU/lQgDv8oqcdJxUN05jg mFcsQWNspuFfEUduJKOqbWVbWB+KSmtwPIGBbDyZ1C0Tm70za5u3KuL7j0QDEUjcA0Wp QPx9+DrMBCJu6Cs1WLiQ5Bvohn95EVfpi5DyN+4tlpkR6rfG5cJPIOlb4NgTXdxg8fPu 6ndJzp5JbKc+l9EHzSSa/tLDsRYxDUiqqdnJg0ngO2C/vX5N+Ni9hoBggLE44FS1+aVN 6MRw== X-Gm-Message-State: AOAM530Tdo9sM3AgxxKvn8FApoBpfHPxyn+RjiHQ4YeiBXdrQfEeljQy KeDrGyoWmoTXeCJWgQ2QQK09b1r3GIGeia6Fwf4= X-Received: by 2002:a92:3609:0:b0:2c6:3595:2a25 with SMTP id d9-20020a923609000000b002c635952a25mr29189046ila.233.1653933838071; Mon, 30 May 2022 11:03:58 -0700 (PDT) MIME-Version: 1.0 References: <20220527185600.1236769-1-davidgow@google.com> <20220527185600.1236769-2-davidgow@google.com> In-Reply-To: <20220527185600.1236769-2-davidgow@google.com> From: Andrey Konovalov Date: Mon, 30 May 2022 20:03:47 +0200 Message-ID: Subject: Re: [PATCH v2 2/2] UML: add support for KASAN under x86_64 To: David Gow Cc: Vincent Whitchurch , Johannes Berg , Patricia Alfonso , Jeff Dike , Richard Weinberger , anton.ivanov@cambridgegreys.com, Dmitry Vyukov , Brendan Higgins , Andrew Morton , Andrey Ryabinin , kasan-dev , linux-um@lists.infradead.org, LKML , Daniel Latypov , Linux Memory Management List Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM, RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, May 27, 2022 at 8:56 PM David Gow wrote: > > From: Patricia Alfonso > > Make KASAN run on User Mode Linux on x86_64. > > The UML-specific KASAN initializer uses mmap to map the roughly 2.25TB > of shadow memory to the location defined by KASAN_SHADOW_OFFSET. > kasan_init() utilizes constructors to initialize KASAN before main(). > > The location of the KASAN shadow memory, starting at > KASAN_SHADOW_OFFSET, can be configured using the KASAN_SHADOW_OFFSET > option. UML uses roughly 18TB of address space, and KASAN requires 1/8th > of this. The default location of this offset is 0x100000000000, which > keeps it out-of-the-way even on UML setups with more "physical" memory. > > For low-memory setups, 0x7fff8000 can be used instead, which fits in an > immediate and is therefore faster, as suggested by Dmitry Vyukov. There > is usually enough free space at this location; however, it is a config > option so that it can be easily changed if needed. > > Note that, unlike KASAN on other architectures, vmalloc allocations > still use the shadow memory allocated upfront, rather than allocating > and free-ing it per-vmalloc allocation. > > Also note that, while UML supports both KASAN in inline mode > (CONFIG_KASAN_INLINE) and static linking (CONFIG_STATIC_LINK), it does > not support both at the same time. > > Signed-off-by: Patricia Alfonso > Co-developed-by: Vincent Whitchurch > Signed-off-by: Vincent Whitchurch > Signed-off-by: David Gow Hi David, Thanks for working on this! > diff --git a/mm/kasan/shadow.c b/mm/kasan/shadow.c > index a4f07de21771..c993d99116f2 100644 > --- a/mm/kasan/shadow.c > +++ b/mm/kasan/shadow.c > @@ -295,9 +295,29 @@ int kasan_populate_vmalloc(unsigned long addr, unsigned long size) > return 0; > > shadow_start = (unsigned long)kasan_mem_to_shadow((void *)addr); > - shadow_start = ALIGN_DOWN(shadow_start, PAGE_SIZE); > shadow_end = (unsigned long)kasan_mem_to_shadow((void *)addr + size); > - shadow_end = ALIGN(shadow_end, PAGE_SIZE); > + > + /* > + * User Mode Linux maps enough shadow memory for all of physical memory > + * at boot, so doesn't need to allocate more on vmalloc, just clear it. Should this say "for all of _virtual_ memory"? Otherwise, this is confusing. All KASAN-enabled architectures map shadow for physical memory. And they still need map shadow for vmalloc() separately. This is what kasan_populate_vmalloc() is for. > + * > + * If another architecture chooses to go down the same path, we should > + * replace this check for CONFIG_UML with something more generic, such > + * as: > + * - A CONFIG_KASAN_NO_SHADOW_ALLOC option, which architectures could set > + * - or, a way of having architecture-specific versions of these vmalloc > + * and module shadow memory allocation options. I think this part above and the first sentence below belong to the commit changelog, not to a comment. > + * > + * For the time being, though, this check works. The remaining CONFIG_UML > + * checks in this file exist for the same reason. > + */ > + if (IS_ENABLED(CONFIG_UML)) { > + __memset((void *)shadow_start, KASAN_VMALLOC_INVALID, shadow_end - shadow_start); > + return 0; > + } > + > + shadow_start = PAGE_ALIGN_DOWN(shadow_start); > + shadow_end = PAGE_ALIGN(shadow_end); > > ret = apply_to_page_range(&init_mm, shadow_start, > shadow_end - shadow_start, > @@ -466,6 +486,10 @@ void kasan_release_vmalloc(unsigned long start, unsigned long end, > > if (shadow_end > shadow_start) { > size = shadow_end - shadow_start; > + if (IS_ENABLED(CONFIG_UML)) { > + __memset(shadow_start, KASAN_SHADOW_INIT, shadow_end - shadow_start); > + return; > + } > apply_to_existing_page_range(&init_mm, > (unsigned long)shadow_start, > size, kasan_depopulate_vmalloc_pte, > @@ -531,6 +555,11 @@ int kasan_alloc_module_shadow(void *addr, size_t size, gfp_t gfp_mask) > if (WARN_ON(!PAGE_ALIGNED(shadow_start))) > return -EINVAL; > > + if (IS_ENABLED(CONFIG_UML)) { > + __memset((void *)shadow_start, KASAN_SHADOW_INIT, shadow_size); > + return 0; > + } > + > ret = __vmalloc_node_range(shadow_size, 1, shadow_start, > shadow_start + shadow_size, > GFP_KERNEL, > @@ -554,6 +583,9 @@ int kasan_alloc_module_shadow(void *addr, size_t size, gfp_t gfp_mask) > > void kasan_free_module_shadow(const struct vm_struct *vm) > { > + if (IS_ENABLED(CONFIG_UML)) > + return; > + > if (vm->flags & VM_KASAN) > vfree(kasan_mem_to_shadow(vm->addr)); > } > -- > 2.36.1.124.g0e6072fb45-goog > Thanks!