But that was due to performance problems in hot paths. Nothing of thisIt applies because a new API that individual driver authors is being
applies here.
proposed and that's an ongoing maintenance burden that might be
mitigated by hiding that implementation detail from leaf drivers.
Right now there is no leaf driver changed at all.For me it both seems very straight forward and simple (but then I'm biased)You seem to be having a difficult time iterating this proposal toward
consensus. I don't think the base principles are being contested as
much as the semantics, scope, and need for the proposed API that is in
the purview of all leaf driver developers.
What is the intersection of ioremap() users that are outside of theI'd rather see more concerted efforts focused/limited core changesA hardened driver is a driver that
rather than leaf driver changes until there is a clearer definition of
hardened.
- Had similar security (not API) oriented review of its IO operations
(mainly MMIO access, but also PCI config space) as a non privileged user
interface (like a ioctl). That review should be focused on memory safety.
- Had some fuzzing on these IO interfaces using to be released tools.
proposed probe authorization regime AND want confidential computing
support?
are needed
I am not proposing making the early undebuggable.But how do you debug the kernel then? Making early undebuggable seemsfor booting. For example in TDX we can't print something to the consoleRight, as I suggested [1], just enough early authorization to
with this mechanism, so you would never get any output before the
initrd. Just seems like a nightmare for debugging anything. There really
needs to be an authorization mechanism that works reasonably early.
I can see a point of having user space overrides though, but we need to
have a sane kernel default that works early.
bootstrap/debug initramfs and then that can authorize the remainder.
just bad policy to me.