On 8/15/24 12:07, Ryan Sullivan wrote: > Hi Michael, > > The r2 value is stored to the livepatch stack prior to entering into > the livepatched code, so accessing it will gurantee the previous value > is restored. > > Also, yes, this bug is caused by tooling that "scoops out" pre-compiled > code and places it into the livepatch handler (e.g. kpatch). However, > since the large majority of customers interact with the livepatch > subsystem through tooling, and this fix would not pose any serious risk > to either usability or security (other than those already present in > livepatching), plus it would solve a large problem for these tools with > a simple fix, I feel as though this would be a useful update to > livepatch. > Right, for kpatch-build binary-diff livepatch creation, the tooling scans modified code for a sibling call pattern and errors out with a report to the user: https://github.com/dynup/kpatch/blob/master/kpatch-build/create-diff-object.c#L3886 and we advise users to manually turn sibling calls off as needed: https://github.com/dynup/kpatch/blob/master/doc/patch-author-guide.md#sibling-calls If I understand Ryan's patch, it would remove this restriction from kpatch creation -- assuming that it is safe and sane for the kernel's ftrace handler to do so. -- Joe
