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 X-Spam-Level: X-Spam-Status: No, score=-8.4 required=3.0 tests=DKIMWL_WL_MED,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,USER_IN_DEF_DKIM_WL autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id DA717C43331 for ; Mon, 30 Mar 2020 08:39:08 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id A0ED320776 for ; Mon, 30 Mar 2020 08:39:08 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="wLmWxuLq" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729761AbgC3IjH (ORCPT ); Mon, 30 Mar 2020 04:39:07 -0400 Received: from mail-qk1-f196.google.com ([209.85.222.196]:45714 "EHLO mail-qk1-f196.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729743AbgC3IjD (ORCPT ); Mon, 30 Mar 2020 04:39:03 -0400 Received: by mail-qk1-f196.google.com with SMTP id c145so18031971qke.12 for ; Mon, 30 Mar 2020 01:39:03 -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=4xCc6G1fjYHS6JfynXvIUwvrt/yvbN0xlTjIkaNy98k=; b=wLmWxuLqn8KyJaQMB7X5bKCXwFjzc5aFDK54p9NPQtlgVlF2qRui1Xn+J/PqS4qYdz AxLC7N7UABn9fGxFWDIPvFekDu1Jaj4Qqquj0+qYV0+jNm47Nrh9Q+ql9OERMuHOW64I fXbROUpYZvtnx4heJlLaJK3lpjs7IcUK32hoVLJ7BhWF+SlCKPVU69yTC3EVQ/ag7puD TAF29OMOzh0T0AXrI6jehsr68PwCEZaIJQTR7XzZ74rB7ZNyGsC60Z+W+p8LcQD5e4lu HgU3SCJiO2lyWPfTmxhKfiTLO37E6vKkEY4EpCU7mbYrmffaw03ZICFZK8CGiE9d08mH iIwg== 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=4xCc6G1fjYHS6JfynXvIUwvrt/yvbN0xlTjIkaNy98k=; b=dPWuCOyUBJ0OLWFU4eU8nP+vyZXVrmxFrBQKbpyFi9eEEPYKilvB5gehJ5TIP7pFWI j8ysgtKTti7w+kjyx1YxZ8RLlTQM7puUogXGCSJHXgWOAmGB6FPu+WC621wMVIzGOCzu YV8DMliVnMrCjXdbvfFqS1WAc5TjqGWy0Srx2pwPRTLbKIPZ1Vm8EtUzabNhobUijZqg 1EIw7h3LpYGGm1EPPwU4j6Ukt/cUD5CNgmSLjV6M4hQbIeHw/dpeXH6vRaI/CrkzwLnG 7joqYez5Daq9Z5raz5t76NhpBDfGA8tGsg42W3+rWTwWWKnah76nv/ZZZOOSs/wG8u7z AXCQ== X-Gm-Message-State: ANhLgQ2ui0hpuYYFbHrz0SxJqH+wd1xfoGq3sk/oO0fX2BJJfx1X5ofQ rr8xc5+DmbOzCIH7GYJwP26vgQ2plgGcczd5X64l2A== X-Google-Smtp-Source: ADFU+vsrAoMtOj8G6dIUBTBViI6fwRdVWLliO+YLNi//6orndEbw72BFL0/0zwZiAeZ2r2/mJJfmAyqGgtwIMhlb/hY= X-Received: by 2002:a37:bc47:: with SMTP id m68mr10748443qkf.8.1585557542372; Mon, 30 Mar 2020 01:39:02 -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: <2cee72779294550a3ad143146283745b5cccb5fc.camel@sipsolutions.net> From: Dmitry Vyukov Date: Mon, 30 Mar 2020 10:38:50 +0200 Message-ID: Subject: Re: [PATCH] UML: add support for KASAN under x86_64 To: Johannes Berg Cc: Patricia Alfonso , 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 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. > > 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... But we do mmap it, no? See kasan_init() -> kasan_map_memory() -> mmap. From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qk1-x741.google.com ([2607:f8b0:4864:20::741]) by bombadil.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1jIpwo-0004D4-7e for linux-um@lists.infradead.org; Mon, 30 Mar 2020 08:39:07 +0000 Received: by mail-qk1-x741.google.com with SMTP id h14so18093869qke.5 for ; Mon, 30 Mar 2020 01:39:03 -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: <2cee72779294550a3ad143146283745b5cccb5fc.camel@sipsolutions.net> From: Dmitry Vyukov Date: Mon, 30 Mar 2020 10:38:50 +0200 Message-ID: Subject: Re: [PATCH] UML: add support for KASAN under x86_64 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-um" Errors-To: linux-um-bounces+geert=linux-m68k.org@lists.infradead.org To: Johannes Berg Cc: Patricia Alfonso , Richard Weinberger , Jeff Dike , Brendan Higgins , LKML , kasan-dev , linux-um@lists.infradead.org, David Gow , Andrey Ryabinin , anton.ivanov@cambridgegreys.com 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. > > 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... But we do mmap it, no? See kasan_init() -> kasan_map_memory() -> mmap. _______________________________________________ linux-um mailing list linux-um@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-um