solardiz
commented
1 year ago @fluidog Besides using real exploits on deliberately not-up-to-date kernels, @Adam-pi3 also uses a custom deliberately vulnerable kernel module and exploits against it. We were thinking of cleaning this up, likely adding some safety measures to reduce the risk of someone inadvertently making a real system vulnerable by keeping that module loaded, and making it publicly available, including for Continuous Integration testing via GitHub Actions, but we haven't done that yet. We probably should.
Another idea I had is introducing testing functionality into LKRG itself. We've already recently introduced testing of kretprobes, which LKRG now performs automatically. We could also introduce testing of LKRG's integrity violation detections, perhaps not automatic but on request. A question would be whether to have this code always / by default compiled in (so that a production build can be tested, including in production, for greater relevance of such testing, but OTOH the extra code could provide gadgets for abuse by exploits) or optional / rarely enabled (only when specifically intending to test).
vt-alt
wladmis
As lkrg developers, how do you perform functional testing on lkrg?
For example, by illegally modifying the kernel code segment and then confirming that lkrg does trigger the protection mechanism, but I cannot find a way to illegally modify the kernel code segment.
I saw on your official website that you mentioned preventing several CVEs, but it is difficult to review the attacks and I do not know the principles.
In any case, how do you perform functional testing?