From: Nick Desaulniers <ndesaulniers@google.com> To: Josh Poimboeuf <jpoimboe@redhat.com> Cc: Julien Thierry <jthierry@redhat.com>, Ard Biesheuvel <ardb@kernel.org>, Mark Brown <broonie@kernel.org>, Catalin Marinas <catalin.marinas@arm.com>, Kees Cook <keescook@chromium.org>, Linux ARM <linux-arm-kernel@lists.infradead.org>, linux-efi <linux-efi@vger.kernel.org>, linux-hardening@vger.kernel.org, LKML <linux-kernel@vger.kernel.org>, Mark Rutland <mark.rutland@arm.com>, Masahiro Yamada <masahiroy@kernel.org>, Michal Marek <michal.lkml@markovi.net>, Peter Zijlstra <peterz@infradead.org>, raphael.gault@arm.com, Will Deacon <will@kernel.org>, clang-built-linux <clang-built-linux@googlegroups.com>, Bill Wendling <morbo@google.com>, swine@google.com, yonghyun@google.com Subject: Re: [RFC PATCH 12/17] gcc-plugins: objtool: Add plugin to detect switch table on arm64 Date: Tue, 2 Feb 2021 14:33:38 -0800 [thread overview] Message-ID: <CAKwvOd=R_ELec5Q3+oe9zuYXrwSGfLkqomAPOTr=UH=SZPtKUw@mail.gmail.com> (raw) In-Reply-To: <20210202000203.rk7lh5mx4aflgkwr@treble> On Mon, Feb 1, 2021 at 4:02 PM Josh Poimboeuf <jpoimboe@redhat.com> wrote: > > On Mon, Feb 01, 2021 at 03:17:40PM -0800, Nick Desaulniers wrote: > > On the earlier thread, Julien writes: > > > > >> 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). > > > > Google's production kernels are using livepatching and are built with > > Clang. Getting similar functionality working for arm64 would be of > > interest. > > Well, that's cool. I had no idea. > > I'm curious how they're generating livepatch modules? Because > kpatch-build doesn't support Clang (AFAIK), and if they're not using > kpatch-build then there are some traps to look out for. Ok, I just met with a bunch of folks that are actively working on this. Let me intro Yonghyun Hwang <yonghyun@google.com> Pete Swain <swine@google.com> who will be the folks on point for this from Google. My understanding after some clarifications today is that Google is currently using a proprietary kernel patching mechanism that developed around a decade ago, "pre-ksplice Oracle acquisition." But we are looking to transition to kpatch, and help towards supporting arm64. Live patching is important for deploying kernel fixes faster than predetermined scheduled draining of jobs in clusters. The first steps for kpatch transition is supporting builds with Clang. Yonghyun is working on that and my hope is he will have patches for you for that soon. Curiously, the proprietary mechanism doesn't rely on stack validation. I think that such dependency was questioned on the cover letter patch's thread as well. Maybe there's "some traps to look out for" you're referring to there? I'm not privy to the details, though I would guess it has to do with ensuring kernel threads aren't executing (or planning to return through) code regions that are trying to be patched/unpatched. I am curious about frame pointers never being omitted for arm64; is frame pointer chasing is unreliable in certain contexts? The internal functionality has been used heavily in production for almost a decade, though without it being public or supporting arm64; I'm not sure precisely how they solve such issues (or how others might review such an approach). Either way, the dependencies for live patching are less important, so long as they are toolchain portable. The ability to live patch kernel images is ___important___ to Google. > > Objtool support on arm64 is interesting to me though, because it has > > found bugs in LLVM codegen. That alone is extremely valuable. But not > > it's not helpful if it's predicated or tightly coupled to GCC, as this > > series appears to do. > > I agree 100%, if there are actual Clang livepatch users (which it sounds > like there are) then we should target both compilers. Or will be. (Sorry, I didn't know we hadn't completed the transition to kpatch yet. It is "the opposite side of the house" from where I work; I literally have 8 bosses, not kidding). Though if kpatch moves to requiring GCC plugins for architectures we use extensively or would like to use more of, that's probably going to throw a wrench in multiple transition plans. (The fleet's transition to Clang is done, I'm not worried about that). > And yes, objtool has been pretty good at finding compiler bugs, so the > more coverage the better. > > The idea of rebuilding control flow from binary analysis and using > > that to find codegen bugs is a really cool idea (novel, even? idk), > > and I wish we had some analog for userspace binaries that could > > perform similar checks. > > Objtool is generic in many ways -- in fact I recently heard from a PhD > candidate who used it successfully on another kernel for an ORC > unwinder. That's pretty cool! Reuse outside the initial context is always a good sign that something was designed right. > It could probably be used on user space without much effort. That was > an early original stated goal but I definitely don't have the bandwidth > or incentive to work on it. Heh. I'm a big fan of game theory; carrot or stick, right? -- Thanks, ~Nick Desaulniers
WARNING: multiple messages have this Message-ID (diff)
From: Nick Desaulniers <ndesaulniers@google.com> To: Josh Poimboeuf <jpoimboe@redhat.com> Cc: Mark Rutland <mark.rutland@arm.com>, Bill Wendling <morbo@google.com>, linux-efi <linux-efi@vger.kernel.org>, Julien Thierry <jthierry@redhat.com>, clang-built-linux <clang-built-linux@googlegroups.com>, Peter Zijlstra <peterz@infradead.org>, Catalin Marinas <catalin.marinas@arm.com>, Masahiro Yamada <masahiroy@kernel.org>, yonghyun@google.com, LKML <linux-kernel@vger.kernel.org>, Michal Marek <michal.lkml@markovi.net>, raphael.gault@arm.com, Mark Brown <broonie@kernel.org>, linux-hardening@vger.kernel.org, swine@google.com, Will Deacon <will@kernel.org>, Ard Biesheuvel <ardb@kernel.org>, Linux ARM <linux-arm-kernel@lists.infradead.org>, Kees Cook <keescook@chromium.org> Subject: Re: [RFC PATCH 12/17] gcc-plugins: objtool: Add plugin to detect switch table on arm64 Date: Tue, 2 Feb 2021 14:33:38 -0800 [thread overview] Message-ID: <CAKwvOd=R_ELec5Q3+oe9zuYXrwSGfLkqomAPOTr=UH=SZPtKUw@mail.gmail.com> (raw) In-Reply-To: <20210202000203.rk7lh5mx4aflgkwr@treble> On Mon, Feb 1, 2021 at 4:02 PM Josh Poimboeuf <jpoimboe@redhat.com> wrote: > > On Mon, Feb 01, 2021 at 03:17:40PM -0800, Nick Desaulniers wrote: > > On the earlier thread, Julien writes: > > > > >> 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). > > > > Google's production kernels are using livepatching and are built with > > Clang. Getting similar functionality working for arm64 would be of > > interest. > > Well, that's cool. I had no idea. > > I'm curious how they're generating livepatch modules? Because > kpatch-build doesn't support Clang (AFAIK), and if they're not using > kpatch-build then there are some traps to look out for. Ok, I just met with a bunch of folks that are actively working on this. Let me intro Yonghyun Hwang <yonghyun@google.com> Pete Swain <swine@google.com> who will be the folks on point for this from Google. My understanding after some clarifications today is that Google is currently using a proprietary kernel patching mechanism that developed around a decade ago, "pre-ksplice Oracle acquisition." But we are looking to transition to kpatch, and help towards supporting arm64. Live patching is important for deploying kernel fixes faster than predetermined scheduled draining of jobs in clusters. The first steps for kpatch transition is supporting builds with Clang. Yonghyun is working on that and my hope is he will have patches for you for that soon. Curiously, the proprietary mechanism doesn't rely on stack validation. I think that such dependency was questioned on the cover letter patch's thread as well. Maybe there's "some traps to look out for" you're referring to there? I'm not privy to the details, though I would guess it has to do with ensuring kernel threads aren't executing (or planning to return through) code regions that are trying to be patched/unpatched. I am curious about frame pointers never being omitted for arm64; is frame pointer chasing is unreliable in certain contexts? The internal functionality has been used heavily in production for almost a decade, though without it being public or supporting arm64; I'm not sure precisely how they solve such issues (or how others might review such an approach). Either way, the dependencies for live patching are less important, so long as they are toolchain portable. The ability to live patch kernel images is ___important___ to Google. > > Objtool support on arm64 is interesting to me though, because it has > > found bugs in LLVM codegen. That alone is extremely valuable. But not > > it's not helpful if it's predicated or tightly coupled to GCC, as this > > series appears to do. > > I agree 100%, if there are actual Clang livepatch users (which it sounds > like there are) then we should target both compilers. Or will be. (Sorry, I didn't know we hadn't completed the transition to kpatch yet. It is "the opposite side of the house" from where I work; I literally have 8 bosses, not kidding). Though if kpatch moves to requiring GCC plugins for architectures we use extensively or would like to use more of, that's probably going to throw a wrench in multiple transition plans. (The fleet's transition to Clang is done, I'm not worried about that). > And yes, objtool has been pretty good at finding compiler bugs, so the > more coverage the better. > > The idea of rebuilding control flow from binary analysis and using > > that to find codegen bugs is a really cool idea (novel, even? idk), > > and I wish we had some analog for userspace binaries that could > > perform similar checks. > > Objtool is generic in many ways -- in fact I recently heard from a PhD > candidate who used it successfully on another kernel for an ORC > unwinder. That's pretty cool! Reuse outside the initial context is always a good sign that something was designed right. > It could probably be used on user space without much effort. That was > an early original stated goal but I definitely don't have the bandwidth > or incentive to work on it. Heh. I'm a big fan of game theory; carrot or stick, right? -- Thanks, ~Nick Desaulniers _______________________________________________ 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-02-02 22:35 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 [this message] 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 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='CAKwvOd=R_ELec5Q3+oe9zuYXrwSGfLkqomAPOTr=UH=SZPtKUw@mail.gmail.com' \ --to=ndesaulniers@google.com \ --cc=ardb@kernel.org \ --cc=broonie@kernel.org \ --cc=catalin.marinas@arm.com \ --cc=clang-built-linux@googlegroups.com \ --cc=jpoimboe@redhat.com \ --cc=jthierry@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=morbo@google.com \ --cc=peterz@infradead.org \ --cc=raphael.gault@arm.com \ --cc=swine@google.com \ --cc=will@kernel.org \ --cc=yonghyun@google.com \ /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.