AlexandrY, aaarrr - спасибо
Дали пищу для размышлений... Я вот думал действительно если брать проц с большой флэшкой то туда можно запихнуть расшифровывающий загрузчик из внешней флэши + очень важную часть программы хранить только во внутренней флэшке... Оказывается, если она будет сделана внешней в самом корпусе чипа то её смогут отсоединить и считать... Жить действительно страшно

неисповедимы пути господни...
вот уже и топик про мост usb-ethernet перерос в прикладную хардварную криптографию

Вообще-то исходя из даташита там флеш-память встроенная, на общем кристалле. Примерно как в SAM7. И лок-биты присутствуют.

Могу предложить следующий вариант - конечно, упадет производительность (может и довольно сильно упасть), но ломать будет тяжелее.

1. Необходим проц с MMU (т.е. видимо 9й арм)
2. Внутреннее ОЗУ (ну пусть оно будет 32К) разбиваем на минимальные страницы (по 4К, кажется), значит имеем всего 8 страниц.
3. Отображаем при помощи MMU 8 текущих наиболее часто используемых страниц, из которых выполняется код (данные пусть лежат во внешнем озу, фиг с ними). При обращении к неотображенной странице выбрасываем самую старую страницу и на ее место из флеша достаем необходимую страницу кода (пока тут классическая виртуальная память), но только во флеше храним все в зашифрованном виде. Посему, вместо копирования применяем расшифровку.

У Freescale i.MX есть интересная фишка - High-assurance boot. Почитайте, если кому надо супер защиту.

Да, это интересная мысль, что самый важный код _никогда_ не будет вылезать во внешнюю SDRAM... Но вот вопрос: и как же собственно реализовать такую схему при условии работы ОС Linux? Интересуют именно практические шаги и руководства по претворению мечты в суровую реальность...

Забудьте. Станет клином такая конструкция. Там слишком много кода исполняется при работе. Так что у Вас только один вариант - написать весь софт самому.

Кстати, о безопасности - стек тоже надо иметь во внутреннем озу, иначе легко подламывается патчем на ходу содержимого адресов возврата во внешнем озу и переход на процедуру эксгумации кода из внутреннего флеша, ну а дальше - дизассемблер и все радуются...

Вообщем, создать достаточно защищенную конструкцию с большим внешним флешем программ можно, но это сопряжено с изрядными трудностями.

Ну и конечно, во внешнем озу не должно быть никаких указателей на функции, все данные должны проверяться на валидность и т.д., потому как хацкер может попробовать подломать софт заменой исходных данных в озу (куда доступ наиболее прост). Вообщем, надо аккуратно подходить к вопросу.
И, главное, за 5 минут это не пишется (долгая разработка) и нужен грамотный кодер (и следовательно, высокооплачиваемый). Вы уверены что произведение зарплаты кодера на время разработки будет ниже, чем возможный убыток от взлома девайса?



Какой либо код не должен выполняться из внешнего ОЗУ, иначе - это путь к подлому софта.

Кстати, если вдруг надумаете реализовывать такую схему, не забудьте, что обязательно надо иметь контрольную сумму страниц во флеше, причем шифровать ее вместе со страницей, иначе возможен взлом банальным методом научного тыка - подбором последнего блока шифрования в странице флеша для получения управления в озу - и тогда капец

Кстати, эти теоретизирования не на пустом месте. WinCE умеет хранить во флеше пакованые странички и подкачивать их в озу на лету. Правда, там это сделано для уменьшения объемов требуемой флеши. Но в принципе, от замены zlib на des ничего особо не поменяется