linux-kernel - Re: NMI for ARC

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]

Date:   Thu, 29 Sep 2016 09:47:08 -0700
From:   Vineet Gupta <Vineet.Gupta1@...opsys.com>
To:     Peter Zijlstra <peterz@...radead.org>
CC:     arcml <linux-snps-arc@...ts.infradead.org>,
        Alexey Brodkin <Alexey.Brodkin@...opsys.com>,
        lkml <linux-kernel@...r.kernel.org>,
        "Andy Lutomirski" <luto@...capital.net>
Subject: Re: NMI for ARC

On 09/28/2016 11:43 PM, Peter Zijlstra wrote:
> On Wed, Sep 28, 2016 at 06:20:29PM -0700, Vineet Gupta wrote:
>> On 09/28/2016 03:26 PM, Andy Lutomirski wrote:

> 
> 
> 	user	irq	nmi
> 
> 	|
> 	|
> 	`-----> .
> 		|
> 		|
> 		|
> 		`----->	.
> 			|
> 			|
> 		. <-----'
> 	. <-----'
> 	|
> 	|
> 
> So what Andy is saying is that NMI context never sets TIF_NEED_RESCHED,

Can we we be absolutely sure about that. A perf intr, vmalloc based mmap can go
thru various hoops and. Is it not possible that it hits a reschedule, setting
TIF_NEED_RESCHED

> this means that return from NMI never needs to check for preemption
> etc..

I don't think this implies from prev one. In my example, timer interrupt triggers
a TIF_NEED_RESCHED and irq_exit -> __do_softirq() it hits the perf intr

> Now your return from IRQ obviously should, the normal way. If the IRQ
> return gets interrupted by the NMI nothing special should occur. The
> return from NMI should simply resume the return from IRQ.
> 
> So I'm a little confused by your timer interrupt example, it _should_ do
> the preemption, the nested interrupt (NMI) will return to the regular
> interrupt which should resume its normal return preemption or not.

So lets first see how a single priority intr works on ARC (maybe on other arches
as well).

1. task t1 enters kernel syscall (Trap Exception on ARC), handler drops down to
pure kernel model and proceeds into syscall handler.
2. while in handler, some intr is taken, which causes a reschedule to task t2.
3. t2's control flow returns (say it was in syscall when originally
scheduled-out). It needs to return to user mode but cpu needs to return from
active interrupt. So we return to user mode, "riding" the intr return path. Means
intr in step #2 returns to a different PC and execution mode (user vs. kernel etc).

Now the same scheme doesn't work out of the box when u have intr and nmi. We have
to actively ensure that nmi doesn't lead to a __schedule() sans user code. And
this is done by bumping preempt_count(NMI_OFFSET) in entry of nmi handler.