On 7/17/20 2:29 PM, Josh Poimboeuf wrote:
Use of the new -flive-patching flag was introduced with the following
commit:
43bd3a95c98e ("kbuild: use -flive-patching when CONFIG_LIVEPATCH is enabled")
This flag has several drawbacks:
[ ... snip ... ]
- While there *is* a distro which relies on this flag for their distro
livepatch module builds, there's not a publicly documented way to
create safe livepatch modules with it. Its use seems to be based on
tribal knowledge. It serves no benefit to those who don't know how to
use it.
(In fact, I believe the current livepatch documentation and samples
are misleading and dangerous, and should be corrected. Or at least
amended with a disclaimer. But I don't feel qualified to make such
changes.)
FWIW, I'm not exactly qualified to document source-based creation
either, however I have written a few of the samples and obviously the
kselftest modules.
The samples should certainly include a disclaimer (ie, they are only for
API demonstration purposes!) and eventually it would be great if the
kselftest modules could guarantee their safety as well. I don't know
quite yet how we can automate that, but perhaps some kind of post-build
sanity check could verify that they are in fact patching what they
intend to patch.
As for a more general, long-form warning about optimizations, I grabbed
Miroslav's LPC slides from a few years back and poked around at some
IPA-optimized disassembly... Here are my notes that attempt to capture
some common cases:
http://file.bos.redhat.com/~jolawren/klp-compiler-notes/livepatch/compiler-considerations.html
It's not complete and I lost steam about 80% of the way through today.
:) But if it looks useful enough to add to Documentation/livepatch, we
can work on it on-list and try to steer folks into using the automated
kpatch-build, objtool (eventually) or a source-based safety checklist.
The source-based steps have been posted on-list a few times, but I think
it only needs to be formalized in a doc.
-- Joe
