Forum: HF, Funk und Felder Neue nRF52-Revision erzwingt Updates der Nordic-Toolchain


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
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/

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.