News Neue nRF52-Revision erzwingt Updates der Nordic-Toolchain


von Tam H. (Firma: Tamoggemon Holding k.s.) (tamhanna)


Angehängte Dateien:

Lesenswert?

Nutzer der von Nordic Semiconductor entwickelten nRF52-Bluetooth-SOC müssen mit Umstellungen rechnen. Eine neue Hardware-Revision erzwingt - unbedingt erforderliche - Aktualisierungen der Entwicklungswerkzeuge und Binärimages.

Worum geht es hier?

Wer ein Funkmodul mit Mikrocontroller sucht, denkt normalerweise instinktiv an Espressif. Das ist nicht unbedingt richtig - die nRF52-Serie von Nordic mag zwar keinen WLAN-Transmitter haben, hat aber geringeren Energieverbrauch und mehr Zertifikationen. Am 12. Juni 2020 hat Nordic – siehe IN-133 unter https://infocenter.nordicsemi.com/pdf/in_133_v1.0.pdf -allerdings eine Schwachstelle in den Controllern gefunden, die den Zugriff auf an sich schreibgeschützte Chips ermöglicht:

1
Failure of the APPROTECT configuration and debug port connectivity and function implies access to all memory on a device. A
2
device that programmatically configured APPROTECT can have that configuration circumvented and program memory containing
3
program instructions can be read out of the device. It is also possible to write to memory.

Behebung durch Firmware unmöglich =Y neue Hardware erforderlich

In der ursprünglichen Ankündigung der Schwachstelle fand sich folgende, wenig Erhellung versprechende Passage:

1
Mitigations:
2
3
Preventing physical access to the device, or detecting and responding to product enclosure breach, are mitigations for fault
4
injection techniques.

Zur Lösung des Problems musste man im Hause Nordic Semiconductor Kontakt neue Revisionen des Chips nachschieben. Dabei sind sowohl nRF52832 als auch nRF52833 und nRF52840 betroffen - die Abbildung zeigt die „neuen“ Revisionen.

Verpflichtendes MDK-Update!

Mit dem „Release“ der neuen Revisionen der Hardware geht ein verpflichtendes Update der als MDK bezeichneten Entwicklungskomponente einher. In der Ankündigung warnt Nordic nach folgendem Schema davor, dass das Verwenden eines mit einer „älteren“ Version kompilierten Binärimages – immer - zur Deaktivierung des Debugger-Ports bei aktuellen Revisionen führt:

1
If one of the mentioned new device revisions is programmed with software compiled with a version of the MDK prior to release 8.36.0, the debug port will be locked. It is strongly recommended upgrading to the latest MDK (at least version 8.40.2 or later)

Schon aus diesem Grund ist eine Aktualisierung unbedingt erforderlich. Im Laufe der nächsten Zeit werden die „alten“ Revisionen nämlich vom Markt verschwinden - bieten sie derzeit nRF-basierte Produkte an, so besteht nach Ansicht des Autors akuter Handlungsbedarf.

Aktualisierungen der weiteren Entwicklungssysteme

Die Anpassung des als MDK bezeichneten Header-Pakets “schlägt“ in den Rest des Nordic Semiconductor-Ökosystems durch. Die als nRF5 SDK bezeichnete Legacy-Entwicklungsumgebung wurde nach folgendem Schema aktualisiert:

1
Highlights:
2
 
3
- Added support for the new versions of the nRF52 devices:
4
   - nRF52820 revision 3
5
   - nRF52832 revision 3
6
   - nRF52833 revision 2
7
   - nRF52840 revision 3
8
   (Note: Programming these requires nrfjprog v10.13 or newer.)
9
- Updated nrf_oberon to v3.0.8.
10
- Updated Mbed TLS to v2.16.10.

Auch für die „aktuelle“ Version nRF Connect for Desktop gibt es ein Update, das sie aufgrund des weiter oben erwähnten Problems mit MDK unbedingt einspielen sollten.

Weitere Informationen

Change Log für nRF5 SDK – nach unten scrollen, um IDE-spezifische Informationen zu erhalten => https://infocenter.nordicsemi.com/index.jsp?topic=%2Fsdk_nrf5_v17.1.0%2Findex.html


: Bearbeitet durch NewsPoster
von yeet (Gast)


Lesenswert?

Hier wird auch gezeigt, wie einfach man "geschützte" nRF's auslesen 
kann.
https://www.youtube.com/watch?v=tMPD0kBG_So

von nordic (Gast)


Lesenswert?

Hallo zusammen,

im Endeffekt muss nicht zwingend ein SDK Upgrade durchgeführt werden, es 
reicht in dem eigenen Code folgendes zu berücksichtigen:

https://infocenter.nordicsemi.com/index.jsp?topic=%2Ferrata_nRF52832_Rev2%2FERR%2FnRF52832%2FRev2%2Flatest%2Ferr_832_new.html

Viele Grüße

von Rick (Gast)


Lesenswert?

Lassen sich mit den Dingern einigermaßen komfortabel (per 
PlatformIO/Arduino Framework) Thread-Mesh-Nodes entwickeln?

Das wäre vielleicht was für mein Häusle, wo derzeit noch alles per 
ESP32/WiFi läuft...

von GCWCID (Gast)


Lesenswert?

>Am 12. Juni 2020 hat Nordic – siehe IN-133 unter 
https://infocenter.nordicsemi.com
>/pdf/in_133_v1.0.pdf -allerdings eine Schwachstelle in den Controllern gefunden, 
die den Zugriff
>auf an sich schreibgeschützte Chips ermöglicht:

Das liest sich so als ob Nordic den Fehler entdeckt hat!?

Siehe auch:
https://limitedresults.com/2020/06/nrf52-debug-resurrection-approtect-bypass/

Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.