linux-kernel - Re: /dev/mem implementation

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: <af0693f01001180418h6344e4b2v64f82e54ab3d9241@mail.gmail.com>
Date:	Mon, 18 Jan 2010 14:18:22 +0200
From:	Felix Rubinstein <felixru@...il.com>
To:	Arjan van de Ven <arjan@...radead.org>
Cc:	linux-kernel@...r.kernel.org
Subject: Re: /dev/mem implementation

The usecase is broadcom 10GbE switch driver which maps DMA memory to userspace.
I can find one more libe1000 which uses char driver to map DMA memory
to userspace too.
So, how can I implement userspace drivers in recent kernels which want
to map DMA memory to userspace if STRICT_DEVMEM or PAT (either of
them) are enabled.

The motivation to implement network drivers is not new and there are
here and there mini projects to bypass Linux networks stack to gain
better latency as stack has lots of locks around, buffer copying
(userspace to kernel and vice versa), etc... which only add latency.

Thanks,
Felix R.

On Sun, Jan 17, 2010 at 7:40 PM, Arjan van de Ven <arjan@...radead.org> wrote:
> On Sun, 17 Jan 2010 18:47:10 +0200
> Felix Rubinstein <felixru@...il.com> wrote:
>
>> I see the motivation to limit the access to DRAM from root account
>> CONFIG_STRICT_DEVMEM by mmap'ing /dev/[k]mem but it's easily overruled
>> by simple char driver and implementing mmap of it's own totally
>> bypassing all limitations.
>>
>> What do you think about it guy?
>> Appreciate it.
>
> the reason PAT bans parts of /dev/mem is simple: it is illegal to have
> mapping aliases (different cachability) for the same physical page.
> Normal kernel APIs take care of this for the normal case, but /dev/mem
> would be a back door into that.
> This is a hardware imposed requirement, and violating the rule can have
> really nasty consequences... hence the PAT code just not allowing it.
>
> If you feel that you have a valid use case where you really want do
> muck with such memory, it might be a good idea to explain that
> usecase....
>
> --
> 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/