Received: by 2002:a25:1506:0:0:0:0:0 with SMTP id 6csp167933ybv; Wed, 12 Feb 2020 21:41:24 -0800 (PST) X-Google-Smtp-Source: APXvYqzEh8CmepPQr6qaEpwZvtA1V8eTOo4IxR48eRG5bw06mhOA3GqpSkepFqQuXujvFhX2bwCE X-Received: by 2002:a54:440e:: with SMTP id k14mr1776938oiw.160.1581572484143; Wed, 12 Feb 2020 21:41:24 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1581572484; cv=none; d=google.com; s=arc-20160816; b=toHEh0Skn+NerHwMrZTt8yIOaRQ/7AoHfvn6uz4lnaSKfHcrchtbe7U2XqWaToMkoj dcS607C52dOeJHkU9liToHz/Ov7KFLcAl1ismCbguuR40ORKIuzMUmLQxCv1wnlk8HYj ofSNknzweKi/4Q9LWR7h42u3fdRunyMo3pSWCTT9rM8X3vtZDFEZwDR6XW0SPomZTOSE wOe84jEOP2FAxGxY6XO1PEiJP5KwhVQvj0b7nZyap1ETy7N1W/94QTFYGsN7YKpVH/ar 8hmi1HMHtVymSz64WNCuDC4dbJ1Wrmu3vLv+zuuVKXD/bznOxVt6Zb/lzkc/dRM8U5qw IbWQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=tFvB3dUHqlfWY0xdzQLpqooj9O1A8mgi9rJRJWCXmFQ=; b=JM7OGhkhBGUedDiE1f4cJFE0i/cAn1oGNWWBhI0S3wGS78BE3DNW20VKGA5BXDMY4W YH798p5cM2+lef++1cb2TOM75akZ/modSAJzCYuZkZVDWZMMIUdP+OdwmMQs401rK47k PlAv3cmNBUUQqdy0IctEczTgvuVGKVkHAzBpX8Um/LMpRjzgo2Kq+5rd5fu4g2kAq563 CsZd3jM0/TSYjaHjj+PmQ516pHdmw1jVfMHieZ/IeIKFo0KBahsVoiKtiMbPFJOdl2C6 tlwEE1LV8K1RQRgDNrgHNCnQsjqQfASR2s4YqYOXQrmJ9MK4AQ6i9+nayPcy43n1IGe/ oS7Q== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=vtBoid64; 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; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id 6si670701otv.224.2020.02.12.21.41.11; Wed, 12 Feb 2020 21:41:24 -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=@google.com header.s=20161025 header.b=vtBoid64; 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; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729677AbgBMFkE (ORCPT + 99 others); Thu, 13 Feb 2020 00:40:04 -0500 Received: from mail-qk1-f196.google.com ([209.85.222.196]:38537 "EHLO mail-qk1-f196.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725773AbgBMFkD (ORCPT ); Thu, 13 Feb 2020 00:40:03 -0500 Received: by mail-qk1-f196.google.com with SMTP id z19so4574085qkj.5 for ; Wed, 12 Feb 2020 21:40:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=tFvB3dUHqlfWY0xdzQLpqooj9O1A8mgi9rJRJWCXmFQ=; b=vtBoid64kdWQODNZsUHlienhgxFYDOHEaJzpP6h14MdSty1RTBtrn1TQxj+u1qfYhr bRRlbvtlBlLfY6K0aFTZBm7MO3YcfKZ/bqP7MQLeM7MIH8UycmVZrN+cf0+TgFjMEvvt iD8NyrSZBWQ6ZQkN7WFDRZqKVYDHPaLejY7ZgT2CJjZp8d1Mr6eAifbIAFiBzOJMAr/P oV+4pks29Rczjh9mxbujVW8ohd0jGVH5hmMmJMFl4AyNfAVw6S9LzGTjuM6+X2widnnB 3LelD14XVVCJpK8f+45SAFsWZMXt8VE6oLODNh56dWAGAHPyZmIdzO1C/nVFjESghItf AdFw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=tFvB3dUHqlfWY0xdzQLpqooj9O1A8mgi9rJRJWCXmFQ=; b=NhDeu7yDefQoAqx1EqhB3shDlGNT98aE6QoFZ/YYdQEBHX/hvjtGtuzkhRGBUeQ9hS pxuKS/+BAjb1YxfhMHDmW93bK7uQ+NW40kPEwJU2FXkBvldw4BvMpLZVEE/1Xa3mtZOB U1ypOmqZk0sKcUOAGC+HN+HuMgGeqKb5qCwA4LTNwqyZ5imEwk0uDkPJZM7jcuPeqAQ7 LmQeagq5UkIeDOrfgA8gmXqjlUlitPSP+OkDfc/uZX0T6fl/f/kjmiqOaCKNdKMeo+yO VXaPsWOPTKzk/iro+xf8/5cOTGl/h4b+Mnl+1IWxUNtnRz4TNNge2ExCtpUzCBtEhjDv 8XBg== X-Gm-Message-State: APjAAAUS3vYlNOI5/mcEd6rjodK8ET6jd3BZzKgedSUQTCSB2suOICL1 WcOrWAxr49LuPixf47EPM3H8VFX6awSP+FwNIy49Pg== X-Received: by 2002:a37:4755:: with SMTP id u82mr13737500qka.43.1581572402214; Wed, 12 Feb 2020 21:40:02 -0800 (PST) MIME-Version: 1.0 References: <20200115182816.33892-1-trishalfonso@google.com> In-Reply-To: From: Dmitry Vyukov Date: Thu, 13 Feb 2020 06:39:50 +0100 Message-ID: Subject: Re: [RFC PATCH] UML: add support for KASAN under x86_64 To: Patricia Alfonso Cc: Jeff Dike , Richard Weinberger , anton.ivanov@cambridgegreys.com, Andrey Ryabinin , David Gow , Brendan Higgins , linux-um@lists.infradead.org, kasan-dev , LKML Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Feb 12, 2020 at 11:25 PM Patricia Alfonso wrote: > > On Wed, Feb 12, 2020 at 1:19 AM Patricia Alfonso > > wrote: > > > > > > On Thu, Jan 16, 2020 at 12:53 AM Dmitry Vyukov wrote: > > > > > > > > > +void kasan_init(void) > > > > > +{ > > > > > + kasan_map_memory((void *)KASAN_SHADOW_START, KASAN_SHADOW_SIZE); > > > > > + > > > > > + // unpoison the kernel text which is form uml_physmem -> uml_reserved > > > > > + kasan_unpoison_shadow((void *)uml_physmem, physmem_size); > > > > > + > > > > > + // unpoison the vmalloc region, which is start_vm -> end_vm > > > > > + kasan_unpoison_shadow((void *)start_vm, (end_vm - start_vm + 1)); > > > > > + > > > > > + init_task.kasan_depth = 0; > > > > > + pr_info("KernelAddressSanitizer initialized\n"); > > > > > +} > > > > > > > > Was this tested with stack instrumentation? Stack instrumentation > > > > changes what shadow is being read/written and when. We don't need to > > > > get it working right now, but if it does not work it would be nice to > > > > restrict the setting and leave some comment traces for future > > > > generations. > > > If you are referring to KASAN_STACK_ENABLE, I just tested it and it > > > seems to work fine. > > > > > > I mean stack instrumentation which is enabled with CONFIG_KASAN_STACK. > > I believe I was testing with CONFIG_KASAN_STACK set to 1 since that is > the default value when compiling with GCC.The syscall_stub_data error > disappears when the value of CONFIG_KASAN_STACK is 0, though. Then I would either disable it for now for UML, or try to unpoision stack or ignore accesses.