Читать дальше

В мире известно немало паразитов, которые атакуют нервную систему жертвы и заставляют ее подчиняться своим целям. Может ли такой паразит взять под контроль нервную систему человека?

Пожалуй, самый известный пример паразита, способного контролировать нервную систему другого существа — Leucochloridium paradoxum. Этот паразит живет в телах улиток, но для успешного размножения ему нужно быть съеденным птицей. И вот, в определенный момент улитка, как зомби, выползает из укрытия и при этом еще фосфоресцирует, привлекая внимание птиц, которые улитками обычно не питаются. И это далеко не единственный паразит такого рода. Например Toxoplasma gondii, возбудитель токсоплазмоза, может проводить определённые периоды жизни в теле самых разных теплокровных животных, а вот размножаться способен только в кишечнике кошек. Поэтому, если возбудитель попадает в тело мыши или крысы, ему становится выгодно, чтобы животное-хозяин было съедено кошкой. Паразит захватывает контроль над нервной системой животного, в результате чего мыши становятся «бесстрашными» — запах кошки их больше не пугает. Соответственно для них возрастает риск быть съеденными. Важно отметить, что в остальном больные токсоплазмозом мыши ничем не отличаются от здоровых собратьев. За исключением запаха кошки они по-прежнему пугливы.

Как видим, паразиты могут захватывать и успешно использовать нервную систему сравнительно высокоорганизованных животных. Могут ли такие паразиты распространятся в популяциях разумных существ? Если паразит, контролирующий нервную систему, вызывает не очень заметные изменения в поведении хозяина, если действия паразита не ведут к быстрой гибели хозяина (а большинству паразитов быстрая гибель хозяина крайне не выгодна, так что вред, который они наносят хозяину, иногда компенсируется некоторой пользой, в крайних формах такие отношения становятся симбиотическими), то число инфицированных может стать чрезвычайно велико и тогда деятельность паразита будет крайне незаметна. Инфицированных, в силу их многочисленности и незначительности отклонений в поведении признают нормальными. Приведенные выше примеры широко известны потому, что паразит на определенном этапе своего развития заставляет хозяина быть съеденным. Но в принципе паразиту, контролирующему нервную систему хозяина, вовсе не обязательно заставлять хозяина преждевременно умереть. Такое может потребоваться только в том случае, если разные части жизненного цикла паразита протекают в организмах разных животных. Если все стадии жизненного цикла паразита протекают в организме одного животного, все, что требуется паразиту от хозяина – заставить хозяина выполнять некие действия, способствующие распространению паразита. И эта стратегия является более выигрышной с точки зрения паразита, нежели стратегия, подразумевающая преждевременную смерть одного из хозяев.

Если бы я был демиургом и проектировал вирус для контроля нервной системы человека, в техническом задании я перечислили бы следующие обязательные требования:

• Вирус не должен приводить к преждевременной смерти человека. Люди – разумные существа и борются за продление собственной жизни. Вирус, приводящий к преждевременной смерти, скорее всего, обнаружат и постараются уничтожить.
• Вирус не должен вызывать слишком сильных девиаций в поведении человека. Даже мыши, больные токсоплазмозом, не могут быть слишком девиантными. Люди – общественные существа со сложной социальной структурой. Девиантов они изолируют, а иногда даже уничтожают, следовательно и вирус, вызывающий сильные отклонения от норм поведения, никогда не сможет стать массовым.
• Для своего распространения вирус должен заставлять человека совершать «невинные» действия, которое будут социально приемлемы для самых разных культур. В том числе и действие, необходимое для распространения вируса, не должно выглядеть слишком странным или угрожающим.

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

Устройства, основанные на ARM можно разделить на три группы.

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

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

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

Однако это не значит, что устройства первой ив торой категорий больше не нужны. Попробуйте соорудить микроконтроллер на основе обычного мобильного устройства. Это не так-то просто, не говоря уже о цене подобного решения.
Обширный зоопарк устройств на основе ARM приводит к тому, что про программирование для них становится довольно трудно писать. Точнее говоря, трудно приводить примеры программ, которые будут работать не только на устройствах, которые есть у автора, но и на устройстве, которым располагает читатель.

Труднее всего, конечно, описывать программирование на голом железе, потому что любая ОС создает некую среду, сохраняющую единообразие на всех платформах. Но мы начнем именно с самых простых устройств, которые оказываются самыми сложными в программировании. Даже самая простая программа, предназначенная для работы на голом железе, должна выполнить ряд неочевидных для обычного (привыкшего к программированию под ОС) программиста действий. Чтобы понять механику работы программы на голом железе, давайте вспомним, что делает операционная система с момента загрузки и до момента запуска прикладной программы. Прежде всего, любая ОС подготавливает компьютер к работе: настраивает средства управления различными элементами машины, в том числе, например, устанавливает скорость доступа к шинам и памяти. Важный этап в работе любой ОС – настройка таблицы векторов прерываний.

Когда операционная система загружает прикладную программу, она, помимо прочего, создает различные элементы среды окружения для этой программы, и располагает различные блоки программы в оперативной памяти так, чтобы они могли найти друг друга. Все, что я пишу здесь про работу ОС, представляет собой довольно упрощенную картину. Это тот необходимый минимум, который нужно знать, чтобы понять, как работает программа на голом железе. Одной из задач, которые такая программа должна решить самостоятельно, является заполнение таблицы векторов прерываний. Вот как выглядит таблица векторов прерываний минимальной программы для микроконтроллера ARM (пример позаимствован из замечательного блога ):

 B Reset_Handler /* Reset */
 B . /* Undefined */
B . /* SWI */
B . /* Prefetch Abort */
B . /* Data Abort */
B . /* reserved */
B . /* IRQ */
B . /* FIQ */

Таблица векторов прерываний состоит из команд безусловного перехода (B). Таблица векторов может содержать и другие команды, но смысл их должен быть тот же – переход по некоторому адресу. Команда

В.

(B с точкой) это переход на тот же адрес, по которому расположена инструкция, то есть бесконечный цикл. Таким образом, мы видим, что в приведенной таблице прерываний определен только обработчик прерывания Reset. Прерывание Reset может быть генерировано, например, кнажатием кнопки Reset. В любом случае это единственное прерывание, которое программа обязана  обрабатывать. Нетрудно видеть, что любое другое прерывание, буде фоно возникнет, приведет к зависанию программы. Обработчик прерывания Reset выглядит следующим образом:

Reset_Handler:
 LDR sp, =stack_top
 BL c_entry
 B .

Первая инструкция загружает в регистр SP адрес верхушки стека. Следующая инструкция – это вызов процедуры c_entry, с которой начинается, собственно, работа нашей программы. Фактически вся наша программа умещается в обработчике прерывания Reset. Вам может показаться, что это не самое элегантное решение, но многие серьезные программы для микроконтроллеров делают точно так же.

Далее следует уже знакомая нам «B с точкой». После выхода из функции c_entry программа снова зацикливается (если бы программа работала под управлением операционной системы, она должна была бы передать управление системе, но программе, которая работает сама по себе, после выхода из основной функции просто нечего делать. Коротко говоря, прерывание Reset заставляет систему запустить программу на выполнение. Все вместе это собирается в ассемблерный файл crt.s:

.section INTERRUPT_VECTOR, "x"
.global _Reset
_Reset:
B Reset_Handler /* Reset */
B . /* Undefined */
B . /* SWI */
B . /* Prefetch Abort */
B . /* Data Abort */
B . /* reserved */
B . /* IRQ */
B . /* FIQ */

Reset_Handler:
  LDR sp, =stack_top
  BL c_entry
  B .

Первая строка  ассемблерного файла  сообщает компоновщику, что файл содержит раздел INTERRUPT_VECTOR, который содержит исполнимый код «x». Вторая строчка объявляет глобально видимое имя «_Reset». Оно тоже понадобится компоновщику. Все, что следует дальше, мы уже описали.

Теперь нам нужна собственно функция c_entry. В нашем случае она  будет выглядеть так:

int c_entry()
{
return 0;
}

Эта функция не делает ничего полезного, но именно по этой причине она будет выполняться на любом микроконтроллере (назовем файл, содержащий этот код, test.c).

Дальше нам нужно написать еще один скрипт, с которым прикладные программисты обычно не имеют дела. Речь идет о скрипте компоновщика, который указывает, как скомпоновать программу. Когда программа собирается для операционной системы, компоновщик, рассчитанный на эту ОС, сам знает, что ему делать. Но в случае программирования на голом железе мы должны рассказать ему об этом. Наш скрипт предназначен для компоновщика GNU (ld), так в дальнейшем для сборки программ мы будем пользоваться именно инструментами GNU.

ENTRY(_Reset)
SECTIONS
{
 . = 0x0;
 .text : {
 startup.o (INTERRUPT_VECTOR)
 *(.text)
 }
 .data : { *(.data) }
 .bss : { *(.bss) }
 . = . + 0x1000; /* 4kB of stack memory */
 stack_top = .;
}

Первая строка скрипта компоновки указывает точку входа в программу. Таким образом выполнении нашей программы начнется с перехода на обработчик прерывания Reset, который вызовет функцию c_entry. Дальше мы сообщаем компоновщику, что секция INTERRUPT_VECTOR находится в файле starup.o и должна быть расположена, начиная с адреса 0×0. Затем следует еще описание нескольких секций, которые мы сейчас пропустим. Интересно для нас то, как заполняется переменная stack_top, которую использует процедура инициализации. Вы уже наверное догадались, что точка означает в этом скрипте то же, что и в ассемблерном файле – текущий адрес. Таким образом, выражение

 . = . + 0x1000;

Означает «прибавить к текущему адресу значение 4096». То есть верхушка стека оказывается смещена на 4096 байтов относительно завершающего адреса последней секции программы. Для программ на микроконтроллерах 4096 байтов стека – совсем неплохо (а для нашей конкретной программы даже слишком много).

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

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

Вот и все на сегодня. В заключение ссылки на очень полезную книгу. Она доступна в сети бесплатно (хотя, к сожалению, не переведена на русский):

Miro Samek, Building Bare Metal ARM Systems with GNU – как указывает название, эта книга как раз про то, о чем мы сегодня говорили, хотя изложение в ней начинается сразу с вещей гораздо более сложных.

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

Read more…

An Axiomatic Basis for Computer Programming, C. A. R. HOARE, 1969.

While Mr. Hoare is well known for quite many things, including the QuickSort algorithm, this article is an excellent insight into the logical foundations of computer programming.

Predicate Dispatching: A Unied Theory of Dispatch, Michael Ernst, et al., 1998.

Describes a method for dispatching functions based not on a static set of rules, but instead as the traversal of a decision tree that could be built at compile-time and extended incrementally at runtime.

Cooperating sequential processes, E.W.Dijkstra, 1965

While Dijkctra’s is quite famous for many CS discoveries and sarcastic remarks, this article describes the methods of synchronization which gained much of importance with the growth of multi-threaded programming. The sheer weight of the heady topics assembled in one place is stunning to observe.

Fundamental Concepts in Programming Languages, Christopher Strachey, 1967

L-values, R-values, parameter passing, variable binding, functions as data, parametric polymorphism, ad hoc polymorphism… All these concepts are explained in this classical text with crystal clarity.

On Understanding Types, Data Abstraction, and Polymorphism, Luca Cardelli, Peter Wegner, 1985

An excellent article on the foundations of types theory and OOP.

Time, Clocks, and the Ordering o f Events in a Distributed System, Leslie Lamport, 1978

This paper presents a single-handed definitions of the two branches of study in distributed computing: the reasoning of event ordering in distributed systems and protocols, and the state machine approach to redundancy

Sketchpad: A Man-Machine Graphical Communication System, I. E. Sutheland, 1963

The pioneering work on computer graphics

To be updated…

Страница проекта:  http://symmetrica.net/cuneiform-linux/yagf-ru.html

Страница YAGF на Goole+

Пара видеороликов про YAGF:

Сканирование и распознавание

Исправление наклона страницы и распознавание

Первая часть

Одно из первых действий после установки системы – создание нового пользователя. После создания пользователя с обычными правами вы обнаружите, что он не может выходить в сеть. Вызов любой сетевой программы заканчивается сообщением об отсутствии разрешений. Для того чтобы пользователь получил разрешение на выход в сеть, необходимо создать группу sockets и добавить пользователя в эту группу:

adduser newuser
addgroup --gid 3003 sockets
usermod -G sockets -a newuser

Другой полезной программой, которую следует установить в систему – демон SSH. Для того чтобы запустить сервер sshd необходимо настроить файл /etc/ssh/sshd_config. Вот один из вариантов конфига:

Port 22
Protocol 2
HostKey /etc/ssh/ssh_host_rsa_key
HostKey /etc/ssh/ssh_host_dsa_key
UsePrivilegeSeparation no
KeyRegenerationInterval 3600
ServerKeyBits 768
SyslogFacility AUTH
LogLevel INFO
LoginGraceTime 120
PermitRootLogin yes
StrictModes yes
RSAAuthentication yes
PubkeyAuthentication yes
IgnoreRhosts yes
RhostsRSAAuthentication no
HostbasedAuthentication no
PermitEmptyPasswords yes
ChallengeResponseAuthentication no
X11Forwarding yes
X11DisplayOffset 10
PrintMotd no
PrintLastLog yes
TCPKeepAlive yes
AcceptEnv LANG LC_*
Subsystem sftp /usr/lib/openssh/sftp-server
UsePAM yes

Эта конфигурация разрешает доступ пользователю root по SSH. Если вы опасаетесь за безопасность системы, замените в строке

PermitRootLogin yes

параметр yes на no. Теперь мы можем подключаться к системе на мобильном устройстве с компьютера, обладающего полноценной клавиатурой. Дополнительное удобство SSH – возможность обмениваться файлами с мобильной системой с помощью SFTP.

Работа с графическими приложениями возможна в двух вариантах:

1. Можно подключаться к системе с ПК через SSH и использовать X forwarding.
2. Можно установить сервер tightvnc и подключаться через VNC. Этот вариант хорош тем, что клиент VNC может быть установлен на само мобильное устройство (например, на устройство Android). Впрочем, работать с десктопными графическими программами с устройства, которое рассчитано в основном на ввод не с клавиатуры, не очень удобно.

Итак, что же мы имеем? Мы имеем систему, которая способна запускаться с любого мобильного устройства на базе ARM, где есть Linux с подходящим ядром и хост USB. При этом в нашей системе нам доступно все, что предоставляет в наше распоряжение ядро Linux, в том числе директория /dev/.

Иначе говоря, мы получили неплохой полигон для программирования под ARM Linux и изучения периферии мобильного девайса.

Этот способ установки является на сегодняшний день самым безболезненным для девайса, что хорошо подходит тем, кто хочет по-прежнему пользоваться устройством по назначению, а не только как площадкой для тестирования Linux. При использовании этого способа файлы Linux вообще не будут устанавливаться на устройство с Андроидом. Вместо этого мы установим их на USB-флешку.

Что требуется?

1. Обычный компьютер c Linux Ubuntu (у меня Ubuntu 10.10) или Debian. Можно использовать и другие дистрибутивы Linux, нужно только чтобы в них были установлены утилиты Ubuntu: пакет dpkg и его друзья, и скрипт debootstrap.
2. Собственно устройство с ОС Android (или другой ОС, основанной на Linux), которое умеет работать с флешкой. Я использовал Toshiba AC100 и еще один мобильный девайс, который работает под Linux Angstrom, но ничего специфического для этих устройств не применял, так что советы должны сгодиться и для других девайсов.
3. Если у вас устройство Android или другое устройство, на котором нет доступа к Linux root, необходимо выполнить рутинг устройства и установить на него набор утилит BusyBox. Стараниями хакеров и то, и другое теперь можно сделать из-под самого Андроида, без всяких перепрошивок. Тем не менее, рутование Андроида остается потенциально опасной операцией. Будем радоваться тому, что это единственное серьезное вмешательство в саму ОС Андроид, которое нам понадобится.

Шаг 1, необходимый, если у вас на устройстве не рутованный Андроид.
Рутование Андроида стало уже неприлично простым благодаря программе z4root. Эта программа устанавливается как и любая программа Android. После запуска программы и выполнения ей всех операций достаточно перезагрузить устройства и все готово – ваш Андроид порутан. Более подробные инструкции можно найти на сайтах, посвященных программе z4root. Далее устанавливаем BusyBox. Для этого тоже есть специальная программа – BusyBox for Android. Как и z4root, BusyBox устанавливается из-под Андроида. На моем девайсе программа установки BusyBox сообщила, что утилита установить не удалось, но они, тем не менее, были установлены. Ну и последнее, это установка программы-эмулятора терминала для Android. Без такой программы работать с Линуксом будет трудно и неинтересно.

Шаг 2. Подготовка флешки.
Задача этого этапа – отформатировать флешку в Ext3 и записать на нее файлы базовой установки Ubunu Linux. Допустим, флешка, приговоренная к установке Убунты, опознана системой как /dev/sda1. Тогда сначала ее нужно размонтировать, а затем скомандовать:

mkfs.ext3 –L linux /dev/sda1

Опция -L устанавливает метку диска. Если ваш вариант mkfs.ext3 не поддерживает эту опцию, метку можно установить после выполнения mkfs.ext3 с помощью e2label:

e2label /dev/sda1 linux

Теперь смонтируйте флешку снова (Linux может смонтировать ее автоматически, например, в директорию /media/linux) и запишите на нее файлы Linux. Флешка должна быть смонтирована (перемонтирована) с опциями dev,suid,exec. На всякий случай, команда ручного монтирования выглядит так:

mount -t ext3 -o exec,suid,dev /dev/sda1 /media/linux/

Для создания базовой системы Ubuntu ARM на флешке хорошо подходит утилита debootstrap.
Командуем:

debootstrap --foreign --arch=armel maverick /media/linux

Здесь «maverick» – название дистрибутива Ubuntu. Ключ —foreign указывает на то, что базовая система Linux собирается для другой архитектуры (в данном случае – ARMEL). Информацию об установке различных версий Ubuntu скрипт debootstrap читает из файлов в директории

/usr/share/debootstrap/scripts/

Вы можете посмотреть содержимое этой директории, чтобы узнать, какие версии Ubuntu сконфигурированы для debootstrap. Если такой директории у вас нет, или в ней нет файлов конфигурации maverick или natty, это значит, что у вас установлена старая версия debootstrap, которая не сможет сделать все правильно. Необходимо обновиться.

После того как утилита debootstrap запишет на флешку все необходимые файлы Linux, размонтируйте флешку и и подключите к целевому устройству.

Шаг 3. запуск Linux на целевом устройстве.
Флешка может быть распознана устройством автоматически, а может и не быть. Откройте эмулятор терминала (или подключитесь к терминалу другим способом) и в режиме root найдите устройство, соответствующее флешке, в директории /dev. У меня оно нашлось как /dev/block/sda1. Лучше всего создать для монтирования раздела с Ubuntu Linux специальную директорию. Я перемонтировал файловую систему /system в режиме rw и создал директорию /system/linux, но подойдет и любая другая. Монтируем флешку:

mount –t ext3 /dev/block/sda1 /system/linux

Мы почти у цели. Осталось совсем немного, выполнить последовательность команд, которая подготовит систему в разделе /system/linux к запуску в режиме chroot. Вот эти команды:

export PATH=/bin:/usr/bin:/sbin:/usr/sbin:$PATH
export USER=root
export HOME=/root
export TERM=xterm
busybox mount -o remount,exec,suid /system/linux
cd /system/linux
busybox mount -o bind /proc proc
busybox mount -o bind /sys sys
busybox mount -o bind /dev dev
busybox mount -o bind /dev/pts dev/pts
busybox chroot . bash

Для удобства эти команды можно записать в файл скрипта, например, startlinux.sh.
Выполнив файл startlinux.sh, вы должны увидеть нечто вроде:

I have no name!@localhost#

Это означает, что Ubutu на устройстве ARM запущена (Ура!), но не настроена. Для завершения установки необходимо, уже в Ubuntu, скомандовать:

/debootstrap/debootstrap --second-stage

что и завершит установку. Теперь выходите из Ubutu в «родную систему» устройства с помощью exit и снова запустите файл startlinux.sh. На этот раз приглашение командной строки в Ubuntu выглядит как

root@localhost#

или наподобие. Это значит, что система настроена. Осталось настроить apt-get. Для этого в файл /etc/apt/sources.list добавьте строку

deb http://ports.ubuntu.com/ubuntu-ports/ maverick main

где «maverick», опять же, нужно заменить именем установленной версии Ubuntu. На этом предварительная установка Ubuntu для ARM закончена. Можете приступать к закачке дополнительного софта.
Продолжение следует.

ARM Linux

MOV r0, дескриптор_файла;
MOV r1, адрес_буфера;
MOV r2, длина_буфера;
SWI 0x900004;

В режиме EABI номер вызова передается в регистре r7, а операндом SWI всегда является значение 0×0. Еще одно отличие связано с передачей 64-битных аргументов. В обоих режимах их передают в паре 32-битных регистров, но в старом режиме это просто два следующих не занятых регистра, а в режиме EABI – следующая пара регистров, в которой первый регистр имеет четный номер. Тот же вызов _write() в режиме EABI будет выглядеть так:

MOV r0, дескриптор_файла;
MOV r1, адрес_буфера;
MOV r2, длина_буфера;
MOV r7, #4;
SWI 0x0;

Помимо прочего, между двумя режимами существует одно, не сразу заметное, различие: режим EABI может использовать как в режиме ARM MODE (32-битные инструкции), так и в более компактном THUMB MODE. Старый режим не может использоваться в THUMB MODE просто потому, что число 0×900000 не поместится в 16-битном операнде инструкции SWI режима THUMB.
Ну и напоследок, описания нескольких системных вызовов ARM Linux. Зная общий принцип, остальные описания легко «конвертировать» из описаний аналогичных вызовов для Intel.

#include <stdio.h>
 int main(int argc, char ** argv)
 {
  printf("Hello!\n");
  return 0;
 }

Очевидно, что свой вклад в размер исполнимого файла вносит библиотека glibc, из которой мы берем функцию printf(). Попробуем обойтись без нее:

int main(int argc, char ** argv)
{
	char * s = "Hello!\n";
	__asm__ ("movl $4, %%eax; movl $0, %%ebx; movl $7, %%edx; int $0x80"
	:
	: "c"(s)
	: "%eax", "%ebx", "%edx");
	return 0;
}

Последовательность ассемблерных команд в этом примере выполняет системный вызов syscall_write с аргументами 0 (стандартный поток вывода), s и 7 (длина строки s без конечного 0). Однако после компиляции этого варианта программы мы обнаруживаем, что размер исполнимого файла не изменился. Проблема в том, что библиотека glibc по-прежнему присутствует в нашей программе. Схематически структуру программы Linux можно представить так:

void _start() 
{
// подготовка к вызову main()
int retval = main();
// Вежливое завершение
_exit(retval);
}

Точкой входа в программу является функция _start(), которая готовит программу к вызову main(), а после выхода из этой функции завершает программу системным вызовом exit(). Мы можем сами написать функцию _start:

void _start()
{
	char * s = "Hello!\n";
	__asm__ ("movl $4, %%eax; movl $0, %%ebx; movl  $8, %%edx; int $0x80"
	:
	: "c"(s)
	: "%eax", "%ebx", "%edx");
	__asm__ ("movl $1, %eax; xorl %ebx, %ebx; int $0x80"); // Вызов, эквивалентный _exit(0)
}

Теперь наша программа не использует функций glibc, но при попытке ее скомпилировать компоновщик пожалуется, что у нас определено две функции _start(). Исправить это можно, вызвав gcc с ключом  -nostdlib. В результате (при компиляции с ключом -O2 и после обработки strip’ом) получим исполнимый файл программы размером 1082 байта. Чуть больше одного килобайта! Вряд ли на 64-битном процессоре можно добиться более компактного результата. ;)

Полезная ссылка по теме

А вот, например, та же программа для ARM Linux. Программа написана для ARM mode (32-битные инструкции)

void _start()
{
char * s = "Hello\n";
__asm__ ("mov r0, #0; mov r1, %[sptr]; mov r2, #7; swi 0x900004" // _write(0, s, 7);
:
: [sptr] "r" (s)
: "r0", "r1", "r2");
__asm__ ("mov r0, #0; swi 0x900001"); // _exit(0);
}

Программу, естественно, тоже нужно собирать с ключом -nostdlib. Получается исполнимый файл длиной 538 байтов, что и не удивительно, если учесть, что плотность кода ARM выше, чем плотность кода X86-64.