[Karmic] SRU: AppArmor fix file perm reporting and dfa allocation
Andy Whitcroft
apw at canonical.com
Thu Oct 29 18:06:06 UTC 2009
On Thu, Oct 29, 2009 at 07:59:43AM -0700, John Johansen wrote:
> The following changes since commit 7423c4c3b22816168b912c39a0298227076854b8:
> Scott James Remnant (1):
> UBUNTU: SAUCE: trace: add trace events for open(), exec() and uselib()
>
> are available in the git repository at:
>
> kernel.ubuntu.com:/srv/kernel.ubuntu.com/git/jj/apparmor-karmic.git master
>
> John Johansen (2):
> UBUNTU: SAUCE: AppArmor: AppArmor wrongly reports allow perms as denied
> UBUNTU: SAUCE: AppArmor: Policy load and replacement can fail to alloc mem
This second one is worrying me a little. To quote the description:
AppArmor dfas can be rather large under some circumstances with some
requiring allocations of 128K+ per table (with at least 4 tables per dfa,
and a dfa per profile).
This can result in memory allocation asking for page allocations with an
order of 5 or more, which will fail if memory has become fragemented.
If I am reading the above correctly we are saying we have 4*128K per
profile = 512K per profile. And we have more than 5 profiles already?
Does this mean that we need multiple megabytes of vmalloc space?
Bear in mind that vmalloc space on 32bit machines with 1GB of ram is
very small indeed:
[ 0.000000] vmalloc : 0xf7ffe000 - 0xff7fe000 ( 120 MB)
I think it might be safer to use kmalloc if we can and if that fails use
vmalloc. There is a is_vmalloc_addr() helper to help with the free
case.
Reviewing the change itself with smb we think that the failure cases in
unpack_dfa() should also be using the matching vfree() style if you are
making this conversion?
int unpack_dfa(struct aa_dfa *dfa, void *blob, size_t size)
[...]
default:
kfree(table);
goto fail;
[...]
for (i = 0; i < ARRAY_SIZE(dfa->tables); i++) {
kfree(dfa->tables[i]);
dfa->tables[i] = NULL;
}
[...]
-apw
More information about the kernel-team
mailing list