lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Message-ID: <alpine.LSU.2.21.2102091613320.31501@pobox.suse.cz> Date: Tue, 9 Feb 2021 16:16:05 +0100 (CET) From: Miroslav Benes <mbenes@...e.cz> To: Steven Rostedt <rostedt@...dmis.org> cc: Peter Zijlstra <peterz@...radead.org>, Josh Poimboeuf <jpoimboe@...hat.com>, Linus Torvalds <torvalds@...ux-foundation.org>, Borislav Petkov <bp@...e.de>, Dave Hansen <dave.hansen@...el.com>, x86-ml <x86@...nel.org>, lkml <linux-kernel@...r.kernel.org>, Alexei Starovoitov <ast@...nel.org>, live-patching@...r.kernel.org Subject: Re: [GIT PULL] x86/urgent for v5.11-rc7 On Tue, 9 Feb 2021, Steven Rostedt wrote: > On Tue, 9 Feb 2021 09:32:34 +0100 (CET) > Miroslav Benes <mbenes@...e.cz> wrote: > > > powerpc has this > > > > static inline unsigned long klp_get_ftrace_location(unsigned long faddr) > > { > > /* > > * Live patch works only with -mprofile-kernel on PPC. In this case, > > * the ftrace location is always within the first 16 bytes. > > */ > > return ftrace_location_range(faddr, faddr + 16); > > } > > > > > > I suppose the trivial fix is to see if it points to endbr64 and if so, > > > > increment the addr by the length of that. > > > > > > I thought of that too. But one thing that may be possible, is to use > > > kallsym. I believe you can get the range of a function (start and end of > > > the function) from kallsyms. Then ask ftrace for the addr in that range > > > (there should only be one). > > > > And we can do this if a hard-coded value live above is not welcome. If I > > remember correctly, we used to have exactly this in the old versions of > > kGraft. We walked through all ftrace records, called > > kallsyms_lookup_size_offset() on every record's ip and if the offset+ip > > matched faddr (in this case), we returned the ip. > > Either way is fine. Question is, should we just wait till CET is > implemented for the kernel before making any of these changes? Just knowing > that we have a solution to handle it may be good enough for now. I'd prefer it to be a part of CET enablement patch set. Miroslav
Powered by blists - more mailing lists