sqlite: Remove USE_SYSTEM_SQLITE option.
We currently use the system-supplied SQLite library on iOS.
This is not the end of the world, because we require iOS 10.0+, which
means SQLite 3.14+, which has the features that Chrome uses. iOS is also
special in that we don't ship Blink, so we don't expose SQLite via
WebSQL -- we control all the other SQL queries we send to SQLite, so
SQLite security bugs aren't easily exploitable.
At the same time, USE_SYSTEM_SQLITE means Chrome for iOS uses an
entirely different SQLite build that most developers don't run. This
makes it more likely that we'll introduce bugs or crashes, and makes it
more difficult to investigate existing bugs/crashes.
In theory, USE_SYSTEM_SQLITE seems appealing on Android and Linux. In
practice, the idea isn't workable on either platform.
* On Android, not shipping our own SQLite would cut down APK size by a few
hundred KB. However, Android doesn't have a great upgrade story before
Lollipop (5.0), and we still support KitKat (4.4). SQLite is exposed
via WebSQL on Android, so we must be in control of SQLite upgrades.
* Linux distributions would like to ship Chromium builds linked against
their SQLite copies. However, https://crbug.com/807487 suggests that
USE_SYSTEM_SQLITE on Linux would result in unacceptable stability. The
root cause of the bug was that NSS can load SQLite on Linux, resulting
in SQLite getting initialized outside our control. Even if we could
fix that bug (via a dependency from //crypto to //sql), we'd still
have to chase all the libraries that might potentially initialize
SQLite. Today we believe that NSS is the only library in that set, but
we simply don't have the bandwidth to justify investigating the bug
reports that will come if we miss something.
In conclusion, there is no platform where USE_SYSTEM_SQLITE is desirable
and viable. So, this CL removes USE_SYSTEM_SQLITE from the codebase.
This will cause the iOS build to increase by a few hundred KB. This
price buys us one less difference between iOS and every other platform,
and increased OS stability in the long run, as iOS bugs / crashes will
be easier to diagnose.
Bug: 22208, 299684, 372584, 807093, 807487
Cq-Include-Trybots: master.tryserver.chromium.mac:ios-device
Change-Id: I1bd64bd93527624e197bd082c725a952c8b3c430
Reviewed-on: https://chromium-review.googlesource.com/898223
Commit-Queue: Victor Costan <[email protected]>
Reviewed-by: Chris Mumford <[email protected]>
Reviewed-by: Sylvain Defresne <[email protected]>
Cr-Commit-Position: refs/heads/master@{#535148}diff --git a/sql/vfs_wrapper.cc b/sql/vfs_wrapper.cc
index e0e33b75..4db41485 100644
--- a/sql/vfs_wrapper.cc
+++ b/sql/vfs_wrapper.cc
@@ -284,17 +284,23 @@
}
#endif
- // The wrapper instances must support a specific |iVersion|, but there is no
- // explicit guarantee that the wrapped VFS will always vend instances with the
- // same |iVersion| (though I believe this is always the case in practice).
- // Vend a distinct set of IO methods for each version supported.
+ // |iVersion| determines what methods SQLite may call on the instance.
+ // Having the methods which can't be proxied return an error may cause SQLite
+ // to operate differently than if it didn't call those methods at all. To be
+ // on the safe side, the wrapper sqlite3_io_methods version perfectly matches
+ // the version of the wrapped files.
//
- // |iVersion| determines what methods SQLite may call on the instance. Having
- // the methods which can't be proxied return an error may cause SQLite to
- // operate differently than if it didn't call those methods at all. Another
- // solution would be to fail if the wrapped file does not have the expected
- // version, which may cause problems on platforms which use the system SQLite
- // (iOS and some Linux distros).
+ // At a first glance, it might be tempting to simplify the code by
+ // restricting wrapping support to VFS version 3. However, this would fail
+ // on Fuchsia and might fail on Mac.
+ //
+ // On Mac, SQLite built with SQLITE_ENABLE_LOCKING_STYLE ends up using a VFS
+ // that dynamically dispatches between a few variants of sqlite3_io_methods,
+ // based on whether the opened database is on a local or on a remote (AFS,
+ // NFS) filesystem. Some variants return a VFS version 1 structure.
+ //
+ // Fuchsia doesn't implement POSIX locking, so it always uses dot-style
+ // locking, which returns VFS version 1 files.
VfsFile* file = AsVfsFile(wrapper_file);
file->wrapped_file = wrapped_file;
if (wrapped_file->pMethods->iVersion == 1) {
@@ -503,12 +509,14 @@
(wrapped_vfs->xCurrentTime ? &CurrentTime : nullptr);
wrapper_vfs->xGetLastError = &GetLastError;
// The methods above are in version 1 of sqlite_vfs.
- // There were VFS implementations with nullptr for |xCurrentTimeInt64|.
- wrapper_vfs->xCurrentTimeInt64 =
- (wrapped_vfs->xCurrentTimeInt64 ? &CurrentTimeInt64 : nullptr);
+ DCHECK(wrapped_vfs->xCurrentTimeInt64);
+ wrapper_vfs->xCurrentTimeInt64 = &CurrentTimeInt64;
// The methods above are in version 2 of sqlite_vfs.
+ DCHECK(wrapped_vfs->xSetSystemCall);
wrapper_vfs->xSetSystemCall = &SetSystemCall;
+ DCHECK(wrapped_vfs->xGetSystemCall);
wrapper_vfs->xGetSystemCall = &GetSystemCall;
+ DCHECK(wrapped_vfs->xNextSystemCall);
wrapper_vfs->xNextSystemCall = &NextSystemCall;
// The methods above are in version 3 of sqlite_vfs.
