[PATCH 00/10] Enhance /dev/mem to allow read/write of arbitrary physical addresses

[PATCH 00/10] Enhance /dev/mem to allow read/write of arbitrary physical addresses

[Petr Tesarik]

This patch series enhances /dev/mem, so that read and write is possible
at any address. The patchset includes actual implementation for x86.

Petr Tesarik (10):
  Return EOF on out-of-bounds read from /dev/mem
  (un)xlate_dev_mem_ptr: use phys_addr_t for the @phys parameter
  x86: translate highmem /dev/mem pointers
  ia64: change xlate_dev_mem_ptr's argument to phys_addr_t
  valid_phys_addr_range: use phys_addr_t for the @addr parameter
  sh: change valid_phys_addr_range's @addr param to phys_addr_t
  arm: change valid_phys_addr_range's @addr param to phys_addr_t
  ia64: change valid_phys_addr_range's @addr param to phys_addr_t
  x86: provide arch-specific valid_phys_addr_range()
  Allow reading/writing all memory through /dev/mem

 arch/arm/include/asm/io.h       |    2 +-
 arch/arm/mm/mmap.c              |    2 +-
 arch/ia64/include/asm/io.h      |    2 +-
 arch/ia64/include/asm/uaccess.h |    2 +-
 arch/ia64/kernel/efi.c          |    2 +-
 arch/sh/include/asm/io.h        |    2 +-
 arch/sh/mm/mmap.c               |    2 +-
 arch/x86/include/asm/io.h       |   15 +++++++++++++--
 arch/x86/mm/ioremap.c           |   24 ++++++++++++++++++------
 drivers/char/mem.c              |   14 ++++++++++----
 10 files changed, 48 insertions(+), 19 deletions(-)

-- 
1.7.3.4

[PATCH 07/10] arm: change valid_phys_addr_range's @addr param to phys_addr_t

[Petr Tesarik]

No other changes are needed, the function will work just fine with
a potentially larger data type.


Signed-off-by: Petr Tesarik <ptesarik@suse.cz>
---
 arch/arm/include/asm/io.h |    2 +-
 arch/arm/mm/mmap.c        |    2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/include/asm/io.h b/arch/arm/include/asm/io.h
index d66605d..91e4ff2 100644
--- a/arch/arm/include/asm/io.h
+++ b/arch/arm/include/asm/io.h
@@ -290,7 +290,7 @@ extern void pci_iounmap(struct pci_dev *dev, void __iomem *addr);
 
 #ifdef CONFIG_MMU
 #define ARCH_HAS_VALID_PHYS_ADDR_RANGE
-extern int valid_phys_addr_range(unsigned long addr, size_t size);
+extern int valid_phys_addr_range(phys_addr_t addr, size_t size);
 extern int valid_mmap_phys_addr_range(unsigned long pfn, size_t size);
 extern int devmem_is_allowed(unsigned long pfn);
 #endif
diff --git a/arch/arm/mm/mmap.c b/arch/arm/mm/mmap.c
index 74be05f..3bf1d88 100644
--- a/arch/arm/mm/mmap.c
+++ b/arch/arm/mm/mmap.c
@@ -127,7 +127,7 @@ full_search:
  * You really shouldn't be using read() or write() on /dev/mem.  This
  * might go away in the future.
  */
-int valid_phys_addr_range(unsigned long addr, size_t size)
+int valid_phys_addr_range(phys_addr_t addr, size_t size)
 {
 	if (addr < PHYS_OFFSET)
 		return 0;
-- 
1.7.3.4

[PATCH 00/10] Enhance /dev/mem to allow read/write of arbitrary physical addresses

[Ingo Molnar]

* Petr Tesarik <ptesarik@suse.cz> wrote:

> This patch series enhances /dev/mem, so that read and write is 
> possible at any address. The patchset includes actual 
> implementation for x86.

This series lacks a description of why this is desired.

My strong opinion is that it's not desired at all: /dev/mem never 
worked beyond 4G addresses so by today it has become largely obsolete 
and is on the way out really.

I'm aware of these current /dev/mem uses:

 - Xorg maps below 4G non-RAM addresses and the video BIOS

 - It used to have some debugging role but these days kexec and kgdb 
   has largely taken over that role - partly due to the 4G limit.

 - there's some really horrible out-of-tree drivers that do mmap()s
   via /dev/mem, those should be fixed if they want to move beyond 
   4G: their char device should be mmap()able.

 - all distro kernel's i'm aware of use CONFIG_STRICT_DEVMEM=y, which
   restricts /dev/mem to non-RAM pages of physical memory.
   [ With the sad inclusion of the first 1MB, which Xorg needs. ]

Are you aware of any legitimate usecases?

Frankly, i dont think we ever *want* to 'fix' /dev/mem to support 
addresses beyond 4G and grow messy userspace (and kernelspace) that 
somehow relies on that. Thank goodness that we never supported it ...

Thanks,

	Ingo

[PATCH 00/10] Enhance /dev/mem to allow read/write of arbitrary physical addresses

[Russell King - ARM Linux]

On Fri, Jun 17, 2011 at 11:30:32AM +0200, Ingo Molnar wrote:
> I'm aware of these current /dev/mem uses:
> 
>  - Xorg maps below 4G non-RAM addresses and the video BIOS
> 
>  - It used to have some debugging role but these days kexec and kgdb 
>    has largely taken over that role - partly due to the 4G limit.
> 
>  - there's some really horrible out-of-tree drivers that do mmap()s
>    via /dev/mem, those should be fixed if they want to move beyond 
>    4G: their char device should be mmap()able.
> 
>  - all distro kernel's i'm aware of use CONFIG_STRICT_DEVMEM=y, which
>    restricts /dev/mem to non-RAM pages of physical memory.
>    [ With the sad inclusion of the first 1MB, which Xorg needs. ]

There's another use case for /dev/mem:

 - debugging via devmem2 on embedded platforms, where you want to be able
   to boot a kernel, and then peek and poke at MMIO registers either to
   verify register values or test things out.

[PATCH 00/10] Enhance /dev/mem to allow read/write of arbitrary physical addresses

[Petr Tesarik]

Dne P? 17. ?ervna 2011 11:30:32 Ingo Molnar napsal(a):
> * Petr Tesarik <ptesarik@suse.cz> wrote:
> > This patch series enhances /dev/mem, so that read and write is
> > possible at any address. The patchset includes actual
> > implementation for x86.
> 
> This series lacks a description of why this is desired.

Hi Ingo,

> My strong opinion is that it's not desired at all: /dev/mem never
> worked beyond 4G addresses so by today it has become largely obsolete
> and is on the way out really.
> 
> I'm aware of these current /dev/mem uses:
> 
>  - Xorg maps below 4G non-RAM addresses and the video BIOS
> 
>  - It used to have some debugging role but these days kexec and kgdb
>    has largely taken over that role - partly due to the 4G limit.

It is still used as a "memory source" by Dave Anderson's crash utility for 
live examination of a running system. Redhat has "overcome" the /dev/mem 
deficiencies by writing an out-of-tree re-implementation of /dev/mem, which 
uses /dev/crash instead. As it is an "unnecessary duplication of an existing 
driver", this method was rejected by the project manager here at SUSE.

The suggested alternative was to enhance (or fix) the existing driver. Without 
this patch series there is no way to access high memory. In conjunction with 
CONFIG_HIGHPTE, it makes the crash utility near to useless on anything with 
high memory, because crash can no longer translate virtual to physical 
addresses.

>  - there's some really horrible out-of-tree drivers that do mmap()s
>    via /dev/mem, those should be fixed if they want to move beyond
>    4G: their char device should be mmap()able.
> 
>  - all distro kernel's i'm aware of use CONFIG_STRICT_DEVMEM=y, which
>    restricts /dev/mem to non-RAM pages of physical memory.
>    [ With the sad inclusion of the first 1MB, which Xorg needs. ]

Well, there's one (quite unimportant) distro that doesn't compile with 
CONFIG_STRICT_DEVMEM: openSUSE (and SLES, consequently).

> Are you aware of any legitimate usecases?

See above - live crash sessions on i586 (or any other arch that has high 
memory).

> Frankly, i dont think we ever *want* to 'fix' /dev/mem to support
> addresses beyond 4G and grow messy userspace (and kernelspace) that
> somehow relies on that. Thank goodness that we never supported it ...

Let me put it differently. Do you think that an out-of-tree duplicated effort 
(the crash.ko module) offered by Redhat is somehow superior to enhancing the 
in-tree /dev/mem driver?

Regards,
Petr Tesarik

[PATCH 00/10] Enhance /dev/mem to allow read/write of arbitrary physical addresses

[Américo Wang]

On Fri, Jun 17, 2011 at 5:55 PM, Petr Tesarik <ptesarik@suse.cz> wrote:
> Dne P? 17. ?ervna 2011 11:30:32 Ingo Molnar napsal(a):
>> * Petr Tesarik <ptesarik@suse.cz> wrote:
>> > This patch series enhances /dev/mem, so that read and write is
>> > possible at any address. The patchset includes actual
>> > implementation for x86.
>>
>> This series lacks a description of why this is desired.
>
> Hi Ingo,
>
>> My strong opinion is that it's not desired at all: /dev/mem never
>> worked beyond 4G addresses so by today it has become largely obsolete
>> and is on the way out really.
>>
>> I'm aware of these current /dev/mem uses:
>>
>> ?- Xorg maps below 4G non-RAM addresses and the video BIOS
>>
>> ?- It used to have some debugging role but these days kexec and kgdb
>> ? ?has largely taken over that role - partly due to the 4G limit.
>
> It is still used as a "memory source" by Dave Anderson's crash utility for
> live examination of a running system. Redhat has "overcome" the /dev/mem
> deficiencies by writing an out-of-tree re-implementation of /dev/mem, which
> uses /dev/crash instead. As it is an "unnecessary duplication of an existing
> driver", this method was rejected by the project manager here at SUSE.
>
> The suggested alternative was to enhance (or fix) the existing driver. Without
> this patch series there is no way to access high memory. In conjunction with
> CONFIG_HIGHPTE, it makes the crash utility near to useless on anything with
> high memory, because crash can no longer translate virtual to physical
> addresses.
>

How about /proc/kcore? AFAIK, it can access highmem, but Dave didn't consider
it for some reason.

[PATCH 00/10] Enhance /dev/mem to allow read/write of arbitrary physical addresses

[Petr Tesarik]

Am?rico Wang p??e v Po 20. 06. 2011 v 10:42 +0800:
> On Fri, Jun 17, 2011 at 5:55 PM, Petr Tesarik <ptesarik@suse.cz> wrote:
> > Dne P? 17. ?ervna 2011 11:30:32 Ingo Molnar napsal(a):
> >> * Petr Tesarik <ptesarik@suse.cz> wrote:
> >> > This patch series enhances /dev/mem, so that read and write is
> >> > possible at any address. The patchset includes actual
> >> > implementation for x86.
> >>
> >> This series lacks a description of why this is desired.
> >
> > Hi Ingo,
> >
> >> My strong opinion is that it's not desired at all: /dev/mem never
> >> worked beyond 4G addresses so by today it has become largely obsolete
> >> and is on the way out really.
> >>
> >> I'm aware of these current /dev/mem uses:
> >>
> >>  - Xorg maps below 4G non-RAM addresses and the video BIOS
> >>
> >>  - It used to have some debugging role but these days kexec and kgdb
> >>    has largely taken over that role - partly due to the 4G limit.
> >
> > It is still used as a "memory source" by Dave Anderson's crash utility for
> > live examination of a running system. Redhat has "overcome" the /dev/mem
> > deficiencies by writing an out-of-tree re-implementation of /dev/mem, which
> > uses /dev/crash instead. As it is an "unnecessary duplication of an existing
> > driver", this method was rejected by the project manager here at SUSE.
> >
> > The suggested alternative was to enhance (or fix) the existing driver. Without
> > this patch series there is no way to access high memory. In conjunction with
> > CONFIG_HIGHPTE, it makes the crash utility near to useless on anything with
> > high memory, because crash can no longer translate virtual to physical
> > addresses.
> >
> 
> How about /proc/kcore? AFAIK, it can access highmem, but Dave didn't consider
> it for some reason.

(Sorry for the dealy, I was on vacation.)

/proc/kcore is in fact supported by the crash utility and it does work
with highmem to some extent. Unfortunately, it cannot handle all of it,
because it is ELF32 format, so there's no way to describe regions beyond
4GB.

Petr Tesarik

[PATCH 00/10] Enhance /dev/mem to allow read/write of arbitrary physical addresses

[Ryan Mallon]

On 17/06/11 19:30, Ingo Molnar wrote:
> * Petr Tesarik<ptesarik@suse.cz>  wrote:
>
>> This patch series enhances /dev/mem, so that read and write is
>> possible at any address. The patchset includes actual
>> implementation for x86.
> This series lacks a description of why this is desired.
>
> My strong opinion is that it's not desired at all: /dev/mem never
> worked beyond 4G addresses so by today it has become largely obsolete
> and is on the way out really.
>
> I'm aware of these current /dev/mem uses:
>
>   - Xorg maps below 4G non-RAM addresses and the video BIOS
>
>   - It used to have some debugging role but these days kexec and kgdb
>     has largely taken over that role - partly due to the 4G limit.
>
>   - there's some really horrible out-of-tree drivers that do mmap()s
>     via /dev/mem, those should be fixed if they want to move beyond
>     4G: their char device should be mmap()able.

There are drivers where this makes sense. For example an FPGA device 
with a proprietary register layout on the memory bus can be done this 
way. The FPGA can simply be mapped in user-space via /dev/mem and 
handled there. If the device requires no access other than memory bus 
reads and writes then writing a custom char device driver just to get an 
mmap function seems a bit overkill.

~Ryan

[PATCH 00/10] Enhance /dev/mem to allow read/write of arbitrary physical addresses

[H. Peter Anvin]

On 06/19/2011 04:02 PM, Ryan Mallon wrote:
> On 17/06/11 19:30, Ingo Molnar wrote:
>> * Petr Tesarik<ptesarik@suse.cz>  wrote:
>>
>>> This patch series enhances /dev/mem, so that read and write is
>>> possible at any address. The patchset includes actual
>>> implementation for x86.
>> This series lacks a description of why this is desired.
>>
>> My strong opinion is that it's not desired at all: /dev/mem never
>> worked beyond 4G addresses so by today it has become largely obsolete
>> and is on the way out really.
>>
>> I'm aware of these current /dev/mem uses:
>>
>>   - Xorg maps below 4G non-RAM addresses and the video BIOS
>>
>>   - It used to have some debugging role but these days kexec and kgdb
>>     has largely taken over that role - partly due to the 4G limit.
>>
>>   - there's some really horrible out-of-tree drivers that do mmap()s
>>     via /dev/mem, those should be fixed if they want to move beyond
>>     4G: their char device should be mmap()able.
> 
> There are drivers where this makes sense. For example an FPGA device
> with a proprietary register layout on the memory bus can be done this
> way. The FPGA can simply be mapped in user-space via /dev/mem and
> handled there. If the device requires no access other than memory bus
> reads and writes then writing a custom char device driver just to get an
> mmap function seems a bit overkill.
> 

There are some test drivers which really want /dev/mem to work.

FPGA devices like that really should be exported as resources from a
platform driver or device tree driver, at which point those resources
can be memory-mapped.  That being said, using /dev/mem for fixed
resources is semicommon.

	-hpa

-- 
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel.  I don't speak on their behalf.

[PATCH 00/10] Enhance /dev/mem to allow read/write of arbitrary physical addresses

[Ingo Molnar]

* H. Peter Anvin <hpa@zytor.com> wrote:

> There are some test drivers which really want /dev/mem to work.

Test drivers and test hardware with zero enumeration can use below 4G 
addresses just fine.

Also, debugging is not an issue and some non-default kernel or boot 
option can enable any sort of device i guess, so my main worry isnt 
really security but that we should stand in the way of the apparent 
practice of *shipping* user-space drivers that use /dev/mem ...

Thanks,

	Ingo

[PATCH 00/10] Enhance /dev/mem to allow read/write of arbitrary physical addresses

[H. Peter Anvin]

On 06/20/2011 12:41 AM, Ingo Molnar wrote:
> 
> * H. Peter Anvin <hpa@zytor.com> wrote:
> 
>> There are some test drivers which really want /dev/mem to work.
> 
> Test drivers and test hardware with zero enumeration can use below 4G 
> addresses just fine.
>
> Also, debugging is not an issue and some non-default kernel or boot 
> option can enable any sort of device i guess, so my main worry isnt 
> really security but that we should stand in the way of the apparent 
> practice of *shipping* user-space drivers that use /dev/mem ...
> 

We should either fix /dev/mem to work according to its specification or
rip it out.  The issue with test drivers is not spurious... I ran into
this one myself a few weeks ago while trying to do a memory test (by
limiting the amount of memory available to the kernel).  This is
something that is typically done on factory floors, and it would be nice
to be able to get those environments over to using Linux.

	-hpa

-- 
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel.  I don't speak on their behalf.

[PATCH 00/10] Enhance /dev/mem to allow read/write of arbitrary physical addresses

[Ingo Molnar]

* H. Peter Anvin <hpa@zytor.com> wrote:

> On 06/20/2011 12:41 AM, Ingo Molnar wrote:
> > 
> > * H. Peter Anvin <hpa@zytor.com> wrote:
> > 
> >> There are some test drivers which really want /dev/mem to work.
> > 
> > Test drivers and test hardware with zero enumeration can use below 4G 
> > addresses just fine.
> >
> > Also, debugging is not an issue and some non-default kernel or boot 
> > option can enable any sort of device i guess, so my main worry isnt 
> > really security but that we should stand in the way of the apparent 
> > practice of *shipping* user-space drivers that use /dev/mem ...
> > 
> 
> We should either fix /dev/mem to work according to its 
> specification or rip it out.  The issue with test drivers is not 
> spurious... I ran into this one myself a few weeks ago while trying 
> to do a memory test (by limiting the amount of memory available to 
> the kernel).  This is something that is typically done on factory 
> floors, and it would be nice to be able to get those environments 
> over to using Linux.

There is no reason why they couldnt use a .config option or a boot 
option to get their weird stuff going, which weird stuff also happens 
to be useful.

What i'm somewhat against is having this enabled by default for weird 
stuff that also happens to be harmful - and the fact that it never 
worked over 4G physical gives us the perfect opportunity to do just 
that.

Thanks,

	Ingo

[PATCH 00/10] Enhance /dev/mem to allow read/write of arbitrary physical addresses

[H. Peter Anvin]

On 06/20/2011 09:40 AM, Ingo Molnar wrote:
> 
> There is no reason why they couldnt use a .config option or a boot 
> option to get their weird stuff going, which weird stuff also happens 
> to be useful.
> 
> What i'm somewhat against is having this enabled by default for weird 
> stuff that also happens to be harmful - and the fact that it never 
> worked over 4G physical gives us the perfect opportunity to do just 
> that.
> 

I'm concerned about that notion.  I think it's fine to modularize
/dev/mem, but what we're seeing is that Red Hat and all kinds of other
entities are putting in ad hoc versions of /dev/mem, but of course doing
so incorrectly.

	-hpa

-- 
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel.  I don't speak on their behalf.

[PATCH 00/10] Enhance /dev/mem to allow read/write of arbitrary physical addresses

[Srivatsa Vaddagiri]

On Mon, Jun 20, 2011 at 08:59:20AM -0700, H. Peter Anvin wrote:
> We should either fix /dev/mem to work according to its specification or
> rip it out.  The issue with test drivers is not spurious... I ran into
> this one myself a few weeks ago while trying to do a memory test (by
> limiting the amount of memory available to the kernel).  This is
> something that is typically done on factory floors, and it would be nice
> to be able to get those environments over to using Linux.

We came across a similar request from our manufacturing folks. They have a
memory stress tool that needs to test how much bandwidth is possible between
various cpus and memory modules. Essentially they want the tool to run on some
chosen CPU and want it to drive traffic to some chosen memory module.

/dev/mem would be handy for such test programs ..

- vatsa

[PATCH 00/10] Enhance /dev/mem to allow read/write of arbitrary physical addresses

[Matthew Wilcox]

On Mon, Jun 20, 2011 at 09:02:17AM +1000, Ryan Mallon wrote:
> There are drivers where this makes sense. For example an FPGA device  
> with a proprietary register layout on the memory bus can be done this  
> way. The FPGA can simply be mapped in user-space via /dev/mem and  
> handled there. If the device requires no access other than memory bus  
> reads and writes then writing a custom char device driver just to get an  
> mmap function seems a bit overkill.

Calling a 30 line device driver "overkill" might in itself be overkill?

-- 
Matthew Wilcox				Intel Open Source Technology Centre
"Bill, look, we understand that you're interested in selling us this
operating system, but compare it to ours.  We can't possibly take such
a retrograde step."

[PATCH 00/10] Enhance /dev/mem to allow read/write of arbitrary physical addresses

[Ryan Mallon]

On 20/06/11 10:42, Matthew Wilcox wrote:
> On Mon, Jun 20, 2011 at 09:02:17AM +1000, Ryan Mallon wrote:
>> There are drivers where this makes sense. For example an FPGA device
>> with a proprietary register layout on the memory bus can be done this
>> way. The FPGA can simply be mapped in user-space via /dev/mem and
>> handled there. If the device requires no access other than memory bus
>> reads and writes then writing a custom char device driver just to get an
>> mmap function seems a bit overkill.
> Calling a 30 line device driver "overkill" might in itself be overkill?
>
I mean overkill in the sense of having to write the driver at all. Why 
write a 30 line driver just to re-implement some functionality of /dev/mem?

~Ryan

[PATCH 00/10] Enhance /dev/mem to allow read/write of arbitrary physical addresses

[Matthew Wilcox]

On Mon, Jun 20, 2011 at 10:46:08AM +1000, Ryan Mallon wrote:
> On 20/06/11 10:42, Matthew Wilcox wrote:
>> On Mon, Jun 20, 2011 at 09:02:17AM +1000, Ryan Mallon wrote:
>>> There are drivers where this makes sense. For example an FPGA device
>>> with a proprietary register layout on the memory bus can be done this
>>> way. The FPGA can simply be mapped in user-space via /dev/mem and
>>> handled there. If the device requires no access other than memory bus
>>> reads and writes then writing a custom char device driver just to get an
>>> mmap function seems a bit overkill.
>> Calling a 30 line device driver "overkill" might in itself be overkill?
>>
> I mean overkill in the sense of having to write the driver at all. Why  
> write a 30 line driver just to re-implement some functionality of 
> /dev/mem?

Because it pushes the tradeoff in the right direction.  Somebody wants
to do something weird is a little inconvenienced vs protecting the vast
majority of users from some security escalation problems.

Besides, if you have a real bus with discoverable regions
(like PCI BARs), the bus should have sysfs entries like
/sys/bus/pci/devices/0000\:06\:06.0/resource0 that can be mmaped.
Then there's no need for a device driver at all, *and* the privilege
escalation isn't achievable.

Of course, most embedded architectures have crap discoverability.

-- 
Matthew Wilcox				Intel Open Source Technology Centre
"Bill, look, we understand that you're interested in selling us this
operating system, but compare it to ours.  We can't possibly take such
a retrograde step."

[PATCH 00/10] Enhance /dev/mem to allow read/write of arbitrary physical addresses

[Ryan Mallon]

On 20/06/11 10:52, Matthew Wilcox wrote:
> On Mon, Jun 20, 2011 at 10:46:08AM +1000, Ryan Mallon wrote:
>> On 20/06/11 10:42, Matthew Wilcox wrote:
>>> On Mon, Jun 20, 2011 at 09:02:17AM +1000, Ryan Mallon wrote:
>>>> There are drivers where this makes sense. For example an FPGA device
>>>> with a proprietary register layout on the memory bus can be done this
>>>> way. The FPGA can simply be mapped in user-space via /dev/mem and
>>>> handled there. If the device requires no access other than memory bus
>>>> reads and writes then writing a custom char device driver just to get an
>>>> mmap function seems a bit overkill.
>>> Calling a 30 line device driver "overkill" might in itself be overkill?
>>>
>> I mean overkill in the sense of having to write the driver at all. Why
>> write a 30 line driver just to re-implement some functionality of
>> /dev/mem?
> Because it pushes the tradeoff in the right direction.  Somebody wants
> to do something weird is a little inconvenienced vs protecting the vast
> majority of users from some security escalation problems.
How does it protect against security escalation? A process mapping a 
region either from /dev/mem or from some custom char device can't escape 
that region right? In either case you need root privileges to make the 
mapping in the first place.
> Besides, if you have a real bus with discoverable regions
> (like PCI BARs), the bus should have sysfs entries like
> /sys/bus/pci/devices/0000\:06\:06.0/resource0 that can be mmaped.
> Then there's no need for a device driver at all, *and* the privilege
> escalation isn't achievable.
>
> Of course, most embedded architectures have crap discoverability.
Which is also where devices like FPGAs tend to exist :-).

~Ryan

[PATCH 00/10] Enhance /dev/mem to allow read/write of arbitrary physical addresses

[Ingo Molnar]

* Ryan Mallon <rmallon@gmail.com> wrote:

> On 17/06/11 19:30, Ingo Molnar wrote:
> >* Petr Tesarik<ptesarik@suse.cz>  wrote:
> >
> >>This patch series enhances /dev/mem, so that read and write is
> >>possible at any address. The patchset includes actual
> >>implementation for x86.
> >This series lacks a description of why this is desired.
> >
> >My strong opinion is that it's not desired at all: /dev/mem never
> >worked beyond 4G addresses so by today it has become largely obsolete
> >and is on the way out really.
> >
> >I'm aware of these current /dev/mem uses:
> >
> >  - Xorg maps below 4G non-RAM addresses and the video BIOS
> >
> >  - It used to have some debugging role but these days kexec and kgdb
> >    has largely taken over that role - partly due to the 4G limit.
> >
> >  - there's some really horrible out-of-tree drivers that do mmap()s
> >    via /dev/mem, those should be fixed if they want to move beyond
> >    4G: their char device should be mmap()able.
> 
> There are drivers where this makes sense. For example an FPGA 
> device with a proprietary register layout on the memory bus can be 
> done this way. [...]

So you want us to help vendors screw users with insane, proprietary, 
user-space drivers with sekrit binary blobs?

Wow.

Thanks,

	Ingo

[PATCH 00/10] Enhance /dev/mem to allow read/write of arbitrary physical addresses

[Ryan Mallon]

On 20/06/11 17:31, Ingo Molnar wrote:
> * Ryan Mallon <rmallon@gmail.com> wrote:
>
>> On 17/06/11 19:30, Ingo Molnar wrote:
>>> * Petr Tesarik<ptesarik@suse.cz>  wrote:
>>>
>>>> This patch series enhances /dev/mem, so that read and write is
>>>> possible at any address. The patchset includes actual
>>>> implementation for x86.
>>> This series lacks a description of why this is desired.
>>>
>>> My strong opinion is that it's not desired at all: /dev/mem never
>>> worked beyond 4G addresses so by today it has become largely obsolete
>>> and is on the way out really.
>>>
>>> I'm aware of these current /dev/mem uses:
>>>
>>>  - Xorg maps below 4G non-RAM addresses and the video BIOS
>>>
>>>  - It used to have some debugging role but these days kexec and kgdb
>>>    has largely taken over that role - partly due to the 4G limit.
>>>
>>>  - there's some really horrible out-of-tree drivers that do mmap()s
>>>    via /dev/mem, those should be fixed if they want to move beyond
>>>    4G: their char device should be mmap()able.
>> There are drivers where this makes sense. For example an FPGA 
>> device with a proprietary register layout on the memory bus can be 
>> done this way. [...]
> So you want us to help vendors screw users with insane, proprietary, 
> user-space drivers with sekrit binary blobs?
>
> Wow.
It's not about that. I mean proprietary in the sense that the register
layout is not based on some open spec and is customised to some
particular usage, not that it is evil, anti-GPL and "sekrit". I have
worked on embedded products which have custom FPGAs for _very_ dedicated
usage. The FPGA firmware is company IP and therefore not open (which is
nothing to do with Linux). The types of products I'm talking about are
often very niche market and dedicate use and therefore not a case of
vendors screwing over the general public. Writing the drivers in
user-space makes development easier; it's not an attempt to hide code
from the public. There is nothing to stop a /dev/mem userspace driver
from being open, just as there is nothing to stop a kernel driver for a
closed platform under Linux being "closed".

~Ryan

[PATCH 00/10] Enhance /dev/mem to allow read/write of arbitrary physical addresses

[Ray Lee]

On Sun, Jun 19, 2011 at 4:02 PM, Ryan Mallon <rmallon@gmail.com> wrote:
> On 17/06/11 19:30, Ingo Molnar wrote:
>> ?- there's some really horrible out-of-tree drivers that do mmap()s
>> ? ?via /dev/mem, those should be fixed if they want to move beyond
>> ? ?4G: their char device should be mmap()able.
>
> There are drivers where this makes sense. For example an FPGA device with a
> proprietary register layout on the memory bus can be done this way. The FPGA
> can simply be mapped in user-space via /dev/mem and handled there. If the
> device requires no access other than memory bus reads and writes then
> writing a custom char device driver just to get an mmap function seems a bit
> overkill.

While VFIO is still out-of-tree, it handles this use-case, as well as
interrupts and transparent DMA remapping via the IOMMU. I'm using it
on a current project and it works as advertised. UIO is in-tree and
also handles this (as I understand it), but without DMA or interrupt
support.

   https://github.com/pugs/vfio-linux-2.6/blob/vfio/Documentation/vfio.txt

It's perhaps arguable whether any human with taste should ship a
driver based on UIO/VFIO, but for code that exists solely to exercise
and test a hardware design, it works great.

~r.

[PATCH 00/10] Enhance /dev/mem to allow read/write of arbitrary physical addresses

[Petr Tesarik]

Dne P? 17. ?ervna 2011 11:30:32 Ingo Molnar napsal(a):
> * Petr Tesarik <ptesarik@suse.cz> wrote:
> > This patch series enhances /dev/mem, so that read and write is
> > possible at any address. The patchset includes actual
> > implementation for x86.
> 
> This series lacks a description of why this is desired.
>[...]
> 
> Are you aware of any legitimate usecases?

Looking back at the mail tread, I'd say there are people who have legitimate 
usecases. However, this may not be the most important question. At the moment, 
the /dev/mem interface is broken (it doesn't implement the specification 
correctly), and my patchset fixes it.

If there are no technical objections, I'd like to ask for an Acked-by from all 
involved people.

@Ingo: you can also send a patchset that rips off the /dev/mem driver 
completely if you believe that would get through. I'm completely fine with 
that, because then the /dev/crash driver will no longer be a semi-broken re-
implementation of an existing in-kernel driver, so I'll be able to post it as 
a new driver.

But please make a decision either way.

Petr Tesarik

[PATCH 00/10] Enhance /dev/mem to allow read/write of arbitrary physical addresses

[Ingo Molnar]

* Petr Tesarik <ptesarik@suse.cz> wrote:

> Dne P? 17. ?ervna 2011 11:30:32 Ingo Molnar napsal(a):
> > * Petr Tesarik <ptesarik@suse.cz> wrote:
> > > This patch series enhances /dev/mem, so that read and write is
> > > possible at any address. The patchset includes actual
> > > implementation for x86.
> > 
> > This series lacks a description of why this is desired.
> >[...]
> > 
> > Are you aware of any legitimate usecases?
> 
> Looking back at the mail tread, I'd say there are people who have 
> legitimate usecases. However, this may not be the most important 
> question. At the moment, the /dev/mem interface is broken (it 
> doesn't implement the specification correctly), and my patchset 
> fixes it.
> 
> If there are no technical objections, [...]

Well, my objections were entirely technical:

 - the device never implemented above-4G support upstream

 - there's colorful variants of abuse (drivers with binary-only
   userspace) even if we ignore the obvious fact that the
   main use of /dev/mem today is /dev/rootkit ...

Now my objections might be outweighed by the advantages of improving 
this driver, but you misrepresenting my position really does not help 
that process.

So what was not mentioned in your series, what is *your* motivation 
and your usecase? Enabling closed-source userspace drivers? Enabling 
the crash utility?

If the former then shame on you, if the latter then how do you 
explain that distros appear to disable the RAM aspect of /dev/mem:

 $ grep DEVMEM $(rpm -ql kernel-2.6.38-0.rc7.git2.3.fc16.x86_64 | grep config-2.6 )
 CONFIG_STRICT_DEVMEM=y

So the crash utility use-case does not work on unpatched, default 
kernels, right?

As i said i have no problem with extending this, as long as it 
couples to a non-default flag (for example !STRICT_DEVMEM or a boot 
flag) and thus does not extend by default and does not extend the 
abuse.

> @Ingo: you can also send a patchset that rips off the /dev/mem 
> driver completely if you believe that would get through. [...]

Why would we want to do that? Existing users can become more and more 
obsolete just fine.

What i'm asking for is to not enable new abuse by default ...

Thanks,

	Ingo

[PATCH 00/10] Enhance /dev/mem to allow read/write of arbitrary physical addresses

[Petr Tesarik]

Dne P? 1. ?ervence 2011 14:58:02 Ingo Molnar napsal(a):
> * Petr Tesarik <ptesarik@suse.cz> wrote:
> > Dne P? 17. ?ervna 2011 11:30:32 Ingo Molnar napsal(a):
> > > * Petr Tesarik <ptesarik@suse.cz> wrote:
> > > > This patch series enhances /dev/mem, so that read and write is
> > > > possible at any address. The patchset includes actual
> > > > implementation for x86.
> > > 
> > > This series lacks a description of why this is desired.
> > >
> > >[...]
> > >
> > > Are you aware of any legitimate usecases?
> > 
> > Looking back at the mail tread, I'd say there are people who have
> > legitimate usecases. However, this may not be the most important
> > question. At the moment, the /dev/mem interface is broken (it
> > doesn't implement the specification correctly), and my patchset
> > fixes it.
> > 
> > If there are no technical objections, [...]
> 
> Well, my objections were entirely technical:
> 
>  - the device never implemented above-4G support upstream
> 
>  - there's colorful variants of abuse (drivers with binary-only
>    userspace) even if we ignore the obvious fact that the
>    main use of /dev/mem today is /dev/rootkit ...
> 
> Now my objections might be outweighed by the advantages of improving
> this driver, but you misrepresenting my position really does not help
> that process.
> 
> So what was not mentioned in your series, what is *your* motivation
> and your usecase? Enabling closed-source userspace drivers? Enabling
> the crash utility?

I think I made it clear that my use-case is enabling the crash utility. But I 
can re-state it now, no problem. ;)

> If the former then shame on you, if the latter then how do you
> explain that distros appear to disable the RAM aspect of /dev/mem:
> 
>  $ grep DEVMEM $(rpm -ql kernel-2.6.38-0.rc7.git2.3.fc16.x86_64 | grep
> config-2.6 ) CONFIG_STRICT_DEVMEM=y

I've already addressed this point as well. Fedora and RHEL ship with 
CONFIG_STRICT_DEVMEM=y. openSUSE and SLES ship with CONFIG_STRICT_DEVMEM=n.

> So the crash utility use-case does not work on unpatched, default
> kernels, right?

Right. And even told you how RedHat "solved" that issue. They re-implemented 
the /dev/mem driver and called it /dev/crash. RHEL4 and RHEL5 included this as 
a separate module (called crash.ko), so you can at least blacklist it. With 
RHEL6, the driver is built into the kernel, so it's probably always there.

In short, if you're breaking into a system, remember to symlink /dev/rootkit 
to /dev/crash instead of /dev/mem, and your rootkit will continue to work. 
Anyway, I fail to see how this can be a problem. To acces /dev/mem you must 
have root privileges already, so what else does it protect?

> As i said i have no problem with extending this, as long as it
> couples to a non-default flag (for example !STRICT_DEVMEM or a boot
> flag) and thus does not extend by default and does not extend the
> abuse.

I'm not sure what you mean. If you have a kernel compiled with 
CONFIG_STRICT_DEVMEM, then my patchset doesn't change anything in practice 
(unless you have an MMIO device mapped above 4G, in which case it will allow 
you to program it by writing to /dev/mem, instead of wrapping around to a 
random area in the first 4G and corrupting innocent data).

Hope that helps,
Petr Tesarik

> > @Ingo: you can also send a patchset that rips off the /dev/mem
> > driver completely if you believe that would get through. [...]
> 
> Why would we want to do that? Existing users can become more and more
> obsolete just fine.
> 
> What i'm asking for is to not enable new abuse by default ...
> 
> Thanks,
> 
> 	Ingo

[PATCH 00/10] Enhance /dev/mem to allow read/write of arbitrary physical addresses

[Christoph Hellwig]

On Fri, Jul 01, 2011 at 02:58:02PM +0200, Ingo Molnar wrote:
> So what was not mentioned in your series, what is *your* motivation 
> and your usecase? Enabling closed-source userspace drivers? Enabling 
> the crash utility?

He stated it pretty clearly in the thread, it's the crash utility.

> 
> If the former then shame on you, if the latter then how do you 
> explain that distros appear to disable the RAM aspect of /dev/mem:
> 
>  $ grep DEVMEM $(rpm -ql kernel-2.6.38-0.rc7.git2.3.fc16.x86_64 | grep config-2.6 )
>  CONFIG_STRICT_DEVMEM=y
> 
> So the crash utility use-case does not work on unpatched, default 
> kernels, right?

Not if you have highmem.  That's why Redhat or Fedora to quote your
example patch in the /dev/crash driver, which totally defeats the
CONFIG_STRICT_DEVMEM setting.  But apparently it's good enough that no
one either noticed or at least doesn't care.

[PATCH 00/10] Enhance /dev/mem to allow read/write of arbitrary physical addresses

[Ingo Molnar]

* Christoph Hellwig <hch@infradead.org> wrote:

> On Fri, Jul 01, 2011 at 02:58:02PM +0200, Ingo Molnar wrote:
> > So what was not mentioned in your series, what is *your* motivation 
> > and your usecase? Enabling closed-source userspace drivers? Enabling 
> > the crash utility?
> 
> He stated it pretty clearly in the thread, it's the crash utility.

True. I only re-read the first patch and forgot about the resulting 
discussion. Sorry Petr!

> > If the former then shame on you, if the latter then how do you 
> > explain that distros appear to disable the RAM aspect of 
> > /dev/mem:
> > 
> >  $ grep DEVMEM $(rpm -ql kernel-2.6.38-0.rc7.git2.3.fc16.x86_64 | grep config-2.6 )
> >  CONFIG_STRICT_DEVMEM=y
> > 
> > So the crash utility use-case does not work on unpatched, default 
> > kernels, right?
> 
> Not if you have highmem.  That's why Redhat or Fedora to quote your
> example patch in the /dev/crash driver, which totally defeats the
> CONFIG_STRICT_DEVMEM setting.  But apparently it's good enough that no
> one either noticed or at least doesn't care.

After initial modules have loaded i essentially disable crash.ko via 
/proc/sys/kernel/modules_disabled so rootkits have to work a bit 
harder than that.

But yeah, crash.ko is a rootkit-and-other-badness-enabler as it 
stands today.

Thanks,

	Ingo

[PATCH 00/10] Enhance /dev/mem to allow read/write of arbitrary physical addresses

[Christoph Hellwig]

On Fri, Jul 01, 2011 at 04:37:35PM +0200, Ingo Molnar wrote:
> After initial modules have loaded i essentially disable crash.ko via 
> /proc/sys/kernel/modules_disabled so rootkits have to work a bit 
> harder than that.

Not sure for fedora as I don'[t have a kernel tree at hand right now,
but for x86 systems at least RHEL6 has the module built in.  Either
way we'll need some way to support crash properly in mainline,
preferably in a boot-time opt-in way.  I'd tend slightly toward
optionally enabling /dev/mem for it instead of a separate driver, but
if people prefer a different route I'm fine, too.

Note that for normal crash usage read only access is just fine.

[PATCH 00/10] Enhance /dev/mem to allow read/write of arbitrary physical addresses

[Ingo Molnar]

* Christoph Hellwig <hch@infradead.org> wrote:

> On Fri, Jul 01, 2011 at 04:37:35PM +0200, Ingo Molnar wrote:
>
> > After initial modules have loaded i essentially disable crash.ko 
> > via /proc/sys/kernel/modules_disabled so rootkits have to work a 
> > bit harder than that.
> 
> Not sure for fedora as I don'[t have a kernel tree at hand right 
> now, but for x86 systems at least RHEL6 has the module built in. 
> [...]

Fedora Rawhide has it modular:

 # grep CRASH /boot/config-2.6.38-0.rc7.git2.3.fc16.x86_64
 CONFIG_CRASH=m

 # rpm -ql kernel-2.6.38-0.rc7.git2.3.fc16.x86_64 | grep crash
 /lib/modules/2.6.38-0.rc7.git2.3.fc16.x86_64/kernel/drivers/char/crash.ko

> [...]  Either way we'll need some way to support crash properly in 
> mainline, preferably in a boot-time opt-in way. [...]

Yes, boot-time opt-in was what i suggested.

> [...] I'd tend slightly toward optionally enabling /dev/mem for it 
> instead of a separate driver, but if people prefer a different 
> route I'm fine, too.

No, sharing the driver is perfectly fine and sane as long as this 
weird usage is not enabled widely.

> Note that for normal crash usage read only access is just fine.

That's true as well. Petr?

Thanks,

	Ingo

[PATCH 00/10] Enhance /dev/mem to allow read/write of arbitrary physical addresses

[Petr Tesarik]

Dne P? 1. ?ervence 2011 16:46:41 Ingo Molnar napsal(a):
> * Christoph Hellwig <hch@infradead.org> wrote:
> > On Fri, Jul 01, 2011 at 04:37:35PM +0200, Ingo Molnar wrote:
> > > After initial modules have loaded i essentially disable crash.ko
> > > via /proc/sys/kernel/modules_disabled so rootkits have to work a
> > > bit harder than that.
> > 
> > Not sure for fedora as I don'[t have a kernel tree at hand right
> > now, but for x86 systems at least RHEL6 has the module built in.
> > [...]
> 
> Fedora Rawhide has it modular:
> 
>  # grep CRASH /boot/config-2.6.38-0.rc7.git2.3.fc16.x86_64
>  CONFIG_CRASH=m
> 
>  # rpm -ql kernel-2.6.38-0.rc7.git2.3.fc16.x86_64 | grep crash
>  /lib/modules/2.6.38-0.rc7.git2.3.fc16.x86_64/kernel/drivers/char/crash.ko
> 
> > [...]  Either way we'll need some way to support crash properly in
> > mainline, preferably in a boot-time opt-in way. [...]
> 
> Yes, boot-time opt-in was what i suggested.
> 
> > [...] I'd tend slightly toward optionally enabling /dev/mem for it
> > instead of a separate driver, but if people prefer a different
> > route I'm fine, too.
> 
> No, sharing the driver is perfectly fine and sane as long as this
> weird usage is not enabled widely.

Note that if you want to solve the Fedora case, you want to make STRICT_DEVMEM 
run-time configurable. My patch set does nothing about it. It merely tries to 
fix the highmem deficiency (actually, the first patch is a plain bugfix on any 
architecture where loff_t is larger than long).

The STRICT_DEVMEM logic is implemented in range_is_allowed(), and I leave it 
as-is.

> > Note that for normal crash usage read only access is just fine.
> 
> That's true as well. Petr?

Yes, that's true. Although there is some write support in crash, I have never 
ever felt the need to use it, and I've been using crash a lot in the last 5 
years.

Thanks,
Petr Tesarik

[PATCH 00/10] Enhance /dev/mem to allow read/write of arbitrary physical addresses

[Ingo Molnar]

* Petr Tesarik <ptesarik@suse.cz> wrote:

> Dne P? 1. ?ervence 2011 16:46:41 Ingo Molnar napsal(a):
> > * Christoph Hellwig <hch@infradead.org> wrote:
> > > On Fri, Jul 01, 2011 at 04:37:35PM +0200, Ingo Molnar wrote:
> > > > After initial modules have loaded i essentially disable crash.ko
> > > > via /proc/sys/kernel/modules_disabled so rootkits have to work a
> > > > bit harder than that.
> > > 
> > > Not sure for fedora as I don'[t have a kernel tree at hand right
> > > now, but for x86 systems at least RHEL6 has the module built in.
> > > [...]
> > 
> > Fedora Rawhide has it modular:
> > 
> >  # grep CRASH /boot/config-2.6.38-0.rc7.git2.3.fc16.x86_64
> >  CONFIG_CRASH=m
> > 
> >  # rpm -ql kernel-2.6.38-0.rc7.git2.3.fc16.x86_64 | grep crash
> >  /lib/modules/2.6.38-0.rc7.git2.3.fc16.x86_64/kernel/drivers/char/crash.ko
> > 
> > > [...]  Either way we'll need some way to support crash properly in
> > > mainline, preferably in a boot-time opt-in way. [...]
> > 
> > Yes, boot-time opt-in was what i suggested.
> > 
> > > [...] I'd tend slightly toward optionally enabling /dev/mem for it
> > > instead of a separate driver, but if people prefer a different
> > > route I'm fine, too.
> > 
> > No, sharing the driver is perfectly fine and sane as long as this
> > weird usage is not enabled widely.
> 
> Note that if you want to solve the Fedora case, you want to make 
> STRICT_DEVMEM run-time configurable. My patch set does nothing 
> about it. It merely tries to fix the highmem deficiency (actually, 
> the first patch is a plain bugfix on any architecture where loff_t 
> is larger than long).

I'm not focused on Fedora here (i brought it up as an example). I'd 
like to improve upstream, and if that is done Fedora can just go use 
it and symlink /dev/mem to /dev/crash.

> The STRICT_DEVMEM logic is implemented in range_is_allowed(), and I 
> leave it as-is.
> 
> > > Note that for normal crash usage read only access is just fine.
> > 
> > That's true as well. Petr?
> 
> Yes, that's true. Although there is some write support in crash, I 
> have never ever felt the need to use it, and I've been using crash 
> a lot in the last 5 years.

If you make it a read-only thing then that removes many of the 
negative aspects of this feature.

Also, does Xorg really need the first 1MB truly write-mapped? Last i 
checked it needed it for the BIOS ...

So we could kill multiple birds with the same stone here:

 - remove various ugly uses of /dev/mem (including the rootkit usage),
   with or without strict-devmem

 - extending it to above-4G for inspection purposes

 - allowing to kill /dev/mem access runtime similar to the 
   disable_modules lock-down killswitch, for the so inclined.

Would you be interested in modifying your patch-set in such a 
fashion?

Thanks,

	Ingo

[PATCH 00/10] Enhance /dev/mem to allow read/write of arbitrary physical addresses

[H. Peter Anvin]

On 07/01/2011 08:36 AM, Ingo Molnar wrote:
> 
> So we could kill multiple birds with the same stone here:
> 
>  - remove various ugly uses of /dev/mem (including the rootkit usage),
>    with or without strict-devmem
> 
>  - extending it to above-4G for inspection purposes
> 
>  - allowing to kill /dev/mem access runtime similar to the 
>    disable_modules lock-down killswitch, for the so inclined.
> 
> Would you be interested in modifying your patch-set in such a 
> fashion?
> 

There is another use that I have looked at, as well: for testing
purposes, it would be extremely good to be able to dirty and/or flush an
arbitrary physical cache line for testing purposes.

This is very very similar to /dev/mem usage -- access to an arbitrary
chunk of memory -- and a fully enabled /dev/mem can of course support
this use (just mmap the page with the relevant cache line).  However, it
could also be a separate device which could have looser permissions than
/dev/mem; or a set of ioctls on /dev/mem with a separate kill switch,
because no data would ever be have modified or returned to user space.

Either way, though, we found that it would share a lot of code with the
/dev/mem implementation, and as such fixing up the underlying machinery
is the sanest way to upstream this.

	-hpa

-- 
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel.  I don't speak on their behalf.

[PATCH 00/10] Enhance /dev/mem to allow read/write of arbitrary physical addresses

[Ingo Molnar]

* H. Peter Anvin <hpa@zytor.com> wrote:

> On 07/01/2011 08:36 AM, Ingo Molnar wrote:
> > 
> > So we could kill multiple birds with the same stone here:
> > 
> >  - remove various ugly uses of /dev/mem (including the rootkit usage),
> >    with or without strict-devmem
> > 
> >  - extending it to above-4G for inspection purposes
> > 
> >  - allowing to kill /dev/mem access runtime similar to the 
> >    disable_modules lock-down killswitch, for the so inclined.
> > 
> > Would you be interested in modifying your patch-set in such a 
> > fashion?
> > 
> 
> There is another use that I have looked at, as well: for testing 
> purposes, it would be extremely good to be able to dirty and/or 
> flush an arbitrary physical cache line for testing purposes.
> 
> This is very very similar to /dev/mem usage -- access to an 
> arbitrary chunk of memory -- and a fully enabled /dev/mem can of 
> course support this use (just mmap the page with the relevant cache 
> line).  However, it could also be a separate device which could 
> have looser permissions than /dev/mem; or a set of ioctls on 
> /dev/mem with a separate kill switch, because no data would ever be 
> have modified or returned to user space.
> 
> Either way, though, we found that it would share a lot of code with 
> the /dev/mem implementation, and as such fixing up the underlying 
> machinery is the sanest way to upstream this.

To me that cache flush thing sounds obscure (but still useful) enough 
to justify a new ioctl over /dev/mem.

Not sure it even needs a killswitch, unless there's some real 
security problem related to it.

Thanks,

	Ingo

[PATCH 00/10] Enhance /dev/mem to allow read/write of arbitrary physical addresses

[Petr Tesarik]

Dne P? 1. ?ervence 2011 18:13:45 Ingo Molnar napsal(a):
> * H. Peter Anvin <hpa@zytor.com> wrote:
> > On 07/01/2011 08:36 AM, Ingo Molnar wrote:
> > > So we could kill multiple birds with the same stone here:
> > >  - remove various ugly uses of /dev/mem (including the rootkit usage),
> > >  
> > >    with or without strict-devmem
> > >  
> > >  - extending it to above-4G for inspection purposes
> > >  
> > >  - allowing to kill /dev/mem access runtime similar to the
> > >  
> > >    disable_modules lock-down killswitch, for the so inclined.
> > > 
> > > Would you be interested in modifying your patch-set in such a
> > > fashion?

Yes, this works for me. How persistent should the kill-switch be? I assume it 
doesn't make much sense to make a sysfs toggle, because then it would still be 
open to abuse. I'd rather see it specified on boot and never changed. Agreed?

Something like "enable_dev_mem" on the kenrel command line (default is 
disabled).

On a similar note, I should probably rip off write_mem() completely and 
disallow PROT_WRITE mmapping of the device. Right?

> > There is another use that I have looked at, as well: for testing
> > purposes, it would be extremely good to be able to dirty and/or
> > flush an arbitrary physical cache line for testing purposes.
> > 
> > This is very very similar to /dev/mem usage -- access to an
> > arbitrary chunk of memory -- and a fully enabled /dev/mem can of
> > course support this use (just mmap the page with the relevant cache
> > line).  However, it could also be a separate device which could
> > have looser permissions than /dev/mem; or a set of ioctls on
> > /dev/mem with a separate kill switch, because no data would ever be
> > have modified or returned to user space.
> > 
> > Either way, though, we found that it would share a lot of code with
> > the /dev/mem implementation, and as such fixing up the underlying
> > machinery is the sanest way to upstream this.
> 
> To me that cache flush thing sounds obscure (but still useful) enough
> to justify a new ioctl over /dev/mem.
> 
> Not sure it even needs a killswitch, unless there's some real
> security problem related to it.

It can be used for DoS, but if you have permission for the ioctl(), then you 
probably also have easier ways to kill the system.

Petr

[PATCH 00/10] Enhance /dev/mem to allow read/write of arbitrary physical addresses

[Ingo Molnar]

* Petr Tesarik <ptesarik@suse.cz> wrote:

> Dne P? 1. ?ervence 2011 18:13:45 Ingo Molnar napsal(a):
> > * H. Peter Anvin <hpa@zytor.com> wrote:
> > > On 07/01/2011 08:36 AM, Ingo Molnar wrote:
> > > > So we could kill multiple birds with the same stone here:
> > > >  - remove various ugly uses of /dev/mem (including the rootkit usage),
> > > >  
> > > >    with or without strict-devmem
> > > >  
> > > >  - extending it to above-4G for inspection purposes
> > > >  
> > > >  - allowing to kill /dev/mem access runtime similar to the
> > > >  
> > > >    disable_modules lock-down killswitch, for the so inclined.
> > > > 
> > > > Would you be interested in modifying your patch-set in such a
> > > > fashion?
> 
> Yes, this works for me. How persistent should the kill-switch be? I 
> assume it doesn't make much sense to make a sysfs toggle, because 
> then it would still be open to abuse. I'd rather see it specified 
> on boot and never changed. Agreed?
> 
> Something like "enable_dev_mem" on the kenrel command line (default 
> is disabled).
> 
> On a similar note, I should probably rip off write_mem() completely 
> and disallow PROT_WRITE mmapping of the device. Right?

Yeah - there's two things here: one is the boot option to turn it on, 
the other is the kill-switch that is runtime and kills this method of 
access permanently (until next reboot that is).

the kill-switch works like modules_disabled: once you echo 1 into it 
you cannot move it back to 0 anymore.

The boot option would be a standard boot option - devmem=1 would be 
the canonical naming? (but no strong feelings about the naming)

Do you expect distros to enable this boot option by default? I.e. 
would SuSE be willing to ship with a restrictive /dev/mem by default? 
That's really the wider goal we want to work towards.

> > > There is another use that I have looked at, as well: for 
> > > testing purposes, it would be extremely good to be able to 
> > > dirty and/or flush an arbitrary physical cache line for testing 
> > > purposes.
> > > 
> > > This is very very similar to /dev/mem usage -- access to an 
> > > arbitrary chunk of memory -- and a fully enabled /dev/mem can 
> > > of course support this use (just mmap the page with the 
> > > relevant cache line).  However, it could also be a separate 
> > > device which could have looser permissions than /dev/mem; or a 
> > > set of ioctls on /dev/mem with a separate kill switch, because 
> > > no data would ever be have modified or returned to user space.
> > > 
> > > Either way, though, we found that it would share a lot of code 
> > > with the /dev/mem implementation, and as such fixing up the 
> > > underlying machinery is the sanest way to upstream this.
> > 
> > To me that cache flush thing sounds obscure (but still useful) 
> > enough to justify a new ioctl over /dev/mem.
> > 
> > Not sure it even needs a killswitch, unless there's some real 
> > security problem related to it.
> 
> It can be used for DoS, but if you have permission for the ioctl(), 
> then you probably also have easier ways to kill the system.

Hm, why would the ability "dirty and/or flush an arbitrary physical 
cache line for testing purposes" be a DoS?

Thanks,

	Ingo

[PATCH 00/10] Enhance /dev/mem to allow read/write of arbitrary physical addresses

[Petr Tesarik]

Dne P? 1. ?ervence 2011 21:56:29 Ingo Molnar napsal(a):
> * Petr Tesarik <ptesarik@suse.cz> wrote:
> > Dne P? 1. ?ervence 2011 18:13:45 Ingo Molnar napsal(a):
> > > * H. Peter Anvin <hpa@zytor.com> wrote:
> > > > On 07/01/2011 08:36 AM, Ingo Molnar wrote:
> > > > > So we could kill multiple birds with the same stone here:
> > > > >  - remove various ugly uses of /dev/mem (including the rootkit
> > > > >  usage),
> > > > >  
> > > > >    with or without strict-devmem
> > > > >  
> > > > >  - extending it to above-4G for inspection purposes
> > > > >  
> > > > >  - allowing to kill /dev/mem access runtime similar to the
> > > > >  
> > > > >    disable_modules lock-down killswitch, for the so inclined.
> > > > > 
> > > > > Would you be interested in modifying your patch-set in such a
> > > > > fashion?
> > 
> > Yes, this works for me. How persistent should the kill-switch be? I
> > assume it doesn't make much sense to make a sysfs toggle, because
> > then it would still be open to abuse. I'd rather see it specified
> > on boot and never changed. Agreed?
> > 
> > Something like "enable_dev_mem" on the kenrel command line (default
> > is disabled).
> > 
> > On a similar note, I should probably rip off write_mem() completely
> > and disallow PROT_WRITE mmapping of the device. Right?
> 
> Yeah - there's two things here: one is the boot option to turn it on,
> the other is the kill-switch that is runtime and kills this method of
> access permanently (until next reboot that is).
> 
> the kill-switch works like modules_disabled: once you echo 1 into it
> you cannot move it back to 0 anymore.

Got it.

> The boot option would be a standard boot option - devmem=1 would be
> the canonical naming? (but no strong feelings about the naming)

I don't have any strong feelings either. "devmem=<int>" might be better, 
because it could be used to control whether the device is read-only. That is, 
if we want allow writing to /dev/mem under any circumstances. I'm fine with 
removing the write part completely.

> Do you expect distros to enable this boot option by default? I.e.
> would SuSE be willing to ship with a restrictive /dev/mem by default?
> That's really the wider goal we want to work towards.

I'm not really the decision-maker on this, but even though I don't need it for 
crash, there are several other users which would have to be fixed:

1. hwinfo (EFI, MPTABLE and ACPI table parsing, analyzing video BIOS)
2. dmidecode (SMBIOS, DMI)
3. possibly others

IMO there should be standard interfaces for all of these. SUSE will probably 
continue to ship devmem-enabled kernels until we have a complete replacement 
(esp. hwinfo seems to be important, because it is run as part of the 
supportconfig script, which is run on customer machines and gathers all kind 
of info that is useful to support teams). Note that these tools are mostly 
content with access to the lowest megabyte, so they can also be used with 
CONFIG_STRICT_DEVMEM.

However, somebody must do the first step, and since we are the ones who 
dislike the current state of affairs, it's probably our turn. Once /dev/mem is 
disabled, authors of diagnostic tools will probably complain loudly here. We 
(as in "kernel hackers") should provide proper interfaces for the low-level 
info, and they'll adjust user-space. At this point I would expect distros to 
disable /dev/mem by default.

> > > > There is another use that I have looked at, as well: for
> > > > testing purposes, it would be extremely good to be able to
> > > > dirty and/or flush an arbitrary physical cache line for testing
> > > > purposes.
> > > > 
> > > > This is very very similar to /dev/mem usage -- access to an
> > > > arbitrary chunk of memory -- and a fully enabled /dev/mem can
> > > > of course support this use (just mmap the page with the
> > > > relevant cache line).  However, it could also be a separate
> > > > device which could have looser permissions than /dev/mem; or a
> > > > set of ioctls on /dev/mem with a separate kill switch, because
> > > > no data would ever be have modified or returned to user space.
> > > > 
> > > > Either way, though, we found that it would share a lot of code
> > > > with the /dev/mem implementation, and as such fixing up the
> > > > underlying machinery is the sanest way to upstream this.
> > > 
> > > To me that cache flush thing sounds obscure (but still useful)
> > > enough to justify a new ioctl over /dev/mem.
> > > 
> > > Not sure it even needs a killswitch, unless there's some real
> > > security problem related to it.
> > 
> > It can be used for DoS, but if you have permission for the ioctl(),
> > then you probably also have easier ways to kill the system.
> 
> Hm, why would the ability "dirty and/or flush an arbitrary physical
> cache line for testing purposes" be a DoS?

Effectively switching off CPU caches can slow things down quite a bit... 
especially on a large SMP system. ;)

Petr Tesarik

[PATCH 00/10] Enhance /dev/mem to allow read/write of arbitrary physical addresses

[Ingo Molnar]

* Petr Tesarik <ptesarik@suse.cz> wrote:

> > Do you expect distros to enable this boot option by default? I.e. 
> > would SuSE be willing to ship with a restrictive /dev/mem by 
> > default? That's really the wider goal we want to work towards.
> 
> I'm not really the decision-maker on this, but even though I don't 
> need it for crash, there are several other users which would have 
> to be fixed:
> 
> 1. hwinfo (EFI, MPTABLE and ACPI table parsing, analyzing video BIOS)
> 2. dmidecode (SMBIOS, DMI)
> 3. possibly others

But those tables wont be in regular RAM (they will be in ROM or in 
RAM marked non-RAM in a special way in the e820 tables).

dmidecode certainly works on Fedora.

> > Hm, why would the ability "dirty and/or flush an arbitrary 
> > physical cache line for testing purposes" be a DoS?
> 
> Effectively switching off CPU caches can slow things down quite a 
> bit... especially on a large SMP system. ;)

Flushing a cacheline isnt switching it off. You can already 'flush' 
the cache from user-space as well, by trashing it for example. So i 
don't see the DoS angle.

Thanks,

	Ingo

[PATCH 00/10] Enhance /dev/mem to allow read/write of arbitrary physical addresses

[Matthew Garrett]

On Sun, Jul 03, 2011 at 09:46:18PM +0200, Ingo Molnar wrote:

> But those tables wont be in regular RAM (they will be in ROM or in 
> RAM marked non-RAM in a special way in the e820 tables).
> 
> dmidecode certainly works on Fedora.

I've repeatedly wanted to dump EFI data that's flagged as E820_RESERVED 
above the top of RAM and had to hack the kernel every time. I'm entirely 
in favour of not having to hack the kernel every time.

-- 
Matthew Garrett | mjg59 at srcf.ucam.org

[PATCH 00/10] Enhance /dev/mem to allow read/write of arbitrary physical addresses

[H. Peter Anvin]

On 07/05/2011 10:49 AM, Matthew Garrett wrote:
> On Sun, Jul 03, 2011 at 09:46:18PM +0200, Ingo Molnar wrote:
> 
>> But those tables wont be in regular RAM (they will be in ROM or in 
>> RAM marked non-RAM in a special way in the e820 tables).
>>
>> dmidecode certainly works on Fedora.
> 
> I've repeatedly wanted to dump EFI data that's flagged as E820_RESERVED 
> above the top of RAM and had to hack the kernel every time. I'm entirely 
> in favour of not having to hack the kernel every time.
> 

That definitely needs to be fixed.

	-hpa

-- 
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel.  I don't speak on their behalf.

[PATCH 00/10] Enhance /dev/mem to allow read/write of arbitrary physical addresses

[H. Peter Anvin]

On 07/05/2011 10:49 AM, Matthew Garrett wrote:
> On Sun, Jul 03, 2011 at 09:46:18PM +0200, Ingo Molnar wrote:
> 
>> But those tables wont be in regular RAM (they will be in ROM or in 
>> RAM marked non-RAM in a special way in the e820 tables).
>>
>> dmidecode certainly works on Fedora.
> 
> I've repeatedly wanted to dump EFI data that's flagged as E820_RESERVED 
> above the top of RAM and had to hack the kernel every time. I'm entirely 
> in favour of not having to hack the kernel every time.
> 

Alright... I must admit I have lost track...

Where are we at with this patchset, and what path should it go through?

	-hpa