On Wed, Jan 15, 2025 at 07:46:00PM +0000, Lorenzo Stoakes wrote: > You are now suggesting disabling the !CRIU requirement. Which violates my > _requirements_ (not optional features). Why not make this simply incremental? The feature isn't intended to work with CRIU. Why don't we get the feature in first, with a !CRUI depends? This lets the users of this feature actually use it. > You seem to be saying you're pushing an internal feature on upstream and > only care about internal use cases, this is not how upstream works, as > Matthew alludes to. Internal? No. Chrome OS and Android. Linux runs more Android devices than everything else in the world combined -- this is not some random experiment. I really don't like the feature creep nature of the system mapping sealing reviews. There's nothing special here -- we have plenty of features that conflict with other features. And we have a long history in the kernel of landing the core changes with lots of conflict depends that we then resolve as we move forward. Why not just make system map sealing conflict with CRIU? Who is asking to use both at the same time? > I have told you that my requirements are: > > 1. You cannot allow a user to set config or boot options to have a > broken kernel configuration. What do you define as a "broken kernel configuration"? > 2. You must provide evidence that the arches you claim work with this, > actually do. What evidence would you find sufficient? I'm concerned this is turning into a rock fetching quest. -Kees -- Kees Cook
