From: Alexandre Belloni <alexandre.belloni@free-electrons.com>
To: Juergen Borleis <jbe@pengutronix.de>
Cc: linux-kernel@vger.kernel.org, rtc-linux@googlegroups.com,
kernel@pengutronix.de, Alessandro Zummo <a.zummo@towertech.it>,
linux-arm-kernel@lists.infradead.org
Subject: Re: [rtc-linux] [PATCHv2] RTC/i.MX/DryICE: add recovery routines to the driver
Date: Sun, 3 May 2015 17:12:03 +0200 [thread overview]
Message-ID: <20150503151203.GY12076@piout.net> (raw)
In-Reply-To: <1430143192-20667-1-git-send-email-jbe@pengutronix.de>
Hi,
On 27/04/2015 at 15:59:46 +0200, Juergen Borleis wrote :
> The built-in RTC unit on some i.MX SoCs isn't an RTC only. It is also a tamper
> monitor unit which can keep some (secret) keys. When it does its tamper
> detection job and a security violation is detected, the whole DryICE unit
> including the real-time counter locks completely. In this state the whole unit
> is completely useless. The only way to bring it out of this locked state is a
> power cylce with a POR (most of the case) or additionally a battery power
> cycle which includes the loss of the secret keys.
> At the next boot time some flags signals the security violation and a specific
> register access sequence must be done to finaly bring this unit into life
> again. Until this is done, there is no way to use it again as an RTC.
>
> But also without any enabled tamper detection sometimes this unit tends to
> lock. And in this case the same steps must be done to bring it into life
> again.
>
> The current implementation of the DryIce driver isn't able to unlock the
> device successfully in the case it is locked somehow. Only a full power cycle
> including *battery power* can help in this case.
>
> The attached change set adds the required routines to be able to unlock the
> DryIce unit in the case the driver detects a locked unit. This includes
> unlocking it if it is locked by accident or malfunction and not by a real
> security violation.
>
> The last patch of this series is for reference only and should not be part
> of the kernel. It just adds some code to force a locked DryIce unit to check
> if the new routines are able to unlock it again. This code was required
> because I had no hardware which really uses the tamper detection features of
> this unit.
>
> This is the 2nd version of the patch series. Hopefully I addressed all comments
> from Alexandre.
>
> In this version I added a new patch which replaces all __raw* register functions
> as recommended by Alexandre.
>
> Comments are welcome.
>
I've applied 1-5 after fixing a few parenthesis alignments you missed.
I've also reworked the commit subject prefix to the more concise "rtc:
imdi:" and you forgot the commit message in patch 2, you can check it
here:
https://github.com/alexandrebelloni/linux/commit/eff76de33878687dc1877f40ac2cc34794f499e0
Tell me if you have any objection.
BTW, I guess your email address has been recycled as patchwork recognize
it has belonging to Juergen Beisert ;)
--
Alexandre Belloni, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
--
--
You received this message because you are subscribed to "rtc-linux".
Membership options at http://groups.google.com/group/rtc-linux .
Please read http://groups.google.com/group/rtc-linux/web/checklist
before submitting a driver.
---
You received this message because you are subscribed to the Google Groups "rtc-linux" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rtc-linux+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
WARNING: multiple messages have this Message-ID (diff)
From: alexandre.belloni@free-electrons.com (Alexandre Belloni)
To: linux-arm-kernel@lists.infradead.org
Subject: [rtc-linux] [PATCHv2] RTC/i.MX/DryICE: add recovery routines to the driver
Date: Sun, 3 May 2015 17:12:03 +0200 [thread overview]
Message-ID: <20150503151203.GY12076@piout.net> (raw)
In-Reply-To: <1430143192-20667-1-git-send-email-jbe@pengutronix.de>
Hi,
On 27/04/2015 at 15:59:46 +0200, Juergen Borleis wrote :
> The built-in RTC unit on some i.MX SoCs isn't an RTC only. It is also a tamper
> monitor unit which can keep some (secret) keys. When it does its tamper
> detection job and a security violation is detected, the whole DryICE unit
> including the real-time counter locks completely. In this state the whole unit
> is completely useless. The only way to bring it out of this locked state is a
> power cylce with a POR (most of the case) or additionally a battery power
> cycle which includes the loss of the secret keys.
> At the next boot time some flags signals the security violation and a specific
> register access sequence must be done to finaly bring this unit into life
> again. Until this is done, there is no way to use it again as an RTC.
>
> But also without any enabled tamper detection sometimes this unit tends to
> lock. And in this case the same steps must be done to bring it into life
> again.
>
> The current implementation of the DryIce driver isn't able to unlock the
> device successfully in the case it is locked somehow. Only a full power cycle
> including *battery power* can help in this case.
>
> The attached change set adds the required routines to be able to unlock the
> DryIce unit in the case the driver detects a locked unit. This includes
> unlocking it if it is locked by accident or malfunction and not by a real
> security violation.
>
> The last patch of this series is for reference only and should not be part
> of the kernel. It just adds some code to force a locked DryIce unit to check
> if the new routines are able to unlock it again. This code was required
> because I had no hardware which really uses the tamper detection features of
> this unit.
>
> This is the 2nd version of the patch series. Hopefully I addressed all comments
> from Alexandre.
>
> In this version I added a new patch which replaces all __raw* register functions
> as recommended by Alexandre.
>
> Comments are welcome.
>
I've applied 1-5 after fixing a few parenthesis alignments you missed.
I've also reworked the commit subject prefix to the more concise "rtc:
imdi:" and you forgot the commit message in patch 2, you can check it
here:
https://github.com/alexandrebelloni/linux/commit/eff76de33878687dc1877f40ac2cc34794f499e0
Tell me if you have any objection.
BTW, I guess your email address has been recycled as patchwork recognize
it has belonging to Juergen Beisert ;)
--
Alexandre Belloni, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
WARNING: multiple messages have this Message-ID (diff)
From: Alexandre Belloni <alexandre.belloni@free-electrons.com>
To: Juergen Borleis <jbe@pengutronix.de>
Cc: linux-kernel@vger.kernel.org, rtc-linux@googlegroups.com,
kernel@pengutronix.de, Alessandro Zummo <a.zummo@towertech.it>,
linux-arm-kernel@lists.infradead.org
Subject: Re: [rtc-linux] [PATCHv2] RTC/i.MX/DryICE: add recovery routines to the driver
Date: Sun, 3 May 2015 17:12:03 +0200 [thread overview]
Message-ID: <20150503151203.GY12076@piout.net> (raw)
In-Reply-To: <1430143192-20667-1-git-send-email-jbe@pengutronix.de>
Hi,
On 27/04/2015 at 15:59:46 +0200, Juergen Borleis wrote :
> The built-in RTC unit on some i.MX SoCs isn't an RTC only. It is also a tamper
> monitor unit which can keep some (secret) keys. When it does its tamper
> detection job and a security violation is detected, the whole DryICE unit
> including the real-time counter locks completely. In this state the whole unit
> is completely useless. The only way to bring it out of this locked state is a
> power cylce with a POR (most of the case) or additionally a battery power
> cycle which includes the loss of the secret keys.
> At the next boot time some flags signals the security violation and a specific
> register access sequence must be done to finaly bring this unit into life
> again. Until this is done, there is no way to use it again as an RTC.
>
> But also without any enabled tamper detection sometimes this unit tends to
> lock. And in this case the same steps must be done to bring it into life
> again.
>
> The current implementation of the DryIce driver isn't able to unlock the
> device successfully in the case it is locked somehow. Only a full power cycle
> including *battery power* can help in this case.
>
> The attached change set adds the required routines to be able to unlock the
> DryIce unit in the case the driver detects a locked unit. This includes
> unlocking it if it is locked by accident or malfunction and not by a real
> security violation.
>
> The last patch of this series is for reference only and should not be part
> of the kernel. It just adds some code to force a locked DryIce unit to check
> if the new routines are able to unlock it again. This code was required
> because I had no hardware which really uses the tamper detection features of
> this unit.
>
> This is the 2nd version of the patch series. Hopefully I addressed all comments
> from Alexandre.
>
> In this version I added a new patch which replaces all __raw* register functions
> as recommended by Alexandre.
>
> Comments are welcome.
>
I've applied 1-5 after fixing a few parenthesis alignments you missed.
I've also reworked the commit subject prefix to the more concise "rtc:
imdi:" and you forgot the commit message in patch 2, you can check it
here:
https://github.com/alexandrebelloni/linux/commit/eff76de33878687dc1877f40ac2cc34794f499e0
Tell me if you have any objection.
BTW, I guess your email address has been recycled as patchwork recognize
it has belonging to Juergen Beisert ;)
--
Alexandre Belloni, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
next prev parent reply other threads:[~2015-05-03 15:12 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-04-27 13:59 [rtc-linux] [PATCHv2] RTC/i.MX/DryICE: add recovery routines to the driver Juergen Borleis
2015-04-27 13:59 ` Juergen Borleis
2015-04-27 13:59 ` Juergen Borleis
2015-04-27 13:59 ` [rtc-linux] [PATCH 1/6] RTC/i.MX/DryIce: avoid the __raw* register access functions Juergen Borleis
2015-04-27 13:59 ` Juergen Borleis
2015-04-27 13:59 ` Juergen Borleis
2015-04-27 13:59 ` [rtc-linux] [PATCH 2/6] RTC/i.MX/DryIce: add some background info about the states the machine can be in Juergen Borleis
2015-04-27 13:59 ` Juergen Borleis
2015-04-27 13:59 ` Juergen Borleis
2015-04-27 13:59 ` [rtc-linux] [PATCH 3/6] RTC/i.MX/DryIce: add the unit recovery code Juergen Borleis
2015-04-27 13:59 ` Juergen Borleis
2015-04-27 13:59 ` Juergen Borleis
2015-04-27 13:59 ` [rtc-linux] [PATCH 4/6] RTC/i.MX/DryIce: monitor a security violation at runtime Juergen Borleis
2015-04-27 13:59 ` Juergen Borleis
2015-04-27 13:59 ` Juergen Borleis
2015-04-27 13:59 ` [rtc-linux] [PATCH 5/6] RTC/i.MX/DryIce: when locked, do not fail silently Juergen Borleis
2015-04-27 13:59 ` Juergen Borleis
2015-04-27 13:59 ` Juergen Borleis
2015-04-27 13:59 ` [rtc-linux] [PATCH 6/6] RTC/i.MX/DryIce: prepare to force a security violation Juergen Borleis
2015-04-27 13:59 ` Juergen Borleis
2015-04-27 13:59 ` Juergen Borleis
2015-05-03 15:12 ` Alexandre Belloni [this message]
2015-05-03 15:12 ` [rtc-linux] [PATCHv2] RTC/i.MX/DryICE: add recovery routines to the driver Alexandre Belloni
2015-05-03 15:12 ` Alexandre Belloni
2015-05-03 15:13 ` Marc Kleine-Budde
2015-05-03 15:13 ` Marc Kleine-Budde
2015-05-03 15:13 ` Marc Kleine-Budde
2015-05-03 15:38 ` Alexandre Belloni
2015-05-03 15:38 ` Alexandre Belloni
2015-05-03 15:38 ` Alexandre Belloni
2015-05-04 10:12 ` Jürgen Borleis
2015-05-04 10:12 ` Jürgen Borleis
2015-05-04 10:12 ` Jürgen Borleis
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20150503151203.GY12076@piout.net \
--to=alexandre.belloni@free-electrons.com \
--cc=a.zummo@towertech.it \
--cc=jbe@pengutronix.de \
--cc=kernel@pengutronix.de \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=rtc-linux@googlegroups.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.