Cranelift: x64, aarch64, s390x, riscv64: ensure addresses are I64s. (#5972)
* Cranelift: x64, aarch64, s390x, riscv64: ensure addresses are I64s. @avanhatt has been looking at our address-mode lowering and found an example where when feeding an `I32`-typed address into a load or store, we can violate assumptions and get incorrect codegen. This should never be reachable in practice, because all producers on 64-bit architectures use 64-bit types for addresses. However, our IR is insufficiently constrained, and allows loads/stores to `I32` addresses as well. This is nonsensical on a 64-bit architecture. Initially I had thought we should tighten either the instruction definition's accepted types, or the CLIF verifier, to reject this. However both are target-independent, and we don't want to bake an assumption of 64-bit-ness into the compiler core. Instead this PR tightens specific backends' lowerings to rejecct loads/stores of `I32`-typed addresses. tl;dr: no security implications as all producers use I64-typed addresses (and must, for correct operation); but we currently accept I32-typed addresses too, and this breaks other assumptions. * Allow R64 as well as I64 types. * Add an explicit extractor to match 64-bit address types.
This commit is contained in:
@@ -347,6 +347,10 @@
|
||||
(decl ty_vec128_int (Type) Type)
|
||||
(extern extractor ty_vec128_int ty_vec128_int)
|
||||
|
||||
;; An extractor that only matches types that can be a 64-bit address.
|
||||
(decl ty_addr64 (Type) Type)
|
||||
(extern extractor ty_addr64 ty_addr64)
|
||||
|
||||
;; A pure constructor that matches everything except vectors with size 32X2.
|
||||
(decl pure partial not_vec32x2 (Type) Type)
|
||||
(extern constructor not_vec32x2 not_vec32x2)
|
||||
|
||||
Reference in New Issue
Block a user