Thanks a lot.

I'll do something that removes the unnecessary module_request to personality-8.

On 2015/9/23 23:45, enh wrote:
> On Wed, Sep 23, 2015 at 7:42 AM, Stephen Smalley <s...@tycho.nsa.gov> wrote:
>> On 09/23/2015 02:56 AM, weiyuan wrote:
>>> @Dimitry @Stephen
>>>
>>>
>>> I get lot of these avc too, under Android6.0, with kernel version 3.10.86.
>>>
>>> like this one:
>>> avc:  denied  { module_request } for pid=3638 comm="logd" 
>>> kmod="personality-8" scontext=u:r:logd:s0 tcontext=u:r:kernel:s0 
>>> tclass=system
>>>
>>>
>>> When loading a ELF format, it will invoke
>>>  __libc_init
>>>       -> __libc_init_AT_SECURE
>>>               -> __initialize_personality
>>>
>>> with patch "https://android-review.googlesource.com/#/c/122131/";
>>> In func __initialize_personality, it will set PER_LINUX32 flag for 32bit 
>>> ELF executable.
>>> But inside kernel, elf_set_personality do not support PER_LINUX32, so it 
>>> will cause
>>> request_module("personality-%d", pers), which will lead to request 
>>> "personality-8".
>>>
>>>
>>> 1. What is "Bug: 18069809"? why we need this patch?
> 
> the problem is the contents of /proc/cpuinfo. lots of apps assume they
> can parse this to check for features like NEON, but the aarch64
> kernel's /proc/cpuinfo looks very different. a compatibility patch was
> added to the kernel
> (https://lists.linaro.org/pipermail/cross-distro/2014-October/000751.html
> is the patch, with a fuller description of what was done and why) and
> this is the userspace side of it.
> 
>> I don't have visibility into Android bugs, so can't answer the first
>> part, but I think that the second part is just the userland support for
>> 32-bit compat.  That isn't the problem; the problem is that the kernel
>> blindly calls request_module() in this case even though there isn't any
>> personality-8 module to be loaded (right?).
>>
>>> 2. This patch will lead all the 32bit ELF executables to request_module 
>>> personality-8.
>>>    What's your suggestion about how to solve this problem?
>>
>> My first suggestion would be to build your kernels with
>> CONFIG_MODULES=n.  Non-modular kernels are preferred for Android anyway.
>>
>> If that isn't an option for you, then you could back-port the kernel
>> patches to remove execution domain support from 4.0 or do something
>> similar to the patch that adds a linux32 domain directly to eliminate
>> this unnecessary request_module() call.
>>
>> If neither of those options work for you, you can dontaudit it.
>> However, this will hide any other module_request denials, even for other
>> kernel modules, so you shouldn't do that until you are sure you have
>> fully resolved all legitimate module_request cases and allowed
>> module_request in those cases where it is truly needed for other modules.
>>
>>
> 
> 
> 


_______________________________________________
Seandroid-list mailing list
Seandroid-list@tycho.nsa.gov
To unsubscribe, send email to seandroid-list-le...@tycho.nsa.gov.
To get help, send an email containing "help" to 
seandroid-list-requ...@tycho.nsa.gov.

Reply via email to