linux-kernel - Re: Turn CONFIG_STRICT_DEVMEM in sysctl dev.mem.restricted

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

Message-ID: <20081116080641.3f4c3dba@infradead.org>
Date:	Sun, 16 Nov 2008 08:06:41 -0800
From:	Arjan van de Ven <arjan@...radead.org>
To:	Bernhard Walle <bwalle@...e.de>
Cc:	x86@...nel.org, linux-kernel@...r.kernel.org,
	linux-arch@...r.kernel.org, crash-utility@...hat.com
Subject: Re: Turn CONFIG_STRICT_DEVMEM in sysctl dev.mem.restricted

On Sun, 16 Nov 2008 16:56:09 +0100
Bernhard Walle <bwalle@...e.de> wrote:

> > > While the original submission of CONFIG_STRICT_DEVMEM mentions
> > > that the option has been in RHEL and Fedora for 4 years without
> > > problems, that's only a half of the story. The truth is that at
> > > least RHEL has /dev/crash exactly to circumvent that /dev/mem
> > > restriction. Don't tell me that this is better than having that
> > > sysctl entry. ;-)
> > 
> > I assume /dev/crash is read only
> 
> I don't know. But if that matters, why can't we make /dev/mem
> write-only for certain areas and read-only for the rest ...?
> 
> > You either want this at compile time or you don't want it at all.
> 
> Why? You don't write something about my arguments (as Alan does, even
> though I disagree), you only write that you "nak" it.

It's very simple: if you want the strict form you really want the
strict form, not some half "oh but it's one line to turn off" form.


(Note: your usecase is in trouble in general already with PAT used by
modern video drivers: the requirement is that all mappings of the same
physical page are mapped with the same cachability semantics. mmaping
random parts of physical real memory via /dev/mem makes that a way too
complex issue and will likely turn the crash utility in what it's name
says ;-)

-- 
Arjan van de Ven 	Intel Open Source Technology Centre
For development, discussion and tips for power savings, 
visit http://www.lesswatts.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/