Системный вызов позволяет приложению обратиться к ОС с просьбой выполнить то или иное действие, оформленное как процедура (или набор процедур) кодового сегмента ОС. Для прикладного программиста ОС выглядит как некая библиотека, предоставляющая некоторый набор полезных функций, с помощью которых можно упростить прикладную программу или выполнить действия, запрещенные в пользовательском режиме, например обмен данными с устройством ввода-вывода.

Реализация системных вызовов должна удовлетворять следующим требованиям:

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

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

Для обеспечения высокой скорости полезно использовать векторные свойства системы программных прерываний, имеющиеся во многих процессорах, т.е. закрепить за каждым системным вызовом определенное значение вектора. Приложение при таком способе вызова непосредственно указывает в аргументе запроса значение вектора, после чего управление немедленно передается требуемой процедуре ОС (рис. 3.5, а). Однако этот децентрализованный способ передачи управления привязан к особенностям аппаратной платформы, а также не позволяет ОС легко модифицировать набор системных вызовов и контролировать их использование. Например, в процессоре Pentium количество системных вызовов определяется количеством векторов прерываний, выделенных для этой цели из общего пула в 256 элементов (часть которых используется под аппаратные прерывания и обработку исключений). Добавление нового системного вызова требует от системного программиста тщательного поиска свободного элемента в таблице прерываний, которого к тому же на каком-то этапе развития ОС может и не оказаться.

В большинстве ОС системные вызовы обслуживаются по централизованной схеме, основанной на существовании диспетчера системных вызовов (рис. 3.5, б). При любом системном вызове приложение выполняет программное прерывание с определенным и единственным номером вектора. Например, ОС Linux использует для системных вызовов команду INT 80h, а ОС Windows NT (при работе на платформе Pentium) - INT 2Eh. Перед выполнением программного прерывания приложение тем или иным способом передает операционной системе номер системного вызова, который является индексом в таблице адресов процедур ОС, реализующих системные вызовы (таблица sysent на рис. 3.5, б). Способ передачи зависит от реализации. Например, номер можно поместить в определенный регистр общего назначения процессора или передать через стек (в этом случае после прерывания и перехода в привилегированный режим их нужно будет скопировать в системный стек из пользовательского, это действие в некоторых процессорах автоматизировано). Также некоторым способом передаются аргументы системного вызова, они могут как помещаться в регистры общего назначения, так и передаваться через стек

Рис. 3.5. Децентрализованная (а) и централизованная (б) схемы обработки

системных вызовов

или массив, находящийся в оперативной памяти. Массив удобен при большом объеме данных, передаваемых в качестве аргументов, при этом в регистре общего назначения указывается адрес этого массива.

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

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

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

Для приложения системный вызов внешне ничем не отличается от вызова обычной библиотечной функции языка С, связанной (динамически или статически) с объектным кодом приложения и выполняющейся в пользовательском режиме. И такая ситуация действительно имеет место - для всех системных вызовов в библиотеках, предоставляемых компилятором С, имеются так называемые «заглушки» (в англоязычном варианте используется термин stub - остаток, огрызок). Каждая заглушка оформлена как С-функция, при этом она содержит несколько ассемблерных строк, нужных для выполнения инструкции программного прерывания. Таким образом, пользовательская программа вызывает заглушку, а та в свою очередь вызывает процедуру ОС.

Для ускорения некоторых достаточно простых системных вызовов, которым к тому же не нужен привилегированный режим, требуемая работа полностью выполняется библиотечной функцией, которую несправедливо называть в данном случае заглушкой. Точнее, такая функция не является системным вызовом, а представляет собой «чистую» библиотечную функцию, выполняющую всю свою работу в пользовательском режиме в виртуальном адресном пространстве процесса, но прикладной программист может об этом и не знать - для него системные вызовы и библиотечные функции выглядят единообразно. Прикладной программист имеет дело с набором функций прикладного программного интерфейса - API (например, Win32 или POSIX), состоящего и библиотечных функций, часть которых пользуется для завершения работы системными вызовами, а часть нет.

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

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

Асинхронный системный вызов не приводит к переводу процесса в режим ожидания после выполнения некоторых начальных системных действий, например запуска операции вывода/вывода, управление возвращается прикладному процессу (рис. 3.6, б).

Рис. 3.6. Синхронные (а) и асинхронные (б) системные вызовы

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

Блок управления процессом

Для того чтобы ОС могла управлять процессами, она должна располагать всей необходимой для этого информацией. С этой целью на каждый процесс заводится специальная информационная структура, содержащая определенную важную информацию о процессе и называемая дескриптором процесса (блоком управления процессом - Process Control Block, PCB). В общем случае дескриптор процесса содержит следующую информацию:

• идентификатор процесса (так называемый PID - Process IDentificator);
• тип (или класс) процесса, который определяет для супервизора некоторые правила предоставления ресурсов;
• приоритет процесса, в соответствии с которым супервизор предоставляет ресурсы. В рамках одного класса процессов в первую очередь обслуживаются более приоритетные процессы;
• переменную состояния, которая определяет, в каком состоянии находится процесс (готов к работе, в состоянии выполнения, ожидание устройства ввода/вывода и т.д.);
• защищенную область памяти (или адрес такой зоны), в которой хранятся текущие значения регистров процессора, если процесс прерывается, не закончив работы. Эта информация называется контекстом задачи (процесса);
• информацию о ресурсах, которыми процесс владеет и/или имеет право пользоваться (указатели на открытые файлы, информация о незавершенных операциях ввода/вывода и т. п.);
• место (или его адрес) для организации общения с другими процессами;
• параметры времени запуска (момент времени, когда процесс должен активизироваться, и периодичность этой процедуры).

Таким образом, в блоке управления процессом ОС может сосредоточить всю ключевую информацию о процессе.

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

Процессы в ОС UNIX. Все построение ОС UNIX основано на использовании концепции процессов. Контекст процесса складывается из пользовательского контекста и контекста ядра, как изображено на рис. 3.7.

Под пользовательским контекстом процесса понимают код и данные, расположенные в адресном пространстве процесса. Все данные подразделяются:

• на инициализируемые неизменяемые данные (например, константы);
• инициализируемые изменяемые данные (все переменные, начальные значения которых присваиваются на этапе компиляции);
• ^инициализируемые изменяемые данные (все статические переменные, которым не присвоены начальные значения на этапе компиляции);

Рис. 3.7.

• стек пользователя;
• данные, расположенные в динамически выделяемой памяти (например, с помощью стандартных библиотечных С функций mallocO, callocO, reallocO).

Исполняемый код и инициализируемые данные составляют содержимое файла программы, который исполняется в контексте процесса. Пользовательский стек применяется при работе процесса в пользовательском режиме (user-mode).

Под понятием «контекст ядра» объединяются системный контекст и регистровый контекст. Выделим в контексте ядра стек ядра, который используется при работе процесса в режиме ядра (kernel mode), и данные ядра, хранящиеся в структурах, являющихся аналогом блока управления процессом - РСВ. В данные ядра входят: идентификатор пользователя - UID, групповой идентификатор пользователя - G1D, идентификатор процесса - P1D, идентификатор родительского процесса - PP1D.

Идентификация процесса. Каждый процесс в ОС получает уникальный идентификационный номер - P1D (process identificator).

При создании нового процесса ОС пытается присвоить ему свободный номер больший, чем у процесса, созданного перед ним. Если таких свободных номеров не оказывается (например, достигнут максимально возможный номер для процесса), то ОС выбирает минимальный номер из всех свободных номеров. В ОС Linux присвоение идентификационных номеров процессов начинается с номера 0, который получает процесс kernel при старте ОС. Этот номер впоследствии не может быть присвоен никакому другому процессу. Максимально возможное значение для номера процесса в Linux на базе 32-разрядных процессоров Intel составляет 2 31 -1.

Состояния процесса. Краткая диаграмма состояний. Модель состояний процессов в ОС UNIX представляет собой детализацию модели состояний. Диаграмма состояний процессов в ОС UNIX изображена на рис. 3.8.

Состояние процесса «исполнение» расщепилось на два состояния: «исполнение в режиме ядра» и «исполнение в режиме пользователя». В состоянии «исполнение в режиме пользователя» процесс выполняет прикладные инструкции пользователя. В состоянии «исполнение в режиме ядра» выполняются инструкции ядра ОС в контексте текущего процесса (например, при обработке сис-

Рис. 3.8. Краткая диаграмма состояний процесса в UNIX темного вызова или прерывания). Из состояния «исполнение в режиме пользователя» процесс не может непосредственно перейти в состояния «ожидание», «готовность» и «закончил исполнение». Такие переходы возможны только через промежуточное состояние «исполняется в режиме ядра». Также запрещен прямой переход из состояния «готовность» в состояние «исполнение в режиме пользователя».

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

Иерархия процессов. В ОС UNIX все процессы, кроме одного, создающегося при старте ОС, могут быть порождены только какими-либо другими процессами. В качестве прародителя всех остальных процессов в подобных UNIX системах могут выступать процессы с номерами 1 или 0. В ОС Linux таким родоначальником, существующим только при загрузке системы, является процесс kernel с идентификатором 0.

Таким образом, все процессы в UNIX связаны отношениями «процесс-родитель - процесс-ребенок» и образуют генеалогическое дерево процессов. Для сохранения целостности генеалогического дерева в ситуациях, когда процесс-родитель завершает свою работу до завершения выполнения процесса-ребенка, идентификатор родительского процесса в данных ядра процесса-ребенка (PPID - parent process identificator) изменяет свое значение на значение 1, соответствующее идентификатору процесса init, время жизни которого определяет время функционирования ОС. Тем самым процесс init как бы усыновляет осиротевшие процессы. Наверное, логичнее было бы заменять PPID не на значение 1, а на значение идентификатора ближайшего существующего процесса- прародителя умершего процесса-родителя, но в UNIX почему-то такая схема не была реализована.

Системные вызовы де1рр1с!() и де1ртс1()

Данные ядра, находящиеся в контексте ядра процесса, не могут быть прочитаны процессом непосредственно. Для получения информации о них процесс должен совершить соответствующий системный вызов. Значение идентификатора текущего процесса может быть получено с помощью системного вызова §е1р1с1(), а значение идентификатора родительского процесса для текущего процесса - с помощью системного вызова getppid(). Прототипы этих системных вызовов и соответствующие типы данных описаны в системных файлах и. Системные вызовы не имеют параметров и возвращают идентификатор текущего процесса и идентификатор родительского процесса соответственно.

Прототипы системных вызовов

#include ttinclude pid_t getpid(void); pid_t getppid(void);

Описание системных вызовов

Системный вызов getpid возвращает идентификатор текущего процесса. Системный вызов getppid возвращает идентификатор процесса-родителя для текущего процесса.

Тип данных pid_t является синонимом для одного из целочисленных типов языка С.

Создание процесса в UNIX. Системный вызов fork()

В ОС UNIX новый процесс может быть порожден единственным способом - с помощью системного вызова fork(). При этом вновь созданный процесс будет являться практически полной копией родительского процесса. У порожденного процесса по сравнению с родительским процессом (на уровне уже полученных знаний) изменяются значения следующих параметров:

• идентификатор процесса - PID;
• идентификатор родительского процесса - РРШ. Дополнительно может измениться поведение порожденного

процесса по отношению к некоторым сигналам.

Системный вызов для порождения нового процесса

Прототип системного вызова

#include ttinclude pid_t fork(void);

Описание системного вызова

Системный вызов fork служит для создания нового процесса в операционной системе UNIX. Процесс, который инициировал системный вызов fork, принято называть родительским процессом (parent process). Вновь порожденный процесс принято называть процессом-ребенком (child process). Процесс-ребенок является почти полной копией родительского процесса. У порожденного процесса по сравнению с родительским изменяются значения следующих параметров:

• идентификатор процесса;
• идентификатор родительского процесса;
• время, оставшееся до получения сигнала SIGALRM;
• сигналы, ожидавшие доставки родительскому процессу, не будут доставляться порожденному процессу.

При однократном системном вызове возврат из него может произойти дважды: один раз в родительском процессе, а второй раз в порожденном процессе. Если создание нового процесса произошло успешно, то в порожденном процессе системный вызов вернет значение 0, а в родительском процессе - положительное значение, равное идентификатору процесса-ребенка. Если создать новый процесс не удалось, то системный вызов вернет в инициировавший его процесс отрицательное значение.

Системный вызов fork является единственным способом породить новый процесс после инициализации ОС UNIX.

В процессе выполнения системного вызова fork() порождается копия родительского процесса и возвращение из системного вызова будет происходить уже как в родительском, так и в порожденном процессах. Этот системный вызов является единственным, который вызывается один раз, а при успешной работе возвращается два раза (один раз в процессе-родителе и один раз в процессе-ребенке)! После выхода из системного вызова оба процесса продолжают выполнение регулярного пользовательского кода, следующего за системным вызовом.

Завершение процесса. Функция ех1Ч()

Существует два способа корректного завершения процесса в программах, написанных на языке С. Первый способ мы использовали до сих пор: процесс корректно завершался по достижении конца функции main() или при выполнении оператора return в функции main(), второй способ применяется при необходимости завершить процесс в каком-либо другом месте программы. Для этого используется функция exit () из стандартной библиотеки функций для языка С. При выполнении этой функции происходит сброс всех частично заполненных буферов ввода/вы- вода с закрытием соответствующих потоков, после чего инициируется системный вызов прекращения работы процесса и перевода его в состояние «закончил исполнение».

Значение параметра функции exitQ - кода завершения процесса - передается ядру ОС и может быть затем получено процессом, породившим завершившийся процесс. На самом деле при достижении конца функции main() также неявно вызывается эта функция со значением параметра 0.

Функция для нормального завершения процесса

Прототип функции

«include void exit(int status);

Описание функции

Функция exit служит для нормального завершения процесса. При выполнении этой функции происходит сброс всех частично заполненных буферов ввода/вывода с закрытием соответствующих потоков (файлов, pipe, FIFO, сокетов), после чего инициируется системный вызов прекращения работы процесса и перевода его в состояние закончил исполнение.

Возврата из функции в текущий процесс не происходит, и функция ничего не возвращает.

Значение параметра status - кода завершения процесса - передается ядру ОС и может быть затем получено процессом, породившим завершившийся процесс. При этом используются только младшие 8 бит параметра, так что для кода завершения допустимы значения от 0 до 255. По соглашению, код завершения 0 означает безошибочное завершение процесса.

Если процесс завершает свою работу раньше, чем его родитель, и родитель явно не указал, что он не хочет получать информацию о статусе завершения порожденного процесса, то завершившийся процесс не исчезает из системы окончательно, а остается в состоянии «закончил исполнение» либо до завершения процесса-родителя, либо до того момента, когда родитель получит эту информацию. Процессы, находящиеся в состоянии «закончил исполнение», в ОС UNIX принято называть процессами-зомби (zombie, defunct).

Программы для Windows 7 или любой другой версии, включая собственные инструменты системы на все случаи жизни, сегодня настолько разнообразны, что пользователи зачастую не знают, для чего они предназначены. Особое непонимание связано с системными процессами, которые могут работать в фоновом режиме. Одной из таких служб является процесс с отвечающим за него исполняемым файлом MRT.exe. Что это за инструмент системы, многие пользователи даже понятия не имеют. Именно поэтому далее предлагается разобраться, что это такое и для чего он нужен.

MRT.exe: что это за служба?

Название исполняемого файла является аббревиатурой, обозначающей встроенный защитный инструмент системы под названием Microsoft Removal Tool. Исходя из этого, нетрудно сделать вывод о том, что это некое подобие антивирусного сканера, которое призвано обеспечить защиту системы от разного рода угроз.

Однако не все так просто. Самая главная проблема этой службы связана только с тем, что она неспособна определять угрозы на входе и защищать систему в реальном времени, а применяется исключительно для сканирования, обнаружения и удаления вирусов или в уже зараженной ОС. Это основная задача сканера MRT.exe. Что это с точки зрения общей безопасности? Тут можно провести самую простую аналогию с портативными вроде Kaspersky Virus Removal Tool или еще с чем-то подобным. Только вот функциональность данного апплета вызывает достаточно большие сомнения.

Как использовать этот инструмент?

Что касается выполнения штатной проверки, достаточно просто запустить программу в виде EXE-файла или изначально загрузить пакет KB890830 с официального сайта корпорации Microsoft.

После старта приложение предложит несколько вариантов сканирования: быстрое, полное и выборочное. После выбора одного из вариантов стартует проверка. Если какие-либо угрозы или подозрительные элементы будут найдены, программа при выдаче результата оповестит пользователя об их наличии и местоположении зараженных или вирусных объектов.

Вопросы отключения и удаления процесса

Но это только часть вопроса, касающегося службы MRT.exe. Что это такое, разобрались. Теперь посмотрим, можно ли убрать этот компонент из системы.

Действительно, данный апплет обязательным для Windows не является, поэтому удалить его можно без всяких проблем. Сам процесс сначала завершается в «Диспетчере задач», после чего в разделе установленных обновлений деинсталлируется вышеуказанный пакет обновления, который можно найти в списке установленных апдейтов в разделе программ и компонентов. Также можно обратиться и к «Центру обновления».

Как определить, что это вирус?

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

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

Файл оригинальной службы расположен по пути c:\Windows\System32\MRT.exe или по тому же пути, но в папке MRT. Если для выявленного процесса указан другой путь, можете не сомневаться, что это именно вирус. Для его нейтрализации, если это возможно, нужно сразу же удалить основную директорию и все ее компоненты, а также использовать портативный сканер для полного удаления угрозы из системы.

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

В качестве ключевых положений рефлекторной теории П.К. Анохин выделял следующие:

1. исключительность пускового стимула как фактора, детерминирующего действие, которое является его причиной;

2. завершение поведенческого акта рефлекторным действием, ответом;

3. поступательный ход возбуждения по рефлекторной дуге.

Все эти положения отвергаются при рассмотрении поведения с позиций ТФС [Анохин, 1978].

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

Согласно ТФС, интеграция всех этих компонентов осуществляется в рамках специального системного механизма афферентного синтеза, в процессе которого на основе мотивации, при учете обстановки и прошлого опыта создаются условия для устранения избыточных степеней свободы – принятия решения о том, что, как и когда сделать, чтобы получить полезный приспособительный результат. Принятие решения завершается формированием акцептора результатов действия, который представляет собой аппарат прогнозирования параметров будущих результатов: этапных и конечного, и их сличения с параметрами результатов, реально полученных при реализации программы действия. При сличении с параметрами полученных этапных результатов выявляется соответствие хода выполнения программы запланированному (подробнее см. [Батуев, 1978; Пашина, Швырков, 1978]) при сравнении с параметрами конечного – соответствие достигнутого соотношения организма и среды тому, для достижения которого была сформирована система. Эти системные механизмы составляют операциональную архитектонику любой функциональной системы (рис. 14.1). Их введение в концептуальную схему – второе важнейшее преимущество и признак, отличающий ТФС от других вариантов системного подхода.

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

Открытие системных процессов позволило, в отличие от рассмотрения в качестве основы поведения материально-энергетических отношений между локальным воздействием и реакцией, протрактовать поведение как обмен организованностью, или информацией между организмом и средой, осуществляемый в рамках этих информационных процессов. При этом было обосновано положение о том, что системные категории ТФС описывают одновременно и организацию активности элементов организма, и ее связь с организацией внешней среды [Швырков, 1995].

В стабильных условиях, например в ситуации лабораторного эксперимента, пусковой стимул реализует готовую предпусковую интеграцию, которую можно охарактеризовать как готовность систем будущего поведения, формирующуюся в процессе выполнения предыдущего. Она направлена в будущее, но стабильность ситуации делает очевидной связь «стимул–ответ». Однако анализ нейронной активности в поведении четко показывает, что организация последней определяется тем, какой результат достигается в данном поведении, тогда как стимул лишь «запускает», «разрешает» реализацию. В тех случаях, когда один и тот же по физическим параметрам стимул «запускает» разные поведенческие акты (например, пищедобывательный или оборонительный), разными в этих актах оказываются не только характеристики активности нейронов, но даже и сам набор вовлеченных клеток, в том числе и в «специфических» по отношению к стимулу областях мозга (например, в зрительной коре при предъявлении зрительного стимула; см. [Швыркова, 1979; Александров, 1989]).

Рис. 14.1. Функционольная система и поведенческий континуум

Операциональная архитектоника функциональной системы по П.К. Анохину (вверху). О системных механизмах, составляющих операциональную архитектонику, см. параграф 2. Стрелки от «доминирующей мотивации» к «памяти» демонстрируют, что характер информации, извлекаемой из памяти, определяется доминирующей мотивацией. Схема также иллюстрирует представление о том, что в акцепторе результатов действия содержатся модели этапных результатов наряду с конечным результатом и что модель последнего представлена не единичной характеристикой, а комплексом параметров.

Поведенческий континуум (внизу). Р n’, Р n+1 – результаты поведенческих актов; p1,2,3, – этапные результаты; Т– трансформационные процессы (см. параграф 2). О наборах систем, обеспечивающих реализацию последовательных актов континуума (каждому набору соответствует свой тип штриховки) и о вовлечении в трансформационные процессы систем, не участвующих в реализации актов, смена которых данными процессами обеспечивается (эти системы обозначены незаштрихованными овалами), см. в параграфе 7

Второе положение рефлекторной теории, которое отвергается ТФС, – оценка действия как завершающего этапа поведенческого акта. С позиций ТФС заключительный этап развертывания акта – сличение прогнозируемых в акцепторе параметров с параметрами реально полученного результата. Если параметры соответствуют прогнозируемым, то индивид реализует следующий поведенческий акт; если же нет, то в аппарате акцептора возникает рассогласование, ведущее к перестройке программ достижения результата.

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

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

Единый паттерн активации и синхронность вовлечения нейронов разных областей мозга в общемозговые системные процессы не означают эквипотенциальности (равнозначности) мозговых структур; вклад этих структур в обеспечение поведения зависит от специфики проекции на них индивидуального опыта (см. параграф 8).

12597

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

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

Оказывается, что не так уже и сложно, но перед тем как приступать к их идентификации, позвольте пару слов о самом процессе svchost. Как видно из его полного названия Generic Host Process for Win32 Services , отвечает он за работу служб и сервисов, причём как системных, так и сторонних, использующих динамические библиотеки DLL , которые в свою очередь составляют немалую часть файлов Windows и прикладных программ.

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

Итак, как же узнать, является ли svchost настоящим? Первым критерием подлинности файла является его месторасположение. Его законным местом обитания являются следующие папки:

C:/WINDOWS/system32
C:/Windows/SysWOW64
C:/WINDOWSPrefetch
C:WINDOWS/ServicePackFiles/i386
С:/WINDOWS/winsxs/*

П римечание: звёздочка в конце пути С:/WINDOWS/winsxs обозначает, что в папке winsxs может быть ещё один каталог. Как правило, он имеет длинное название из набора символов, например, amd64_3ware.inf.resources_31bf3856ad364e35_6.3.9600.16384_ru-ru_7f622cb60fd30b1c . В виде исключения из правил файл может располагаться в каталоге антишпионской программы Malwarebytes Anti-Malware .

Если же он обнаружится в какой-нибудь другой папке, особенно в корневой Windows или в «Пользователи» , то скорее всего вы имеете дело с маскирующимся вирусом. Проверить расположение файла можно из Диспетчера задач , кликнув по процессу правой кнопкой мыши и выбрав в меню опцию либо с помощью сторонних утилит вроде Process Explorer . Используя сторонние файловые менеджеры, также можно выполнить поиск всех файлов по маске.

Последний способ не столь надёжен, так как подделывающийся под процесс svchost вирус может использовать более хитрый способ маскировки. Так, в имени файла одна из латинских букв может быть заменена кириллической. Внешне такой файл ничем не будет отличаться от настоящего , более того, он может располагаться в том же каталоге, что и «правильный» . Впрочем, проверить его подлинность не составляет особого труда. Достаточно сравнить коды символов имени файла воспользовавшись таблицей символов Юникода . Иногда в название файла svchost добавляется лишняя буква, либо наоборот, пропускается. Невнимательный пользователь может и не заметить разницу между, скажем, и svhost.exe .

Тем не менее, спешить удалять подозрительный svchost сходу не стоит. Для начала неплохо было бы проверить его на мульти антивирусном сервисе вроде VirusTotal и, если подозрительный файл окажется подделкой, хотя одна из антивирусных программ выдаст положительный результат. Вредоносный файл, маскирующийся под svchost удаляем с помощью Dr.Web LiveDisk либо утилиты AVZ . Если будете использовать AVZ , вам также понадобиться специальный скрипт, скачать который можно по ссылке ниже.

Системные процессы

Все функции, выполняемые ОС QNX, за исключением функций ядра, реализуются стандартными процессами. В типичной конфигурации системы QNX имеются следующие системные процессы:

• · администратор процессов (Proc),
• · администратор файловой системы (Fsys),
• · администратор устройств (Dev),
• · сетевой администратор (Net).

Системные процессы и процессы пользователя

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

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

Действительно, грань между ОС и прикладными программами весьма условна. Единственным принципиальным отличием системных процессов от прикладных является то, что системные процессы управляют ресурсами системы, предоставляя их прикладным процессам.

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

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