linux-kernel - Re: [rtc-linux] Re: [PATCH v2 0/5] ARM: at91: fix hanged boot

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: <20130412093333.GF21305@localhost>
Date:	Fri, 12 Apr 2013 11:33:33 +0200
From:	Johan Hovold <jhovold@...il.com>
To:	Jean-Christophe PLAGNIOL-VILLARD <plagnioj@...osoft.com>,
	Nicolas Ferre <nicolas.ferre@...el.com>
Cc:	rtc-linux@...glegroups.com, Andrew Victor <linux@...im.org.za>,
	Alessandro Zummo <a.zummo@...ertech.it>,
	linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
	Johan Hovold <jhovold@...il.com>
Subject: Re: [rtc-linux] Re: [PATCH v2 0/5] ARM: at91: fix hanged boot

On Thu, Apr 11, 2013 at 06:54:14PM +0200, Jean-Christophe PLAGNIOL-VILLARD wrote:
> On 17:55 Thu 11 Apr     , Johan Hovold wrote:
> > On Mon, Mar 11, 2013 at 07:07:54PM +0100, Johan Hovold wrote:
> > > These patches fix a few severe issues affecting most AT91 SOCs where
> > > boot can hang after a non-general reset, and where the only way to get
> > > the system booting again is to do a general reset -- something which
> > > could require physically removing any backup battery.
> > 
> > Have you had time to look at these patches yet, Nicolas?
> > 
> > I don't think not having decided on the path forward for DT-support for
> > rtc-at91sam9 needs to be a blocker. The rtt-nodes will be needed in any
> > case.
> > 
> > I could respin the series on top of the DT-patch for rtc-at91rm9200, and
> > add interrupt and status-disabled properties to the DT-nodes as well.
> for this this is still a no go
> 
> this way too much ugly

I understand that you prefer fixing every bootloader. I was just making
sure everyone agrees that that is the best solution.

The two interrupt masks has to be cleared before the kernel enables the
system interrupt; either it needs to be done by the bootloader or by the
at91 arch code.

The various bootloaders may not know anything about RTT or RTC, but
have all made sure interrupts are disabled before executing the kernel.
That is, they have fulfilled the requirement that interrupts must be
disabled.

So the trade-off seems to be: Either we fix this once and for all using
the infrastructure already in place in the kernel (DT), or risk further
(apparently) bricked systems as there are bound to be bootloaders that
won't get updated.

[...]

> > > The problems stem from the fact that the RTC and RTT-peripherals are
> > > powered by backup power (VDDBU) and are not reset on wake-up, user,
> > > watchdog or software reset. Consequently, RTC and RTT-alarms and their
> > > interrupts may be enabled at boot, leading to a system lock-up when an
> > > interrupt arrives on the shared system-interrupt line before the
> > > appropriate handler (e.g. RTC-driver) has been installed.
> > > 
> > > The easiest way to trigger this is to simply wake up from an RTC-alarm
> > > on at91sam9g45. The RTC-driver currently does not disable interrupts at
> > > shutdown so even after a clean shut-down the system will always hang
> > > after waking up.
> > > 
> > > The first patch fixes this very general case of RTC-wake up after a
> > > clean shutdown in the RTC-driver and is marked for stable as it is
> > > perfectly straight-forward. [ Note that the other, RTT-based, AT91
> > > RTC-driver already disables its interrupts at shutdown. ]

And what about this patch? If it's decided that every bootloader needs
to be updated, then perhaps it's better to risk bricked systems also
after a clean shutdown to enforce those updates? Should we then remove
the corresponding disable of interrupts at shutdown from the rtc-at91sam9
driver by the same logic?

> > > The more general problem can be triggered, for example, by doing a
> > > user-reset while updating the RTC-time or if an RTC or RTT-alarm goes
> > > off after a non-clean shutdown.
> > > 
> > > To fix this I propose that arch-code should mask the relevant interrupts
> > > before enabling the system interrupt at early boot, and this is what
> > > the fifth patch does. To access the RTC-registers I choose to revert a
> > > recent patch that moved the register definitions to drivers/rtc.
> > > 
> > > Arguably, the relevant interrupts could also be disabled in bootloaders,
> > > but I suggest fixing it in the kernel once and for all.

Thanks,
Johan
--
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/