These add 16 bytes per ZIP entry, and are usually avoidable. APKs contain thousands of
deflated entries, so this overhead adds up to tens of kilobytes.
Bug: 135470635
Change-Id: Ib928aa41dd55cacc41f7394c218c4340d3bbd570
This would allow adding entries from one zip archive into
a new one without copying, directly from a ZipString object
Change-Id: I52f91008f497e798e044c43f57a6481cf4bec36d
All but one existing caller actually wants a std::string.
Bug: http://b/129068177
Test: treehugger
Change-Id: I428c4453edaae74451db56e9542e4e462f08d43a
Same issue as with FindEntry: using ZipString in the API forces all
callers to make sure they don't hit the ZipString length limits. Switch
to std::string_view and uniformly use the empty string as a way to
signal no prefix/suffix rather than nullptr.
Also use default arguments to make the common case of no prefix and no
suffix more convenient.
Also just use std::string to increase the lifetime of the provided
prefix/suffix rather than manual memory management.
Bug: http://b/129068177
Test: treehugger
Change-Id: I6675e39ce62fadd766386d77d27423013c17d6f7
Enable native bridge support for libbase, liblog,
libziparchive and libpropertyinfoparser.
This makes it possible to use them in binaries for translated
architectures.
Bug: http://b/77159578
Test: make
Change-Id: If67ce92288b17a052ea1e79a268e284f7d941439
Switch FindEntry and the ZipString constructor to std::string_view. This
lets us accept an over-long name so that we can reject it as too long.
Also fastboot changes to track the API change.
Bug: http://b/129068177
Test: treehugger
Change-Id: I7df7acd1fe2c46380b789c25f8909e0553e2d55e
Enable -Wconversion (but not -Wsign-conversion). Fix up code. Handle
some actual error cases:
* too many files
* files too large
Bug: 130039052
Test: atest ziparchive-tests
Change-Id: I632af317b9e65dbc728851efefd0d11a2b5c29b9
converting from a size_t to a uint8_t results in a loss of precision,
which triggers ubsan's implicit-unsigned-integer-truncation checker.
Make the conversion explicit.
This change allows the ziparchive-tests to pass with ubsan enabled.
Test: atest ziparchive-tests
Test: compiles and boots
Bug: 122975762
Change-Id: I63f28b58f1ca1f4c57323494cb1f4a41e0f34fba
Although ubsan's implicit-unsigned-integer-truncation sanitizer may be
happy, this code still performs an implicit conversion from a wider
width data structure to a narrower width data structure. Rather than
masking the bits, make the conversion explicit. This keeps ubsan happy
as well as addressing a -Wconversion warning.
This change addresses comments from the post-submit review
of a4e5433660.
Test: compiles and boots.
Bug: 122975762
Change-Id: I1fa6d6f8a6fcfb93ba9916b7d2b3564ca1d8caf3
std::hash returns a 64 bit value, which is truncated to a 32 bit value
in ComputeHash. ubsan's implicit-unsigned-integer-truncation doesn't
like this implicit truncation and crashes the program. Explicitly strip
off the top order bits after computing the hash.
Remove the windows specific version of the hash computation. The windows
compile now uses clang, so this code is obsolete. This also avoids us
having to add __attribute__((no_sanitize("integer"))) to the windows
code.
This is needed to support Android booting with ubsan's
implicit-unsigned-integer-truncation option enabled.
Test: compiles and boots
Bug: 122975762
Change-Id: I2f05fbf5ffee8e90a66a6fda32e80de9cca246c0
Update the powerof2 macro to one that is integer overflow safe.
This definition is the same one used by bionic, but cleaned up using
clang_format.
Unconditionally use this powerof2 macro, to ensure consistency across
all the build environments.
Test: compiles and boots
Change-Id: I21bfaf2360d1f77caf96365e20490b1deadfdfe0
The process of determining whether or not to emit a safetynet error
entry while processing a malformed file relies on addition overflow.
Since this is only logging, and logging which isn't used, delete the
code instead of trying to fix the logic which is causing the integer
overflow.
This change is necessary to enable integer sanitization on this code.
Somewhat related to Bug: 122975762
Test: atest ziparchive-tests
Change-Id: I6b41ccf7881348cb4e5236324eaa44a05662a725
Attempting to shift a uint8_t which has the top bit set results in a
value outside of the range allowable for a uint8_t. The process of
converting this value back to a uint8_t triggers ubsan's
implicit-conversion sanitizer.
Ensure the high order bit is stripped before shifting, so that the
shifted value fits into the allowable uint8_t range.
This change is necessary to enable integer sanitization on this code.
Somewhat related to Bug: 122975762
Test: atest ziparchive-tests
Change-Id: I940c8b2828ac88348d80f731274b990e35de6631
The code in libziparchive has lots of questionable looking but not
obviously wrong integer operations. In order to shake out integer bugs
in libziparchive (for example, commit
1ee4892e66 from bug 31251826) and provide
protection against security bugs, enable some integer sanitization
options in libziparchive.
Bug: 122975762
Bug: https://bugs.chromium.org/p/chromium/issues/detail?id=941802
Test: device boots and no obvious problems.
Change-Id: I215d81892a6eff12d692648c69a03e8200b334d7
Other CL in topic address the issue of the file pusher.
The explicit config for this module will not be required
anymore.
Test: atest -v ziparchive-tests
Bug: 124515549
Change-Id: I4dad8adbce0817009158bc191c2cce86c38d9e3e
To work around problems with the autogenerated one.
Bug: 117891984
Bug: 124515549
Test: atest ziparchive-tests
Change-Id: Ia4b352b7404255a4fe9e644a56ae9c5d41c79886
Prevent file descriptors from leaking across an exec() boundary.
Bug: 120983106
Test: compiles and boots
Change-Id: I392b0767674b557b1e4404a2ba63bc48e3e37b24
We can't add the ones that need a shared library because the
infrastructure doesn't work yet. (We also can't comment this in the file,
because there's no support for comments :-( .)
Bug: N/A
Test: N/A
Change-Id: I4d84f962bbf48fc708df336726c18e48fe206492
The Mac doesn't have lseek64, and this code is built with
_FILE_OFFSET_BITS=64 anyway.
Bug: N/A
Test: ran tests
Change-Id: Ibda49c44ecfbe21b304e163e48f7ea42d97e38a7
system/core/libziparchive/zip_archive.cc:847:36: error: use of undeclared identifier 'lseek64'; did you mean 'lseek'?
const off64_t current_offset = lseek64(fd, 0, SEEK_CUR);
Bug: N/A
Test: builds
Change-Id: If762011722d53376bb6dab35c6ee8031762e5a95
The libziparchive public headers that refer to `off64_t` also need the
Mac workaround.
In fastboot, there's a stray `lseek64` but since it's only for offset 0,
any kind of seek is fine.
Bug: N/A
Test: builds
Change-Id: I68b4f95202623ebf07ffe6c3e0e21437e7922c5b
This allows us to remove libziparchive's dependency on libutils.
Bug: http://b/79112958
Test: ran libbase and libziparchive tests, ran fastboot manually
Change-Id: I95c651976dad222863e5b8c37d4514b778f5dce7
A typedef to void* allows an implicit conversion from ZipArchiveHandle*
(or any other pointer type) to ZipArchiveHandle.
See I95d79809b6e118fb3c39c7b98b8055c8e324db1a in platform/bionic.
Bug: none
Test: m checkbuild
Change-Id: I3dd426cb64c46ef81e1dd81b4a2e4f40ac2701df
Bug: http://b/91353691
Enable -Wold-style-cast only for non-Windows targets. _islower_l,
_isupper_l etc. in MinGW locale_win32.h (included from
libcxx/include/__locale) have an old-style-cast.
Test: Build and test Windows modules under Wine.
Change-Id: Ib7594559a43096885b0cc1c656cf59db8b52d38b
Debugging memory allocations on the nexus launcher unveiled significant memory allocations for the hashatable used in libziparchive, ~1MB.
This is partly because of the ZipString struct storing an entry in the table. The struct stored a pointer to a string (on 64 bit, 8 bytes) and the length to read from that pointer, 2 bytes. Because of alignment, the structure consumed 16 bytes, wasting 6 bytes.
Now, we store entries in the hashtable as a ZipStringOffset. This new structure stores a 4 byte offset from a fixed location in the memory mapped file instead of the entire address, consuming 8 bytes with alignment.
Bug: 79416399
Test: Builds successfully and manual testing by opening launcher on Pixel 2 shows precisely 50% decrease in memory allocated for the hashtable. From 909312 bytes to 454656.
Change-Id: I28b43699233fbee7f63fccae2d4fe96fcc07e5c4
Allows for opening zip files usng paths longer than 260 characters and
with unicode characters on Windows.
Bug: 113110184
Test: manual and libziparchive_tests
Change-Id: I9ce96ac2f1b1e448ae2a2f69c1d4cb3395ea79ee
