A while ago I posted this:
While preparing a hardware workshop and playing with multi-position keylocks, I was reading out the keylock position using GPIO pins. I had the idea to structure this a bit more and integrate it with the operating system. Out of this, experimental support for keylocks was born. The attached diff, which is also online at http://www.netbsd.org/~mbalmer/diffs/keylock_03.diff , adds the following components:- Generic support for keylocks in the kernel. The number of keylock positions and the current keylock position can be read from the kernel using two functions, userland can access them through the hw.keylock.npos and hw.keylock.pos sysctl variables.- gpiolock(4) a driver for GPIO attached multi-position keylocks. The driver registers with the in-kernel keylock "subsystem".- secmodel_keylock, a kauth(9) security model that authorizes based on the keylock "closedness". Wheter the rightmost (default) or leftmost position of the keylock means open can be controlled using the security.models.keylock.order sysctl variable (access to which will be protected later).The enable this, "options KEYLOCK" and "options secmodel_keylock" must be set in the kernel configuration; to use the gpiolock(4) driver att a "gpiolock* at gpio?" line.
[ ...]In the meantime I got useful feedback and reworked the keylock support. In particular I changed the following parts:
- The secmodel_keylock security model is now decoupled from the bsd44 security model. It is started when a keylock driver registers and stopped when there is no more keylock driver. The keylock security model is optional, keylock support can be used without the security model as well (e.g. to provide keylock state to a userland applications. very useful for POS applications).
- The keylock state interpretation has moved from secmodel_keylock.c to kern_keylock.c. This is the better place and it allows us to add support for multiple keylocks in the future. The hw.keylock.pos and hw.keylock.npos sysctl variable have debugging character, the hw.keylock.state variable reflects the state and should be used.
- The keylock positions are interpreted as follows: There are max. four positions, OPEN, SEMIOPEN, SEMICLOSE, CLOSE. What exactly that means leaves room for interpretation right now.... (experience will show what makes sense in the end).
- The hw.keylock.order sysctl value can only be changed when the keylock is in the open state.
The attached diff can also be found online at http://www.netbsd.org/~mbalmer/diffs/keylock_04.diff Many thanks to all that replied to my initial posting. - Marc "Lockpicker" Balmer
Attachment:
keylock_04.diff
Description: Binary data