Received: by 2002:a25:8b91:0:0:0:0:0 with SMTP id j17csp7550513ybl; Thu, 16 Jan 2020 01:22:05 -0800 (PST) X-Google-Smtp-Source: APXvYqyQS+kaCJma+kPowm0IEtoZkT2omYbDE5b2hv0MfMe7pA70NTRzyULZpNPMdu0oAOwD2wfH X-Received: by 2002:a9d:748d:: with SMTP id t13mr1210156otk.181.1579166525001; Thu, 16 Jan 2020 01:22:05 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1579166524; cv=none; d=google.com; s=arc-20160816; b=GTUxYIdmD8NgN/VPP9rt9jyu9hbMteekaKAxvGEnN/6h0fwrEzRRNFTCwFQBUhhJJL vwuBUIPfFBy523aoltor8FdkS7dSNl0avYJxOVN9k2ef+rTdDMfXNA/gY4GcYyz4dwCo o8T05mrQTReRcmVjiaRMsnG/SZW1U52A+5IfY2v8JiiG+68LLQPKOie+8IODvW1mpszi b2CgGBf+EckkESMhZOAhAOMAXhAFqgs9x1qtST3Gd9W9UcszuNs8EQH8LF8lXP9bmSnA PuIaLp7sgeJDwzxrFhxqHhp1YxaZplKFBCpl0K4Nk5C3AEYi3DPc/AVQbsrO4CHcKfWH vegA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :user-agent:references:in-reply-to:date:cc:to:from:subject :message-id; bh=cCrKdUykToj0LjfqGl+8hrXiC1ZmRNpjtmlrLsCbgVM=; b=LG9TR7y3ILEsLzqPSWqrYmmPMMshdLz+6W0qcTrge6kiBbzZF4dy+2G6oASiBmQ6oS OfciIySm99yDlR06T2qHrBshMpqhsizBYCzCkyFD27nWPI8EQxDt9T3WiPK4xDidB27l p+Ai4tnXvBmzF0OQA9O2VxC42h0r3AVNKUzyC6W7trtJj8jgsSIzGk8D5NK0pMpCmkov oKkSSo8uiMuCcBzywirxX4eP/HDRKOGFxMZV/lS7O0fQtLzJf1dtjCJq4o1XNvTK40+E famDS5k7Xb7KOgxl5pfc/p+EeJgHezZW3ZIc28Fj5ud8SUswOQHNk9CefHwWKt7+Jvbt hbiw== ARC-Authentication-Results: i=1; mx.google.com; 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id k7si13122259otp.22.2020.01.16.01.21.52; Thu, 16 Jan 2020 01:22:04 -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; 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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729274AbgAPJUg (ORCPT + 99 others); Thu, 16 Jan 2020 04:20:36 -0500 Received: from s3.sipsolutions.net ([144.76.43.62]:50284 "EHLO sipsolutions.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726684AbgAPJUg (ORCPT ); Thu, 16 Jan 2020 04:20:36 -0500 Received: by sipsolutions.net with esmtpsa (TLS1.3:ECDHE_SECP256R1__RSA_PSS_RSAE_SHA256__AES_256_GCM:256) (Exim 4.93) (envelope-from ) id 1is1KF-00BgMa-LC; Thu, 16 Jan 2020 10:20:27 +0100 Message-ID: <2092169e6dd1f8d15f1db4b3787cc9fe596097b7.camel@sipsolutions.net> Subject: Re: [RFC PATCH] UML: add support for KASAN under x86_64 From: Johannes Berg To: Dmitry Vyukov 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 Date: Thu, 16 Jan 2020 10:20:26 +0100 In-Reply-To: (sfid-20200116_101838_954522_B05BB78D) References: <20200115182816.33892-1-trishalfonso@google.com> <4f382794416c023b6711ed2ca645abe4fb17d6da.camel@sipsolutions.net> (sfid-20200116_101838_954522_B05BB78D) Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.34.2 (3.34.2-1.fc31) MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, 2020-01-16 at 10:18 +0100, Dmitry Vyukov wrote: > > Looking at this problem and at the number of KASAN_SANITIZE := n in > Makefiles (some of which are pretty sad, e.g. ignoring string.c, > kstrtox.c, vsprintf.c -- that's where the bugs are!), I think we > initialize KASAN too late. I think we need to do roughly what we do in > user-space asan (because it is user-space asan!). Constructors run > before main and it's really good, we need to initialize KASAN from > these constructors. Or if that's not enough in all cases, also add own > constructor/.preinit array entry to initialize as early as possible. We even control the linker in this case, so we can put something into the .preinit array *first*. > All we need to do is to call mmap syscall, there is really no > dependencies on anything kernel-related. OK. I wasn't really familiar with those details. > 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. That'd be great :) johannes