Kernel environments: use any and all provided environments, evict hintmode and envmode

[kevans]

Summary

(This one I'll actually let sit for a longer period of time)

At the moment, hintmode and envmode are used to indicate whether static hints or static env have been provided in the kernel config(5) and the static versions are mutually exclusive with loader(8)-provided environment. hintmode *can* be reconfigured later to pull from the dynamic environment, thus taking advantage of the loader(8) or post-kmem environment setting.

This changeset fixes both problems at once to move us from a semi-confusing state to a consistent state: if an environment file, hints file, or loader(8) environment are provided, we use them in a well-known order of precedence:

• loader(8) environment
• static environment
• static hints file

Once the dynamic environment is setup this becomes a moot point. The loader(8) and static environments are merged (respecting the above order of precedence), and the static hints are merged in on an as-needed basis after the dynamic environment has been setup.

Hints lookup are changed to respect all of the above. Before the dynamic environment is setup, lookups use the above-mentioned order and fallback to the next environment if a matching hint is not found. Once the dynamic environment is setup, that is used on its own since it captures all of the above information plus any dynamic kenv settings that came up later in boot.

The following tangentially related changes were made to res_find:

• A hintp cookie is now passed in so that related searches continue using the chain of environments (or dynamic environment) without relying on global state
• All three environments will be searched if they actually have valid hints to use, rather than just choosing the first environment that actually had a hint and rolling with that only

The hintmode sysctl has been ripped out.

[kevans]

Add back in the ability to specify static_env.disabled and static_hints.disabled. The reimplementation of these follows suit with how we treat environments in the new age- static_hints.disabled may be specified in either static_env or loader(8) env, and static_env.disabled may only be specified in loader(8) env.

[kevans]

I intend to commit this by the end of next week (July 6-8 time frame) without any strong objections, given the lack of any outcry from my e-mail to -arch/-embedded.

[brooks]

I don't see anything that's going to cause us obvious problems on BERI.

sys/kern/kern_environment.c

319 ↗

(On Diff #44284)

Shouldn't there be a realloc if prevlen < len - 1?

[kevans]

Add realloc missed in previous revision

[kevans]

sys/kern/kern_environment.c

319 ↗

(On Diff #44284)

Whoops, indeed. =) Expanded my local test setup for that, and added a check for kenvp[pos] == NULL since nothing here seemed to previously care if the allocation actually failed.

[kevans]

*sigh*

Avoid reallocation if we're looking at a same-size replacement.

[brooks]

sys/kern/kern_environment.c

335 ↗

(On Diff #44437)

Since you're using M_WAITOK this could probably be a panic.

[imp]

Looks OK to me.

sys/kern/kern_environment.c

335 ↗

(On Diff #44437)

At most this is a kassert, no?
We cant fail the alloc above.

[kevans]

sys/kern/kern_environment.c

335 ↗

(On Diff #44437)

Right, I seem to have mixed up my flags internally... I'll remove this before commit (since it's otherwise harmless) unless further changes are required here.

[kevans]

Some relatively minor issues:

• The logic for static_env.disabled was backwards
• Initializing the dynamic env now uses the first value for a variable that it finds, and any later assignments of the same value are ignored. This is to match how searching the static environment in the kernel works so that we get consistent results between the static environment and the dynamic environment. config(8) should setup the static environment for us in such a way that a later assignment to a variable overrides an earlier assignment.
• In rS273487. @cperciva started zero'ing out the static environment as it filled the dynamic environment to avoid leaking data from the kernel environment. I've extended this cleaning to zero out even the skipped entries to eradicate all traces of the static environment once we've provisioned the dynamic one.