Skip to main content

Now freely available: A # text covering a @LinuxSecSummit 2021 talk about "some research that dug further into [# #] bugs that # has found; the results are rather worrisome […] more serious problems lurking […]":…

[bookmark=]Fantastic, detailed, and sobering examination of data-only attacks. I wrote up some responses here:…
(now with the correct link! 🤦)[/bookmark]

# with its "generic # image" (GKI) is moving closer to upstream # in #. It restricts what vendors can do, but allows them to use add-on modules – which creates a new problem, described in this now freely available # article:…

[bookmark=]Fantastic, detailed, and sobering examination of data-only attacks. I wrote up some responses here:…[/bookmark]

[bookmark=]What # instruction set extensions exist, what kernel/LLVM versions they require, and why do they matter. My latest blog post is out! [/bookmark]

[bookmark=]Article released about the details of fs-verity support coming to btrfs, Boris spent a good bit of time on this and there's still some work left to be done on the userspace side, hoping to get it deployed into production soon! [/bookmark]

[bookmark=]Always good to see others hitting the same numbers, haters gonna hate.
I think we're where we want to be in terms of peak, next round of work will be (again) diminishing the impact of things like blk-cgroup, and other block/kernel options that have an adverse performance impact.[/bookmark]

[bookmark=]Since I'm on my b4 kick, figured I'd clean up and publish an internal note I wrote about patch review that I wrote to help some of our new-to-kernel-development engineers [/bookmark]

[bookmark=]new blogpost:
"How a simple Linux kernel memory corruption bug can lead to complete system compromise: An analysis of current and potential kernel security mitigations"
I'll post a copy to the kernel-hardening list later in case folks want to discuss it. [/bookmark]

[bookmark=]The most entertaining part is 4 descriptions of real CPU bugs found in real x86 CPUs in the Appendix.[/bookmark]

[bookmark=]@josefbacik Github is a proprietary platform -- a significant part of kernel developers have deep-rooted (and not unfounded) objections to that.[/bookmark]

[bookmark=]Wrote a blog post about setting up lei and using b4 to ultimately unsubscribe from all the linux kernel mailinglists, in case anybody is curious about getting the workflow set up [/bookmark]

# kernel 5.15-rc6 is out, a few hours later than usual due to travel:…

"[…] I'd love to say that it's all looking average, but rc6 is actually bigger han rc5 was, and larger than normal for this time in the release cycle. […] slightly worrisome[…]"

Just rechecked the calendar if it really Monday or if I was off-by-one.

Because on Monday mornings I normally find a new # # -rc announcement in my inbox, unless we are in the merge window.

But today Linus didn't release one. Must be a glitch in the matrix.

[bookmark=]This is my favorite kernel conference. Please consider both sponsoring and attending![/bookmark]

"[…] new project […] replacement for #'s --netdev user […], a feature that is commonly used but not really considered production-ready. What # improves on is security and performance, finally making usermode networking production-ready […]"…

[bookmark=]NVIDIA Beta 495.29.05 rolls out with GBM for expanded Wayland support…


[bookmark=]And it's here: Sysmon for Linux! [/bookmark]

TL;DR for Memory-Model recommendations for using # in the # # – @paulmckrcu of RCU fame published this yesterday and outlines some recommendation for the short-term and some for the long-term: