-
Notifications
You must be signed in to change notification settings - Fork 71
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat(pass-style,marshal): ByteArray, a binary Passable #2414
Draft
erights
wants to merge
1
commit into
master
Choose a base branch
from
markm-binary-direct
base: master
Could not load branches
Branch not found: {{ refName }}
Loading
Could not load tags
Nothing to show
Loading
Are you sure you want to change the base?
Some commits from the old base branch may be removed from the timeline,
and old review comments may become outdated.
Conversation
This file contains 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
erights
force-pushed
the
markm-binary-direct
branch
from
August 16, 2024 22:21
eed07e2
to
1df60e9
Compare
erights
force-pushed
the
markm-binary-direct
branch
from
August 19, 2024 22:47
835d70e
to
74007b3
Compare
erights
changed the base branch from
master
to
markm-repair-arraybuffer-transfer
August 19, 2024 22:48
erights
force-pushed
the
markm-repair-arraybuffer-transfer
branch
from
August 22, 2024 01:08
4dd9bf8
to
d19e509
Compare
erights
force-pushed
the
markm-binary-direct
branch
from
August 22, 2024 01:09
74007b3
to
6af60d7
Compare
erights
force-pushed
the
markm-repair-arraybuffer-transfer
branch
from
August 26, 2024 20:48
d19e509
to
585042f
Compare
erights
force-pushed
the
markm-binary-direct
branch
from
August 26, 2024 20:49
6af60d7
to
affa6b3
Compare
Converting to draft until more of the stubbed out cases are implemented, and until more of both are tested. |
erights
force-pushed
the
markm-repair-arraybuffer-transfer
branch
3 times, most recently
from
September 2, 2024 21:30
8dce401
to
06e15fe
Compare
erights
force-pushed
the
markm-binary-direct
branch
2 times, most recently
from
September 4, 2024 00:11
53ec91b
to
ce0fd14
Compare
erights
added a commit
that referenced
this pull request
Sep 4, 2024
Staged on #2419 Closes: #XXXX Refs: #2414 #2418 #2419 ## Description #2414 by itself does not work on Node 18 and Node 20 because - those platforms do not have `Array.prototype.transfer`, so #2414 must use `structuredClone` instead - `structuredClone` does exist on Node >= 18, so it should be on supported platforms (though see #2418 ). However, `structuredClone` itself is dangerous and so must not be added to the shared intrinsics. As a result, in #2414 , when `@endo/pass-style` is initialized in a created compartment, it fails to find either `Array.prototype.transfer` and `structuredClone To solve this, @kriskowal suggested that we also shim `Array.prototype.transfer` if needed during `lockdown`, along with other repairs. We are avoiding similarly shimming `Array.prototype.transferToImmutable` because it is not yet standard. But `Array.prototype.transfer` is standard, and so `lockdown` can globally shim it before hardening the shared intrinsics. This PR implements @kriskowal 's suggestion. ### Security Considerations none ### Scaling Considerations by itself, none ### Documentation Considerations nothing signicant. ### Testing Considerations See #2418 . Aside from that, none ### Compatibility and Upgrade Considerations On platforms with neither `Array.prototype.transfer` nor a global `structuredClone`, the ses-shim will *currently* not install an emulation of `Array.prototype.transfer`. However, once we verify that endo is not intended to support platforms without both, we may change lockdown to throw, failing to lock down.
erights
force-pushed
the
markm-binary-direct
branch
from
September 7, 2024 20:42
ce0fd14
to
066637e
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Staged on #2414
Closes: #1331
Refs: #1538 ocapn/ocapn#5 (comment)
Description
Use the
@endo/immutable-arraybuffer
ponyfill directly, rather than the shim@endo/immutable-arraybuffer/shim.js
, to provide objects that act like the immutable ArrayBuffers that would result from thetransferToImmutable
proposal.Recognize these objects, when also frozen, as the new pass-style
byteArray
. Add a branch for each of the dispatches on pass-style that must now understand byte-arrays as well. As of this PR, many of those additional branches are stubbed out with "not yet implemented" errors as placeholders.Security Considerations
Does correctly enforce immutability. But by depending only on the ponyfill rather than the shim, this PR inherits the eval twin problem of the ponyfill. Each instantiation of
passStyleOf
will only recognize the byte-arrays from the instantiation of@endo/pass-style
that made that byte-array. For environment that, for example, use thepassStyleOf
endowed to them by liveslots, liveslots will also need to endow them with the corresponding byte-array maker.In theory, this is not much worse than the need to co-endow
passStyleOf
andProxy
, so thatpassStyleOf
can reject apparent copy structures that are also proxies.Scaling Considerations
The underlying ponyfill implementation helps us handle bulk binary data in a largely no-copy or minimal-copy manner.
Documentation Considerations
Will add a new pass-style, so everywhere we enumerate all the pass-styles, we'll need to add byte-array.
Testing Considerations
test.failing
test.Compatibility Considerations
Old code that dispatched only on the pass-styles it knew about will not correctly handle passables that contain byte-arrays.
Upgrade Considerations