PCC: remove proof-carrying code (for now?).#12800
Open
cfallin wants to merge 1 commit intobytecodealliance:mainfrom
Open
PCC: remove proof-carrying code (for now?).#12800cfallin wants to merge 1 commit intobytecodealliance:mainfrom
cfallin wants to merge 1 commit intobytecodealliance:mainfrom
Conversation
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 bytecodealliance#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.
github-actions
bot
added
cranelift
Subscribe to Label ActionDetailsThis issue or pull request has been labeled: "cranelift", "cranelift:area:aarch64", "cranelift:area:machinst", "cranelift:area:x64", "cranelift:meta", "isle"Thus the following users have been cc'd because of the following labels:
To subscribe or unsubscribe from this label, edit the |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
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.