matthewruffell
commented
6 years ago Okay, I spent all weekend getting dapper-secure-kernel-patchset-stable from 4.9.80 to 4.9.92. It was quite a lot of effort, as it seems minor patches are growing in size rapidly these days.
You can get my latest release from here
There's a few compile errors in the 4.9.8x series since I forward ported without compiling to save the 2 or so hours needed to compile the kernel, and I have resolved these in 4.9.91 as I went and compiled 4.9.90 and 4.9.91. I haven't tested 4.9.92, but the patch was small, so I think it will be okay.
My current plan is to catch up to the latest release (4.9.103+) and then complete the gcc8 port, since some of the 4.9.10x patches include gcc8 support. From there on I'll have a look at retpoline, but it is hard enough simply staying up to date. We will see what happens.
If anyone wants to help out, you can help by compiling my code and testing, fixing those pesky kconfig warnings I introduced today, or having a go at getting retpoline working.
theLOICofFRANCE
miroR
Spent a bit of time looking at the KPTI thing and trying to figure how the pieces impacted by the changes in this tree actually work, and what the kpti patches are doing there. It looks like there's a bunch of delta around the way tss_struct is handled, and lower down to things i dont yet understand, seemingly related to how data is laid out on the stack. It appears that some of the memory access is actually occuring from kernel context whereas the 4.9 upstream code being patched seems to expect its in the user context (in truct tss_struct doublefault_tss for instance)
@minipli: if this is actually "portable" into the fork, is there any chance you might be able to detail the changes from upstream in the commit log so we could better understand the clockwork? Thanks as always.