linux-kernel - [PATCH] Allow userspace block device 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-next>] [day] [month] [year] [list]

Date:	Sun, 26 Jul 2009 23:57:10 -1000
From:	Zachary Amsden <zamsden@...hat.com>
To:	linux-kernel@...r.kernel.org, torvalds@...ux-foundation.org,
	axboe@...nel.dk, hch@...radead.org, akpm@...ux-foundation.org,
	Paul.Clements@...eleye.com, tytso@....edu
Subject: [PATCH] Allow userspace block device implementation

Well, it may be a good, bad, idiotic or brilliant idea depending on your
personal philosophy.  I went down this route out of pragmatism.
Hopefully I have not fully re-invented the wheel.

The patch included allows one to implement a kernel level block device
in userspace, using an ioctl() based interface to create a sized device
with given properties, and then receive and respond to bio requests
issued to the device.  One can poll on the associated control socket to
allow efficient servicing of device requests.  So far only strict copy
to/from user memory is supported, there is no fancy page flipping or
mapping operations.

Which there probably should not be.  This device is not about
performance, is it about extending the boundaries of the kernel to the
almost improbable.  Now one can literally create any kind of device
imaginable and use it as a block device in the kernel, mounting
partitions and such and using them as if they existed natively.  I have
attached a very simple dummy program showing how to do this.

The design requirements 'kernel block device in user space' to me
demanded that the interface be stateless.  Userspace can crash, be
killed, or interrupted.  Block devices cannot, they must answer all
requests, even if that answer is a failure.  Thus there exists no state
between the kernel and the userspace process(es) or threads serving the
device.  No establishment of connections, just a queue which can be read
and answered via get and put, the ioctl operators available.  This
allows a completely flexible userspace implementation, with multiple
processes, etc, and allows complete recovery via a simple reset command
if those programs fail.  I believe this also prevents any possibility of
accidental deadlock.  There may of course be some hidden deep deadlock
potential in such a device, especially if one decided to use it as a
swap device, but again, this is a philosophical issue.

Enough talking, let's have at it and see where this goes.  Obviously
this is experimental and open to feedback.  Considering it turns kernel
interfaces on their head, I have given it what I feel is an appropriate
name.

If there is any person or list you know that I forgot to copy this to,
please forward it on to them.

Thanks,

Zach

View attachment "abuse-module.patch" of type "text/plain" (24439 bytes)

View attachment "abusectl.c" of type "text/x-csrc" (4042 bytes)