diff options
author | Jean-Baptiste Boric <jblbeurope@gmail.com> | 2021-07-18 10:03:10 +0200 |
---|---|---|
committer | Andreas Kling <kling@serenityos.org> | 2021-08-07 11:48:00 +0200 |
commit | 75260bff92fa75033c92cf09d0ab6cf55b515c85 (patch) | |
tree | 63519d1ab6a1d4c5c6367cd82e06861e89d62268 /Kernel/FileSystem/UnveilNode.h | |
parent | 39ceefa5ddc01c422d1c85b919cb1ef3bbf68ff2 (diff) | |
download | serenity-75260bff92fa75033c92cf09d0ab6cf55b515c85.zip |
Kernel: Introduce ProtectedValue
A protected value is a variable with enforced locking semantics. The
value is protected with a Mutex and can only be accessed through a
Locked object that holds a MutexLocker to said Mutex. Therefore, the
value itself cannot be accessed except through the proper locking
mechanism, which enforces correct locking semantics.
The Locked object has knowledge of shared and exclusive lock types and
will only return const-correct references and pointers. This should
help catch incorrect locking usage where a shared lock is acquired but
the user then modifies the locked value.
This is not a perfect solution because dereferencing the Locked object
returns the value, so the caller could defeat the protected value
semantics once it acquires a lock by keeping a pointer or a reference
to the value around. Then again, this is C++ and we can't protect
against malicious users from within the kernel anyways, but we can
raise the threshold above "didn't pay attention".
Diffstat (limited to 'Kernel/FileSystem/UnveilNode.h')
0 files changed, 0 insertions, 0 deletions