Use higher dynamic address space limit unconditionally.

We are working to enable full guard regions for WebAssembly memories on all
64-bit platforms, whereas previously they were only used when the WebAssembly
trap handler feature was used. Since each memory + guard region requires 8 GiB
of address space, the original 16 GiB limit is no longer sufficient. This CL
makes the behavior of having a higher hard limit on the address space and a
lower soft limit that is raised when needed to allocate a WebAssembly memory
available even when not using trap handlers.

Bug: chromium:828499, v8:7619
Change-Id: I31a279176b91bf18be140a15bf2f64ae62debba1
Reviewed-on: https://chromium-review.googlesource.com/1000334Reviewed-by: Kentaro Hara <haraken@chromium.org>
Reviewed-by: Jorge Lucangeli Obes <jorgelo@chromium.org>
Reviewed-by: Chris Palmer <palmer@chromium.org>
Commit-Queue: Eric Holk <eholk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#550754}

content/renderer/renderer_main_platform_delegate_linux.cc

@@ -35,8 +35,6 @@ bool RendererMainPlatformDelegate::EnableSandbox() {
   //
   // Anything else is started in InitializeSandbox().
   service_manager::SandboxLinux::Options options;
-  options.has_wasm_trap_handler =
-      base::FeatureList::IsEnabled(features::kWebAssemblyTrapHandler);
   service_manager::Sandbox::Initialize(
       service_manager::SandboxTypeFromCommandLine(
           *base::CommandLine::ForCurrentProcess()),

services/service_manager/sandbox/linux/sandbox_linux.cc

@@ -439,18 +439,12 @@ bool SandboxLinux::LimitAddressSpace(const std::string& process_type,
     if (process_type == switches::kRendererProcess ||
         process_type == switches::kGpuProcess) {
       address_space_limit = 1ULL << 34;
-      if (options.has_wasm_trap_handler) {
-        // WebAssembly memory objects use a large amount of address space when
-        // trap-based bounds checks are enabled. To accomodate this, we allow
-        // the address space limit to adjust dynamically up to a certain limit.
-        // The limit is currently 4TiB, which should allow enough address space
-        // for any reasonable page. See https://crbug.com/750378.
-        address_space_limit_max = 1ULL << 42;
-      } else {
-        // If we are not using trap-based bounds checks, there's no reason to
-        // allow the address space limit to grow.
-        address_space_limit_max = address_space_limit;
-      }
+      // WebAssembly memory objects use a large amount of address space for
+      // guard regions. To accomodate this, we allow the address space limit to
+      // adjust dynamically up to a certain limit. The limit is currently 4TiB,
+      // which should allow enough address space for any reasonable page. See
+      // https://crbug.com/750378.
+      address_space_limit_max = 1ULL << 42;
     }
   }
 

services/service_manager/sandbox/linux/sandbox_seccomp_bpf_linux.h

@@ -26,9 +26,6 @@ class SERVICE_MANAGER_SANDBOX_EXPORT SandboxSeccompBPF {
   struct Options {
     bool use_amd_specific_policies = false;  // For ChromiumOS.
 
-    // Options for Web Assembly.
-    bool has_wasm_trap_handler = false;
-
     // Options for GPU's PreSandboxHook.
     bool accelerated_video_decode_enabled = false;
     bool accelerated_video_encode_enabled = false;