[PATCH 2/2] lkdtm: fix irq handler entry for arm64
Kees Cook
keescook at chromium.org
Tue Feb 27 07:46:15 PST 2018
On Mon, Feb 26, 2018 at 11:20 PM, AKASHI Takahiro
<takahiro.akashi at linaro.org> wrote:
> Hi Kees,
>
> On Mon, Feb 26, 2018 at 07:57:10PM -0800, Kees Cook wrote:
>> On Thu, Feb 1, 2018 at 1:34 AM, AKASHI Takahiro
>> <takahiro.akashi at linaro.org> wrote:
>> > Arm64 doesn't have "do_IRQ" function, instead *handle_arch_irq, which is
>> > initialized by irq chip (gic), is called from exception entry.
>> > This patch fixes this problem.
>>
>> As in, this symbol is not known a lkdtm setup time? Hm, seems like
>> we'd want a more generalized approach here.
>
> Hmm. See my comments below.
>
>> >
>> > Signed-off-by: AKASHI Takahiro <takahiro.akashi at linaro.org>
>> > ---
>> > drivers/misc/lkdtm_core.c | 20 ++++++++++++++++++--
>> > 1 file changed, 18 insertions(+), 2 deletions(-)
>> >
>> > diff --git a/drivers/misc/lkdtm_core.c b/drivers/misc/lkdtm_core.c
>> > index ba92291508dc..e20343543053 100644
>> > --- a/drivers/misc/lkdtm_core.c
>> > +++ b/drivers/misc/lkdtm_core.c
>> > @@ -249,13 +249,29 @@ static int lkdtm_register_cpoint(struct crashpoint *crashpoint,
>> > if (lkdtm_kprobe != NULL)
>> > unregister_kprobe(lkdtm_kprobe);
>> >
>> > + if (IS_ENABLED(CONFIG_ARM64) &&
>> > + !strcmp(crashpoint->name, "INT_HARDWARE_ENTRY")) {
>> > + extern void (*handle_arch_irq)(struct pt_regs *regs);
>>
>> I don't like this extern -- can handle_arch_irq be properly exported somewhere?
>
> Define a weak function, get_handle_irq(), in linux/irq.h and
> a real one in arch code. Then
>
> if (!kallsyms_lookup_name(crashpoint->symbol_name)) {
> if (!strcmp(crashpoint->name, "INT_HARDWARE_ENTRY")) {
> func = get_handle_irq();
> if (func) {
> crashpoint->kprobe.addr = func;
> crashpoint->kprobe.symbol_name = NULL;
> } else {
> /* error */
> }
> } /* anything else? */
> }
>
> Do you like this code better?
Yeah, this is more generalized; thanks! If we end up with other
late-defined functions we can further generalize this, but this is
fine for our one case. :)
>
>>
>> > + crashpoint->kprobe.addr = (kprobe_opcode_t *)*handle_arch_irq;
>>
>> I don't think the * is needed here: it's already a function pointer.
>
> Will check.
>
>> > + /*
>> > + * Instantiating kprobe.symbol_name here, say
>> > + * with lookup_symbol_name(*handle_arch_irq),
>> > + * would cause register_kprobe() to fail.
>> > + */
>> > + crashpoint->kprobe.symbol_name = NULL;
>>
>> Is kprobe.addr sufficient for register_kprobe?
>
> Yes as Masami explained.
> Leaving symbol_name ends up failure of register_kprobe().
>
>> > + }
>> > lkdtm_crashpoint = crashpoint;
>> > lkdtm_crashtype = crashtype;
>> > lkdtm_kprobe = &crashpoint->kprobe;
>> > ret = register_kprobe(lkdtm_kprobe);
>> > if (ret < 0) {
>> > - pr_info("Couldn't register kprobe %s\n",
>> > - crashpoint->kprobe.symbol_name);
>> > + if (IS_ENABLED(CONFIG_ARM64))
>> > + pr_info("Couldn't register kprobe 0x%lx\n",
>> > + (unsigned long)crashpoint->kprobe.addr);
>> > + else
>> > + pr_info("Couldn't register kprobe %s\n",
>> > + crashpoint->kprobe.symbol_name);
>> > lkdtm_kprobe = NULL;
>> > lkdtm_crashpoint = NULL;
>> > lkdtm_crashtype = NULL;
>>
>> So I can replicate, how did you test this?
>
> All what I did in my arm64 test is
> # echo PANIC > /sys/kernel/debug/provoke-crash/INT_HARDWARE_ENTRY
>
> The probe point will hit sooner or later and we will see a panic
> (and kdump kicks in).
Great, thanks!
-Kees
--
Kees Cook
Pixel Security
More information about the linux-arm-kernel
mailing list