There is a race in ueventd's coldboot procedure that permits creation
of device block nodes before platform devices are registered. This happens
when the kernel sends events for adding block devices during ueventd's
coldboot /sys walk.
In this case the device node links used to compute the SELinux context
are not known and the node is created under the generic context:
u:object_r:block_device:s0.
A second add event for block device nodes is triggered after the platform
devices are handled by ueventd and the SELinux context is correctly computed
but the mknod call fails because the node already exists. This patch handles
this error case and updates the node's security context.
The race is introduced by the uevent sent from the sdcard device probe
function. The issue appears when this uevent is triggered during ueventd's
coldboot procedure but before the /sys/devices recursive walk reached the
corresponding sdcard platform device path.
The backtrace looks something like:
1. ueventd_main()
2. device_init()
3. coldboot("/sys/devices");
4. do_coldboot()
5. handle_device_fd()
6. handle_device_event()
6.1 handle_block_device_event()
6.2 handle_platform_device_event()
Because handle_device_fd() reads all events from the netlink socket it may
handle the add events for the sdcard partition nodes send occasionally by the
kernel during coldboot /sys walk procedure.
If handle_device_event() continues with handle_block_device_event()
before handle_platform_device_event() registers the sdcard platform device then
handle_block_device_event() will create device nodes without knowing all block
device symlinks (get_block_device_symlinks()):
1. handle_device(path=/dev/block/mmcblk0p3, links = NULL)
2. make_device(path=/dev/block/mmcblk0p3, links = NULL)
3. selabel_lookup_best_match(path=/dev/block/mmcblk0p3, links = NULL)
returns the default context (u:object_r:block_device:s0) for
/dev/block/mmcblk0p3 instead of more specific context like:
u:object_r:boot_block_device:s0
4. setfscreatecon(u:object_r:block_device:s0)
5. mknod(/dev/block/mmcblk0p3)
So the node is create with the wrong context. Afterwards the coldboot /sys walk
continues and make_device() will be called with correct path and links.
But even if the secontext is computed correctly this time it will not be
applied to the device node because mknod() fails.
I see this issue randomly appearing (one time in 10 reboots) on a Minnoboard
Turbot with external sdcard as the boot device.
BUG=28388946
Change-Id: I96e239af29d82b753e5d349b3ecefaad09edee87
Signed-off-by: Mihai Serban <mihai.serban@intel.com>
Most of the system/core/include/log/log.h file uses the C99 syntax of
variadic macros (that is, '...' in parameter list and __VA_ARGS__
in arguments). Except for andoid_printLog and android_printAssert
which still uses GCC custom extension syntax.
Switched the remaining macros to use C99 syntax. GCC extension syntax
makes my editor's code parser puke.
BUG: None
Change-Id: Ia6ebc0f2044b64182c425b179da0229c7046be4a
We previously relied on the fact that target sdk version 0
implies system_server, which is not true, target sdk version
may be set to 0 for other apps and it means 1 - the earliest
version of android. This change enables namespaces for
apps targeting all sdk version and for system_server.
Bug: http://b/27702070
Change-Id: I16fbdeb6868c7035aec71132c80c150c08ea2cc3
(cherry picked from commit 213676b880)
am: f7c31b9
* commit 'f7c31b9552da778ebea5ac3c2bd3c5260b5e7705':
adb: use a custom thread to poll for usb devices on mac.
Change-Id: I6fb6686525a9e67f2a12be955d4a1692eeb5ab6a
Problem: For devices using /dev/usb-ffs/adb, Run
`while true; do adb reconnect device; sleep 1; done`. And the
device soon becomes offline. The adbd log shows that calling
adb_read(h->bulk_out) in usb_ffs_read() gets EOVERFLOW error.
Reason: When kicking a transport using usb-ffs, /dev/usb-ffs/adb/ep0
is not closed, and the device will not notify a usb connection reset
to host. So the host will continue to send unfinished packets even
if a new transport is started on device. The unfinished packets may
not have the same size as what is expected on device, so adbd on
device gets EOVERFLOW error. At the worst case, adbd has to create new
transports for each unfinished packet.
Fixes:
The direct fix is to make the usb connection reset when kicking transports,
as in https://android-review.googlesource.com/#/c/211267/1. And I think
we can make following improvements beside that.
1. Close a file that is used in other threads isn't safe. Because the file
descriptor may be reused to open other files, and other threads may operate
on the wrong file. So use dup2(dummy_fd) to replace close() in kick function,
and really close the file descriptor after the read/write threads exit.
2. Open new usb connection after usb_close() instead of after
usb_kick(). After usb_kick(), the transport may still exist and
reader/writer for the transport may be still running. But after
usb_close(), the previous transport is guaranteed to be destroyed.
Bug: 25935458
Change-Id: I1eff99662d1bf1cba66af7e7142f4c0c4d82c01b
(cherry picked from commit 005bf1e05b)
am: dbb3e3b
* commit 'dbb3e3ba92b090afa32808cbb504d4c653f5311c':
adb: decrease the number of fds used in fd_count test.
Change-Id: Id48542904272ac506eec121fa21cbed374b9408d
am: c296440
* commit 'c2964402b6ff91126bbbf7dd453adca40a13bd64':
adb: decrease the number of fds used in fd_count test.
Change-Id: Id078e3b319bdd8591b78898e543a636f9eac6bf0
On mac, if the adb server kicks a transport on some error, mac usb driver
will not report a new usb device. So instead of relying on mac usb driver
to report new usb devices, this CL uses a loop to search for usb devices
not exist before. Note that this is also the behavior on windows and linux
host.
`adb reconnect` can be used to verity this CL.
Bug: 25935458
Change-Id: I890e0eb1fae173f2e7a0c962ededa294d821e015
(cherry picked from commit 48d4c0c42a)
https://android-review.googlesource.com/#/c/210646/ added a
has_shell_protocol() function but the test_device.py tests were still
trying to use the now-missing SHELL_PROTOCOL_FEATURE constant.
This CL just switches test_device.py to correctly use the
has_shell_protocol() method.
Change-Id: Ie0a2f0dc07529843d25051a01e08fb677551a4e1
Test: `python -m unittest discover -v` on devices with and without
the shell protocol.
This allows inotify requests on FUSE to be alerted when any
other stacked filesystem would trigger an inotify for the
same file.
Bug: 23904372
Change-Id: I4289b38230c314432eaf2c0d20d4ccefc058f59e
