lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Message-ID: <Ys/+qghGmH4kK4DN@FVFF77S0Q05N> Date: Thu, 14 Jul 2022 12:31:54 +0100 From: Mark Rutland <mark.rutland@....com> To: Mark Brown <broonie@...nel.org> Cc: linux-kernel@...r.kernel.org, linux-arm-kernel@...ts.infradead.org, Kees Cook <keescook@...omium.org>, peterz@...radead.org Subject: Re: [PATCH] lkdtm: cfi: add test for HW landing pad CFI On Wed, Jul 13, 2022 at 05:13:57PM +0100, Mark Brown wrote: > On Wed, Jul 13, 2022 at 04:18:15PM +0100, Mark Rutland wrote: > > Some architectures have coarse-grained HW CFI schemes where indirect > > branches must target a "landing pad" instruction (e.g. BTI on arm64, > > ENDBR on x86). These prevent gadgetization of arbitrary portions of > > functions. > > > Add a test which checks these work as expected. > > > For example, on arm64 HW with BTI this should result in a BTI exception > > being taken: > > > +/* > > + * This tries to call an indirect function with an address which is not a > > + * function entry point. This should be caught by architectures with "landing > > + * pad" instructions (e.g. BTI on arm64, or ENDBR on x86). > > + */ > > +static void lkdtm_CFI_FORWARD_LANDING_PAD(void) > > +{ > > + void (*func)(int *); > > + > > + func = (void *)((unsigned long)lkdtm_increment_void + 4); > > + > > + pr_info("Calling gadget address ...\n"); > > + func(&called_count); > > + > > + pr_err("FAIL: survived gadget function call!\n"); > > +} > > Incrementing the address by 4 here is the right number for arm64 and it > looks like it's also right for the x86_64 ENDBR64 instruction but are we > guaranteed that it'll do the right thing for other architectures, > especially those with variable length instructions - couldn't we just > get an illegal instruction exception due to ending up pointing at > something that isn't the start of an instruction even if CFI isn't > active? > > Not sure that worrying about that at this point isn't making perfect the > enemy of good though, it could be dealt with later. Perhaps just put > the offset behind a #define to make it a tiny bit more discoverable? How about I just add a comment for now? e.g. /* * Skip past a landing pad instruction. * On arm64 all instructions are 4-byte aligned, and x86's ENDBR is 4 * bytes. */ Thanks, Mark.
Powered by blists - more mailing lists