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. > > 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) > If we can rely on shadow call stack to implement the reliable unwinder, > I guess this could be the way to go. > > > In summary, I would not be in favor of enabling objtool on arm64 at > > all until we have exhausted other options for providing the > > functionality that we need it for (given that objtool provides many > > other things that only x86 cares about, IIUC) > > > I understand the concern and appreciate the suggestion. I guess this > does need some thorough discussions for the right approach. > Agreed.
