From: Ryan Mallon <rmallon@gmail.com>
To: linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH 00/10] Enhance /dev/mem to allow read/write of arbitrary
Date: Mon, 20 Jun 2011 01:02:31 +0000 [thread overview]
Message-ID: <4DFE9C27.3000305@gmail.com> (raw)
In-Reply-To: <20110620005255.GF19693@parisc-linux.org>
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
WARNING: multiple messages have this Message-ID (diff)
From: rmallon@gmail.com (Ryan Mallon)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 00/10] Enhance /dev/mem to allow read/write of arbitrary physical addresses
Date: Mon, 20 Jun 2011 11:02:31 +1000 [thread overview]
Message-ID: <4DFE9C27.3000305@gmail.com> (raw)
In-Reply-To: <20110620005255.GF19693@parisc-linux.org>
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
WARNING: multiple messages have this Message-ID (diff)
From: Ryan Mallon <rmallon@gmail.com>
To: Matthew Wilcox <matthew@wil.cx>
Cc: Ingo Molnar <mingo@elte.hu>, Petr Tesarik <ptesarik@suse.cz>,
Andrew Morton <akpm@linux-foundation.org>,
Fenghua Yu <fenghua.yu@intel.com>,
"H. Peter Anvin" <hpa@zytor.com>, Ingo Molnar <mingo@redhat.com>,
Paul Mundt <lethal@linux-sh.org>,
Russell King <linux@arm.linux.org.uk>,
Thomas Gleixner <tglx@linutronix.de>,
Tony Luck <tony.luck@intel.com>,
x86@kernel.org, linux-arm-kernel@lists.infradead.org,
linux-ia64@vger.kernel.org, linux-sh@vger.kernel.org,
linux-kernel@vger.kernel.org,
Arjan van de Ven <arjan@infradead.org>,
Dave Jones <davej@redhat.com>,
Linus Torvalds <torvalds@linux-foundation.org>
Subject: Re: [PATCH 00/10] Enhance /dev/mem to allow read/write of arbitrary physical addresses
Date: Mon, 20 Jun 2011 11:02:31 +1000 [thread overview]
Message-ID: <4DFE9C27.3000305@gmail.com> (raw)
In-Reply-To: <20110620005255.GF19693@parisc-linux.org>
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
next prev parent reply other threads:[~2011-06-20 1:02 UTC|newest]
Thread overview: 128+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-06-17 8:38 [PATCH 00/10] Enhance /dev/mem to allow read/write of arbitrary physical addresses Petr Tesarik
2011-06-17 8:38 ` Petr Tesarik
2011-06-17 8:38 ` Petr Tesarik
2011-06-17 8:43 ` [PATCH 01/10] Return EOF on out-of-bounds read from /dev/mem Petr Tesarik
2011-06-17 8:44 ` [PATCH 02/10] (un)xlate_dev_mem_ptr: use phys_addr_t for the @phys parameter Petr Tesarik
2011-06-17 8:45 ` [PATCH 03/10] x86: translate highmem /dev/mem pointers Petr Tesarik
2011-06-17 8:45 ` [PATCH 04/10] ia64: change xlate_dev_mem_ptr's argument to phys_addr_t Petr Tesarik
2011-06-17 8:45 ` Petr Tesarik
2011-06-17 8:45 ` [PATCH 05/10] valid_phys_addr_range: use phys_addr_t for the @addr parameter Petr Tesarik
2011-06-17 8:46 ` [PATCH 06/10] sh: change valid_phys_addr_range's @addr param to phys_addr_t Petr Tesarik
2011-06-17 8:46 ` Petr Tesarik
2011-06-17 8:46 ` [PATCH 07/10] arm: " Petr Tesarik
2011-06-17 8:46 ` Petr Tesarik
2011-06-17 8:47 ` [PATCH 08/10] ia64: " Petr Tesarik
2011-06-17 8:47 ` Petr Tesarik
2011-06-17 8:48 ` [PATCH 09/10] x86: provide arch-specific valid_phys_addr_range() Petr Tesarik
2011-06-17 8:48 ` [PATCH 10/10] Allow reading/writing all memory through /dev/mem Petr Tesarik
2011-06-17 9:30 ` [PATCH 00/10] Enhance /dev/mem to allow read/write of arbitrary Ingo Molnar
2011-06-17 9:30 ` [PATCH 00/10] Enhance /dev/mem to allow read/write of arbitrary physical addresses Ingo Molnar
2011-06-17 9:30 ` Ingo Molnar
2011-06-17 9:41 ` [PATCH 00/10] Enhance /dev/mem to allow read/write of Russell King - ARM Linux
2011-06-17 9:41 ` [PATCH 00/10] Enhance /dev/mem to allow read/write of arbitrary physical addresses Russell King - ARM Linux
2011-06-17 9:41 ` Russell King - ARM Linux
2011-06-17 9:55 ` Petr Tesarik
2011-06-17 9:55 ` Petr Tesarik
2011-06-17 9:55 ` Petr Tesarik
2011-06-20 2:42 ` [PATCH 00/10] Enhance /dev/mem to allow read/write of arbitrary Américo Wang
2011-06-20 2:42 ` [PATCH 00/10] Enhance /dev/mem to allow read/write of arbitrary physical addresses Américo Wang
2011-06-20 2:42 ` Américo Wang
2011-06-27 7:46 ` [PATCH 00/10] Enhance /dev/mem to allow read/write of Petr Tesarik
2011-06-27 7:46 ` [PATCH 00/10] Enhance /dev/mem to allow read/write of arbitrary physical addresses Petr Tesarik
2011-06-27 7:46 ` Petr Tesarik
2011-06-19 23:02 ` [PATCH 00/10] Enhance /dev/mem to allow read/write of arbitrary Ryan Mallon
2011-06-19 23:02 ` [PATCH 00/10] Enhance /dev/mem to allow read/write of arbitrary physical addresses Ryan Mallon
2011-06-19 23:02 ` Ryan Mallon
2011-06-19 23:44 ` [PATCH 00/10] Enhance /dev/mem to allow read/write of arbitrary H. Peter Anvin
2011-06-19 23:44 ` [PATCH 00/10] Enhance /dev/mem to allow read/write of arbitrary physical addresses H. Peter Anvin
2011-06-19 23:44 ` H. Peter Anvin
2011-06-20 7:41 ` [PATCH 00/10] Enhance /dev/mem to allow read/write of arbitrary Ingo Molnar
2011-06-20 7:41 ` [PATCH 00/10] Enhance /dev/mem to allow read/write of arbitrary physical addresses Ingo Molnar
2011-06-20 7:41 ` Ingo Molnar
2011-06-20 15:59 ` [PATCH 00/10] Enhance /dev/mem to allow read/write of arbitrary H. Peter Anvin
2011-06-20 15:59 ` [PATCH 00/10] Enhance /dev/mem to allow read/write of arbitrary physical addresses H. Peter Anvin
2011-06-20 15:59 ` H. Peter Anvin
2011-06-20 16:40 ` [PATCH 00/10] Enhance /dev/mem to allow read/write of arbitrary Ingo Molnar
2011-06-20 16:40 ` [PATCH 00/10] Enhance /dev/mem to allow read/write of arbitrary physical addresses Ingo Molnar
2011-06-20 16:40 ` Ingo Molnar
2011-06-20 16:44 ` [PATCH 00/10] Enhance /dev/mem to allow read/write of arbitrary H. Peter Anvin
2011-06-20 16:44 ` [PATCH 00/10] Enhance /dev/mem to allow read/write of arbitrary physical addresses H. Peter Anvin
2011-06-20 16:44 ` H. Peter Anvin
2011-06-21 6:55 ` Srivatsa Vaddagiri
2011-06-21 6:56 ` [PATCH 00/10] Enhance /dev/mem to allow read/write of Srivatsa Vaddagiri
2011-06-21 6:55 ` [PATCH 00/10] Enhance /dev/mem to allow read/write of arbitrary physical addresses Srivatsa Vaddagiri
2011-06-20 0:42 ` [PATCH 00/10] Enhance /dev/mem to allow read/write of Matthew Wilcox
2011-06-20 0:42 ` [PATCH 00/10] Enhance /dev/mem to allow read/write of arbitrary physical addresses Matthew Wilcox
2011-06-20 0:42 ` Matthew Wilcox
2011-06-20 0:46 ` [PATCH 00/10] Enhance /dev/mem to allow read/write of arbitrary Ryan Mallon
2011-06-20 0:46 ` [PATCH 00/10] Enhance /dev/mem to allow read/write of arbitrary physical addresses Ryan Mallon
2011-06-20 0:46 ` Ryan Mallon
2011-06-20 0:52 ` [PATCH 00/10] Enhance /dev/mem to allow read/write of Matthew Wilcox
2011-06-20 0:52 ` [PATCH 00/10] Enhance /dev/mem to allow read/write of arbitrary physical addresses Matthew Wilcox
2011-06-20 0:52 ` Matthew Wilcox
2011-06-20 1:02 ` Ryan Mallon [this message]
2011-06-20 1:02 ` Ryan Mallon
2011-06-20 1:02 ` Ryan Mallon
2011-06-20 7:31 ` [PATCH 00/10] Enhance /dev/mem to allow read/write of arbitrary Ingo Molnar
2011-06-20 7:31 ` [PATCH 00/10] Enhance /dev/mem to allow read/write of arbitrary physical addresses Ingo Molnar
2011-06-20 7:31 ` Ingo Molnar
2011-06-20 8:03 ` [PATCH 00/10] Enhance /dev/mem to allow read/write of arbitrary Ryan Mallon
2011-06-20 8:03 ` [PATCH 00/10] Enhance /dev/mem to allow read/write of arbitrary physical addresses Ryan Mallon
2011-06-20 8:03 ` Ryan Mallon
2011-06-20 17:10 ` [PATCH 00/10] Enhance /dev/mem to allow read/write of arbitrary Ray Lee
2011-06-20 17:10 ` [PATCH 00/10] Enhance /dev/mem to allow read/write of arbitrary physical addresses Ray Lee
2011-06-20 17:10 ` Ray Lee
2011-06-29 9:05 ` Petr Tesarik
2011-06-29 9:05 ` Petr Tesarik
2011-06-29 9:05 ` Petr Tesarik
2011-07-01 12:58 ` [PATCH 00/10] Enhance /dev/mem to allow read/write of arbitrary Ingo Molnar
2011-07-01 12:58 ` [PATCH 00/10] Enhance /dev/mem to allow read/write of arbitrary physical addresses Ingo Molnar
2011-07-01 12:58 ` Ingo Molnar
2011-07-01 13:43 ` Petr Tesarik
2011-07-01 13:43 ` Petr Tesarik
2011-07-01 13:43 ` Petr Tesarik
2011-07-01 13:47 ` [PATCH 00/10] Enhance /dev/mem to allow read/write of arbitrary Christoph Hellwig
2011-07-01 13:47 ` [PATCH 00/10] Enhance /dev/mem to allow read/write of arbitrary physical addresses Christoph Hellwig
2011-07-01 13:47 ` Christoph Hellwig
2011-07-01 14:37 ` [PATCH 00/10] Enhance /dev/mem to allow read/write of arbitrary Ingo Molnar
2011-07-01 14:37 ` [PATCH 00/10] Enhance /dev/mem to allow read/write of arbitrary physical addresses Ingo Molnar
2011-07-01 14:37 ` Ingo Molnar
2011-07-01 14:41 ` [PATCH 00/10] Enhance /dev/mem to allow read/write of arbitrary Christoph Hellwig
2011-07-01 14:41 ` [PATCH 00/10] Enhance /dev/mem to allow read/write of arbitrary physical addresses Christoph Hellwig
2011-07-01 14:41 ` Christoph Hellwig
2011-07-01 14:46 ` [PATCH 00/10] Enhance /dev/mem to allow read/write of arbitrary Ingo Molnar
2011-07-01 14:46 ` [PATCH 00/10] Enhance /dev/mem to allow read/write of arbitrary physical addresses Ingo Molnar
2011-07-01 14:46 ` Ingo Molnar
2011-07-01 14:54 ` Petr Tesarik
2011-07-01 14:54 ` Petr Tesarik
2011-07-01 14:54 ` Petr Tesarik
2011-07-01 15:36 ` [PATCH 00/10] Enhance /dev/mem to allow read/write of arbitrary Ingo Molnar
2011-07-01 15:36 ` [PATCH 00/10] Enhance /dev/mem to allow read/write of arbitrary physical addresses Ingo Molnar
2011-07-01 15:36 ` Ingo Molnar
2011-07-01 16:00 ` [PATCH 00/10] Enhance /dev/mem to allow read/write of arbitrary H. Peter Anvin
2011-07-01 16:00 ` [PATCH 00/10] Enhance /dev/mem to allow read/write of arbitrary physical addresses H. Peter Anvin
2011-07-01 16:00 ` H. Peter Anvin
2011-07-01 16:13 ` [PATCH 00/10] Enhance /dev/mem to allow read/write of arbitrary Ingo Molnar
2011-07-01 16:13 ` [PATCH 00/10] Enhance /dev/mem to allow read/write of arbitrary physical addresses Ingo Molnar
2011-07-01 16:13 ` Ingo Molnar
2011-07-01 19:34 ` Petr Tesarik
2011-07-01 19:34 ` Petr Tesarik
2011-07-01 19:34 ` Petr Tesarik
2011-07-01 19:56 ` [PATCH 00/10] Enhance /dev/mem to allow read/write of arbitrary Ingo Molnar
2011-07-01 19:56 ` [PATCH 00/10] Enhance /dev/mem to allow read/write of arbitrary physical addresses Ingo Molnar
2011-07-01 19:56 ` Ingo Molnar
2011-07-01 20:44 ` Petr Tesarik
2011-07-01 20:44 ` Petr Tesarik
2011-07-01 20:44 ` Petr Tesarik
2011-07-03 19:46 ` [PATCH 00/10] Enhance /dev/mem to allow read/write of arbitrary Ingo Molnar
2011-07-03 19:46 ` [PATCH 00/10] Enhance /dev/mem to allow read/write of arbitrary physical addresses Ingo Molnar
2011-07-03 19:46 ` Ingo Molnar
2011-07-05 17:49 ` [PATCH 00/10] Enhance /dev/mem to allow read/write of Matthew Garrett
2011-07-05 17:49 ` [PATCH 00/10] Enhance /dev/mem to allow read/write of arbitrary physical addresses Matthew Garrett
2011-07-05 17:49 ` Matthew Garrett
2011-07-05 17:56 ` [PATCH 00/10] Enhance /dev/mem to allow read/write of arbitrary H. Peter Anvin
2011-07-05 17:56 ` [PATCH 00/10] Enhance /dev/mem to allow read/write of arbitrary physical addresses H. Peter Anvin
2011-07-05 17:56 ` H. Peter Anvin
2011-07-05 22:34 ` [PATCH 00/10] Enhance /dev/mem to allow read/write of arbitrary H. Peter Anvin
2011-07-05 22:34 ` [PATCH 00/10] Enhance /dev/mem to allow read/write of arbitrary physical addresses H. Peter Anvin
2011-07-05 22:34 ` H. Peter Anvin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4DFE9C27.3000305@gmail.com \
--to=rmallon@gmail.com \
--cc=linux-arm-kernel@lists.infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.