On 1/21/21 12:08 PM, Ard Biesheuvel wrote:
On Thu, 21 Jan 2021 at 11:26, Julien Thierry <jthierry@xxxxxxxxxx> wrote:
Hi Ard,
On 1/21/21 10:03 AM, Ard Biesheuvel wrote:
Hello Julien,
On Wed, 20 Jan 2021 at 18:38, Julien Thierry <jthierry@xxxxxxxxxx> wrote:
Hi,
This series enables objtool to start doing stack validation on arm64
kernel builds.
Could we elaborate on this point, please? 'Stack validation' means
getting an accurate picture of all kernel code that will be executed
at some point in the future, due to the fact that there are stack
frames pointing to them. And this ability is essential in order to do
live patching safely?
If this is the goal, I wonder whether this is the right approach for
arm64 (or for any other architecture, for that matter)
Parsing/decoding the object code and even worse, relying on GCC
plugins to annotate some of the idioms as they are being generated, in
order to infer intent on the part of the compiler goes *way* beyond
what we should be comfortable with. The whole point of this exercise
is to guarantee that there are no false positives when it comes to
deciding whether the kernel is in a live patchable state, and I don't
see how we can ever provide such a guarantee when it is built on such
a fragile foundation.
If we want to ensure that the stack contents are always an accurate
reflection of the real call stack, we should work with the toolchain
folks to identify issues that may interfere with this, and implement
controls over these behaviors that we can decide to use in the build.
In the past, I have already proposed adding a 'kernel' code model to
the AArch64 compiler that guarantees certain things, such as adrp/add
for symbol references, and no GOT indirections for position
independent code. Inhibiting optimizations that may impact our ability
to infer the real call stack from the stack contents is something we
might add here as well.
I'm not familiar with toolcahin code models, but would this approach be
able to validate assembly code (either inline or in assembly files?)
No, it would not. But those files are part of the code base, and can
be reviewed and audited.
That means that every actor maintaining their own stable version of the
kernel have to do their own audit when they do backports (assuming the
audit would be done for upstream) to be able to provide a safe
livepatching feature in their kernel.
Another thing that occurred to me is that inferring which kernel code
is actually live in terms of pending function returns could be
inferred much more easily from a shadow call stack, which is a thing
we already implement for Clang builds.
I was not familiar with the shadow call stack. If I understand correctly
that would be a stack of return addresses of function currently on the
call stack, is that correct?
That would indeed be a simpler approach, however I guess the
instrumentation has a cost. Is the instrumentation also available with
GCC? And is this instrumentation efficient enough to be suitable for
production builds?
I am not aware of any plans to enable this in GCC, but the Clang
implementation is definitely intended for production use (it's a CFI
feature for ROP/JOP mitigation)
I think most people interested in livepatching are using GCC built
kernels, but I could be mistaken (althought in the long run, both
compilers should be supported, and yes, I realize the objtool solution
currently only would support GCC).
I don't know how feasible it will be to get it into GCC if people decide
to go with that. Also, now that I think about it, it will probably come
with similar limitations as stackframes where the unwinder would need to
know when/where the shadow call stack is unavailable for some reason and
the stack trace is not reliable. (it might be a bit simpler to audit
than stack frame setting and maybe have less limitations, but I guess
there will still be cases where we can't rely on it)
--
Julien Thierry
