From: Julien Thierry <jthierry@redhat.com> To: Ard Biesheuvel <ardb@kernel.org> Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>, Linux ARM <linux-arm-kernel@lists.infradead.org>, Catalin Marinas <catalin.marinas@arm.com>, Will Deacon <will@kernel.org>, Masahiro Yamada <masahiroy@kernel.org>, Kees Cook <keescook@chromium.org>, Michal Marek <michal.lkml@markovi.net>, Josh Poimboeuf <jpoimboe@redhat.com>, Peter Zijlstra <peterz@infradead.org>, Mark Rutland <mark.rutland@arm.com>, Mark Brown <broonie@kernel.org>, linux-efi <linux-efi@vger.kernel.org>, linux-hardening@vger.kernel.org Subject: Re: [RFC PATCH 00/17] objtool: add base support for arm64 Date: Thu, 21 Jan 2021 14:23:53 +0100 [thread overview] Message-ID: <6e21cd51-017e-2135-ed9d-33a60f22a457@redhat.com> (raw) In-Reply-To: <CAMj1kXHznGnN2UEai1c2UgyKuTFCS5SZ+qGR6VJwyCuccViw_A@mail.gmail.com> On 1/21/21 12:08 PM, Ard Biesheuvel wrote: > On Thu, 21 Jan 2021 at 11:26, Julien Thierry <jthierry@redhat.com> 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@redhat.com> 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
WARNING: multiple messages have this Message-ID (diff)
From: Julien Thierry <jthierry@redhat.com> To: Ard Biesheuvel <ardb@kernel.org> Cc: Mark Rutland <mark.rutland@arm.com>, linux-efi <linux-efi@vger.kernel.org>, Michal Marek <michal.lkml@markovi.net>, Kees Cook <keescook@chromium.org>, Peter Zijlstra <peterz@infradead.org>, Catalin Marinas <catalin.marinas@arm.com>, Masahiro Yamada <masahiroy@kernel.org>, Linux Kernel Mailing List <linux-kernel@vger.kernel.org>, Mark Brown <broonie@kernel.org>, linux-hardening@vger.kernel.org, Josh Poimboeuf <jpoimboe@redhat.com>, Will Deacon <will@kernel.org>, Linux ARM <linux-arm-kernel@lists.infradead.org> Subject: Re: [RFC PATCH 00/17] objtool: add base support for arm64 Date: Thu, 21 Jan 2021 14:23:53 +0100 [thread overview] Message-ID: <6e21cd51-017e-2135-ed9d-33a60f22a457@redhat.com> (raw) In-Reply-To: <CAMj1kXHznGnN2UEai1c2UgyKuTFCS5SZ+qGR6VJwyCuccViw_A@mail.gmail.com> On 1/21/21 12:08 PM, Ard Biesheuvel wrote: > On Thu, 21 Jan 2021 at 11:26, Julien Thierry <jthierry@redhat.com> 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@redhat.com> 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 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2021-01-21 13:29 UTC|newest] Thread overview: 106+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-01-20 17:37 [RFC PATCH 00/17] objtool: add base support for arm64 Julien Thierry 2021-01-20 17:37 ` Julien Thierry 2021-01-20 17:37 ` [RFC PATCH 01/17] tools: Add some generic functions and headers Julien Thierry 2021-01-20 17:37 ` Julien Thierry 2021-01-20 17:37 ` [RFC PATCH 02/17] tools: arm64: Make aarch64 instruction decoder available to tools Julien Thierry 2021-01-20 17:37 ` Julien Thierry 2021-01-20 17:37 ` [RFC PATCH 03/17] tools: bug: Remove duplicate definition Julien Thierry 2021-01-20 17:37 ` Julien Thierry 2021-01-20 17:37 ` [RFC PATCH 04/17] objtool: arm64: Add base definition for arm64 backend Julien Thierry 2021-01-20 17:37 ` Julien Thierry 2021-01-20 17:37 ` [RFC PATCH 05/17] objtool: arm64: Decode add/sub instructions Julien Thierry 2021-01-20 17:37 ` Julien Thierry 2021-01-20 17:37 ` [RFC PATCH 06/17] objtool: arm64: Decode jump and call related instructions Julien Thierry 2021-01-20 17:37 ` Julien Thierry 2021-01-20 17:37 ` [RFC PATCH 07/17] objtool: arm64: Decode other system instructions Julien Thierry 2021-01-20 17:37 ` Julien Thierry 2021-01-20 17:37 ` [RFC PATCH 08/17] objtool: arm64: Decode load/store instructions Julien Thierry 2021-01-20 17:37 ` Julien Thierry 2021-01-20 17:37 ` [RFC PATCH 09/17] objtool: arm64: Decode LDR instructions Julien Thierry 2021-01-20 17:37 ` Julien Thierry 2021-01-20 17:37 ` [RFC PATCH 10/17] objtool: arm64: Accept padding in code sections Julien Thierry 2021-01-20 17:37 ` Julien Thierry 2021-01-20 17:37 ` [RFC PATCH 11/17] efi: libstub: Ignore relocations for .discard sections Julien Thierry 2021-01-20 17:37 ` Julien Thierry 2021-01-20 17:37 ` [RFC PATCH 12/17] gcc-plugins: objtool: Add plugin to detect switch table on arm64 Julien Thierry 2021-01-20 17:37 ` Julien Thierry 2021-01-27 22:15 ` Nick Desaulniers 2021-01-27 22:15 ` Nick Desaulniers 2021-01-27 23:26 ` Josh Poimboeuf 2021-01-27 23:26 ` Josh Poimboeuf 2021-01-29 18:10 ` Nick Desaulniers 2021-01-29 18:10 ` Nick Desaulniers 2021-02-01 21:44 ` Josh Poimboeuf 2021-02-01 21:44 ` Josh Poimboeuf 2021-02-01 23:17 ` Nick Desaulniers 2021-02-01 23:17 ` Nick Desaulniers 2021-02-02 0:02 ` Josh Poimboeuf 2021-02-02 0:02 ` Josh Poimboeuf 2021-02-02 14:24 ` David Laight 2021-02-02 14:24 ` David Laight 2021-02-02 22:33 ` Nick Desaulniers 2021-02-02 22:33 ` Nick Desaulniers 2021-02-02 23:36 ` Josh Poimboeuf 2021-02-02 23:36 ` Josh Poimboeuf 2021-02-02 23:52 ` Nick Desaulniers 2021-02-02 23:52 ` Nick Desaulniers 2021-02-02 8:57 ` Julien Thierry 2021-02-02 8:57 ` Julien Thierry 2021-02-02 23:01 ` Nick Desaulniers 2021-02-02 23:01 ` Nick Desaulniers 2021-02-03 0:14 ` Josh Poimboeuf 2021-02-03 0:14 ` Josh Poimboeuf 2021-02-03 11:57 ` Peter Zijlstra 2021-02-03 11:57 ` Peter Zijlstra 2021-02-03 13:04 ` Mark Brown 2021-02-03 13:04 ` Mark Brown 2021-02-03 13:58 ` Mark Rutland 2021-02-03 13:58 ` Mark Rutland 2021-02-03 8:11 ` Julien Thierry 2021-02-03 8:11 ` Julien Thierry 2021-02-09 16:30 ` Daniel Kiss 2021-02-09 16:30 ` Daniel Kiss 2021-01-20 17:37 ` [RFC PATCH 13/17] objtool: arm64: Implement functions to add switch tables alternatives Julien Thierry 2021-01-20 17:37 ` Julien Thierry 2021-01-20 17:37 ` [RFC PATCH 14/17] objtool: arm64: Cache section with switch table information Julien Thierry 2021-01-20 17:37 ` Julien Thierry 2021-01-20 17:37 ` [RFC PATCH 15/17] objtool: arm64: Handle supported relocations in alternatives Julien Thierry 2021-01-20 17:37 ` Julien Thierry 2021-01-20 17:37 ` [RFC PATCH 16/17] objtool: arm64: Ignore replacement section for alternative callback Julien Thierry 2021-01-20 17:37 ` Julien Thierry 2021-01-20 17:38 ` [RFC PATCH 17/17] objtool: arm64: Enable stack validation for arm64 Julien Thierry 2021-01-20 17:38 ` Julien Thierry 2021-01-21 5:39 ` kernel test robot 2021-01-21 9:03 ` [RFC PATCH 00/17] objtool: add base support " Ard Biesheuvel 2021-01-21 9:03 ` Ard Biesheuvel 2021-01-21 10:26 ` Julien Thierry 2021-01-21 10:26 ` Julien Thierry 2021-01-21 11:08 ` Ard Biesheuvel 2021-01-21 11:08 ` Ard Biesheuvel 2021-01-21 11:23 ` Peter Zijlstra 2021-01-21 11:23 ` Peter Zijlstra 2021-01-21 11:48 ` Ard Biesheuvel 2021-01-21 11:48 ` Ard Biesheuvel 2021-01-21 18:54 ` Josh Poimboeuf 2021-01-21 18:54 ` Josh Poimboeuf 2021-01-22 17:43 ` Mark Brown 2021-01-22 17:43 ` Mark Brown 2021-01-22 17:54 ` Ard Biesheuvel 2021-01-22 17:54 ` Ard Biesheuvel 2021-01-28 22:10 ` Madhavan T. Venkataraman 2021-01-28 22:10 ` Madhavan T. Venkataraman 2021-01-29 15:47 ` Mark Brown 2021-01-22 21:15 ` Madhavan T. Venkataraman 2021-01-22 21:15 ` Madhavan T. Venkataraman 2021-01-22 21:43 ` Ard Biesheuvel 2021-01-22 21:43 ` Ard Biesheuvel 2021-01-22 21:44 ` Madhavan T. Venkataraman 2021-01-22 21:44 ` Madhavan T. Venkataraman 2021-01-25 21:19 ` Josh Poimboeuf 2021-01-25 21:19 ` Josh Poimboeuf 2021-01-22 21:16 ` Madhavan T. Venkataraman 2021-01-22 21:16 ` Madhavan T. Venkataraman 2021-01-21 13:23 ` Julien Thierry [this message] 2021-01-21 13:23 ` Julien Thierry 2021-01-21 14:23 ` Mark Brown 2021-01-21 14:23 ` Mark Brown
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=6e21cd51-017e-2135-ed9d-33a60f22a457@redhat.com \ --to=jthierry@redhat.com \ --cc=ardb@kernel.org \ --cc=broonie@kernel.org \ --cc=catalin.marinas@arm.com \ --cc=jpoimboe@redhat.com \ --cc=keescook@chromium.org \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-efi@vger.kernel.org \ --cc=linux-hardening@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=mark.rutland@arm.com \ --cc=masahiroy@kernel.org \ --cc=michal.lkml@markovi.net \ --cc=peterz@infradead.org \ --cc=will@kernel.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.