On 4/8/22 07:06, Peter Zijlstra wrote: > On Thu, Apr 07, 2022 at 03:25:09PM -0500, madvenka@xxxxxxxxxxxxxxxxxxx wrote: >> The solution >> ============ >> >> The goal here is to use the absolute minimum CFI needed to compute the FP at >> every instruction address. The unwinder can compute the FP in each frame, >> compare the actual FP with the computed one and validate the actual FP. >> >> Objtool is enhanced to parse the CFI, extract just the rules required, >> encode them in compact data structures and create special sections for >> the rules. The unwinder uses the special sections to find the rules for >> a given instruction address and compute the FP. >> >> Objtool can be invoked as follows: >> >> objtool dwarf generate <object-file> >> >> The version of the DWARF standard supported in this work is version 4. The >> official documentation for this version is here: >> >> https://dwarfstd.org/doc/DWARF4.pdf >> >> Section 6.4 contains the description of the CFI. > > The problem is of course that DWARF is only available for compiler > generated code and doesn't cover assembly code, of which is there is > always lots. > Yes. But assembly functions are of two types: SYM_CODE_*() functions SYM_FUNC_*() functions SYM_CODE functions are, by definition, special functions that don't follow any ABI rules. They don't set up a frame. Based on the opinion of ARM64 experts, these need to be recognized by the unwinder and, if they are present in a stack trace, the stack trace must be considered unreliable. I have, in fact, submitted a patch to implement that. So, only SYM_FUNC*() functions are relevant for this part. I will look into these for arm64 and check if any of them can occur frequently in stack traces. If any of them is likely to occur frequently in stack traces, I must address them. If there are only a few such functions, unwind hints may be sufficient. I will get back to you on this. > I suppose you can go add DWARF annotations to all the assembly, but IIRC > those are pretty terrible. We were *REALLY* happy to delete all that > nasty from the x86 code. > DWARF annotations are a PITA to maintain. I will never recommend that! > On top of that, AFAIK compilers don't generally consider DWARF > generation to be a correctness issue. For them it's debug info and > having it be correct is nice but not required. So using it as input for > something that's required to be correct, seems unfortunate. It is only debug info. But if that info can be verified, then it is usable for livepatch purposes. I am thinking of implementing a verifier since DWARF reliability is a valid concern. I will keep you posted. Thanks! Madhavan
