- 19 Dec, 2014 1 commit
-
-
Brian Carlstrom authored
Change-Id: Ic0a77a754b649d360d07eaa9e6a93274e7eaf0a8
-
- 18 Dec, 2014 6 commits
-
-
Dan Albert authored
Change-Id: Ie5ef819dd8168cb6a73f84a881a92c116705fffc
-
Dan Albert authored
-
Dan Albert authored
Since the dm_ioctl struct was being allocated on the stack as a large character array, it was getting character alignment rather than the proper alignment for the struct. GCC had been getting away with this so far, but it's undefined behavior that clang managed to expose. Bug: 18736778 Change-Id: Ied275dfad7fcc41d712b2d02c8a185f499221f57
-
Tim Murray authored
Change-Id: If504710a618d8c3adf85297d5fd2909558ed57a3
-
Tim Murray authored
-
Tim Murray authored
-Wno-missing-field-initializers is used as well, but that is an overzealous warning from initializing structs with {0} and not a real warning. bug 18736778 and 16868177 Change-Id: Iffde89cd7200d9a11193e1614f1819f9fcace30a
-
- 13 Dec, 2014 3 commits
-
-
Dan Albert authored
* commit 'a20bb17e': Move vold to GCC.
-
Dan Albert authored
-
Dan Albert authored
It looks like clang might have a miscompile that is causing SIGBUS in `ioctl_init` when the device is encrypted. Move back to GCC until we can sort this out. Bug: 18736778 Change-Id: I21ae3b9d7d9ebff8679ecc1a828b7c59f27d0903
-
- 02 Dec, 2014 8 commits
-
-
Paul Lawrence authored
* commit 'acfdc30e': Fix error in clocks leading to devices staying unlocked
-
Paul Lawrence authored
* commit 'd44a8f59': Fix encrypt-and-wipe
-
Paul Lawrence authored
* commit 'b25302e1': Do not log passwords returned through vdc
-
Paul Lawrence authored
-
Paul Lawrence authored
-
Paul Lawrence authored
Requires framework change: https://googleplex-android-review.git.corp.google.com/#/c/585511/ Bug: 18260068 Change-Id: I95d3bb39404ede7128b8f5d61ce2423a5f09a9b8
-
Paul Lawrence authored
Use BOOTTIME consistently! Bug: 18246810 Change-Id: I630bf39f72ab69f971d2f772e8d4545ffe467b82
-
Paul Lawrence authored
encrypt-and-wipe was broken when checks were added that encryption succeeded which assumed a 'normal' full encrypt traversing the device. encrypt-and-wipe doesn't traverse, it just lays down a file system over the encrypted device, so in this mode do not check the amount encrypted - it will always be 0. Bug: 18511900 Change-Id: Icb1d7e0cdb67abd2eac0ab3cbfc1a88912768f9d
-
- 21 Nov, 2014 4 commits
-
-
Iliyan Malchev authored
* commit 'bb7d9afe': fall back to dm-crypt if device already encrypted
-
Iliyan Malchev authored
Change-Id: Ie873baff626fe786515497f2e81aa9db2329168d
-
Iliyan Malchev authored
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>
-
Ajay Dudani authored
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>
-
- 06 Nov, 2014 5 commits
-
-
Dan Albert authored
* commit '89bcc638': Move vold to libc++.
-
Dan Albert authored
* commit 'a05cb413': Move vold to clang so ASAN_ALL works.
-
Dan Albert authored
* commit '36859212': Move vold to libc++.
-
Dan Albert authored
* commit '460a93a6': Move vold to clang so ASAN_ALL works.
-
Dan Albert authored
-
- 05 Nov, 2014 2 commits
-
-
Dan Albert authored
Bug: 15193147 Change-Id: Ib868f1ed8145ca5cbfdb4cd60ed0c47a6182ac62
-
Shawn Willden authored
automerge: 7c49ab0a * commit '7c49ab0a': Modify vold to check for hardware keymaster.
-
- 04 Nov, 2014 1 commit
-
-
Shawn Willden authored
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
-
- 30 Oct, 2014 1 commit
-
- 29 Oct, 2014 9 commits
-
-
Rubin Xu authored
-
Nick Kralevich authored
* commit '096dd2dd':
-
JP Abgrall authored
* commit '9b5a3812':
-
JP Abgrall authored
* commit '4c9b4d8c':
-
Paul Lawrence authored
* commit 'fd2180a9':
-
Paul Lawrence authored
am 6bcac81e: am 7639a6ab: Merge "Reset failed decryption count on successful decryptions" into lmp-dev * commit '6bcac81e':
-
Greg Hackmann authored
* commit 'b69a5e44':
-
Paul Lawrence authored
* commit 'f2eabef8':
-
Greg Hackmann authored
* commit 'e46f7122':
-