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>
Hi Madhaven,
This is quite interesting. And it's exactly the kind of crazy idea I
can appreciate ;-)
Some initial thoughts:
1)
I have some concerns about DWARF's reliability, especially considering
a) inline asm, b) regular asm, and c) the kernel's tendency to push
compilers to their limits.
BUT, supplementing the frame pointer unwinding with DWARF, rather than
just relying on DWARF alone, does help a LOT.
I guess the hope is that cross-checking two "mostly reliable" things
against each other (frame pointers and DWARF) will give a reliable
result ;-)
In a general sense, I've never looked at DWARF's reliability, even for
just normal C code. It would be good to have some way of knowing that
DWARF looks mostly sane for both GCC and Clang. For example, maybe
somehow cross-checking it with objtool's knowledge. And then of course
we'd have to hope that it stays bug-free in future compilers.
I'd also be somewhat concerned about assembly. Since there's nothing
ensuring the unwind hints are valid, and will stay valid over time, I
wonder how likely it would be for that to break, and what the
implications would be. Most likely I guess it would break silently, but
then get caught by the frame pointer cross-checking. So a broken hint
might not get noticed for a long time, but at least it (hopefully)
wouldn't break reliable unwinding.
Also, inline asm can sometimes do stack hacks like
"push;do_something;pop" which isn't visible to the toolchain. But
again, hopefully the frame pointer checking would fail and mark it
unreliable.
So I do have some worries about DWARF, but the fact that it's getting
"fact checked" by frame pointers might be sufficient.
2)
If I understand correctly, objtool is converting parts of DWARF to a new
format which can then be read by the kernel. In that case, please don't
call it DWARF as that will cause a lot of confusion.
There are actually several similarities between your new format and ORC,
which is also an objtool-created DWARF alternative. It would be
interesting to see if they could be combined somehow.
3)
Objtool has become an integral part of x86-64, due to security and
performance features and toolchain workarounds.
Not *all* of its features require the full "branch validation" which
follows all code paths -- and was the hardest part to get right -- but
several features *do* need that: stack validation, ORC, uaccess
validation, noinstr validation.
Objtool has been picking up a lot of steam (and features) lately, with
more features currently in active development. And lately there have
been renewed patches for porting it to powerpc and arm64 (and rumors of
s390).
If arm64 ever wants one of those features -- particularly a "branch
validation" based feature -- I think it would make more sense to just do
the stack validation in objtool, rather than the DWARF supplementation
approach.
Just to give an idea of what objtool already supports and how useful it
has become for x86, here's an excerpt from some documentation I've been
working on, since I'm in the middle of rewriting the interface to make
it more modular. This is a list of all its current features:
Features
--------
Objtool has the following features:
- Stack unwinding metadata validation -- useful for helping to ensure
stack traces are reliable for live patching
- ORC unwinder metadata generation -- a faster and more precise
alternative to frame pointer based unwinding
- Retpoline validation -- ensures that all indirect calls go through
retpoline thunks, for Spectre v2 mitigations
- Retpoline call site annotation -- annotates all retpoline thunk call
sites, enabling the kernel to patch them inline, to prevent "thunk
funneling" for both security and performance reasons
- Non-instrumentation validation -- validates non-instrumentable
("noinstr") code rules, preventing unexpected instrumentation in
low-level C entry code
- Static call annotation -- annotates static call sites, enabling the
kernel to implement inline static calls, a faster alternative to some
indirect branches
- Uaccess validation -- validates uaccess rules for a proper safe
implementation of Supervisor Mode Access Protection (SMAP)
- Straight Line Speculation validation -- validates certain SLS
mitigations
- Indirect Branch Tracking validation -- validates Intel CET IBT rules
to ensure that all functions referenced by function pointers have
corresponding ENDBR instructions
- Indirect Branch Tracking annotation -- annotates unused ENDBR
instruction sites, enabling the kernel to "seal" them (replace them
with NOPs) to further harden IBT
- Function entry annotation -- annotates function entries, enabling
kernel function tracing
- Other toolchain hacks which will go unmentioned at this time...
--
Josh
