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
| ||
|
Date: Fri, 16 Feb 2007 21:27:58 +0100 From: Arjan van de Ven <arjan@...radead.org> To: Dave Jones <davej@...hat.com> Cc: Pavel Machek <pavel@....cz>, David Howells <dhowells@...hat.com>, torvalds@...l.org, akpm@...l.org, herbert.xu@...hat.com, linux-kernel@...r.kernel.org, linux-crypto@...r.kernel.org Subject: Re: [PATCH 0/6] MODSIGN: Kernel module signing > > The restricted dev/mem patches we've had in Fedora for a while > do the right thing, but they're a bit crufty (in part due to > drivers/char/mem.c being a bit of a mess before we even start > patching it). I've had "clean these up for upstream" on my > todo for a while. I might get around to it one of these days. the real thing is that /dev/mem is too many things for too many people. Fundamentally it has 3 components 1) ram-but-not-kernel data: basically BIOS datastructures 2) kernel visible ram: user/kernel data, this has all the nasty cache coherency issues. This is also a "debug only" use, and "rootkit only" sometimes ;) 3) MMIO space: this really should not be used anymore, sysfs provides a MUCH better interface and it also breaks if you have enforcing IOMMU's in the system... it can't really work since the kernel doesn't get told which device is being accessed unless we split this up (well the third is split already) it's going to remain a big mess. -- if you want to mail me at work (you don't), use arjan (at) linux.intel.com Test the interaction between Linux and your BIOS via http://www.linuxfirmwarekit.org - 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/
Powered by blists - more mailing lists