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 Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id AABEEC433F5 for ; Mon, 30 May 2022 18:04:00 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id A974F6B0071; Mon, 30 May 2022 14:03:59 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id A1EF56B0072; Mon, 30 May 2022 14:03:59 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 908946B0073; Mon, 30 May 2022 14:03:59 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id 7F6696B0071 for ; Mon, 30 May 2022 14:03:59 -0400 (EDT) Received: from smtpin19.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay12.hostedemail.com (Postfix) with ESMTP id 591DC121158 for ; Mon, 30 May 2022 18:03:59 +0000 (UTC) X-FDA: 79523182998.19.1BFADBF Received: from mail-il1-f181.google.com (mail-il1-f181.google.com [209.85.166.181]) by imf29.hostedemail.com (Postfix) with ESMTP id 394ED12004A for ; Mon, 30 May 2022 18:03:46 +0000 (UTC) Received: by mail-il1-f181.google.com with SMTP id b11so8046516ilr.4 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=5xol/MpUdH12+rLbHJLI2SvuHLwYATcLAO4tiXanB1JBHk9ARJisi0EPy+cZAZ3umg nqOKGZfVfr836T07poD+1zT55hj0jIdgDrgxesXTqN8zrVgKXUIGMw1zETcfHEEQZyyQ Oa+4g9Pao69JOiZdpHBZ/Nb9cCpdhHD1hCWYGjfWlr7w+YmNiC4RGtVPIh+MzeL52SeB s+XOPPdWMBrCQhddqhTGq2KyotuLbFYFB+nu6SDxFAhM6uk5Cni/bQHCIwdCBoIOnqPC iQcttnW+HqOSgJh4jzYInA2wx/kToJvzOZqINitWmJBxYVCHgW7pQaKOODMhrxnzAazX bTwA== X-Gm-Message-State: AOAM531tx63zVwvgKT/Z8ro+Mw6vQwSvHuk2H7QgrTxzPKpU9iDGQeBt YFrhVDtGr/X2hZl5WXGnZU6+wt1IvUd3VA/rBg4= X-Google-Smtp-Source: ABdhPJxiqxPqwJuqTiFuZDkGTIRpFwwWIWMOfo3koX/mS67/Z2NFSGsiwTDAU3oePhaHTSWXzOV+eDNnRpinoTkJYk8= 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-Stat-Signature: m5e4t9xwj9njh5hp8z475gtr53uhhhrq X-Rspam-User: Authentication-Results: imf29.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=GTWyyPNR; spf=pass (imf29.hostedemail.com: domain of andreyknvl@gmail.com designates 209.85.166.181 as permitted sender) smtp.mailfrom=andreyknvl@gmail.com; dmarc=pass (policy=none) header.from=gmail.com X-Rspamd-Server: rspam10 X-Rspamd-Queue-Id: 394ED12004A X-HE-Tag: 1653933826-271106 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: 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!