linux-kernel - Re: [PATCH] x86/mm/kaiser: Fix IRQ entries text section mapping

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20171127081448.27wy6jq2dexa7em5@hirez.programming.kicks-ass.net>
Date:   Mon, 27 Nov 2017 09:14:48 +0100
From:   Peter Zijlstra <peterz@...radead.org>
To:     Thomas Gleixner <tglx@...utronix.de>
Cc:     Ingo Molnar <mingo@...nel.org>,
        Andy Lutomirski <luto@...capital.net>,
        Dave Hansen <dave.hansen@...ux.intel.com>,
        Josh Poimboeuf <jpoimboe@...hat.com>,
        LKML <linux-kernel@...r.kernel.org>,
        Andy Lutomirski <luto@...nel.org>,
        "H . Peter Anvin" <hpa@...or.com>, Borislav Petkov <bp@...en8.de>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        Steven Rostedt <rostedt@...dmis.org>,
        Andrey Ryabinin <aryabinin@...tuozzo.com>,
        kasan-dev@...glegroups.com, Masami Hiramatsu <mhiramat@...nel.org>
Subject: Re: [PATCH] x86/mm/kaiser: Fix IRQ entries text section mapping

On Sat, Nov 25, 2017 at 05:08:08PM +0100, Thomas Gleixner wrote:
> On Sat, 25 Nov 2017, Ingo Molnar wrote:
> >  	kaiser_add_user_map_ptrs_early(__entry_text_start, __entry_text_end,
> >  				       __PAGE_KERNEL_RX | _PAGE_GLOBAL);
> > +	kaiser_add_user_map_ptrs_early(__irqentry_text_start, __irqentry_text_end,
> > +				       __PAGE_KERNEL_RX | _PAGE_GLOBAL);
> 
> The bad news is that this maps more stuff than actually needed:
> 
> ffffffff81ab1c20 T __irqentry_text_start
> ffffffff81ab1c20 T apic_timer_interrupt
> ffffffff81ab1cf0 T x86_platform_ipi
> ffffffff81ab1dc0 T threshold_interrupt
> ffffffff81ab1e90 T deferred_error_interrupt
> ffffffff81ab1f60 T thermal_interrupt
> ffffffff81ab2030 T call_function_single_interrupt
> ffffffff81ab2100 T call_function_interrupt
> ffffffff81ab21d0 T reschedule_interrupt
> ffffffff81ab22a0 T error_interrupt
> ffffffff81ab2370 T spurious_interrupt
> ffffffff81ab2440 T irq_work_interrupt

I'm confused though; for IDT we have that trampoline Andy did. So the
interrupt should land on the entry stack, do the switch magic and then
call the 'real' IDT entry, no?

So why do these functions need to be mapped at all?