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: <53C6761A.9090002@linaro.org>
Date:	Wed, 16 Jul 2014 13:54:50 +0100
From:	Daniel Thompson <daniel.thompson@...aro.org>
To:	Marek Vasut <marex@...x.de>, linux-arm-kernel@...ts.infradead.org
CC:	Harro Haan <hrhaan@...il.com>, linaro-kernel@...ts.linaro.org,
	Russell King <linux@....linux.org.uk>, patches@...aro.org,
	kgdb-bugreport@...ts.sourceforge.net,
	Linus Walleij <linus.walleij@...aro.org>,
	Nicolas Pitre <nico@...aro.org>, linux-kernel@...r.kernel.org,
	Colin Cross <ccross@...roid.com>,
	Anton Vorontsov <anton.vorontsov@...aro.org>,
	Ben Dooks <ben.dooks@...ethink.co.uk>,
	John Stultz <john.stultz@...aro.org>,
	Fabio Estevam <festevam@...il.com>,
	Catalin Marinas <catalin.marinas@....com>,
	kernel-team@...roid.com, Frederic Weisbecker <fweisbec@...il.com>,
	Dave Martin <Dave.Martin@....com>, Detlev Zundel <dzu@...x.de>
Subject: Re: [PATCH v8 0/4] arm: KGDB NMI/FIQ support

On 15/07/14 19:45, Marek Vasut wrote:
>>> I can reduce the number of occurrences (not prevent it) by adding the
>>> following hack to irq-gic.c
>>> @@ -297,10 +309,12 @@ static asmlinkage void __exception_irq_entry
>>> gic_handle_irq(struct pt_regs *regs
>>>
>>>   u32 irqstat, irqnr;
>>>   struct gic_chip_data *gic = &gic_data[0];
>>>   void __iomem *cpu_base = gic_data_cpu_base(gic);
>>>   
>>>   do {
>>>
>>> + while(readl_relaxed(gic_data_dist_base(gic) + GIC_DIST_PENDING_SET)
>>> & (1 << 30))
>>> +   printk(KERN_ERR "TEMP: gic_handle_irq: wait for FIQ exception\n");
>>>
>>>   irqstat = readl_relaxed(cpu_base + GIC_CPU_INTACK);
>>>   irqnr = irqstat & ~0x1c00;
>>
>> I've made a more complete attempt to fix this. Could you test the
>> following? (and be prepared to fuzz the line numbers)
> 
> There's also another workaround, look at [1], but it's really a perverse hack 
> thus far (blush). What I did there is I got hinted that an L1 page table can 
> have this NS bit set. If this bit is set for a mapping, all accesses to memory 
> area via that mapping will be non-secure. And then, in turn, by doing a non-
> secure read of the INTACK register, it will not ever happen that the FIQ number 
> will pop up in the INTACK. I only do a non-secure read of the INTACK register,
> all other registers of the GICv1 are read via regular secure-mode accesses.

I'll be looking into this approach.

It is technically a better approach than mine since it prevents the IRQ
handler from ever reading a group 0 interrupt from INTACK.

Unfortunately the tentacles of this workaround reach pretty deep in the
memory management code (rather than being concentrated in the GIC
driver) but the improved runtime behaviour might be worth it.
--
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ