[apparmor] [PATCH 08/16] apparmor: add parameter to control whether policy hashing is used
John Johansen
john.johansen at canonical.com
Thu Apr 21 17:52:27 UTC 2016
On 04/21/2016 03:57 AM, Christian Boltz wrote:
> Hello,
>
> Am Mittwoch, 20. April 2016, 23:52:50 CEST schrieb John Johansen:
> ...
>> + help
>> + This option selects whether sha1 hashing of loaded policy
>> + is enabled by default. The generation of sha1 hashes for
>> + loaded policy provide system administrators a quick way
>> + to verify that policy in the kernel matches what is expected,
>> + however it can slow down policy load on some devices. In
>> + these cases policy hashing can be disabled by default and
>> + enabled only if needed.
>
> I'm surprised that calculating some sha1 hashes brings a noticable
> slowdown ;-)
>
heh sadly it does on some platforms
> Just curious - would it make sense to calculate the sha1 only when
> reading it from apparmorfs, instead of doing it at profile load time?
> (I'd guess that loading a profile happens more often than reading a sha1
> from apparmorfs, and it would solve the "slow down load" part.)
>
Nope its not feasible because the kernel on unpack transforms the policy
into an internal form, data gets cache aligned, some things (eg. rlimits
get remapped to the architecture define), trees and lists get built, and
certain bits of info from the policy container are even thrown away.
Yes it would be possible to save everything, and do the reverse map (but
costly time wise), or hang onto the the original buffer loaded to the
kernel (extra memory overhead), but its not really worth it.
More information about the AppArmor
mailing list