Browse Prior Art Database

User space driver for general purpose adapter Disclosure Number: IPCOM000239724D
Publication Date: 2014-Nov-27
Document File: 2 page(s) / 125K

Publishing Venue

The Prior Art Database


Design for secure user space driver for general purpose adapters using storage keys.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 51% of the total text.

Page 01 of 2

User space driver for general purpose adapter

Device drivers are mainly implemented in kernel to control and operate a particular device or adapter.

Applications using the device will encounter the overhead in performance due to the kernel implementation. Overheads are mainly incurred due to context switches, copying..etc

To address these overhead, the user space driver were implemented. But the user space drivers have their own limitations and disadvantages like
1. User space drivers are mainly useful if the device is used only by a single application at a time.

2. User space driver architecture needs access to device control block in the user space. Misbehaving applications can accidentally mess up the device state and hence not suitable for shared devices.

3. Operating system doesn't have the control over the user space driver code. Applications can easily write their own code to access the device instead of using system provided drivers.

This idea is to address current limitation faced in the user space driver architecture.

To address the limitation in the current user space driver architecture, we propose a new architecture, where the applications will have a hidden user thread which interacts with the device from user space to control and operate the device or address.

Highlights of the new design
1. A hidden user space thread will be created which will have the same user address space as that of the application.

2. The device control block which is mapped into the user address space process will be protected using a reserved storage keys. Only the hidden thread can access it, not the application code.

3. The hidden thread will created using the kernel infrastructure and will only execute the driver code installed on the system, making the design secure.

4. All the hidden threads for a particular device will have access to system wide memory which can be used for serialization/synchronization, which will allow implementation of this architecture of general purpose adapters.

5. The device APIs like read/write will internally be implemented to talk to this hidden user space thread which in-turn will program the device to fulfill the application's request.

1. Application will get the performance benefit similar to a user space driver due to zero copy and no context switches.

2. Due to secure design, this architecture can be used even shared and general purpose devices.

3. Existing application can seamlessly use this architecture without any modific...