userspace: easy checking for specific driver #12056
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
In general driver system calls are implemented at a subsystem layer. However, some drivers may have capabilities specific to the hardware not covered by the subsystem API. Such drivers may want to define their own system calls. This macro makes it simple to validate in the driver-specific system call handlers that not only does the untrusted device pointer correspond to the expected subsystem, initialization state, and caller permissions, but also that the device object is an instance of a specific driver (and not just any driver in that subsystem). Signed-off-by: Andrew Boie <andrew.p.boie@intel.com>
andrewboie
requested review from
andyross,
ceolin,
pabigot,
ioannisg and
agross-oss
pabigot
reviewed
Dec 12, 2018
Codecov Report
@@ Coverage Diff @@
## master #12056 +/- ##
=======================================
Coverage 48.05% 48.05%
=======================================
Files 281 281
Lines 43414 43414
Branches 10404 10404
=======================================
Hits 20862 20862
Misses 18403 18403
Partials 4149 4149Continue to review full report at Codecov.
|
|
recheck |
andyross
approved these changes
Dec 13, 2018
ioannisg
reviewed
Dec 13, 2018
| a provided pointer is a valid instance of a specific device driver, that | ||
| the calling thread has permissions on it, and that the driver has been | ||
| initialized. It does this by checking the init function pointer that | ||
| is stored within the driver instance and ensuring that it matches the |
There was a problem hiding this comment.
I don't think "by ensuring" would be correct. The ensuring is part of the checking that's already under "by". Perhaps:
It does this by checking that the init function pointer stored within the driver instance matches the provided value, which should be the address of the specific driver's init function.
ioannisg
approved these changes
Dec 21, 2018
pizi-nordic
approved these changes
Dec 27, 2018
Closed
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
In general driver system calls are implemented at a subsystem
layer. However, some drivers may have capabilities specific to
the hardware not covered by the subsystem API. Such drivers may
want to define their own system calls.
This macro makes it simple to validate in the driver-specific
system call handlers that not only does the untrusted device
pointer correspond to the expected subsystem, initialization
state, and caller permissions, but also that the device object
is an instance of a specific driver (and not just any driver in
that subsystem).
Signed-off-by: Andrew Boie andrew.p.boie@intel.com