PCC: remove proof-carrying code (for now?). (#12800)

In late 2023, we built out an experimental feature called
Proof-Carrying Code (PCC), where we attached "facts" to values in the
CLIF IR and built

PCC: remove proof-carrying code (for now?). (#12800)

In late 2023, we built out an experimental feature called
Proof-Carrying Code (PCC), where we attached "facts" to values in the
CLIF IR and built verification of these facts after lowering to
machine instructions. We also added "memory types" describing layout
of memory and a "checked" flag on memory operations such that we could
verify that any checked memory operation accessed valid memory (as
defined by memory types attached to pointer values via
facts). Wasmtime's Cranelift backend then put appropriate memory types
and facts in its IR such that all accesses to memory (aspirationally)
could be checked, taking the whole mid-end and lowering backend of
Cranelift out of the trusted core that enforces SFI.

This basically worked, at the time, for static memories; but never for
dynamic memories, and then work on the feature lost
prioritization (aka I had to work on other things) and I wasn't able
to complete it and put it in fuzzing/enable it as a production option.

Unfortunately since then it has bit-rotted significantly -- as we add
new backend optimizations and instruction lowerings we haven't kept
the PCC framework up to date.

Inspired by the discussion in #12497 I think it's time to delete
it (hopefully just "for now"?) unless/until we can build it again. And
when we do that, we should probably get it to the point of validating
robust operation on all combinations of memory configurations before
merging. (That implies a big experiment branch rather than a bunch of
eager PRs in-tree, but so it goes.) I still believe it is possible to
build this (and I have ideas on how to do it!) but not right now.

show more ...

Cranelift: preserve_all: disallow return values. (#12447)

In #12399 a fuzzbug uncovered an issue whereby a function with
`preserve_all` and with many return values cannot be called, because
`emit_re

Cranelift: preserve_all: disallow return values. (#12447)

In #12399 a fuzzbug uncovered an issue whereby a function with
`preserve_all` and with many return values cannot be called, because
`emit_retval_loads` cannot codegen memory-to-memory moves (from on-stack
return value slots directly to spillslots) without a
temporary/clobberable register, and `preserve_all` implies no such
registers exist.

I thought about trying to support this by shuffling registers -- such a
case implies many return values, and at least some of them will be in
registers, so we might be able to temporarily spill one of those and use
it as a scratch to move other values memory-to-memory. But the
complexity doesn't seem worthwhile, and this path is not actually needed
at the moment.

Thinking more broadly, anyone using `preserve_all` for hooks meant to
minimally perturb register state will likely not want to use many return
values anyway (that defeats the point). We could allow *one* return
value, with the knowledge that this always fits in a register in our
existing ABIs, but that also feels somewhat arbitrary, and I could make
the argument that "preserve all" should really mean preserve *all*.
Someone wanting to return a value anyway from such a hook could use
indirect means (pass in a pointer to a stackslot, for example). I'm
happy to tweak this limit if others have more thoughts, however.

Fixes #12399.

show more ...