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 _______________________________________________ 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
