На самом деле MIK32 ни чуть не более геморройней чем изделия серии ATMega. Есть своя ниша. Миросхема производится полностью в России. Очень простая и понятная архитектура. Программировать его приятно и легко если всё пишешь сам, а не занимаешься борьбой с чужими глюками и недоработками типа Arduino IDE. Некто Vladimir Zaytsev написал к MIK32 набор однофайловых (.h) HAL библиотек - очень удобно, рекомендую.
Существует альтернативный загрузчик ex_loader_2 от fabmicro.
Это не наш код, а какого-то парня по имени Vladimir Zaytsev. Я всего лишь выложил его на Gitflic. Но рад, что кому-то это могло помочь. :-)
Загрузка в NOR flash (SPIFI) через OpenOCD действительно жутко медленная и это сильно достает когда прошивка становится большой. Хочу попробовать через OpenFPGALoader, эта утилита может писать/читать QSPI Flash через JTAG.
Простите, а кто будет проверять те миллиарды строк кода которые нагенерировала машина ? Или уважаемый Нолан полагает, что в сгенерированном его болванчиком коде совершенно нет ошибок, неприятных артефактов и прочих дыр в безопасности ? Чтож, пожелаем успехов его клиентам.
А Flash память кокого типа ? SLC, TLC или QLC ? SLC продержится лет 8-10. QLC - года 3.
Основная проблема с храненим данных на NAND Flash состоит в том, она очень сильно подверженна влиянию поверхностного статического заряда и ESD защита тут бессильна. Храните ваши флэшки в токопроводящей заземленной коробке. :-)
Я правильно понимаю, что автор сам, т.е. своим аллокатором, создал себе проблему и мужественно её преодолел ? :-)
Я попробовал сделать что-то подобное на FreeBSD: две заглушки для malloc(), одна на Си, другая на C++. Вот как это выглядит у меня:
Malloc wrapper in C on FreeBSD
rz@butterfly:~/code_snippets/C/Preload % make clean testc
rm -rf libpreload.o libpreloadc.so libpreloadcpp.so
=== Building malloc wrapper in C
cc -c -fPIC -o libpreload.o libpreload.c
cc -shared -o libpreloadc.so libpreload.o
=== Testing malloc wrapper written in C
FreeBSD butterfly 13.5-RELEASE-p9 FreeBSD 13.5-RELEASE-p9 GENERIC amd64
LD_PRELOAD=./libpreloadc.so /bin/ls -al
MALLOC: 128
MALLOC: 377
ls: fts_open: MALLOC: 2
Invalid argument
*** Error code 1
Stop.
make: stopped in /usr/home/rz/code_snippets/C/Preload
Malloc wrapper in C++ on FreeBSD
rz@butterfly:~/code_snippets/C/Preload % make clean testcpp
rm -rf libpreload.o libpreloadc.so libpreloadcpp.so
=== Building malloc wrapper in C++
c++ -c -fPIC -o libpreload.o libpreload.cpp
c++ -shared -o libpreloadcpp.so libpreload.o
=== Testing malloc wrapper written in C++
FreeBSD butterfly 13.5-RELEASE-p9 FreeBSD 13.5-RELEASE-p9 GENERIC amd64
LD_PRELOAD=./libpreloadcpp.so /bin/ls -al
MALLOC: 4096
Class Test has been constructed
MALLOC: 128
MALLOC: 377
ls: fts_open: MALLOC: 2
Invalid argument
*** Error code 1
Stop.
make: stopped in /usr/home/rz/code_snippets/C/Preload
Как видно, если не использовать stdlib++, то первые аллокации совсем крохотные - столько, солько требуется утилите /bin/ls. Если использовать библиотку libstdc++, то её инициализация запрашивает 4096 байт (ровно одну страничку).
На Linux-е этот же тест действительно первым запросом показывает 72704 байт. Еще один плюс в карму FreeBSD. ;-)
Забавно, но на Linux-е результат malloc() не проверяется на NULL не внутри инициализации stdlib++, не в коде /bin/ls. Моя обертка выдает NULL, а программа продолжает работу как будь-то всё в порядке и снимается с ипольнения только системой когда уже совсем того:
Malloc wrapper in C++ on Linux
rz@devbox:~/Preload$ make clean testcpp
rm -rf libpreload.o libpreloadc.so libpreloadcpp.so
=== Building malloc wrapper in C++
c++ -c -fPIC -o libpreload.o libpreload.cpp
c++ -shared -o libpreloadcpp.so libpreload.o
=== Testing malloc wrapper written in C++
Linux devbox 4.15.0-30-generic #32-Ubuntu SMP Thu Jul 26 17:42:43 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux
LD_PRELOAD=./libpreloadcpp.so /bin/ls -al
MALLOC: 72704
MALLOC: 552
MALLOC: 552
MALLOC: 1024
Class Test has been constructed
MALLOC: 5
MALLOC: 552
MALLOC: 5
MALLOC: 34
MALLOC: 10
MALLOC: 56
/bin/ls: memory exhausted
Makefile:27: recipe for target 'testcpp' failed
make: *** [testcpp] Error 2
Никаких. Зато это создает массу проблем с ЭМ совместимостью, трассbровкой диф пар и других высокоскоростных цепей. Используйте сплошные полигоны, всегда подключайте их к цепям питания (GND или VDD).
Про атаку на драйверы GPU слышу давно, спасибо за освещение этой темы на Хабре. Было бы интересно почитать более подробный разбор этой темы - какие версии ядра Linux подверженны, примеры кода выполнения атаки.
Вообще, если вдуматься, драйверы современных GPU на столько обьемные (и закрытые), что дыр там может быть просто бесконечное число. Ставить любое, не тобой написанное, приложение на смартфон небезопасно априори, защиты нет и быть не может.
Еще один интересный момент - WebGL. Подозреваю, что через этот API любое Web приложение может осуществить аналогичную атаку на GPU. Что слышно на этот счет ?
Да, Вы правы. xterm, kconsole, xfce4-terminal - это всё эмуляторы терминала работающие с последовательной линией, хоть и виртуальной. Сетевой эмулятор терминала это Telnet и SSH клиенты.
На самом деле MIK32 ни чуть не более геморройней чем изделия серии ATMega. Есть своя ниша. Миросхема производится полностью в России. Очень простая и понятная архитектура. Программировать его приятно и легко если всё пишешь сам, а не занимаешься борьбой с чужими глюками и недоработками типа Arduino IDE. Некто Vladimir Zaytsev написал к MIK32 набор однофайловых (.h) HAL библиотек - очень удобно, рекомендую.
Ну, как говорится, с почином!
Это не наш код, а какого-то парня по имени Vladimir Zaytsev. Я всего лишь выложил его на Gitflic. Но рад, что кому-то это могло помочь. :-)
Загрузка в NOR flash (SPIFI) через OpenOCD действительно жутко медленная и это сильно достает когда прошивка становится большой. Хочу попробовать через OpenFPGALoader, эта утилита может писать/читать QSPI Flash через JTAG.
А какой у АО "Микрон" логотип на кристаллах ? Есть примеры ?
Ну что-ж, пожелаем еще больше удачи этим
жертвамсчастливцам автоматизации.del
Миллиард тестов тоже машина напишет ?
Простите, а кто будет проверять те миллиарды строк кода которые нагенерировала машина ? Или уважаемый Нолан полагает, что в сгенерированном его болванчиком коде совершенно нет ошибок, неприятных артефактов и прочих дыр в безопасности ? Чтож, пожелаем успехов его клиентам.
А Flash память кокого типа ? SLC, TLC или QLC ? SLC продержится лет 8-10. QLC - года 3.
Основная проблема с храненим данных на NAND Flash состоит в том, она очень сильно подверженна влиянию поверхностного статического заряда и ESD защита тут бессильна. Храните ваши флэшки в токопроводящей заземленной коробке. :-)
Didn't know that Cray maniches had Unix flavour.
Я правильно понимаю, что автор сам, т.е. своим аллокатором, создал себе проблему и мужественно её преодолел ? :-)
Я попробовал сделать что-то подобное на FreeBSD: две заглушки для malloc(), одна на Си, другая на C++. Вот как это выглядит у меня:
Malloc wrapper in C on FreeBSD
Malloc wrapper in C++ on FreeBSD
Как видно, если не использовать stdlib++, то первые аллокации совсем крохотные - столько, солько требуется утилите /bin/ls. Если использовать библиотку libstdc++, то её инициализация запрашивает 4096 байт (ровно одну страничку).
На Linux-е этот же тест действительно первым запросом показывает 72704 байт. Еще один плюс в карму FreeBSD. ;-)
Забавно, но на Linux-е результат malloc() не проверяется на NULL не внутри инициализации stdlib++, не в коде /bin/ls. Моя обертка выдает NULL, а программа продолжает работу как будь-то всё в порядке и снимается с ипольнения только системой когда уже совсем того:
Malloc wrapper in C++ on Linux
PS: Мой код: https://github.com/pointcheck/code_snippets/tree/master/C/Preload
Вам тут уже и без меня накидали в панамку. Но так, на всякий случай:
Проблемы с ЭМ совместимость, антенный эффект, неожиданные резонансы там где их не ожидают, препятствия для возвратных токов.
Проблемы с согласованием импеданса для высокоскоростных линий.
Проблемы с отводом тепла.
Никаких. Зато это создает массу проблем с ЭМ совместимостью, трассbровкой диф пар и других высокоскоростных цепей. Используйте сплошные полигоны, всегда подключайте их к цепям питания (GND или VDD).
Вы понимаете какую проблему Вы можете создать этими своими "кружочками" неподключенными к GND или VDD ?
Спасибо, друг! Еще китайского товарища майора мне нехватало у себя дома.
Заявку подал.
Всяких "хахаряшек" у меня в хозяйстве - хоть отбавляй, а вот книжки - они вечны. Их можно детям или студентам давать почитать. :)
Следующим шагом автор вспомнит про R1,5 и R2 сигнализацию. Только вот Астериск вряд ли поможет с этим.
Я, пожалуй, возьму книжки. ;)
Про атаку на драйверы GPU слышу давно, спасибо за освещение этой темы на Хабре. Было бы интересно почитать более подробный разбор этой темы - какие версии ядра Linux подверженны, примеры кода выполнения атаки.
Вообще, если вдуматься, драйверы современных GPU на столько обьемные (и закрытые), что дыр там может быть просто бесконечное число. Ставить любое, не тобой написанное, приложение на смартфон небезопасно априори, защиты нет и быть не может.
Еще один интересный момент - WebGL. Подозреваю, что через этот API любое Web приложение может осуществить аналогичную атаку на GPU. Что слышно на этот счет ?
Да, Вы правы. xterm, kconsole, xfce4-terminal - это всё эмуляторы терминала работающие с последовательной линией, хоть и виртуальной. Сетевой эмулятор терминала это Telnet и SSH клиенты.
Вопрос интерфейса с CP/M и её наследниками мы здесь не рассматриваем. ;)