'" The data shows that “frozen” vendor #Linux kernels, created by branching off a release point and then using a team of engineers to select specific patches to back-port to that branch, are buggier than the upstream “stable” Linux #kernel created by Greg Kroah-Hartman. '"
@kernellogger On the other hand, what's the difference between a distro branching off and backporting stuff from mainline and upstream stable branching off and backporting stuff from mainline? Why can the upstream stable maintainers do this and "a team of engineers" cannot? I think the difference could be better characterized and (if you pardon the expression) makes all the difference.
Had a very weird first 24 hours back in Europe until I realized (after noticing this for two different kinds of bottles with screw-off plastic caps) that the plastic caps don't detach anymore from the collar. That's new since last year. EU regulation apparently?
@pervognsen Some of them are really annoying if you want to pour from the bottle if they aren't tight enough because the whole thing will rotate around and you'll effectively pour into the cap and splash everywhere.
@kernellogger@corbet@gregkh In this talk, Jon repeats the line that future LTS stable kernels will only be maintained for 2 years -- is that current or just a remnant of the misconception from last year?
@monsieuricon@kees@kernellogger@corbet@gregkh Thanks for the clarifications -- I guess there is a subtle (but significant) difference between "they're going to drop that back to just two years of support for the long-term stable releases" (literal quote) vs. "we start out at 2 and extend as needed" (paraphrased FAQ + parent toot).
Are these all the special sections that run code on program init/exit? Did I miss any?
.section .preinit_array; .quad fun
.section .init, "ax"; callq fun
.section .init_array; .quad fun
.section .ctors, "aw"; .quad fun
.section .dtors, "aw"; .quad fun
.section .fini_array; .quad fun
.section .fini, "ax"; callq fun
@amonakov 🤔 well, obviously there's _start/main and ld.so itself but I meant more like "things I can link with an existing program/library and have it run without modifying anything else".
@pervognsen So .ctors.* and .dtors.* work, anything else..?
@pervognsen Yeah, I guess YouTube isn't the main place people listen to this kind of thing. I was just looking at the view counts which are in the low Ks for most of them (and with likes in low double digits)
@christian Thanks... this was pointed out by @brenns10 as well, but I think this only happens if your sshd doesn't link with systemd/liblzma? Anyway, yeah, a bit unfortunate, hopefully those that need it will figure it out.
if [ "$path" == "" ]
then
echo probably not vulnerable
exit
fi
check for function signature
if hexdump -ve '1/1 "%.2x"' "$path" | grep -q f30f1efa554889f54c89ce5389fb81e7000000804883ec28488954241848894c2410
then
echo probably vulnerable
else
echo probably not vulnerable
fi
For your Sunday reading: https://arxiv.org/pdf/2402.05212.pdf "An Investigation of Patch Porting Practices of the
Linux Kernel Ecosystem" in which different distros, and Android, are evaluated as to how up to date they stay with upstream fixes. Note that RHEL or CentOS is not evaluated "because of the lack of public git repositories or insufficient data."
About time someone started writing papers about this stuff...
"In addition, we find that CVE is also a focus for distributions (as they are responsible for the security of their customers). In particular, [distro] maintainers usually attach a CVE ID to indicate that the patch fixes a known security vulnerability. Interestingly, we note that the picked CVE patches appear in distributions 74.2 days earlier than LTS on average; even if the picked CVE patches are later than LTS, it is only 16.7 days later on average."
"[…] It is clear that the current process is based on the learnings, and frustrations, the [#Linux#kernel's CVE] team has faced in the past. […] By taking this position, this effort is now duplicated across thousands of engineering teams ad infinitum, […]"
Well, yeah, but guess what: maybe then the companies behind those engineering teams will join up and invest money to handle the problem "[…] at the source, in a central, efficient and reliable manner. […]". 😬
Looking over the list of recent CVEs, most of these are probably local DOS in various obscure drivers. But they do arguably fall within the definition of a vulnerability according to CVE.
@ljs@kernellogger@larsmb@gregkh@pavel If we really need to know the security impact of each and every patch (which most distros probably do), then somebody has to do that analysis. Yes, it's going to be expensive in terms of manpower and effort. But it still needs to be done. That's why I'm hoping this will lead to more distros collaborating on this and the community effectively only doing it once, in one place.
@kernellogger@ljs Two points here: 1) Yes, the bad guys are already doing this (sifting through changelogs and finding exploitable bugs), we should be doing it too, and 2) various companies and distros probably are probably already doing some parts of the work but it's done behind closed doors and we have no good mechanism for exchanging notes or collaborating at the scale necessary, so it ends up as duplicated for no good reason. I really do see an opportunity here for everybody to win