Received: by 2002:a25:1506:0:0:0:0:0 with SMTP id 6csp1831998ybv; Thu, 6 Feb 2020 10:34:30 -0800 (PST) X-Google-Smtp-Source: APXvYqx31mXOjE9srhgjPeaxfW3gxMXKxitoXp2COLWOpwvHCpXz0nXYX4Fu1Z3wiVKb7fQHhvo0 X-Received: by 2002:a54:4791:: with SMTP id o17mr7513902oic.70.1581014070078; Thu, 06 Feb 2020 10:34:30 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1581014070; cv=none; d=google.com; s=arc-20160816; b=vLO4F5GFCOSt2LdRTB5K9YzvA/tLRD3Neof+2AMJclmW6IGQUT0qKT+WmjIM4tuTaC ZrZPw7Gu/tvPGnQ58j3a9PKBl6IN4Eca+jsi8EmM9IcElcDkMNDlkzaZbWXz1DAPqs2t qNCoiEyW8JierWxGLV7IrkaLOOusXUABDzRMkfPVBRYRfoXic8CVHs8d3VyZxRwTVtDV 3gMP5lqGLVJ6XtJV1LCIzarV0LVGsZ2kTwRHYuCcqY3Oh6ddbxUuPhd8zO+Tdtt4/i1j tMM8VoRiCgPbF1Qgp6jqyod5biTeUXhStGLClM8gjG5OJSfQNwwmXgqbWwhYxm92h4SA 5woQ== 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=/o0TABmh3sA91z50JGeWR2QdDzZnMyxEswlhRW37yD8=; b=cvx0eacWvl3XblJhC0ecX+bnCj1eC3JZHzUZEvI4RCTiGoRTESjsFJkLO8sivTHgMR FAn/tgLGm4uxdCmkvf3uLGqeFt8bXBUYWyW/od6ug8TpYw5nkb+tVlzMidzPbCBHL43D G7WpoTNp/F9QznadR2PlrJevs+e3wEBAq22J1ZmXiw2KT12iZkxWMa3+hyKXsLZIm/nD pgYbLfSJ4EWGAQMOJqX7kEqX7YJC5W6ue2dGMXTAB0g9EqHclglYrtI4eqeIdECmU25k fhM3J9sEnmY50Xd8m4MpnCf/DwlpLNO25TqXJsIQBAnYiYcT8OKxT6zMmPryQY/n9otO zGrw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=HR7uoCJJ; 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 z2si2620467oix.100.2020.02.06.10.34.17; Thu, 06 Feb 2020 10:34:30 -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=HR7uoCJJ; 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 S1727836AbgBFSdX (ORCPT + 99 others); Thu, 6 Feb 2020 13:33:23 -0500 Received: from mail-wr1-f66.google.com ([209.85.221.66]:33009 "EHLO mail-wr1-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727358AbgBFSdW (ORCPT ); Thu, 6 Feb 2020 13:33:22 -0500 Received: by mail-wr1-f66.google.com with SMTP id u6so8455077wrt.0 for ; Thu, 06 Feb 2020 10:33:20 -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=/o0TABmh3sA91z50JGeWR2QdDzZnMyxEswlhRW37yD8=; b=HR7uoCJJz73XXlC0tOxO2Tberzt+iuXFO7P4ixPw59zFnM5LttKSdf1tK9bRyAf3ka Cez5zxvwnBT7fJBnQ67tpaiouvNPQkKlpM62Rege6LCx2tSl2klKpsGsNk1zSshJSFRu FuGRvMh/ZCCsriTwBwTmSYNjePD9OPMT33VMFZSVk0gM5mYVnvt+OEMeWjL6dkKTVCgF sM0DFsahxxbvFSeltgIWn/b6lzvQQmDgav9bM2cUnKE9gHSBknhyx1jhX4s6EETMLgBX +EjI/i9GazD9vusTFNnsYDo9J3GXYXUZTO47N9ILD/BLLdwQYAt85BoFNwitlYdzsY/d /nsA== 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=/o0TABmh3sA91z50JGeWR2QdDzZnMyxEswlhRW37yD8=; b=fUPqSqZi35cBi3EXH92+YRPQXz+konL0xz4Zo0KCZBrhvYZ8RxTPP3eveqT6bWCrGX QEAX9i6MvdYbajp0j1KAXrtkRG3G3zpH64KIVhKbfjvuPS/wGy+RNTviiRdPhtkvOxXa /10tyTSgmuSRegv6ZnvRk6DqGJNKTEEE/U+nBWjevoy71ilF1SPRX86ALbp++j/6ReuC nUONvJudAYeJ2WKbSFuH9mgGGRj6jrhPG9xHe6a2H+DYWxn2EbYZ1BCURWEMp8f0dqdp TlJ0NBsZB1ka/HtNYYsfl8uK5SGX2EWPWy5BQTibnMyyFylo8TjCaa40lV+8ESCmZw3o /PVQ== X-Gm-Message-State: APjAAAX34H4wZWVMRUfi3IsL9rSJdttY08tPXPXVFgIINK6BDGngkFJH JYebu/dB7sLn/PB3loXnsjUdc+VORW9TgVNdLMq0Rw== X-Received: by 2002:a05:6000:108e:: with SMTP id y14mr5254368wrw.338.1581013999924; Thu, 06 Feb 2020 10:33:19 -0800 (PST) MIME-Version: 1.0 References: <20200115182816.33892-1-trishalfonso@google.com> <4f382794416c023b6711ed2ca645abe4fb17d6da.camel@sipsolutions.net> <2092169e6dd1f8d15f1db4b3787cc9fe596097b7.camel@sipsolutions.net> In-Reply-To: From: Patricia Alfonso Date: Thu, 6 Feb 2020 10:33:08 -0800 Message-ID: Subject: Re: [RFC PATCH] UML: add support for KASAN under x86_64 To: Dmitry Vyukov Cc: Johannes Berg , Richard Weinberger , Jeff Dike , Brendan Higgins , LKML , kasan-dev , linux-um@lists.infradead.org, David Gow , Andrey Ryabinin , anton.ivanov@cambridgegreys.com 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 Fri, Jan 17, 2020 at 2:05 AM Dmitry Vyukov wrote: > > On Fri, Jan 17, 2020 at 11:03 AM Dmitry Vyukov wrote: > > > > On Fri, Jan 17, 2020 at 10:59 AM Dmitry Vyukov wrote: > > > > > > On Thu, Jan 16, 2020 at 10:39 PM Patricia Alfonso > > > wrote: > > > > > > > > On Thu, Jan 16, 2020 at 1:23 AM Dmitry Vyukov wrote: > > > > > > > > > > On Thu, Jan 16, 2020 at 10:20 AM Johannes Berg > > > > > wrote: > > > > > > > > > > > > On Thu, 2020-01-16 at 10:18 +0100, Dmitry Vyukov wrote: > > > > > > > > > > > > > > This should resolve the problem with constructors (after they > > > > > > > initialize KASAN, they can proceed to do anything they need) and it > > > > > > > should get rid of most KASAN_SANITIZE (in particular, all of > > > > > > > lib/Makefile and kernel/Makefile) and should fix stack instrumentation > > > > > > > (in case it does not work now). The only tiny bit we should not > > > > > > > instrument is the path from constructor up to mmap call. > > > > By initializing KASAN as the first thing that executes, I have been able to get rid of most of the "KASAN_SANITIZE := n" lines and I am very happy about that. Thanks for the suggestions! > > > If that part of the code I mentioned is instrumented, manifestation > > > would be different -- stack instrumentation will try to access shadow, > > > shadow is not mapped yet, so it would crash on the shadow access. > > > > > > What you are seeing looks like, well, a kernel bug where it does a bad > > > stack access. Maybe it's KASAN actually _working_? :) > > > > Though, stack instrumentation may have issues with longjmp-like things. > > I would suggest first turning off stack instrumentation and getting > > that work. Solving problems one-by-one is always easier. > > If you need help debugging this, please post more info: patch, what > > you are doing, full kernel output (preferably from start, if it's not > > too lengthy). > > I see syscall_stub_data does some weird things with stack (stack > copy?). Maybe we just need to ignore accesses there: individual > accesses, or whole function/file. It is still not clear whether the syscall_stub_data errors are false positives, but while moving the kasan_init() to be as early as possible in main(), I ran into a few more stack-related errors like this(show_stack, dump_trace, and get_wchan). I will be taking your advice to focus on one thing at a time and temporarily disable stack instrumentation wherever possible. -- Patricia Alfonso