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 B7D3EC43334 for ; Thu, 30 Jun 2022 08:12:00 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 5294C6B0072; Thu, 30 Jun 2022 04:12:00 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 5013F8E0002; Thu, 30 Jun 2022 04:12:00 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 3C6CA8E0001; Thu, 30 Jun 2022 04:12:00 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id 2E55F6B0072 for ; Thu, 30 Jun 2022 04:12:00 -0400 (EDT) Received: from smtpin28.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id EA2552149F for ; Thu, 30 Jun 2022 08:11:59 +0000 (UTC) X-FDA: 79634183958.28.BB5273F Received: from mail-wr1-f51.google.com (mail-wr1-f51.google.com [209.85.221.51]) by imf16.hostedemail.com (Postfix) with ESMTP id 76193180063 for ; Thu, 30 Jun 2022 08:11:59 +0000 (UTC) Received: by mail-wr1-f51.google.com with SMTP id i1so21552009wrb.11 for ; Thu, 30 Jun 2022 01:11:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=OOTtRji8xWxni9yaz7W2gJeXuoycpc5ucnabq09T1bI=; b=C/t7WScdZ/5eix0bLbi5ANYeY6fv//pLAEkNiNGTQlX2F/ffEsR+ecAoWsQRUZpi4j d4nJ9pk1zyOyBZAky3saX2ye0R26VCTrlfnfnfbBzbop0L1f8E+raQ9k09JLPunbMvS9 4msYhRwSFUWyBiH/XpkUcLHUQvqqBJXJ5ikK1WDRBW9Yu9FD4lPoFHFF3vb8hoTkhVDB M8NmmKi0v16q7gb8fffcAaZg6IVIzDbKzaEdkfn9or57m3HKOw2Lk/apcF/FqH2RVfcu IixbL3aooVwh7ngriV8dFFzhW5+DOvydORAtoqqkQks5g3WES+aw7SBaj2YKrW8+a4wu 7QNw== 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=OOTtRji8xWxni9yaz7W2gJeXuoycpc5ucnabq09T1bI=; b=1yI8N/4wLMrIEslgJ1RRoKZBsV3tdl3i7A5JvZhxRgBnsskuadniysI6Efsw0bsaL4 kX37sqN2uTM0/nCs5K7a45pMLvx2p2+7XQiXj3A/UFOUyQCA33nqtYLpgw4Qk17FNVsg T2tlXSOP3pJeEyIxcyeh3xZCNI08Ma4Y9bU1uS+27/L5whqv1A14U1enynYsCzmkG5IU QLX4cBrWAZ/TUdefujIiFygnmrxXbupOMJlWM1ItbAvg7cICwrCMAbJlUq+3mzotouPW 7OuZ9237M8DxUhWifxGz9HCbTIdz4leL17Uo0QaszvGLCcaiqTzZFtNHCqOnQdpMIoRK dk7w== X-Gm-Message-State: AJIora9zWIaVuFgwSQtzAIAAlIXF9UvW7sJUO5rNOvL25ygeeKUUgK2r 9BuFEd3FRfEi/10SAQKlOWLjQZeHhSKR2XGr7xkaUw== X-Google-Smtp-Source: AGRyM1sRbLewf4sxnz4dB3dN5YFnj/nq45OZFcL5LF+PbryGz/OIGzLay9e+M5ljvDXSGtGyYeW84pDmWiENzpMBuFI= X-Received: by 2002:a05:6000:1542:b0:21d:28c0:eb43 with SMTP id 2-20020a056000154200b0021d28c0eb43mr7083362wry.622.1656576718103; Thu, 30 Jun 2022 01:11:58 -0700 (PDT) MIME-Version: 1.0 References: <20220630074757.2739000-1-davidgow@google.com> <20220630074757.2739000-2-davidgow@google.com> In-Reply-To: <20220630074757.2739000-2-davidgow@google.com> From: David Gow Date: Thu, 30 Jun 2022 16:11:46 +0800 Message-ID: Subject: Re: [PATCH v3 2/2] UML: add support for KASAN under x86_64 To: Vincent Whitchurch , Johannes Berg , Patricia Alfonso , Jeff Dike , Richard Weinberger , Anton Ivanov , Dmitry Vyukov , Brendan Higgins , Andrew Morton , Andrey Konovalov , Andrey Ryabinin Cc: kasan-dev , linux-um , LKML , Daniel Latypov , Linux Memory Management List , KUnit Development Content-Type: text/plain; charset="UTF-8" ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1656576719; a=rsa-sha256; cv=none; b=HdSVyT4k8cARnlaObjFt5tT1jRe1GI8oXEsldCyEWlOlTqCSdkMDgxsvw6DZodoSM/TSvu MSzFVXQAox3ZOQ37QclL6bvGaNTgBngxRJgczlitRgUwpVNH7bVGgDou4JbWLfzoPloe0N uYMWAGi1OF6ZDgg8lns7ruArVhX4UkU= ARC-Authentication-Results: i=1; imf16.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b="C/t7WScd"; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf16.hostedemail.com: domain of davidgow@google.com designates 209.85.221.51 as permitted sender) smtp.mailfrom=davidgow@google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1656576719; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=OOTtRji8xWxni9yaz7W2gJeXuoycpc5ucnabq09T1bI=; b=siLHaN98NcynDsj8fIioFPhdVvhqhavqoWoseJ5LY6VFAi8guXDzJ5atfyCKSvkCEdEFeA NcBIuo2I3wg/zHyp6r5FTfBCxotdI5L32gTSAifg0nbmRI5xKvBrwX6Tw417yFGblk2Tq5 tka5Fx7+XdqrqxHee2lye7tO+6NwMwY= Authentication-Results: imf16.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b="C/t7WScd"; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf16.hostedemail.com: domain of davidgow@google.com designates 209.85.221.51 as permitted sender) smtp.mailfrom=davidgow@google.com X-Rspamd-Server: rspam10 X-Rspamd-Queue-Id: 76193180063 X-Stat-Signature: 6qk87bye86f3u85uygpb6ypthna85mo5 X-Rspam-User: X-HE-Tag: 1656576719-223859 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 Thu, Jun 30, 2022 at 3:48 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 ~16TB 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. 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. > > If another architecture chooses to go down the same path, we should > replace the checks 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. > > 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 > Reviewed-by: Johannes Berg > --- > This is v3 of the KASAN/UML port. It should be ready to go. > > Note that this will fail to build if UML is linked statically due to: > https://lore.kernel.org/all/20220526185402.955870-1-davidgow@google.com/ > > > Changes since v2: > https://lore.kernel.org/lkml/20220527185600.1236769-2-davidgow@google.com/ > - Don't define CONFIG_KASAN in USER_CFLAGS, given we dont' use it. > (Thanks Johannes) > - Update patch descriptions and comments given we allocate shadow memory based > on the size of the virtual address space, not the "physical" memory > used by UML. > - This was changed between the original RFC and v1, with > KASAN_SHADOW_SIZE's definition being updated. > - References to UML using 18TB of space and the shadow memory taking > 2.25TB were updated. (Thanks Johannes) > - A mention of physical memory in a comment was updated. (Thanks > Andrey) > - Move some discussion of how the vmalloc() handling could be made more > generic from a comment to the commit description. (Thanks Andrey) > > Changes since RFC v3: > https://lore.kernel.org/all/20220526010111.755166-1-davidgow@google.com/ > - No longer print "KernelAddressSanitizer initialized" (Johannes) > - Document the reason for the CONFIG_UML checks in shadow.c (Dmitry) > - Support static builds via kasan_arch_is_ready() (Dmitry) > - Get rid of a redundant call to kasam_mem_to_shadow() (Dmitry) > - Use PAGE_ALIGN and the new PAGE_ALIGN_DOWN macros (Dmitry) > - Reinstate missing arch/um/include/asm/kasan.h file (Johannes) > > Changes since v1: > https://lore.kernel.org/all/20200226004608.8128-1-trishalfonso@google.com/ > - Include several fixes from Vincent Whitchurch: > https://lore.kernel.org/all/20220525111756.GA15955@axis.com/ > - Support for KASAN_VMALLOC, by changing the way > kasan_{populate,release}_vmalloc work to update existing shadow > memory, rather than allocating anything new. > - A similar fix for modules' shadow memory. > - Support for KASAN_STACK > - This requires the bugfix here: > https://lore.kernel.org/lkml/20220523140403.2361040-1-vincent.whitchurch@axis.com/ > - Plus a couple of files excluded from KASAN. > - Revert the default shadow offset to 0x100000000000 > - This was breaking when mem=1G for me, at least. > - A few minor fixes to linker sections and scripts. > - I've added one to dyn.lds.S on top of the ones Vincent added. > > --- <... snip ...> > diff --git a/mm/kasan/shadow.c b/mm/kasan/shadow.c > index a4f07de21771..7a7fc76e99a8 100644 > --- a/mm/kasan/shadow.c > +++ b/mm/kasan/shadow.c > @@ -295,9 +295,22 @@ 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 virtual memory > + * at boot, so doesn't need to allocate more on vmalloc, just clear it. > + * > + * The remaining CONFIG_UML checks in this file exist for the same > + * reason. > + */ Whoops: these lines had tabs converted to spaces when I reformatted them. I've sent out v4 which actually passes checkpatch: https://lore.kernel.org/lkml/20220630080834.2742777-2-davidgow@google.com/ Sorry for the spam! -- David