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-prev] [day] [month] [year] [list]
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