From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756149AbbCCNPN (ORCPT ); Tue, 3 Mar 2015 08:15:13 -0500 Received: from mailout2.w1.samsung.com ([210.118.77.12]:57204 "EHLO mailout2.w1.samsung.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755089AbbCCNPL (ORCPT ); Tue, 3 Mar 2015 08:15:11 -0500 X-AuditID: cbfec7f5-b7fc86d0000066b7-43-54f5b34727bc Message-id: <54F5B3DA.70203@samsung.com> Date: Tue, 03 Mar 2015 16:15:06 +0300 From: Andrey Ryabinin User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-version: 1.0 To: "Luis R. Rodriguez" Cc: "linux-kernel@vger.kernel.org" , xen-devel@lists.xenproject.org, Andy Lutomirski , Boris Ostrovsky , Jeremy Fitzhardinge , Chris Wright , Alok Kataria , Rusty Russell , virtualization@lists.linux-foundation.org Subject: Re: kasan_map_early_shadow() on Xen References: In-reply-to: Content-type: text/plain; charset=windows-1252 Content-transfer-encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrELMWRmVeSWpSXmKPExsVy+t/xq7rum7+GGDSukrZ41ZVkcXF6K4tF 7+0lzBaP5j1itbi8aw6bxeq1DawWz0/uZba4Oe0Ci8Xys/PYLL5vmczkwOVx/81fFo/NF1cz eUy+sZzR4/CHKyweH5/eYvFYseEEs8e2PV3MHuu3XGXx+LxJzuPd/LdsAVxRXDYpqTmZZalF +nYJXBlTpjxlKjjEWzH5wQvmBsZbXF2MnBwSAiYSKyfeYIOwxSQu3FsPZHNxCAksZZS4c6OF CcJpZpJ48XQLYxcjBwevgIbEpD4fkAYWAVWJqb/aWEBsNgE9iX+ztoMNEhWIkJh/7DUziM0r ICjxY/I9FpBWEQFNiV2HK0BGMgs0Mku0dy9hBakRFtCRuNC3G2yOkECARN+/M+wgNqdAsETH v1Vga5mB5t+/qAUSZhaQl9i85i3zBEaBWUg2zEKomoWkagEj8ypG0dTS5ILipPRcI73ixNzi 0rx0veT83E2MkHj5uoNx6TGrQ4wCHIxKPLwnDn4OEWJNLCuuzD3EKMHBrCTCyzz3a4gQb0pi ZVVqUX58UWlOavEhRiYOTqkGxoVh8kmSfJMmqXLe/+LMOOWuX0Ka5XQmZ6/n815/PJXLduHe 7L42zttB3ZJ3xVRvXhTJjBJ7eqdtr6V+mivjlk9vbXVsg3/dPTSjn7dEejK/w7eP4cJKqzMi pQ/YWjIyWLywWRyca/65ofC5xyz76tr0uiebRG+sOntQQXV+4edH0VMKdjl8V2Ipzkg01GIu Kk4EAOHGoKR1AgAA Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 03/03/2015 12:40 PM, Luis R. Rodriguez wrote: > Andrey, > > I believe that on Xen we should disable kasan, would like confirmation I guess Xen guests won't work with kasan because Xen guests doesn't setup shadow (kasan_map_early_shadow() is not called in xen guests). Disabling kasan for Xen in Kconfig is undesirable because that will disable kasan for allmodconfig and allyesconfig builds, but I don't see other option for now. > from someone on xen-devel though. Here's the thing though -- if true > -- I'd like to do it *properly*, where *properly* means addressing a > bit of architecture. A simple Kconfig slap seems rather reactive. I'd > like to address a way to properly ensure we don't run into this and > other similar issues in the future. The CR4 shadow issue was another > recent example issue, also introduced via v4.0 [0]. We can't keep > doing this reactively. > > Let's go down the rabbit hole for a bit. HAVE_ARCH_KASAN will be > selected on x86 when: > > if X86_64 && SPARSEMEM_VMEMMAP > > Now Xen should not have SPARSEMEM_VMEMMAP but PVOPs' goal is to enable > distributions to be able to have a single binary kernels and let the > rest be figured out, so we can't just disable SPARSEMEM_VMEMMAP for > Xen alone, we want to build Xen.. or part of Xen and perhaps keep > SPARSEMEM_VMEMMAP, and only later figure things out. > > How do we do this cleanly and avoid future reactive measures? If the > answer is not upon us, I'd like to at least highlight the issue so > that in case we do come up with something its no surprise PVOPs is > falling short for that single binary pipe dream right now. > > [0] https://lkml.org/lkml/2015/2/23/328 > > Luis >