The `std::string package` variable goes out of scope but the input_path
variable is then used to access the memory as it's set to `c_str()`.
This was detected via OpenBSD malloc's junk filling feature.
Change-Id: Ic4b939347881b6ebebf71884e7e2272ce99510e2
We have the following warnings when compiling uncrypt on LP64 (e.g.
aosp_angler-userdebug).
bootable/recovery/uncrypt/uncrypt.cpp:77:53: warning: format specifies type 'long long' but the argument has type 'off64_t' (aka 'long') [-Wformat]
ALOGE("error seeking to offset %lld: %s\n", offset, strerror(errno));
~~~~ ^~~~~~
%ld
bootable/recovery/uncrypt/uncrypt.cpp:84:54: warning: format specifies type 'long long' but the argument has type 'unsigned long' [-Wformat]
ALOGE("error writing offset %lld: %s\n", (offset + written), strerror(errno));
~~~~ ^~~~~~~~~~~~~~~~~~
%lu
bootable/recovery/uncrypt/uncrypt.cpp:246:16: warning: comparison of integers of different signs: 'size_t' (aka 'unsigned long') and 'off_t' (aka 'long') [-Wsign-compare]
while (pos < sb.st_size) {
~~~ ^ ~~~~~~~~~~
According to POSIX spec [1], we have:
off_t and blksize_t shall be signed integer types;
size_t shall be an unsigned integer type;
blksize_t and size_t are no greater than the width of type long.
And on Android, we always have a 64-bit st_size from stat(2)
(//bionic/libc/include/sys/stat.h).
Fix the type and add necessary casts to suppress the warnings.
[1] http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/sys_types.h.html
Change-Id: I5d64d5b7919c541441176c364752de047f9ecb20
It turns out the standard explicitly states that if the pointer is
null, the deleter function won't be called. So it doesn't matter that
fclose(3) doesn't accept null.
Change-Id: I10e6e0d62209ec03ac60e673edd46f32ba279a04
This patch removes costly O_SYNC flag for encrypted block device.
After writing whole decrypted blocks, fsync should guarantee their consistency
from further power failures.
This patch reduces the elapsed time significantly consumed by upgrading packages
on an encrypted partition, so that it could avoid another time-out failures too.
Change-Id: I1fb9022c83ecc00bad09d107fc87a6a09babb0ec
Signed-off-by: Jaegeuk Kim <jaegeuk@motorola.com>
Move uncrypt from /init.rc to /system/etc/init/uncrypt.rc using the
LOCAL_INIT_RC mechanism
Bug 23186545
Change-Id: Ib8cb6dffd2212f524298279787fd557bc84aa7b9
Clean up leaky file descriptors in uncrypt/uncrypt.cpp. Add unique_fd
for open() and unique_file for fopen() to close FDs on destruction.
Bug: 21496020
Change-Id: I0174db0de9d5f59cd43b44757b8ef0f5912c91a2
When it reboots into recovery for a factory reset, it still needs to
write the uncrypt status (-1) to the pipe.
Bug: 21511893
(cherry picked from commit 2c2cae8a4a)
Change-Id: Ia5a75c5edf3afbd916153da1b4de4db2f00d0209
uncrypt needs to be triggered to prepare the OTA package before
rebooting into the recovery. Separate uncrypt into two modes. In
mode 1, it uncrypts the OTA package, but will not reboot the
device. In mode 2, it wipes the /misc partition and reboots.
Needs matching changes in frameworks/base, system/core and
external/sepolicy to work properly.
Bug: 20012567
Bug: 20949086
(cherry picked from commit 158e11d673)
Change-Id: I349f6d368a0d6f6ee4332831c4cd4075a47426ff
Fix the accidental change of behavior in [1]. OTA packages not on /data
partition should still go through the path that has validity checks and
wipe_misc() steps.
[1]: commit eaf33654c1.
Change-Id: Ice9a049f6259cd2368d2fb95a991f8a6a0120bdd
This should reduce errors if the device reboots before the blocks
are commited to disk.
Bug: 18481902
Change-Id: I13cda1c78955e4c83522fbcf87ddb16cc9f97683
Always create the block map for packages on /data; don't only look at
the encryptable/encrypted flags.
Bug: 17395453
Change-Id: Iaa7643a32898328277841e324305b9419a9e071c
Opening the misc block device in read-write mode runs afoul of
SELinux, which keeps the wipe code from working. Fix. Also change
various things to log to logcat so we can see them happening, for
future debugging.
Bug: 16715412
Change-Id: Ia14066f0a371cd605fcb544547b58a41acca70b9
Something is leaving behind wipe commands in the BCB area of the /misc
partition. We don't know what is doing that. It should always be
safe to zero out that area from uncrypt, though (because if uncrypt is
running then it's got the command we want in the recovery command file
rather than the BCB).
Bug: 16715412
Change-Id: Iad01124287f13b80ff71d6371db6371f43c43211
When going into recovery mode withoug recovery command file present, uncrypt crashes
and the device gets stuck and eventually shuts down.
Check that the command file is present before trying to read from it.
Change-Id: If0192d597032be0067738e437188d92993ce56f7
uncrypt can read a file on an encrypted filesystem and rewrite it to
the same blocks on the underlying (unencrypted) block device. This
destroys the contents of the file as far as the encrypted filesystem
is concerned, but allows the data to be read without the encryption
key if you know which blocks of the raw device to access. uncrypt
produces a "block map" file which lists the blocks that contain the file.
For unencrypted filesystem, uncrypt will produce the block map without
touching the data.
Bug: 12188746
Change-Id: Ib7259b9e14dac8af406796b429d58378a00c7c63
