On Fri, Nov 13, 2020 at 11:33:21AM +0100, Jiri Benc wrote: > On Fri, 13 Nov 2020 10:50:53 +0100, Sergio Lopez wrote: > > Let me clear here, there's absolutely no intention of keeping things > > downstream, but there may be changes that won't be accepted upstream > > because they only make sense for this particular use case. > > If they are not accepted upstream, it's for a reason and you need to > address the reason. I very much doubt the reason for non-acceptance > would be "we don't care about your use case". It may be "please make it > more generic, so others will profit from it, too". Or "please do all of > this differently". Which you should do instead of keeping your own > patches. > > There's no such thing as "we're special, thus we need own kernel > patches". You're not special and you don't need them. Even Android > finally got it. > > > We're not "playing a catch up game". Porting the changes to 5.10 [1] > > took less than one hour, because the changes are small and reasonably > > isolated (it'll be even more isolated once we reimplement the > > Transparent Socket Impersonation part as an independent address > > family). > > "Transparent Socket Impersonation"? Oh. I don't see any such patches on > the netdev mailing list. You'll have to start there, as it's very > well possible you'll have some redesign to do. It's hard to get a > kernel network feature right on the first attempt, the network stack is > very focused on performance and maintainability. > > For your next project, I suggest to start working with upstream > communities from the very beginning. Developing whole infrastructure > behind closed doors and then throwing the result at the communities is > not a viable approach. Many have tried that before you, only to find out > that upstreaming such solution takes more time than it took to develop > it, rewriting pretty much everything along the way. > > My advice to you is instead of "reimplement[ing] the Transparent Socket > Impersonation part as an independent address family", reach out to > netdev right away. Explain what you're trying to do and add a pointer > to the current patches you have (or send them out as RFC directly if > they're reasonably small). It will save you tons of time in the end. > > > As I wrote in the original email, in addition of the downstream > > patches, the kernel is bundled in a different binary format so it can > > be directly injected into a KVM memory region. > > That's something that you'll need to first solve upstream in the kernel > and KVM communities. > > > Security issues in the bundled kernel can't have an impact on the host > > and it's _very_ unlikely the would have it on isolated application, as > > is operating within the security boundary of the VMM/VM, and the > > latter under the security context of the original application (in > > fact, a stricter context with a better seccomp profile). > > I don't think that downplaying security issues is a good approach. > > Jiri > Thanks for all the (unsolicited) advice. Deeply appreciated. If possible, I would like to go back to my original question, so we can both go back to more fruitful matters. Is it acceptable to package non-bootable kernels in Fedora? Thanks, Sergio.
_______________________________________________ kernel mailing list -- kernel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to kernel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@xxxxxxxxxxxxxxxxxxxxxxx
