github/cranelift - cranelift - Gitea: Git with home nas server

Author	SHA1	Message	Date
Alex Crichton	6bcee7f5f7	Add a configuration option to force "static" memories (#3503 ) * Add a configuration option to force "static" memories In poking around at some things earlier today I realized that one configuration option for memories we haven't exposed from embeddings like the CLI is to forcibly limit the size of memory growth and force using a static memory style. This means that the CLI, for example, can't limit memory growth by default and memories are only limited in size by what the OS can give and the wasm's own memory type. This configuration option means that the CLI can artificially limit the size of wasm linear memories. Additionally another motivation for this is for testing out various codegen ramifications of static/dynamic memories. This is the only way to force a static memory, by default, for wasm64 memories with no maximum size listed for example. * Review feedback	3 years ago
Pat Hickey	18a355e092	give sychronous ResourceLimiter an async alternative	3 years ago
Alex Crichton	e8d3b8e3ea	Fix an off-by-two condition in heap legalization (#3462 ) This commit fixes an issue in Cranelift where legalization of `heap_addr` instructions (used by wasm to represent heap accesses) could be off-by-two where loads that should be valid were actually treated as invalid. The bug here happened in an optimization where tests against odd constants were being altered to tests against even constants by subtracting one from the limit instead of adding one to the limit. The comment around this area has been updated in accordance with a little more math-stuff as well to help future readers.	3 years ago
Alex Crichton	bd47a74dab	Always call the resource limiter for memory allocations (#3189 ) * Always call the resource limiter for memory allocations Previously the memory64 support meant that sometimes we wouldn't call the limiter because the calculation for the minimum size requested would overflow. Instead Wasmtime now wraps the minimum size in something a bit smaller than the address space to inform the limiter, which should guarantee that although the limiter is called with "incorrect" information it's effectively correct and is allowed a pass to learn that a massive memory was requested. This was found by the fuzzers where a request for the absolute maximal size of 64-bit memory (e.g. the entire 64-bit address space) didn't actually invoke the limiter which means that we mis-classified an instantiation error and didn't realize that it was an OOM. * Add a test	3 years ago
Alex Crichton	e68aa99588	Implement the memory64 proposal in Wasmtime (#3153 ) * Implement the memory64 proposal in Wasmtime This commit implements the WebAssembly [memory64 proposal][proposal] in both Wasmtime and Cranelift. In terms of work done Cranelift ended up needing very little work here since most of it was already prepared for 64-bit memories at one point or another. Most of the work in Wasmtime is largely refactoring, changing a bunch of `u32` values to something else. A number of internal and public interfaces are changing as a result of this commit, for example: * Acessors on `wasmtime::Memory` that work with pages now all return `u64` unconditionally rather than `u32`. This makes it possible to accommodate 64-bit memories with this API, but we may also want to consider `usize` here at some point since the host can't grow past `usize`-limited pages anyway. * The `wasmtime::Limits` structure is removed in favor of minimum/maximum methods on table/memory types. * Many libcall intrinsics called by jit code now unconditionally take `u64` arguments instead of `u32`. Return values are `usize`, however, since the return value, if successful, is always bounded by host memory while arguments can come from any guest. * The `heap_addr` clif instruction now takes a 64-bit offset argument instead of a 32-bit one. It turns out that the legalization of `heap_addr` already worked with 64-bit offsets, so this change was fairly trivial to make. * The runtime implementation of mmap-based linear memories has changed to largely work in `usize` quantities in its API and in bytes instead of pages. This simplifies various aspects and reflects that mmap-memories are always bound by `usize` since that's what the host is using to address things, and additionally most calculations care about bytes rather than pages except for the very edge where we're going to/from wasm. Overall I've tried to minimize the amount of `as` casts as possible, using checked `try_from` and checked arithemtic with either error handling or explicit `unwrap()` calls to tell us about bugs in the future. Most locations have relatively obvious things to do with various implications on various hosts, and I think they should all be roughly of the right shape but time will tell. I mostly relied on the compiler complaining that various types weren't aligned to figure out type-casting, and I manually audited some of the more obvious locations. I suspect we have a number of hidden locations that will panic on 32-bit hosts if 64-bit modules try to run there, but otherwise I think we should be generally ok (famous last words). In any case I wouldn't want to enable this by default naturally until we've fuzzed it for some time. In terms of the actual underlying implementation, no one should expect memory64 to be all that fast. Right now it's implemented with "dynamic" heaps which have a few consequences: * All memory accesses are bounds-checked. I'm not sure how aggressively Cranelift tries to optimize out bounds checks, but I suspect not a ton since we haven't stressed this much historically. * Heaps are always precisely sized. This means that every call to `memory.grow` will incur a `memcpy` of memory from the old heap to the new. We probably want to at least look into `mremap` on Linux and otherwise try to implement schemes where dynamic heaps have some reserved pages to grow into to help amortize the cost of `memory.grow`. The memory64 spec test suite is scheduled to now run on CI, but as with all the other spec test suites it's really not all that comprehensive. I've tried adding more tests for basic things as I've had to implement guards for them, but I wouldn't really consider the testing adequate from just this PR itself. I did try to take care in one test to actually allocate a 4gb+ heap and then avoid running that in the pooling allocator or in emulation because otherwise that may fail or take excessively long. [proposal]: https://github.com/WebAssembly/memory64/blob/master/proposals/memory64/Overview.md * Fix some tests * More test fixes * Fix wasmtime tests * Fix doctests * Revert to 32-bit immediate offsets in `heap_addr` This commit updates the generation of addresses in wasm code to always use 32-bit offsets for `heap_addr`, and if the calculated offset is bigger than 32-bits we emit a manual add with an overflow check. * Disable memory64 for spectest fuzzing * Fix wrong offset being added to heap addr * More comments! * Clarify bytes/pages	3 years ago
Ulrich Weigand	acdb388580	Fix offsets_static_dynamic_oh_my failure on s390x (#3015 ) The test unconditionally emits a SIMD load, which fails on s390x as we do not yet support SIMD. Disable this particular part of the test on s390x.	3 years ago
Alex Crichton	7ce46043dc	Add guard pages to the front of linear memories (#2977 ) * Add guard pages to the front of linear memories This commit implements a safety feature for Wasmtime to place guard pages before the allocation of all linear memories. Guard pages placed after linear memories are typically present for performance (at least) because it can help elide bounds checks. Guard pages before a linear memory, however, are never strictly needed for performance or features. The intention of a preceding guard page is to help insulate against bugs in Cranelift or other code generators, such as CVE-2021-32629. This commit adds a `Config::guard_before_linear_memory` configuration option, defaulting to `true`, which indicates whether guard pages should be present both before linear memories as well as afterwards. Guard regions continue to be controlled by `{static,dynamic}_memory_guard_size` methods. The implementation here affects both on-demand allocated memories as well as the pooling allocator for memories. For on-demand memories this adjusts the size of the allocation as well as adjusts the calculations for the base pointer of the wasm memory. For the pooling allocator this will place a singular extra guard region at the very start of the allocation for memories. Since linear memories in the pooling allocator are contiguous every memory already had a preceding guard region in memory, it was just the previous memory's guard region afterwards. Only the first memory needed this extra guard. I've attempted to write some tests to help test all this, but this is all somewhat tricky to test because the settings are pretty far away from the actual behavior. I think, though, that the tests added here should help cover various use cases and help us have confidence in tweaking the various `Config` settings beyond their defaults. Note that this also contains a semantic change where `InstanceLimits::memory_reservation_size` has been removed. Instead this field is now inferred from the `static_memory_maximum_size` and guard size settings. This should hopefully remove some duplication in these settings, canonicalizing on the guard-size/static-size settings as the way to control memory sizes and virtual reservations. * Update config docs * Fix a typo * Fix benchmark * Fix wasmtime-runtime tests * Fix some more tests * Try to fix uffd failing test * Review items * Tweak 32-bit defaults Makes the pooling allocator a bit more reasonable by default on 32-bit with these settings.	3 years ago