linux-kernel - Re: What are the real ioapic rte programming constraints?

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:	Sat, 10 Feb 2007 21:57:56 -0800 (PST)
From:	Zwane Mwaikambo <zwane@...radead.org>
To:	"Eric W. Biederman" <ebiederm@...ssion.com>
Cc:	Ashok Raj <ashok.raj@...el.com>, Ingo Molnar <mingo@...e.hu>,
	Andrew Morton <akpm@...l.org>, linux-kernel@...r.kernel.org,
	"Lu, Yinghai" <yinghai.lu@....com>,
	Natalie Protasevich <protasnb@...il.com>,
	Andi Kleen <ak@...e.de>, Coywolf Qi Hunt <coywolf@...ecn.org>
Subject: Re: What are the real ioapic rte programming constraints?

On Sat, 10 Feb 2007, Eric W. Biederman wrote:

> There are not enough details in the justification to really understand
> the issue so I'm asking to see if someone has some more details.
> 
> The description makes the assertion that reprograming the ioapic
> when an  interrupt is pending is the only safe way to handle this.
> Since edge triggered interrupts cannot be pending at the ioapic I know
> it is not talking level triggered interrupts.
> 
> However it is not possible to fully reprogram a level triggered
> interrupt when the interrupt is pending as the ioapic will not
> receive the interrupt acknowledgement.  So it turns out I have
> broken this change for several kernel releases without people
> screaming at me about io_apic problems.
> 
> Currently I am disabling the irq on the ioapic before reprogramming
> it so I do not run into issues.  Does that solve the concerns that
> were patched around by only reprogramming interrupt redirection
> table entry in interrupt handlers?

Hi Eric,
	Could you outline in pseudocode where you're issuing the mask? If 
it's done whilst an irq is pending some (intel 7500 based) chipsets will 
not actually mask it but treat it as a 'legacy' IRQ and deliver it 
anyway. Using the masked whilst pending logic avoids all of that.

Cheers,
	Zwane
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/