Received: by 2002:a25:6193:0:0:0:0:0 with SMTP id v141csp3671251ybb; Tue, 31 Mar 2020 09:40:47 -0700 (PDT) X-Google-Smtp-Source: ADFU+vtybnbY1iwstgIVHRnKdRRpoGiv2Kr5khL3g+Yoc23sIvNY60AVRZNkE1wR7yBa7KEYD4rc X-Received: by 2002:aca:1c02:: with SMTP id c2mr2585325oic.125.1585672846863; Tue, 31 Mar 2020 09:40:46 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1585672846; cv=none; d=google.com; s=arc-20160816; b=KjDwQCTo4tvk0u6416ahtTFKyEmX0YYSef6XBY7F9aV/8xynl/kHsqYC8SOR4OHrAF Jq5OEnGJvV31duV6f0fzPQJzMNaJ30IevnZmOKgJPyJZKoGMrgyyQ7DBJECW87DYGHqy PSRsozRPZ0o3dyM0JvRjwjwMlVQlPxkOE1LUfq5EzZyaV3KBQ4vD5lzWyyxCftIKCiJw NaQ2511hGT2b+ho1btKWSP0pbzfhw8eLUPHnD45FF0TDVqVtQPakrVeAgfnWuri1PPUN 2K5MNzsXhcG8A2c/burvhGfw7q3fsHHuWKAIv6aL7J/eRaRSdE7ND9c8Q8RxahfPlYoW yoSA== 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=QgoMF0cL9ZUADYdGprv6AZfHS2idq4rpQGViQrbTh3g=; b=BYAyJgpdPX52Yy5GztKSYYvJ5EnJpSeGKCOBwqkVM+O21I0kdsrtzSf11jC1c2my/T bT9jJ4/tAnClCi1On1lSL7tRdSuB4pZVx70rROFU1GAN3Wk/bczHLJgfbRHXCFyqWs3d zA/IpUj6nC8D24GErB+pRGHC3Vf26GBx72hVkIR4GauYnFvDyVXXvu4Y5szg9+0SGVOb iIFPcv6WZ16PsTP7wW3V5oDniSUMtQoUOXEmFGg4oFKt34ZsZQ8/wE6Zblx3S7H0wW/i Pv58WEwBNKqgbpbuCq8shVxanJD3Gk2u2cd5ykZJk2HuBkHVpOEZc+GRaaK8A9of8Mt0 4bJA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=MOyCc4Pg; 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 r25si4843148otq.113.2020.03.31.09.40.34; Tue, 31 Mar 2020 09:40:46 -0700 (PDT) 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=MOyCc4Pg; 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 S1731239AbgCaQje (ORCPT + 99 others); Tue, 31 Mar 2020 12:39:34 -0400 Received: from mail-wm1-f68.google.com ([209.85.128.68]:55831 "EHLO mail-wm1-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726194AbgCaQje (ORCPT ); Tue, 31 Mar 2020 12:39:34 -0400 Received: by mail-wm1-f68.google.com with SMTP id r16so3257527wmg.5 for ; Tue, 31 Mar 2020 09:39:33 -0700 (PDT) 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=QgoMF0cL9ZUADYdGprv6AZfHS2idq4rpQGViQrbTh3g=; b=MOyCc4PgavB5gSASpI6clKEFNY8K2buCcld4kUOHT2U6+ZQD2QBLgweg819jEBdBmH 3B9tDDscrZBDI4FwQuUuqfjtvh/MpztQ9r8K3LEqBZcOaSxJKvQSfcPYIF9azVlNiLbz tZmwU4/gZX2ta8YRKxbZdzOAyUVZaSHjXVx2q2W4Ua+HLIgmzpHsU+tejH9k/rNScbFv 9wfBwW3l4EVy/+GM/Rb4eRtSonYmvPKq9PAvjlzVq5lUsw+7+RYt3c0Fq34dWNp2i8TA 0lcLJZlx0N4M0KVXGD6kjXWagBLecurFWWNfg7DyVUj76MCGtAZB869ZvlLV340LEuyR L5mg== 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=QgoMF0cL9ZUADYdGprv6AZfHS2idq4rpQGViQrbTh3g=; b=iIpt3JKw/p37VbuBRlCb7zZnK98TPyJzhxc4OnHbVHe9Yn/o0oI0hS2s5cpmXjmTwN IEnwlmx6EJc3GYqg6Dd035NCv7FOMgBQZYZMbLY6Zv8/7Uv6FVSRaM819QCsdDJWN+XU Ei5174+3XHabi3NYe5fhaQ+BTHxX35GYScclgL2wMztmR+J3h1boqcP12Aa+WRtSa831 dQSf4KIhJ/0Lm1ATb8PGQWPqgzBfJbVtQTT2lsud1TOqsjFzi4lJg0zgoqaGowgmYwiQ CCEjfsXIwhnleqMY+noZ8Yn7WQAESBeZHumM/b+Rx3E5LfxH0AXwxsuQ0Qt92sfyI7oS 9m5Q== X-Gm-Message-State: ANhLgQ1b4QldVYDdb6FgMgpS2bAkoMJqE+p9GHcyCjZSIx1Qzuqg228w 2NokI3Z+ID3KIs5yUM6E4kfa0kVKMQbWawuznJvHoQ== X-Received: by 2002:a1c:62c5:: with SMTP id w188mr4444781wmb.112.1585672772708; Tue, 31 Mar 2020 09:39:32 -0700 (PDT) MIME-Version: 1.0 References: <20200226004608.8128-1-trishalfonso@google.com> <4b8c1696f658b4c6c393956734d580593b55c4c0.camel@sipsolutions.net> <674ad16d7de34db7b562a08b971bdde179158902.camel@sipsolutions.net> <2cee72779294550a3ad143146283745b5cccb5fc.camel@sipsolutions.net> In-Reply-To: From: Patricia Alfonso Date: Tue, 31 Mar 2020 09:39:21 -0700 Message-ID: Subject: Re: [PATCH] UML: add support for KASAN under x86_64 To: Johannes Berg Cc: Dmitry Vyukov , Jeff Dike , Richard Weinberger , anton.ivanov@cambridgegreys.com, Andrey Ryabinin , Brendan Higgins , David Gow , linux-um@lists.infradead.org, LKML , kasan-dev 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 Mon, Mar 30, 2020 at 1:41 AM Johannes Berg wrote: > > On Mon, 2020-03-30 at 10:38 +0200, Dmitry Vyukov wrote: > > On Mon, Mar 30, 2020 at 9:44 AM Johannes Berg wrote: > > > On Fri, 2020-03-20 at 16:18 +0100, Dmitry Vyukov wrote: > > > > > Wait ... Now you say 0x7fbfffc000, but that is almost fine? I think you > > > > > confused the values - because I see, on userspace, the following: > > > > > > > > Oh, sorry, I copy-pasted wrong number. I meant 0x7fff8000. > > > > > > Right, ok. > > > > > > > Then I would expect 0x1000 0000 0000 to work, but you say it doesn't... > > > > > > So it just occurred to me - as I was mentioning this whole thing to > > > Richard - that there's probably somewhere some check about whether some > > > space is userspace or not. > > > Yeah, it seems the "Kernel panic - not syncing: Segfault with no mm", "Kernel mode fault at addr...", and "Kernel tried to access user memory at addr..." errors all come from segv() in arch/um/kernel/trap.c due to what I think is this type of check whether the address is in userspace or not. > > > I'm beginning to think that we shouldn't just map this outside of the > > > kernel memory system, but properly treat it as part of the memory that's > > > inside. And also use KASAN_VMALLOC. > > > > > > We can probably still have it at 0x7fff8000, just need to make sure we > > > actually map it? I tried with vm_area_add_early() but it didn't really > > > work once you have vmalloc() stuff... > > What x86 does when KASAN_VMALLOC is disabled is make all vmalloc region accesses succeed by default by using the early shadow memory to have completely unpoisoned and unpoisonable read-only pages for all of vmalloc (which includes modules). When KASAN_VMALLOC is enabled in x86, the shadow memory is not allocated for the vmalloc region at startup. New chunks of shadow memory are allocated and unpoisoned every time there's a vmalloc() call. A similar thing might have to be done here by mprotect()ing the vmalloc space as read only, unpoisoned without KASAN_VMALLOC. This issue here is that kasan_init runs so early in the process that the vmalloc region for uml is not setup yet. > > But we do mmap it, no? See kasan_init() -> kasan_map_memory() -> mmap. > > Of course. But I meant inside the UML PTE system. We end up *unmapping* > it when loading modules, because it overlaps vmalloc space, and then we > vfree() something again, and unmap it ... because of the overlap. > > And if it's *not* in the vmalloc area, then the kernel doesn't consider > it valid, and we seem to often just fault when trying to determine > whether it's valid kernel memory or not ... Though I'm not really sure I > understand the failure part of this case well yet. > I have been testing this issue in a multitude of ways and have only been getting more confused. It's still very unclear where exactly the problem occurs, mostly because the errors I found most frequently were reported in segv(), but the stack traces never contained segv. Does anyone know if/how UML determines if memory being accessed is kernel or user memory? > johannes > -- Best, Patricia