bootstrap: run preload prior to --frozen-intrinsics

[bmeck]

This is used to allow people to run polyfills.

Checklist

• make -j4 test (UNIX), or vcbuild test (Windows) passes
• tests and/or benchmarks are included
• documentation is changed or added
• commit message follows commit guidelines

[guybedford]

Credit to @ljharb for suggesting this :)

[nodejs-github-bot]

CI: https://ci.nodejs.org/job/node-test-pull-request/24826/

[ljharb]

One quick nonblocker question - how might i feature detect that a) this flag was invoked, whether via NODE_OPTIONS or a cli flag), as well as b) that this PR’s change was available, from runtime JS?

[bmeck]

@ljharb you can't detect if you are in a preload reliably to my knowledge, but you can detect the flag via process.execArgv (assuming something hasn't hidden that flag ahead of your check). You cannot test the ordering change here via runtime ops and I would be opposed to adding a way to check that since we do reorder things for experimental stuff all the time.

[nodejs-github-bot]

CI: https://ci.nodejs.org/job/node-test-pull-request/24830/

[ljharb]

@bmeck process.execArgv won't contain the flag if it's set via NODE_OPTIONS, tho, i believe?

I'm not asking to test the ordering, more asking "how can i determine if my module that requires --require and --frozen-intrinsics is being used on a compatible version of node, so that I can give a helpful error message"

[joyeecheung]

What would one do if they need to preload modules for purposes other than polyfilling but do not want the preloaded modules (or the modules they depend on) mess with the intrinsics?

[bmeck]

@ljharb I suspect the use case you are talking about is having polyfills that have assurances that intrinsics may not be modified by other preloads so they can use intrinsics directly instead of saving cached copies.

@joyeecheung I suspect the use case you are talking about is replacing things like fs.readFile.

The answer to both is that it is not possible to have both mutable shared state and assurances about the integrity of that shared state. In general preloads are of conflicting interests in this timing and always have been the case regarding these 2 use cases.

Only preloads that do not harm the integrity of the runtime (by mutating core, or improperly polyfilling) should be loaded in general. To this end, preload modules should probably be whitelisted when using policies, but that is out of scope of this PR. Users of these could always freeze things themselves if they want to ensure other preloads cannot touch them, but that would prevent preloads from composing or patching improper behavior of other preloads.

Additionally, as core is hardened over time (using primordials and the like) it is likely to gain a similar flag to --frozen-intrinsics and mutating core modules can probably be seen as increasingly similar in nature.

[joyeecheung]

@bmeck Can't we make the timing configurable? e.g. adding values to --frozen-intrinsics to control that.

[bmeck]

@Joyee we could add my more times, but the problem would remain in the mutable timeframe so I don't think it actually does much / feel a different approach would be better (though I don't have a suggestion)

[devsnek]

would --require=x --frozen-intrinsics --require=y, where the ordering is preserved, be too contrived of a solution?

[bmeck]

@devsnek what is the use case, --require does stuff before user code and is generally mucking around mutating globals and the runtime. I'd expect it to be privileged since side effects are the main purpose of them.

[devsnek]

@bmeck, I was just replying to the above question about configurable timing.

[bmeck]

I think a separate PR adding an API that freezes intrinsics (noop after first freeze) would be fine for people not wishing to use the flag; but that has different implications than a well defined timing and ability to audit/grant policy configuration for what runs prior to the freeze. Perhaps exposing that API could be a separate PR if people want to control timing manually?

[sam-github]

I don't have strong feelings on this, I just notice that an API would satisfy all timings.

// freeze.js
blah.freeze() // name TBD

satisfies:

node --require polyfill.js --require freeze.js --require not-allowed-to-polfill.js app.js

and with node app.js:

// app.js
require("polyfill")
blah.freeze() // name TBD
require("not-allowed-to-polyfill")
// ...

or any other time. I tend towards exposing mechanism, and leaving policy to users.

[bmeck]

@sam-github while it has similar effects it does not have the same overall impact on policy configuration. Exposing via API requires programmer vigilance on understanding when it may be called rather than providing a clear timing. freeze.js may not even freeze things if polyfill.js is corrupted somehow and virtualized the freeze() API. I'm not clear on what we gain by leaving it up to users to understand how to protect freeze() and audit when freeze() could occur and. It seems like for education, configuration, and audit purposes having a well defined contract would be preferred.

[Trott]

Any reason to wait on landing this? @bmeck @joyeecheung

[joyeecheung]

@Trott My previous comments are non-blocking.

[bmeck]

@Trott seems like it is fine to land as nothing seems blocking.

[bmeck]

Landed in 85898e0