Devices already encrypted with aes-cbc-essiv:sha256 will continue to be
decrypted in software, until a factory data reset. New devices that
implement CONFIG_HW_DISK_ENCRYPTION will switch to aes-xts.
b/17475056 Enable hardware crypto for userdata encryption
Change-Id: I62d1583bdaf7ff06b87e386e758fa3b18c719bca
Signed-off-by: Iliyan Malchev <malchev@google.com>
Currently Android provides disk encryption support using dm-crypt
which is based on bios. dm-crypt uses 512 bytes packet size for
crypto operations. While 512 bytes size packet is ok for SW based
disk encryption, it is inefficient for HW based crypto engines.
dm-req-crypt is similar to dm-crypt except it uses block requests
rathe bios for crypto operations. block requests when unpacked
carries data upto 512KB. Hence, HW based crypto engine can be used
more efficiently.
Also move create disk encryption key before framework start as
HW based disk encryption creates key in secure side. Key creation
can take sometime to create the key securely. If framework is
started before creating the key, it is possible that framework
requests service from secure side. Secure side can serve mostly one
request at a time. Secure side may reject framework request if key
creation request is still going on. This may cause problem in the
system
b/17475056 Enable hardware crypto for userdata encryption
Change-Id: I5480ab72a37c02532218a18faaba598a824589fd
Signed-off-by: Iliyan Malchev <malchev@google.com>
vold should only use hardware keymaster implementations to protect the
disk encryption key, because there's little value in using the software
implementation. More importantly, if we allow vold to use softkeymaster
in the absence of a HW keymaster and (somehow) a HW keymaster is added
to a device, the HW version will be loaded, and will be unable to use
the softkeymaster key found in the crypto footer, forcing a factory
reset.
This CL will not break devices without HW keymaster, because
softkeymaster currently reports its keys as non-standalone (which isn't
correct). After this CL is in, I will fix softkeymaster.
Bug: 17362157
Change-Id: I98b169e7a59ff7d44b72069b87743463ec823ea2
Store long field values in multiple underlying fixed-length entries
and concatenate them together when reading back.
Bug: 17556485
Change-Id: I2f8033d18c208993fa1b010712be0dad5d8b646b
ASAN_ALL uses ASAN for anything built with clang. Since some of vold's
dependencies use clang, they will have unresolved ASAN symbols unless
vold is also built with clang. There's no harm in just moving this
project to clang.
Change-Id: Ia6f412beb7bf092121bff2a5a980531636adcdb9
There are cases where the /dev/block/dm-0 fails to open.
This leads to the device not completing the boot up sequence.
Currently, the only way out is to reboot.
Bug: 17898962
Change-Id: If4583ebb1ef1ebdbaf680d69b876459aaec2f4ce
(cherry picked from commit 7fc1de8a44)
There are cases where the /dev/block/dm-0 fails to open.
This leads to the device not completing the boot up sequence.
Currently, the only way out is to reboot.
Bug: 17898962
Change-Id: If4583ebb1ef1ebdbaf680d69b876459aaec2f4ce
Some times the /dev/block/dm-0 fails to open after it has been setup.
Log why.
Bug: 17576594
Bug: 17942270
Change-Id: If0bbfe22d84137f2029bacb10873832038f0d36c
Some times the /dev/block/dm-0 fails to open after it has been setup.
Log why.
Bug: 17576594
Bug: 17942270
Change-Id: If0bbfe22d84137f2029bacb10873832038f0d36c
scrypt pads the password with zeros. Our patterns use 0 to represent
the top left dot. So patterns that end there are equivalent to ones
that end one short.
After much thought, the best solution is to change the way we
represent patterns in keyguard. This, however, is a big change.
The short term solution is to change the pattern representation in vold
so that we are storing the correct thing. Later we will change keyguard
to handle patterns correctly and remove quite a few hacks from vold
(use of hex, this code). b/17840293 created to track this.
Bug: 17751714
Change-Id: I30cdffb0f0db406d2e2b6c54d4153d120d975318