On Thu, Apr 23, 2020 at 11:06:14AM -0700, Kees Cook wrote: > On Wed, Apr 22, 2020 at 11:44:06AM -0500, Josh Poimboeuf wrote: > > On Wed, Apr 22, 2020 at 08:35:29AM -0700, Randy Dunlap wrote: > > > On 4/22/20 12:10 AM, Stephen Rothwell wrote: > > > > Hi all, > > > > > > > > Changes since 20200421: > > > > > > > > > > on x86_64: > > > > In both cases the unreachable instruction happens immediately after a > > call to a function which is truncated with a UD2 (because of > > UBSAN_TRAP). > > > > When I remove UBSAN_TRAP, the UD2s are replaced with calls to > > __ubsan_handle_type_mismatch_v1(). > > Hrm, these are coming out of CONFIG_UBSAN_MISC, yes? It seems that the > UBSAN checks that are non-recoverable all inject unreachable checks > afterwards, from what I can see. > > > Kees, any idea? > > Isn't this another version of the earlier unreachable-ud2 issue? Yes, basically. Objtool has figured out that these are calls to functions which never return. So the instruction after the call is unreachable. Usually GCC also knows that, and knows not to emit the extra unusuable instructions, but I guess this plugin is different. > Regardless, the type_mismatch it triggered for misalignment and > object-size checks, and the alignment check is likely going to always > misfire on x86. The randconfig includes that config: > > CONFIG_UBSAN_ALIGNMENT=y > > So perhaps the config should be strengthened to disallow it under > COMPILE_TEST? > > config UBSAN_ALIGNMENT > def_bool !UBSAN_NO_ALIGNMENT > depends on !COMPILE_TEST But this issue basically makes UBSAN_TRAP unusable, right? Should UBSAN_ALIGNMENT and UBSAN_TRAP be made mutually exclusive? -- Josh
