MemoryIntArray was using the size of the undelying
ashmem region to mmap the data but the ashmem size
can be changed until the former is memory mapped.
Since we use the ashmem region size for boundary
checking and memory unmapping if it does not match
the size used while mapping an attacker can force
the system to unmap memory or to access undefined
memory and crash.
Also we were passing the memory address where the
ashmem region is mapped in the owner process to
support cases where the client can pass back the
MemoryIntArray instance. This allows an attacker
to put invalid address and cause arbitrary memory
to be freed.
Now we no longer support passing back the instance
to the owner process (the passed back instance is
read only), so no need to pass the memory adress
of the owner's mapping, thus not allowing freeing
arbitrary memory.
Further, we now check the memory mapped size against
the size of the underlying ashmem region after we do
the memory mapping (to fix the ahsmem size) and if
an attacker changed the size under us we throw.
Tests: Updated the tests and they pass.
bug:33039926
bug:33042690
Change-Id: Ibf56827209a9b791aa83ae679219baf829ffc2ac
MemoryIntArray was using the size of the undelying
ashmem region to mmap the data but the ashmem size
can be changed until the former is memory mapped.
Since we use the ashmem region size for boundary
checking and memory unmapping if it does not match
the size used while mapping an attacker can force
the system to unmap memory or to access undefined
memory and crash.
Also we were passing the memory address where the
ashmem region is mapped in the owner process to
support cases where the client can pass back the
MemoryIntArray instance. This allows an attacker
to put invalid address and cause arbitrary memory
to be freed.
Now we no longer support passing back the instance
to the owner process (the passed back instance is
read only), so no need to pass the memory adress
of the owner's mapping, thus not allowing freeing
arbitrary memory.
Further, we now check the memory mapped size against
the size of the underlying ashmem region after we do
the memory mapping (to fix the ahsmem size) and if
an attacker changed the size under us we throw.
Tests: Updated the tests and they pass.
bug:33039926
bug:33042690
Change-Id: I1004579181ff7a223ef659e85c46100c47ab2409
MemoryIntArray was using the size of the undelying
ashmem region to mmap the data but the ashmem size
can be changed until the former is memory mapped.
Since we use the ashmem region size for boundary
checking and memory unmapping if it does not match
the size used while mapping an attacker can force
the system to unmap memory or to access undefined
memory and crash.
Also we were passing the memory address where the
ashmem region is mapped in the owner process to
support cases where the client can pass back the
MemoryIntArray instance. This allows an attacker
to put invalid address and cause arbitrary memory
to be freed.
Now we no longer support passing back the instance
to the owner process (the passed back instance is
read only), so no need to pass the memory adress
of the owner's mapping, thus not allowing freeing
arbitrary memory.
Further, we now check the memory mapped size against
the size of the underlying ashmem region after we do
the memory mapping (to fix the ahsmem size) and if
an attacker changed the size under us we throw.
Tests: Updated the tests and they pass.
bug:33039926
bug:33042690
Change-Id: Id7f0e8a4c861b0b9fa796767e0c22d96633b14d1
MemoryIntArray was using the size of the undelying
ashmem region to mmap the data but the ashmem size
can be changed until the former is memory mapped.
Since we use the ashmem region size for boundary
checking and memory unmapping if it does not match
the size used while mapping an attacker can force
the system to unmap memory or to access undefined
memory and crash.
Also we were passing the memory address where the
ashmem region is mapped in the owner process to
support cases where the client can pass back the
MemoryIntArray instance. This allows an attacker
to put invalid address and cause arbitrary memory
to be freed.
Now we no longer support passing back the instance
to the owner process (the passed back instance is
read only), so no need to pass the memory adress
of the owner's mapping, thus not allowing freeing
arbitrary memory.
Further, we now check the memory mapped size against
the size of the underlying ashmem region after we do
the memory mapping (to fix the ahsmem size) and if
an attacker changed the size under us we throw.
Tests: Updated the tests and they pass.
bug:33039926
bug:33042690
Change-Id: Ie267646eb88014034fbd048d7a9bc273420c7eff
This change adds historical operations to the dump state
of the settings provider. The historica operations are
currently appended only on user-debug and eng builds.
These change is needed to help diagnose the referred
bug and improve the settings provider's maintenance.
bug:30561721
Change-Id: I58a1ba0d598c4d28adcb5e654ebb78cf947e94db
If the device being upgraded happens to have a timeout of
500ms it will be reset to 400. If the value is something
else it will be left alone upon upgrade.
Bug: 30159825
Change-Id: Ifec70e458ce0199b61d36f7504aea02b4a974990
- Removed Secure.ACCESSIBILITY_DISPLAY_COLOR_MATRIX, it's not desirable
to persist the actual color transformation matrix.
- Refactored all SurfaceFlinger transforms to DisplayTransformManager,
which allows color transforms to be set independently from the a11y
manager service.
Bug: 30042357
Change-Id: Iefa477dedb66aac90e1218e327802a3fab6899ed
Currently we used global setting to restrict user from enabling oem
unlock. As global settings can be chagned using adb, using user
restrictions instead.
Bug: 29893399
Change-Id: Ic83112a4838b8279bf50408a29ae205e0b8639ee
We send a handle to the generation tracker along with the first accessed
setting but don't send the generation id of when the setting was
actually looked up. So by the time the client gets the setting with the
generation tracker from which to get and cache the last generation the
setting may have changed. We need to pass the generation id along with
the value and the generation tracker.
bug:29458487
Change-Id: I0ac4955ba5b10b547f8fe653a7c28e048a4691eb
When merging backed-up configurations with the current supplicant
configuration, we read both configurations into a instance of
WifiNetworkSettings. No EAP configurations should be restored as
per b/25725016, however existing EAP configurations that already
reside in wpa_supplicant.conf (presumably configured in SUW)
should not be removed in the process.
This CL adds a parameter to the "readNetworks" method to allow it
to select whether or not EAP configurations should be read in. It
is used to allow the "restoreWifiSupplicant" method to copy in EAP
configurations from the existing wpa_supplicant.conf, but not out
of the backup data.
BUG: 28873992
Change-Id: I8b3e0c1a6629b3f1ca5055b1b2190e6b3ca4c033
am: 967fcfa593
* commit '967fcfa5939403017a6edc6d365b2996b915685d':
Use the correct handler when persisting the settings state.
Change-Id: I53fea39e5097512f080f62f3510cc6c7acf87e3c
Settings is using a MemoryIntArray to communicate the settings table
version enabling apps to have up-to-date local caches. However, ashmem
allows an arbitrary process with a handle to the fd (even in read only
mode) to unpin the memory which can then be garbage collected. Here we
make this mechanism fault tolerant against bad apps unpinning the ashmem
region. First, we no longer unpin the ashmem on the client side and if
the ashmem region is purged and cannot be pinned we recreate it and
hook up again with the local app caches. The change also adds a test
that clients can only read while owner can read/write.
bug:28764789
Change-Id: I1ef79b4b21e976124b268c9126a55d614157059b
Settings were persisted on the system background thread but during
first boot the device is under heavy load and persisting settings
competes with other system components using the shared background
thread. As a result persisting settings can be delayed much longer
than the expected 200ms. This can cause issues with setup wizard
being skipped/went over and its component disaabled being persisted
but the setting whether the device is provisioned not being
persisted - now if the device boots it will have no SUW but also
the home button would be missing. Generally, we need a tansactional
abstraction in the system process to peform all delayed operations
atomically.
bug:25472484
Change-Id: I8e0cf7ffa32e86e36e777964eb0c3cc7de02d3c3
Settings were persisted on the system background thread but during
first boot the device is under heavy load and persisting settings
competes with other system components using the shared background
thread. As a result persisting settings can be delayed much longer
than the expected 200ms. This can cause issues with setup wizard
being skipped/went over and its component disaabled being persisted
but the setting whether the device is provisioned not being
persisted - now if the device boots it will have no SUW but also
the home button would be missing. Generally, we need a tansactional
abstraction in the system process to peform all delayed operations
atomically.
bug:25472484
Change-Id: Icf38e72403b190a8fa9d0554b8dd83ce78da3bc8
+ By default, OEM unlocking setting is enabled.
+ Add a check to prevent oem unlock being flipped if the setting isn't
enabled.
Bug: 28163088
Change-Id: I087d8d5a1d99a611a8f66ff71a92ec9ea1da4e9f
We now have a null object instead of null values and
there was a place where we returned null instead of
the correct null object.
bug:28423485
Change-Id: I2626768acdf8d19fc94aa5e978eb057818450fa5
