Received: by 2002:a25:8b91:0:0:0:0:0 with SMTP id j17csp7494793ybl; Thu, 16 Jan 2020 00:12:33 -0800 (PST) X-Google-Smtp-Source: APXvYqw+0wgYfhfbAAi2xGMJ1eNiFGgxsJIvkNydBqpw8H8bLsSNFSfQx9XInMF8BncXJEGGZeZf X-Received: by 2002:aca:f10:: with SMTP id 16mr3079516oip.117.1579162353510; Thu, 16 Jan 2020 00:12:33 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1579162353; cv=none; d=google.com; s=arc-20160816; b=jSRonNfq4qDPNGeFiF6mrLl6jYbGKWxofziUjO1sraUTvupJ9O775xrkGMYCw9CrBJ HUaXT/xBnUozcgVDoOGMoK6uDEDNeQjxRDhMHGFDl2NFVaUrut+cMIkCAVJm2SutCQ9+ 7q8RefYgXNGbm6BKumZHz4VW4ACSXxQgkyDJDPYV6pNhssLoABtVxsBQsRBMZztrKL8J hoCGgwWW1Evep/5tNG3eo2DYorKJ8xk3wO9I8AoiEkv2DtAMDb6p/3a+wzNkozBK9x1U kHnyZO1jrMsnR4fpKXHcM8F3ysXj8j874YEokBrUr70DoQIJW4y5hqUevZhr89DBN/wj /v0w== 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=ao4Y9gZiexavvmdXP+FAoZZy1s84ZmeB58AHmou+NbI=; b=P97dau4b79CvaNDyhnwqpUJlgRpiQ/1uJNeyGlyT6/dHfSi26smBYwFVwJoQpdIcOx ryNPJEz28oklNEvJKK4EsFADPD12ht97NgMCboHqQzbscD5ek5rgg1JnDM7nd/LlwyUD N+k83aSoX74IB9IndWIg0q4wGjHgsjXSvjAGPWn7vQi+d0im0uXsZOFAz9VNeePoxCiw GWu0aL4vFV/kHgYp6u63BhJKOXRQusDgmvLq21NUHc78QezBiRxUq07o5hsg358tnYnx 5MaF2T0xkLVgCArC8ypfmgkrT7hgw90YFRLvVP5BifuJ14Y/FcjsesflXSOx5/0kvZ4s iWIA== 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 d17si10687157oij.136.2020.01.16.00.12.20; Thu, 16 Jan 2020 00:12:33 -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 S1729949AbgAPH5f (ORCPT + 99 others); Thu, 16 Jan 2020 02:57:35 -0500 Received: from s3.sipsolutions.net ([144.76.43.62]:48340 "EHLO sipsolutions.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726369AbgAPH5e (ORCPT ); Thu, 16 Jan 2020 02:57:34 -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 1is01s-00BVg7-C7; Thu, 16 Jan 2020 08:57:24 +0100 Message-ID: <4f382794416c023b6711ed2ca645abe4fb17d6da.camel@sipsolutions.net> Subject: Re: [RFC PATCH] UML: add support for KASAN under x86_64 From: Johannes Berg To: Patricia Alfonso Cc: jdike@addtoit.com, richard@nod.at, anton.ivanov@cambridgegreys.com, aryabinin@virtuozzo.com, dvyukov@google.com, David Gow , Brendan Higgins , linux-um@lists.infradead.org, linux-kernel@vger.kernel.org, kasan-dev@googlegroups.com Date: Thu, 16 Jan 2020 08:57:22 +0100 In-Reply-To: (sfid-20200115_235651_948442_0F0A0073) References: <20200115182816.33892-1-trishalfonso@google.com> (sfid-20200115_235651_948442_0F0A0073) 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 Hi, > This seems like a good idea. I'll keep the #ifdef around > KASAN_SHADOW_SIZE, but add "select HAVE_ARCH_KASAN if X86_64" as well. > This will make extending it later easier. Yeah, that makes a lot of sense. I think once somebody (Anton? Richard?) start applying patches again, they will pick up my revert for CONFIG_CONSTRUCTORS: https://patchwork.ozlabs.org/patch/1204275/ (See there for why I had to revert it) If I remember correctly, KASAN depends on CONSTRUCTORS, so that revert will then break your patch here? And if I remember from looking at KASAN, some of the constructors there depended on initializing after the KASAN data structures were set up (or at least allocated)? It may be that you solved that by allocating the shadow so very early though. In any case, I think you should pick up that revert of CONFIG_CONSTRUCTORS and see what you have to do to make it still work, if that's possible. If not, then ... tricky, not sure what to do. Maybe then we could somehow hook in and have our own constructor that's called even before the compiler-emitted ASAN constructors, to allocate the necessary data structures. johannes