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