feat(ses): option to fake harden unsafely

[erights]

Adds an option to make harden a do-nothing identity function, specifically for speed of the SwingSet kernel, though it could be used for other highly vetted, style restricted, security-critical, and speed-critical code. This would be safe to turn on in the SwingSet kernel or other such specialized code once we're confident that they are free of the kinds of bugs that a working harden would have protected them from.

Adds a __hardenTaming__ option to lockdown, with values 'safe' (the default) in which harden still works, and 'unsafe', in which harden is a do-nothing identity function.

There are various tests for whether something is frozen, sealed, non-extensible, non-configurable, non-writable, that could all be broken by this fake harden. However, in all cases in our non-test, non-demo code that we are aware of so far, for each such branch, one side of the branch reports an error and only the other side is the happy path. If we're confident we have no bugs that harden would have caught, then we need only ensure we go down the happy paths for such tests.

Object.isFrozen, Object.isSealed, Object.isExtensible, Reflect.isExtensible are patched to claim that everything is frozen, since that is typically the happy path. But not always. For those rare occasions where not being frozen is the happy path, we have added a harden.isFake = true property. When this unsafe option is not turned on, there is no isFake property, so harden.isFake is falsy. This lets code test harden.isFake to ensure it still goes down the happy path. This PR fixes the one case of that we know of in the non-test, non-demo code of the endo repository. To my surprise, there do not seem to be any in the non-test, non-demo code of the agoric-sdk repository.

At this time, we do not patch any of the builtins for reflecting on property attributes, such as Object.getOwnPropertyDescriptor. We will soon see if we need to.

• Found the first. See fix(SwingSet): compat with __hardenTaming__: "unsafe" Agoric/agoric-sdk#7263

---

Reviewers, please review by commit. The second commit, fix: tolerate LOCKDOWN_HARDEN_TAMING=unsafe, is not needed to pass under CI. But it is needed to pass locally if I first set export LOCKDOWN_HARDEN_TAMING=unsafe. The fact that it only modifies test files so that the first commit made all the needed changes to the non-test,non-demo files.

[mhofman]

I am quite surprised tests pass without further mitigations for property descriptors. I would have expected some parts of compartments to complain, but I suppose since lockdown is optional for compartment, maybe not. I suppose some things like optimizers may not behave as expected though.

[erights]

The only thing running with the option set to 'unsafe' is the one tiny new test. Now other test should see any difference.

[gibson042]

These changes are internally consistent, but I'm concerned about the boundary of a trusted environment, e.g. between the SwingSet kernel and a local-worker vat. How much confidence do we have that no such cases exist? Should we expose a way to get a functional harden even when the default one is fake, and if so then how would we know we're using it everywhere we should be?

[erights]

These changes are internally consistent, but I'm concerned about the boundary of a trusted environment, e.g. between the SwingSet kernel and a local-worker vat. How much confidence do we have that no such cases exist? Should we expose a way to get a functional harden even when the default one is fake, and if so then how would we know we're using it everywhere we should be?

@warner Are local-worker vats ever to be used in production?

@gibson042 @warner , I assumed not. If they are, we need to discuss.