Linux-Bulgaria.ORG
навигация

 

начало

пощенски списък

архив на групата

семинари ...

документи

как да ...

 

 

Предишно писмо Следващо писмо Предишно по тема Следващо по тема По Дата По тема (thread)

Re: [Lug-bg] LUG-BG 2019


  • Subject: Re: [Lug-bg] LUG-BG 2019
  • From: "Tsvetan Usunov, OLIMEX Ltd" <usunov@xxxxxxxxxx>
  • Date: Tue, 26 Feb 2019 13:42:34 +0200

Здравейте,

Предлагам да направим дискусия на тема:

Как бих направил една ARM линукс система temper-proof
-----------------------------------------------------

Темата е породена от съвсем реален проблем

Произвеждаме малки Linux компютри които хора ползват за най-различни приложение, повечето от които са индустриални решения за управления на машини, POS системи и т.н.

За някои приложения трябва кодът, който е записан да не може да се променя от външни лица без оторизация.

т.е. правите някаква машина която се управлява с компютъра и никой да не може после да сложи една флашка и да смени софтуера без това да е оторизирано.

Всеки ARM процесор има първоначален BROM сложен в ROM памет който инициализира RAM, периферии и изпълнява последователност в търсене от къде да продължи BOOT-a.

ARM има TrustZone и този BROM се изпълнява в такъв режим, проблема е че при всички малки АРМ компютърчета производителите не са мислили изобщо за TrustZone когато са писали и BROM ще предаде контрола на първото устройство което види че има валиден изпълним код, без изобщо да се изолира.

Ако бе направено както трябваше този BOOT имидж трбяваше да е криптиран с частен ключ и да се изпълнява само ако е подписан от ключа който е записан в OTP паметта на процесора. Такава памет има но BROM изобщо не я търси. Няма и никакви ресурси за това как работи TrustZone на Allwinner SOC само разни хора са хаквали от време на време по нещо си.

Съответно и secure boot имиджи не могат да се пуснат директно.

Тук е описан BROM http://linux-sunxi.org/BROM

В зависимост от външни пинове може да се конфигурира от къде да търси boot, обикновено това е:
   if boot pin set -> USB
else try SD-card if fail -> NAND if fail -> eMMC if fail -> SPI if fail -> USB

С най-голям приоритет са USB и SD-карта 0, за да може всяка платка да се спаси ако вътрешните флаш (NAND/eMMC/SPI) памети се компрометират или имат повреден имидж да може да се презапише.

По принцип най-често се ползва вътрешна eMMC памет защото има голям обем (по-голям от SPI) и е по надеждна от NAND.

Ако темата ви е интересна, може да помислим заедно, какво би могло да се направи, включитено ако трябва да се добавят и допълнителни хардуери като външни крипточипове, да се махат периферии като USB SD-карти и т.н. имаме свобода при хардуера да се модифицира за да се получи накрая надеждна temper proof система.

Преди две години на OpenFest имаше подобна лекция:

https://www.openfest.org/2016/bg/programa/#lecture-203

https://www.youtube.com/watch?v=cyHGN72VMSc&list=PLzUxAJX9n5voqruxaw0gevv5C5ZoGLAq1&index=35

Отблежете че основното предназначение на TrustZone не е само trusted secure boot. Чрез TrustZone се имплементира виртуализация на embedded trusted изчислителна платформа, която споделя CPU и паметта с OS но работи напълно изолирано. Например в TrustZone може да имате гарантирано сигурна работа със запазена чувствителна информация, крипто ключове и ресурси, които няма да са достъпни, дори ако user OS е напълно компрометирана с root достъп до всички ресурси, в момента който някой от TrustZone ресурсите се опита да се достъпне отвън се генерира exeption и контрола се поема от TrustZone. За да има обаче истински работеща TrustZone трябва да има secure boot, който да не може лесно да се компрометира иначе няма гаранция за сигурно опазване на TrustZone ресурсите.

Ще ми е интересно да стане дискусия по темата., сигурен съм че ще има хора с много повече опит които да споделят какво и как правят.


поздрави
Цветан

On 2/25/19 7:25 PM, Marian Marinov wrote:
A някой дали би искал да направи лекция на на тази дата?

On 2/17/19 3:26 PM, Marian Marinov wrote:
Здравейте,

искате ли да направим срещата тази година на 06.Април в Пловдив?

Поздрави,
Мариян


_______________________________________________
Lug-bg mailing list
Lug-bg@xxxxxxxxxxxxxxxxxx
http://linux-bulgaria.org/mailman/listinfo/lug-bg




_______________________________________________
Lug-bg mailing list
Lug-bg@xxxxxxxxxxxxxxxxxx
http://linux-bulgaria.org/mailman/listinfo/lug-bg

_______________________________________________
Lug-bg mailing list
Lug-bg@xxxxxxxxxxxxxxxxxx
http://linux-bulgaria.org/mailman/listinfo/lug-bg



 

наши приятели

 

линукс за българи
http://linux-bg.org

FSA-BG
http://fsa-bg.org

OpenFest
http://openfest.org

FreeBSD BG
http://bg-freebsd.org

KDE-BG
http://kde.fsa-bg.org/

Gnome-BG
http://gnome.cult.bg/

проект OpenFMI
http://openfmi.net

NetField Forum
http://netField.ludost.net/forum/

 

 

Linux-Bulgaria.ORG

Mailing list messages are © Copyright their authors.