linux-kernel - kasan_map_early

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 3 Mar 2015 01:40:00 -0800
From:	"Luis R. Rodriguez" <mcgrof@...e.com>
To:	Andrey Ryabinin <a.ryabinin@...sung.com>
Cc:	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	xen-devel@...ts.xenproject.org,
	Andy Lutomirski <luto@...capital.net>,
	Boris Ostrovsky <boris.ostrovsky@...cle.com>,
	Jeremy Fitzhardinge <jeremy@...p.org>,
	Chris Wright <chrisw@...s-sol.org>,
	Alok Kataria <akataria@...are.com>,
	Rusty Russell <rusty@...tcorp.com.au>,
	virtualization@...ts.linux-foundation.org
Subject: kasan_map_early_shadow() on Xen

Andrey,

I believe that on Xen we should disable kasan, would like confirmation
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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/