linux-kernel - [PATCH v3 0/3] 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]

Date:	Wed, 16 Oct 2013 11:56:13 +0200
From:	Johan Hovold <jhovold@...il.com>
To:	Nicolas Ferre <nicolas.ferre@...el.com>
Cc:	Jean-Christophe Plagniol-Villard <plagnioj@...osoft.com>,
	Andrew Victor <linux@...im.org.za>,
	Alessandro Zummo <a.zummo@...ertech.it>,
	linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
	rtc-linux@...glegroups.com, Johan Hovold <jhovold@...il.com>
Subject: [PATCH v3 0/3] ARM: at91: fix hanged boot

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.

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 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 add two helper functions to be called called by arch-code
to mask the relevant interrupts before enabling the system interrupt at
early boot.

The patches have been tested on at91sam9g45 and compile-tested for the
other SOCs.

Johan

v2:
 - add DT-support
 - make sys_irq_mask non-mandatory

v3
 - rebase on v3.12-rc5
 - drop DT-support (interrupt masking is needed even if RTC or RTT nodes
   are missing)
 - drop dedicated SOC-initialiser and call helpers directly from init
 - drop revert-patch of move of RTC-register definitions to drivers/ and
   copy the two needed definitions instead
 - move helper functions from setup.c to a separate file
 - add fix for new sama5d3 SOC
 - add a register read back to make sure write has reached the devices
 - split fix in two patches for RTC and RTT, respectively

Johan Hovold (3):
  ARM: at91: fix hanged boot due to early rtc-interrupt
  ARM: at91: fix hanged boot due to early rtt-interrupt
  ARM: at91/rtc: disable interrupts at shutdown

 arch/arm/mach-at91/Makefile                   |  2 +-
 arch/arm/mach-at91/at91sam9260.c              |  2 +
 arch/arm/mach-at91/at91sam9261.c              |  2 +
 arch/arm/mach-at91/at91sam9263.c              |  3 ++
 arch/arm/mach-at91/at91sam9g45.c              |  3 ++
 arch/arm/mach-at91/at91sam9n12.c              |  6 +++
 arch/arm/mach-at91/at91sam9rl.c               |  3 ++
 arch/arm/mach-at91/at91sam9x5.c               |  6 +++
 arch/arm/mach-at91/generic.h                  |  2 +
 arch/arm/mach-at91/include/mach/at91sam9n12.h |  5 ++
 arch/arm/mach-at91/include/mach/at91sam9x5.h  |  5 ++
 arch/arm/mach-at91/include/mach/sama5d3.h     |  5 ++
 arch/arm/mach-at91/sama5d3.c                  |  6 +++
 arch/arm/mach-at91/sysirq_mask.c              | 71 +++++++++++++++++++++++++++
 drivers/rtc/rtc-at91rm9200.c                  |  9 ++++
 15 files changed, 129 insertions(+), 1 deletion(-)
 create mode 100644 arch/arm/mach-at91/sysirq_mask.c

-- 
1.8.4

--
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/