expose enable/disable metering to xsnap start compartment and liveslots #3457
Assignees
Labels
Milestone
Comments
warner
added
enhancement
|
roger wilco |
dckc
added a commit
that referenced
this issue
Jul 15, 2021
API:
```js
const noLimit = 0;
const limit = currentMeterLimit();
const before = resetMeter(noLimit, 0);
try {
// unmetered work...
} finally {
resetMeter(limit, before);
}
```
fixes #3457
dckc
added a commit
that referenced
this issue
Jul 15, 2021
API:
```js
const noLimit = 0;
const limit = currentMeterLimit();
const before = resetMeter(noLimit, 0);
try {
// unmetered work...
} finally {
resetMeter(limit, before);
}
```
fixes #3457
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
What is the Problem Being Solved?
We kind of want validators to be able to perform GC at arbitrary times, partially because of #3428, in which the "organic" GC schedule changes when a heap snapshot is reloaded because the new XS engine does not pre-allocate all the extra space that was left over in the pre-snapshot heap.
To support variance in GC activity while still maintaining stable metering results, we want to exclude the GC-sensitive code paths from metering. So we're looking for a way to build an unmetered "box". We disable metering when we enter the box, and we re-enable it when we exit the box. The number of times we enter the box is part of consensus, but the liveslots activity while we're inside the box is not (specifically the amount of code executed is allowed to vary from one validator to another). Liveslots may invoke syscalls while inside the box, but it will not resolve promises.
It's an open question as to what should happen if a runaway infinite loop occurs while inside the box. It might be appropriate to terminate the
xsnapworker process (which would kill the kernel, since #3237 says unexplained worker errors should bail). It might be ok to signal an error that consensus-terminates the vat, but I'm wary, because we don't actually know what happened and whether it might match what's happening on other validators (and of course we can't actually detect infinite loops, we can merely run out of patience at some arbitrary time).This suggests that, at least for now, meter underflows while inside the box should be ignored.
A different ticket will track the SwingSet/LiveSlots uses of the box.
Description of the Design
The basic approach is going to be a pair of C "callbacks", defined in
xsnap.c, and exposed as globals to the start compartment (sosupervisor.jscan share them with liveslots). The definition of this "enter"/"exit" pair depends upon how XS enables/disables metering,One option is for the "enter" call to return the current meter value, and replace it with some very large number. The "exit" call would then accept the original value and replace the current value.
Another is for "enter" to disable metering but leave the current meter value alone. "Exit" then just reenables it.
Security Considerations
These globals must only be on the start compartment. SES will strip them (as it does for all unrecognized globals, like
gc), so 1: userspace won't see them, and 2: the liveslots compartment won't either, sosupervisor.jsmust deliberately pass them through. We'll need to augment thegcToolsrecord to include something likeenterGCBoxor similar.If userspace could reach these functions, it could bypass the metering limits.
Test Plan
xsnap unit tests should perform two runs, both with a box enter/exit pair in the middle. One run should do no work inside the box, the other should do a moderate amount of work inside the box. The test should assert that both runs result in the same
computemeter consumption.Unit tests should also create a Compartment and assert that these functions are not available on the compartment's global.
The text was updated successfully, but these errors were encountered: