On Jan 19, 2016 12:20 PM, "Jeffrey Vander Stoep" <je...@google.com> wrote:
>
> Try adding notrim in your fstab. Trimming swap makes no sense.
Does defaults include discard? I haven't looked.
>
> On Tue, Jan 19, 2016 at 9:31 AM William Roberts <bill.c.robe...@gmail.com>
wrote:
>>
>> 1. The no logging on the stat failure is consistent to what I am seeing.
So you might have the correct spot.
>> 2. The fstab entry: /dev/block/zram0 none
swap defaults zramsize=419430400
>>
>>
>> I wanted to run a test with fsck in permissive to see if it only
requests getattr, or if it requests more. The pattern of requests might help
>> deduce the area of code executing.
>>
>> On Tue, Jan 19, 2016 at 9:28 AM, Jeffrey Vander Stoep <je...@google.com>
wrote:
>>>
>>> Does your zram have the notrim option set in the fstab? e.g.
https://android.googlesource.com/device/htc/flounder/+/master/fstab.flounder#16
>>>
>>>
>>> On Tue, Jan 19, 2016 at 9:18 AM Jeffrey Vander Stoep <je...@google.com>
wrote:
>>>>
>>>> I wonder if
https://android.googlesource.com/platform/external/e2fsprogs/+/master/e2fsck/profile.c#270
is
the cause. It's fstat'ing every file in the directory to see if it exists.
>>>>
>>>>
>>>>
>>>> On Tue, Jan 19, 2016 at 8:44 AM William Roberts <
bill.c.robe...@gmail.com> wrote:
>>>>>
>>>>> I was able to reproduce this on a device with sdcard support.
>>>>>
>>>>> [ 171.325196] type=1400 audit(1421405887.930:23): avc: denied {
getattr } for pid=2825 comm="e2fsck" path="/dev/block/zram0" dev="tmpfs"
ino=11308 scontext=u:r:fsck:s0 tcontext=u:object_r:swap_block_device:s0
tclass=blk_file permissive=0
>>>>>
>>>>> It works for us without this rule. This is likely related to vold as
Stephen pointed out calling the Format and Check routines (conjecture).
>>>>>
>>>>> dmesg:
>>>>> [ 9.405740] fs_mgr: Running /system/bin/e2fsck on
/dev/block/by-name/data
>>>>> [ 9.719493] e2fsck: e2fsck 1.42.9 (28-Dec-2013)
>>>>> [ 9.719578] e2fsck: data: clean, 1177/262944 files, 48464/1050112
blocks
>>>>> [ 9.786987] fs_mgr: Running /system/bin/e2fsck on
/dev/block/by-name/cache
>>>>> [ 9.817792] e2fsck: e2fsck 1.42.9 (28-Dec-2013)
>>>>> [ 9.817867] e2fsck: cache: clean, 16/6400 files, 1444/25600 blocks
>>>>>
>>>>> logcat:
>>>>> 01-16 05:56:01.577 168 191 V vold : /system/bin/fsck_msdos
>>>>> 01-16 05:56:25.902 674 1620 I BootReceiver: Checking for fsck
errors
>>>>> 01-16 05:58:07.832 168 191 D Vold : Running /system/bin/e2fsck
on /dev/block/dm-1
>>>>> 01-16 05:58:07.832 168 191 V vold : /system/bin/e2fsck
>>>>> 01-16 05:58:07.940 168 191 I e2fsck : e2fsck 1.42.9 (28-Dec-2013)
>>>>> 01-16 05:58:07.930 2825 2825 W e2fsck : type=1400 audit(0.0:23):
avc: denied { getattr } for path="/dev/block/zram0" dev="tmpfs" ino=11308
scontext=u:r:fsck:s0 tcontext=u:object_r:swap_block_device:s0
tclass=blk_file permissive=0
>>>>> 01-16 05:58:07.995 168 191 I e2fsck : /dev/block/dm-1: clean,
11/485760 files, 34812/1941243 blocks
>>>>>
>>>>>
>>>>> I see nothing failing, and we don't have this rule. As I said before,
and Jeff also re-iterated, if nothing is failing I would dontaudit this
>>>>> and look into whats causing this. I don't really have time to debug
this is an entirety at this point in time.
>>>>>
>>>>> Bill
>>>>>
>>>>> On Tue, Jan 19, 2016 at 8:24 AM, Jeffrey Vander Stoep <
je...@google.com> wrote:
>>>>>>
>>>>>> Some options:
>>>>>> Ignore it. It's working as intended.
>>>>>> dontaudit it. Same as above but removes the denial
>>>>>> track down the source of the denial and fix.
>>>>>> File a bug against AOSP.
>>>>>> On Tue, Jan 19, 2016 at 8:12 AM Inamdar Sharif <isha...@nvidia.com>
wrote:
>>>>>>>
>>>>>>> Checked init.rc as well, that’s perfectly alright.
>>>>>>>
>>>>>>> This avc I am facing while formatting the sdcard as internal
storage. Any more ideas??
>>>>>>>
>>>>>>> Thanks.
>>>>>>>
>>>>>>> -----Original Message-----
>>>>>>> From: Seandroid-list [mailto:seandroid-list-boun...@tycho.nsa.gov]
On Behalf Of Inamdar Sharif
>>>>>>> Sent: Tuesday, January 19, 2016 12:25 PM
>>>>>>> To: Roberts, William C; William Roberts
>>>>>>> Cc: seandroid-list@tycho.nsa.gov
>>>>>>> Subject: RE: avc denial while enabling zram
>>>>>>>
>>>>>>> Yes we do have the same settings from SELinux POV.
>>>>>>> We have the same code as the AOSP an no more additional changes on
top of it.
>>>>>>>
>>>>>>> I think I have to check how setting is done in init.rc . May be
that’s triggering that (Not sure , will try) I am using swapon_all for swap
space in init.rc.
>>>>>>>
>>>>>>> Thanks.
>>>>>>>
>>>>>>> -----Original Message-----
>>>>>>> From: Roberts, William C [mailto:william.c.robe...@intel.com]
>>>>>>> Sent: Tuesday, January 19, 2016 12:50 AM
>>>>>>> To: William Roberts; Inamdar Sharif
>>>>>>> Cc: seandroid-list@tycho.nsa.gov
>>>>>>> Subject: RE: avc denial while enabling zram
>>>>>>>
>>>>>>> The only thing we have is the label and for some reason (not sure
why offhand) a getattr for the swap_block file for vold.
>>>>>>>
>>>>>>> file_contexts:1:# ZRam device configured as swap space
>>>>>>> file_contexts:2:/dev/block/zram0 u:object_r:swap_block_device:s0
>>>>>>>
>>>>>>> vold.te:allow vold swap_block_device:blk_file getattr;
>>>>>>>
>>>>>>> We never had to allow any access from fsck. I see no dontaudits, so
perhaps were just ignoring the audit messages.
>>>>>>>
>>>>>>> Bill
>>>>>>>
>>>>>>> From: Seandroid-list [mailto:seandroid-list-boun...@tycho.nsa.gov]
On Behalf Of William Roberts
>>>>>>> Sent: Monday, January 18, 2016 8:53 AM
>>>>>>> To: Inamdar Sharif <isha...@nvidia.com>
>>>>>>> Cc: seandroid-list@tycho.nsa.gov
>>>>>>> Subject: RE: avc denial while enabling zram
>>>>>>>
>>>>>>> Interesting, we have swap on zram on Intel devices and I don't
recall hearing of anything related to this. So we may just be doing a
dontaudit or ignoring it, not sure offhand.
>>>>>>> On Jan 18, 2016 8:41 AM, "Inamdar Sharif" <isha...@nvidia.com>
wrote:
>>>>>>> >
>>>>>>> > >>Is that denial actually manifesting itself as some broken
functionality?
>>>>>>> >
>>>>>>> > As such it is not breaking anything. But this is seen while
formatting sdcard as internal storage.
>>>>>>> >
>>>>>>> >
>>>>>>> >
>>>>>>> > Also, why is fsck getting invoked on swap, especially one backed
by zram?
>>>>>>> >
>>>>>>> > Not sure about this but got something from the commit message
which says that we don’t have swap device on AOSP.
>>>>>>> >
>>>>>>> >
>>>>>>> >
>>>>>>> > <snip>
>>>>>>> >
>>>>>>> > e2fsck is invoked on any partitions marked with the check mount
>>>>>>> >
>>>>>>> > option in the fstab file, typically userdata and cache but never
>>>>>>> >
>>>>>>> > system. We allow it to read/write the userdata_block_device and
>>>>>>> >
>>>>>>> > cache_block_device types but also allow it to read/write the
default
>>>>>>> >
>>>>>>> > block_device type until we can get the more specific types
assigned
>>>>>>> >
>>>>>>> > in all of the device-specific policies.
>>>>>>> >
>>>>>>> >
>>>>>>> >
>>>>>>> > mkswap is invoked on any swap partition defined in the fstab file.
>>>>>>> >
>>>>>>> > We introduce a new swap_block_device type for this purpose, to be
>>>>>>> >
>>>>>>> > assigned to any such block devices in the device-specific
policies,
>>>>>>> >
>>>>>>> > and only allow it to read/write such block devices. As there
seem to
>>>>>>> > be
>>>>>>> >
>>>>>>> > no devices in AOSP with swap partitions in their fstab files, this
>>>>>>> > does
>>>>>>> >
>>>>>>> > not appear to risk any breakage for existing devices.
>>>>>>> >
>>>>>>> > </snip>
>>>>>>> >
>>>>>>> >
>>>>>>> >
>>>>>>> > Thanks.
>>>>>>> >
>>>>>>> >
>>>>>>> >
>>>>>>> > From: William Roberts [mailto:bill.c.robe...@gmail.com]
>>>>>>> > Sent: Monday, January 18, 2016 9:54 PM
>>>>>>> > To: Inamdar Sharif
>>>>>>> > Cc: seandroid-list@tycho.nsa.gov
>>>>>>> > Subject: Re: avc denial while enabling zram
>>>>>>> >
>>>>>>> >
>>>>>>> >
>>>>>>> > Is that denial actually manifesting itself as some broken
functionality?
>>>>>>> >
>>>>>>> > Also, why is fsck getting invoked on swap, especially one backed
by zram?
>>>>>>> >
>>>>>>> > On Jan 18, 2016 8:20 AM, "Inamdar Sharif" <isha...@nvidia.com>
wrote:
>>>>>>> >
>>>>>>> > Hi Guys,
>>>>>>> >
>>>>>>> >
>>>>>>> >
>>>>>>> > I am facing the below avc denial while enabling zram.
>>>>>>> >
>>>>>>> > avc: denied { getattr } for pid=7545 comm="e2fsck"
>>>>>>> >
path="/dev/block/zram0" dev="tmpfs" ino=11973 scontext=u:r:fsck:s0
>>>>>>> >
tcontext=u:object_r:swap_block_device:s0 tclass=blk_file permissive=0
>>>>>>> >
>>>>>>> >
>>>>>>> >
>>>>>>> > I have labelled dev/block/zram0 as swap_block_device
>>>>>>> >
>>>>>>> > Also I have an entry in the fstab :
>>>>>>> >
>>>>>>> > /dev/block/zram0 none swap defaults
>>>>>>> > zramsize=536870912
>>>>>>> >
>>>>>>> >
>>>>>>> >
>>>>>>> > But due to neverallow rule in fsck.te the above permission
cannot be granted.
>>>>>>> >
>>>>>>> > # fsck should never be run on these block devices
>>>>>>> >
>>>>>>> > neverallow fsck {
>>>>>>> >
>>>>>>> > boot_block_device
>>>>>>> >
>>>>>>> > frp_block_device
>>>>>>> >
>>>>>>> > metadata_block_device
>>>>>>> >
>>>>>>> > recovery_block_device
>>>>>>> >
>>>>>>> > root_block_device
>>>>>>> >
>>>>>>> > swap_block_device
>>>>>>> >
>>>>>>> > system_block_device
>>>>>>> >
>>>>>>> > vold_device
>>>>>>> >
>>>>>>> > }:blk_file no_rw_file_perms;
>>>>>>> >
>>>>>>> >
>>>>>>> >
>>>>>>> > So I think we have to remove swap_block_device from the
neverallow. Any suggestions??
>>>>>>> >
>>>>>>> >
>>>>>>> >
>>>>>>> > Thanks.
>>>>>>> >
>>>>>>> > ________________________________
>>>>>>> >
>>>>>>> > This email message is for the sole use of the intended
recipient(s) and may contain confidential information. Any unauthorized
review, use, disclosure or distribution is prohibited. If you are not the
intended recipient, please contact the sender by reply email and destroy
all copies of the original message.
>>>>>>> >
>>>>>>> > ________________________________
>>>>>>> >
>>>>>>> >
>>>>>>> > _______________________________________________
>>>>>>> > 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.
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> 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.
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> 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.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Respectfully,
>>>>>
>>>>> William C Roberts
>>>>>
>>
>>
>>
>> --
>> Respectfully,
>>
>> William C Roberts
>>
_______________________________________________
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.
