суббота, 29 декабря 2007 г.

Cryptoloop in action...

Что касается LPC2468 (ранее упоминавшегося ARM), то мне удалось отыскать hsc0 патч для ядра 2.6.11.8, что позволило отделить зерна от плевел... То есть отделить изменения касающиеся непосредствено плат LPC от изменений hsc0. Теперь я могу наверное с минимумом напильника наложить архитектуру LPC на более свежее ядро... Но это будет уже в следующем году.

А пока вожусь с шифрованием. Реализовал шифрование по ГОСТ 28147-89 для ядра, там оказалось все достаточно грамотно сделано в этом плане. Режимы работы блочных шифров (правда только CBC и ECB) ядро реализует универсально. От модуля шифрования лишь требуется предоставить две функции по шифрованию и расшифрованию блока. Мне даже удалось без проблем заставить работать со всем этим cryptoloop девайс. Шифрует эта железяка конечно очень медленно... ни один алгоритм не разогнался до 100kib/s, будем искать железку помощнее (пока положили глаз на Intel PXA 806Mhz).

Но не смотря на все трудности основной режим проекта - проходное шифрование флешек уже работает. То есть флешка втыкается к LPC2468 в хостовый разъем, а сама LPC2468 втыкается в комп как девайс. И комп видит флешку, как живую (только медленную), при этом если флешку просто воткнуть в комп, то видно, что над ней кто-то жестоко поиздевался, сплошной urandom.

Не знаю как они собираются сделать проходное шифрование IDE, SATA. Но задачка будет интересная.

Что первичнее - cтраницы или сегменты?

Ну лаконичность .S длилась недолго... Сейчас в нем начинает прибавляться функций, переходники для исключений, большинство реализуется через единственный макрос. Этот макрос подойдет так же для переходников прерываний, но не подойдет для сервисов. С ними вообще сложнее, для каждого системного вызова понадобиться свой переходник.

И еще никак не удается исбавится от зависимостей. В переходниках необходимо явно использовать селектор данных ядра, но поскольку сишный дефайн там не доступен - приходится мучаться. Либо определить константу в .S (она превратиться в метку sic! да и одна константа описанная дважды - плохо), либо писать явное значение (хардкод еще хуже чем сдублированая константа), или можно заложиться на взаимозависимость cs и селектора кода данных (ds = cs + 8) (не слишком ли хитро все запутано?). Наиболее предпочтительным выглядит первый вариант, если бы он не превращался в метку, а так второй вариант с комментарием наверное не слишком плохо (пока один раз, но одним разом не обойдется, придется дефайнить).

В этом ядре я пошел на небольшую хитрость... Архитектура IA32 устроена так, что сегментная защита реализуется на уровне линейной памяти (то есть страничное преобразование - это более низменный механизм). Это, по логике вещей, требует инициализировать сперва страничное преобразование, а уж потом включать сегменты и таблицы прерываний. Но таблица прерываний, а в частности исключения, весьма полезная штука. Чем раньше они будут включены, тем лучше. Поэтому я сперва проинициализировал GDT и IDT. Но поскольку адреса таблиц при переходе в страничный режим не изменятся, то и значения это не имеет.

Это в старое ядро я мог по началу мапить куда угодно... Это было конечно очень круто, но по большому счету бесполезно. Гораздо проще оказалось мапить ядро по тем же адресам, по которым оно загружено, что и было сделано еще в прошлой версии ядра. Но порядок инициализации страницы, сегменты сохранился... А теперь, когда я исходно не собираюсь менять адреса, то могу позволить себе такие вот маленькие хитрости.

пятница, 21 декабря 2007 г.

GNU as

Почему-то последнее время у меня сформировалось ошибочное мнение, что препроцессор as аналогичен сишному, что позволяет пользоваться одними заголовками на всех, и вообще очень удобно... Но как же я ошибался...

До сих пор я не особо писал на as. Так, инлайны иногда... но вот в последнем ядре решил переписать минимальную ассемблерную часть на as, ибо она настолько минимальна, что нет смысла ради нее держать еще один дополнительный инструмент вроде nasm/yasm.

Но как выяснилось as препроцессор нисколько не совместим с си. А применение сишного препроцессора к .s файлам может привести к загадочным результатам... Например ключевое слово .arch i386 после си препроцессинга превращается в... .arch 1 :(. А константа, описанная в ассемблерной нотации автоматически становится абсолютной меткой. Интель синтакс вообще не понятно как использовать.

Но есть и положительные моменты... Например все неописанные имена автоматически становятся внешними.

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

понедельник, 17 декабря 2007 г.

Контроль версий с svk...

Не знаю, кто как, но я без контроля версий вообще не могу.

Можно много спорить о том, какие из систем контроля версий лучше.
Но я последнее время пользуюсь SVK. Эта замечательная распределенная система контроля умеет зеркалировать cvs, subversion, perforce... Но даже если сервер зеркалируемой системы контроля недоступен, это не мешает вносить изменения в локальный репозиторий.

Я бы предпочел monotone, но никто из хостеров проектов его пока не поддерживает (хотя может быть уже поддерживает? когда я последний раз этим интересовался?).

Но речь не о том... Недавно, с тех пор, как занялся с упоминаемым ранее армом) у меня возникла необходимость ковыряться в ядре, или того хуже - в uClinux... И вот тут то SVK меня подвел... чтобы загрузить в него проект такого размера (add, commit) нужно несколько часов (если не дней)... Хотя с незначительными изменениями в больших проектах он справляется без особых тормозов.

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

PS: К тому же всеравно, по работе может потребоваться сервер с системой контроля, чего svk не умеет в принципе - он по большей части frontend...

четверг, 13 декабря 2007 г.

Производители железа не умеют писать софт?

Бытует мнение... и думаю это действительно так. Щас докажу. :)

Работаю, как уже писал, с одной ARM'овой железякой от EmbeddedArtists. Ну начать наверное стоиит с того, что они положили в коробку с железякой...

В корорбке лежит CD, на котором записан exe файл, который представляет из себя 7z архив...

В архиве лежит образ vmware c устаановленным дебианом, в домашнем каталоге пользователя по умолчанию развернуты исходники uClinux, версии 20051014, уже пропатченные и настроенные на сборку. Справедлливости ради отмечу, что там все нормально собирается.

На сайте можно скачать патч, который, почему-то, не хочет накладываться на вышеозначенную версию uClinux. И который, помимо существенных изменений, касающейся данной борды, или хотя бы всех бордов данного производителя, содержит еще множество изменений в других подсистемах (преедпололжительно hsc патч и coldfire патч).

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

В приннципе я ссогласен с тем, что готовая система для vmware - это оправданный шаг, ибоо сборка на других системах весьма не тривиальна. О чем щас тоже расскажу...

Но начатть стоит с того, что в крросскомпиляциях а уж тем более в ARM я не силен. Но и от своей любимой Gentoo отказываться не намерен. Берем crossdev и начинаем делать свои собственные toolchain. uclilbc почему-то вообщее не хочет собираться, может быть не любит ядро 2.6.23, инклюды от которого система ему подсовывает? arm-elf вполне успешно собрался (binutils, gcc-3, newlib), но с ним не захотел собираться busybox, который сказал примерно следующее:
/usr/libexec/gcc/arm-elf/ld: ERROR: /usr/lib/gcc/arm-elf/3.4.6/libgcc.a(_muldi3.o) uses hardware FP, whereas busybox uses software FP
Не совсем понимаю чем ему не нравится hardware FP. Ядро ведь должно его эмулирировать (поддержка включена), или на ARM'ах это не прокатывает?

Ладно, arm-softfloat-elf собрал все, да только очередной затык... все модули в системе получились elf, в то время, как ядро без MMU не может поддерживать ELF. :(

Начал разбираться а почему они собственно не Flat? дык очень просто. Для того, чтобы они стали flat, в binutils необходим дополнительный пакет - elf2flt, который через use флаги не активизируется, и на зеркалах нигде не лежит. Пришлось перековырять ebuild, благо кроссчейны лежат в оверлее... и наконец таки я собрал то, что они предоставили по умолчанию...
## Starting application at 0xA0008000 ...
Linux version 2.6.11.8-hsc0 (dron@mdf2007) (gcc version 3.4.6 (Gentoo 3.4.6-r2 p1.5, ssp-3.4.6-1.0, pie-8.7.10)) #5 Thu Dec 13 17:14:08 MSK 2007
CPU: Philips-lpc24xx [24000000] (ARMv3)
Machine: LPC24xx, NXP
...
init: Booting to single user mode
#
Кто-то скажет, что стоило ли столько мучится, тем более что в виртуальной машине все собирается... но мне в любом случае требовалось наладить свою сборку, мне в дальнейшем придется это менять, возможно дописывать модули.