Главная » Хабрахабр » [Перевод] Курс MIT «Безопасность компьютерных систем». Лекция 4: «Разделение привилегий», часть 1

[Перевод] Курс MIT «Безопасность компьютерных систем». Лекция 4: «Разделение привилегий», часть 1

Массачусетский Технологический институт. Курс лекций #6.858. «Безопасность компьютерных систем». Николай Зельдович, Джеймс Микенс. 2014 год

Computer Systems Security — это курс о разработке и внедрении защищенных компьютерных систем. Лекции охватывают модели угроз, атаки, которые ставят под угрозу безопасность, и методы обеспечения безопасности на основе последних научных работ. Темы включают в себя безопасность операционной системы (ОС), возможности, управление потоками информации, языковую безопасность, сетевые протоколы, аппаратную защиту и безопасность в веб-приложениях.

Лекция 1: «Вступление: модели угроз» Часть 1 / Часть 2 / Часть 3
Лекция 2: «Контроль хакерских атак» Часть 1 / Часть 2 / Часть 3
Лекция 3: «Переполнение буфера: эксплойты и защита» Часть 1 / Часть 2 / Часть 3
Лекция 4: «Разделение привилегий» Часть 1 / Часть 2 / Часть 3

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

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

На прошлой неделе Джеймс показал, что если вы пишете программу на C, то почти неизбежно будете иметь в ней что-то плохое или неправильное. Поэтому, прежде чем мы погрузимся в детали разрешений OKWS и Unix, давайте просто посмотрим, что такое разделение привилегий и почему это такая хорошая идея? При этом проблема состоит в том, что если у вас есть достаточно большое приложение и в нём присутствует какой-либо вид уязвимости, то злоумышленники могут подключиться к программе, отправить запросы этому приложению, обмануть его и проделать «плохие» вещи.

Это означает, что оно включает в себя много данных, которые можно получить при наличии доступа. Любое приложение имеет привилегии доступа. Проблема заключается в том, что уязвимость в этом большом приложении может позволить атакующему изменить какие-то из этих данных или получить достаточно привилегий для управления программой, если вы не будете осторожны.
В этой лекции мы рассмотрим, что пытается сделать разделение привилегий. Можно даже удалить эти файлы, как вы, ребята, делали в лабораторной работе №1. Стоит взять программу, поделить её на части и убедиться, что каждый из отдельных элементов имеет только необходимые привилегии для того, чтобы правильно выполнять свою работу.

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

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

Вы, ребята, вероятно, довольно часто пользовались SSH, или «безопасной оболочкой». Многие приложения фактически используют практику разделения привилегий. Он использует разделение привилегий во многих своих компонентах, чтобы убедиться, что его шифровальные ключи не разгаданы и сервер не будет скомпрометирован. Это сетевой протокол, который используется для удалённого управления ОС и передачи файлов. Так что, если имеется какой-то «баг» в работе Chrome, противник не сможет получить полный контроль над вашим компьютером. Более актуален для вас веб-браузер Chrome, в котором разделение привилегий реализовано также довольно широко.

Однако он больше наглядный пример, чем важная часть программного обеспечения. Это очень краткое изложение того, что такое разделение привилегий и почему OKWS является интересным примером.

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

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

Поэтому я думаю, что предметом, или субъектом Unix является процесс, так как поддерживается некий процесс, потому что каждой операции или запросу, которые мы рассматриваем с точки зрения безопасности, следует что-то разрешать или запрещать. Когда вы думаете о механизме защиты, вы должны думать о его принципах, которые означают, что имеется некто с привилегиями или правами, а Unix инициирует или поддерживает эти права. Здесь важно то, как мы опишем, какие привилегии имеет этот процесс. Вероятно, это будет операция, вызываемая процессом путем выполнения системного вызова syscall.

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

Аудитория: о файлах!

О чём ещё? Профессор: правильно, о файлах и каталогах.

Аудитория: о сетевых сокетах!

Что-нибудь еще у нас происходит в системе? Профессор: да, замечательно, о сетевых сокетах.

Аудитория: другие процессы.

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

Аудитория: переменные среды.

Я думаю, что переменные среды – это просто некое состояние процесса, содержащегося в памяти. Профессор: я думаю, что они, вероятно, не являются субъектом, который вы можете изменить, в смысле управления OC и наличия какой-то политики безопасности. Наверное, в памяти процесса находится много чувствительных к вмешательству извне вещей. Но, я думаю, в более общем плане, нас заботит эта часть процесса, содержащаяся в памяти – переменные среды, стеки, аргументы, это тоже достаточно важно. Что ещё?

Аудитория: файловые дескрипторы в целом.

Файлы, которые находятся на диске, должны нас волновать. Профессор: тут есть еще одно внутреннее обстоятельство, которое имеет большое значение. Какие ещё вещи вы бы хотели защитить в операционной системе? Но есть ещё такой операционный инструмент, как файловый дескриптор, который OKWS старается широко использовать, и мы увидим, что они из себя представляют.

Аудитория: «железо», или аппаратное обеспечение.

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

Аудитория: стоит подумать также о защите периферийных устройств!

Итак, дополнительные устройства, вы правы, особенно на настольном компьютере, там много лишних вещей: USB-накопитель, веб-камера, вероятно, сам дисплей – что-то из этого вы захотите защитить, потому что связанные с ними приложения не должны «гулять» по всему вашему экрану. Профессор: О, да!

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

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

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

Существует идентификатор группы Group ID, который также является 32-разрядным целым числом. Существует нечто под названием User ID, которое представляет собой 32-х битное целое число. На самом деле нет особой причины, почему они должны отличаться.

Есть целые числа User ID, и целочисленные значения Group ID. Было бы неплохо, если бы они просто составляли единый набор 32-битных целых чисел, но, к сожалению, Unix разбивает их на две категории. Как правило, процесс имеет один uid, а также список групповых идентификаторов gid, которые имеет данный процесс. Когда мы говорим о процессе, имеющем определенные привилегии, то имеется в виду процесс, связанный с определенным значением uid. Грубо говоря, процесс может осуществлять привилегии, представленные всеми этими идентификаторами. По историческим причинам сложилось так, что они объединяются в один gid, а потом объединяются в список других идентификаторов. Так что если uid предоставляет к чему-то доступ, то процесс может делать с ним что угодно.

Так что же происходит с файлами, вернее, как создать разрешения Unix для работы с файлами? Теперь давайте поговорим о файлах, каталогах и других видах объектов. С файлами всё относительно просто, в их отношении вас заботят операции, которые можно с ними проделать: чтение, запись, возможно, выполнение, а также способность изменить сами разрешения или другие свойства безопасности.

Аудитория: разрыв связей!

На самом деле это различие немного не чёткое. Профессор: да, разрыв связей, unlink — как вы считаете, это свойство самого файла или каталога? Поэтому в Unix вы можете иметь несколько жёстких ссылок на inode и при отсоединении определенного имени файла Unix с помощью unlink вы на самом деле уничтожаете только одно из имён файла, но у него могут быть другие имена и другие ссылки на него. Когда Unix думает об удалении файла, это в большей степени касается каталога, потому что в Unix файл действительно представляет собой inode, или индексный дескриптор. Так что обычно операции unlink, link, rename и create являются операциями, связанными с каталогом, поэтому create влияет как на каталог, так и на новый файл. На самом деле важно, разрешено ли вам изменять каталог, указывающий на файл, и при этом не делать что-либо с inode самого файла. Поэтому мы должны выяснить, какие правила там действуют.

В Unix каждый inode, который в конечном итоге является файлом или каталогом, в целях безопасности имеет несколько интересных полей. Для того, чтобы решить, что кто-то может прочитать или записать файл, мы собираемся вставить некоторые разрешения, или биты, в файл inode. Таким образом, распоряжаться всеми файлами в вашем домашнем каталоге вы можете благодаря тому, что Unix имеет ваш uid.
В Unix также есть набор битов разрешений, которые можно рассматривать как часть матрицы, в базовом дизайне они выглядят как r (чтение), w (запись) и x (выполнение). Здесь есть идентификатор пользователя и идентификатор группы, которая, как мы говорим, владеет файлом или владеет каталогом. Мы можем указать эти разрешения для различных субъектов, и в Unix они указываются для владельца owner, то есть для uid inode, для группы group, которой принадлежит данный файл, то есть для gid, и для всех остальных – other.

Вы можете заполнить эту бинарную матрицу 3 на 3, где 1 означает разрешение выполнять определённое действие, а 0 запрещает его выполнение:

Есть традиционный способ кодирования этих вещей, который вы будете видеть часто и о котором, вероятно, стоит упомянуть. Вот так Unix хранит разрешения. В Unix эта матрица кодируется как восьмеричное число, поэтому каждую строку здесь следует рассматривать как базовое число 8, поэтому наша матрица в такой кодировке будет выглядеть следующим образом: r это 4 бита, w — 2 бита, x – 1 бит, соответственно, owner – это 6 бит, а group и other содержат по 4 бита.

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

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

Аудитория: если у этого человека есть доступ к файлу?

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

В противном случае, вы этого не можете. Поэтому создатели Unix решили, что если у вас есть файл, то есть ваш uid соответствует uid, занесённому в файл, то по умолчанию вы можете изменить разрешения. Вы можете просто прочитать, переписать, выполнить с ним всё, что угодно, но без uid вы не сможете изменить разрешения. Так что если у вас есть только gid и эта group имеет все разрешения в файле, вы всё равно не сможете изменить разрешения для этого файла.

Таким образом, отсоединение unlink и связывание записей link в каталоге означает наличие разрешения на запись в этот каталог. Каталоги в Unix следуют тем же правилам. В некоторых случаях с жёсткими ссылками могут возникать проблемы, и в материалах лекции эти детали освещены. Если вы хотите переименовать файл, тогда вам, вероятно, нужно иметь права на запись в каталоге, откуда вы его достаёте, и на запись в каталоге, в который вы его помещаете.

Благодаря ей вы можете просто найти файл в каталоге. На самом деле в каталоге есть еще одна интересная операция — поиск. Может быть, что вам и не нужно иметь разрешение на каталог, чтобы искать имя файла, но если у вас нет разрешения на чтение, вы не сможете просмотреть содержимое каталога, то есть разыскать файл. Unix кодирует разрешения execute как возможность реализации поиска для каталогов, так что иметь разрешение execute для каталога фактически означает возможность поиска определенного имени файла. Это полезно в некоторых ситуациях, когда нужно ограничить действия с какими-то файлами или скрыть их от пользователя.

Что происходит в Unix, если я ввожу команду open ("/etc/password")? Давайте рассмотрим пример. Что проверяет ядро системы от моего имени, когда я командую ему выполнить системный вызов?

д.? Аудитория: оно проверяет, есть ли у вас разрешения на выполнение и т.

Мне нужно выполнить что-то и т. Профессор: Да, в определенной степени это имеет место. д.

Аудитория: а затем выполнить указанное слешем!

Так что если я не разберусь с разрешениям на root – права, это не сработает. Профессор: да, на самом деле мне нужно посмотреть, на что указывает /etc?

Аудитория: тогда вам нужно выполнить чтение /etc / password.

Вот вам небольшая головоломка. Профессор: да, это имеет смысл. 858, и другими группами для всех TAs в MIT, которые в терминологии Unix обозначается как gids, но они не входят в группу 6. Предположим, что MIT создает группу для всех людей, связанных с курсом 6. Как мне создать файл, который будет доступен только для группы 6. 858 TAs по каким-то глупым причинам. 858 TAs?

858 gid и TAs gid, но я могу вставить в файл только один gid. Предположим, у меня есть 6.

858 TAs. Аудитория: вы бы не смогли это сделать, потому что здесь у вас может быть TAs, а не 6.

Хотя в группе 6. Профессор: да, это правда. Но, всё же, давайте попробуем как-то сделать пересечения этих групп. 858 есть студенты, которые являются TAs других классов, так что, возможно, это не совсем здорово. 858 и может сделать его исполняемым только для этой группы. Для этого мы можем использовать механизм разрешений.
Можно создать файл /foo/bar/grades, при этом foo владеет, или устанавливает gid для группы 6. А затем я бы установил разрешения для /bar, который устанавливал бы gid для TAs, и так же делал бы это исполняемым для данной группы. Поэтому, если вы не в этой группе, вы даже не сможете искать файлы в каталоге /foo. Таким образом, мы используем некий механизм изоляции файла. Поэтому если вы не можете проследовать по пути этого каталога /foo/bar/, то вы не получите доступ к файлу оценок grades.

858 gid, мог ли TA связать его с каким-то другим каталогом и позволить кому-либо в 6. Аудитория: если, например, разрешения на сам файл оценок, скажем, были только у 6. 858 получить к нему доступ?

Таким образом, вы можете побеспокоиться о других вещах, таких как утечка, поэтому Unix в основном не пытается применить эти виды транзитивных свойств безопасности, что означает, что если один процесс имеет доступ к некоторым данным, или имеет некоторые привилегии, то он может делегировать эти привилегии всем, кому хочет. Профессор: да, это верно. Возможно, мы поговорим о них позже, но в целом они фактически насаждают такое транзитивное свойство: если я дам это тебе, то ты не сможешь дать это другим людям. Существуют другие виды систем, которые называются MACS — mandatory accesscontrol systems, системы контроля обязательного доступа. Это своеобразные путы, так что вы не можете пойти куда-нибудь еще. То есть вы застреваете на одном месте.

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

Однако он может где-то спрятать ссылку на файл оценок, поэтому это, возможно, это не идеальный вариант. Но в целом, вы должны беспокоиться о таких вещах, как транзитивность, например, когда кто-то не был ТА, и поэтому мы его удалили.

Итак, мы кратко рассмотрели всё, что связано с файлами и каталогами в Unix.

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

И проверки безопасности не применяется в том смысле, что для получения этого файлового дескриптора вам нужно просто открыть этот файл. Таким образом, правила доступа к файловому дескриптору таковы: если у вас есть открытый файловый дескриптор в вашем процессе, то вы можете получить к нему доступ. Если какой-то процесс передаёт вам файловый дескриптор, или родительский процесс передаёт его дочернему процессу, или передача происходит через сокеты Unix – неважно, как вам удалось получить файловый дескриптор, вы всё равно можете читать и записывать в него все, что хотите, потому что проверки безопасности уже были сделаны при его создании.

Так что на самом деле дескрипторы – это полезная способность Unix предоставить кому-то привилегии, которых они бы не имели в противном случае.

И один из способов реализовать это, не давая им прямого доступа к чтению и записи это файла в файловой системе, состоит в том, что кто-то другой открыл файл, создал файловый дескриптор и затем передал его в этот дополнительный компонент. В OKWS есть много компонентов, которые нуждаются в доступе к определённому сокету или файлу. И больше никто не сможет попробовать что-либо сделать в файловой системе, что может привести к опасным последствиям. Таким образом, вы сможете точно сказать, что это единственный файловый дескриптор, который у вас когда-либо будет.

Если у вас есть файловый дескриптор, вы можете делать с ним все, что захотите. На самом деле, у дескриптора довольно простые правила.

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

Таким образом, вы всегда можете создать процесс, за исключением того, что дочерний процесс получит тот же идентификатор пользователя, что и вы, поэтому вы не сможете создать процесс с другим идентификатором пользователя по умолчанию. И правила относительно просты. Так что вы не можете создать, например, процесс web, используя gid для одного из TAs, ядро операционной системы просто не позволит вам это сделать.

Все вещи с одним userid изолированы от вещей с другими идентификаторами пользователя. Если вы хотите убить процесс, вы в основном должны иметь тот же идентификатор пользователя, что и этот процесс. То же самое правило относится и к ptrace — процесс с этим же uid может отлаживать процессы с тем же uid.

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

27:50 мин

Продолжение:

Лекция 4: «Разделение привилегий», часть 2 Курс MIT «Безопасность компьютерных систем».

Полная версия курса доступна здесь.

Вам нравятся наши статьи? Спасибо, что остаётесь с нами. Поддержите нас оформив заказ или порекомендовав знакомым, 30% скидка для пользователей Хабра на уникальный аналог entry-level серверов, который был придуман нами для Вас: Вся правда о VPS (KVM) E5-2650 v4 (6 Cores) 10GB DDR4 240GB SSD 1Gbps от $20 или как правильно делить сервер? Хотите видеть больше интересных материалов? (доступны варианты с RAID1 и RAID10, до 24 ядер и до 40GB DDR4).

класса c применением серверов Dell R730xd Е5-2650 v4 стоимостью 9000 евро за копейки? Dell R730xd в 2 раза дешевле? Только у нас 2 х Intel Dodeca-Core Xeon E5-2650v4 128GB DDR4 6x480GB SSD 1Gbps 100 ТВ от $249 в Нидерландах и США! Читайте о том Как построить инфраструктуру корп.


Оставить комментарий

Ваш email нигде не будет показан
Обязательные для заполнения поля помечены *

*

x

Ещё Hi-Tech Интересное!

Бесплатная трансляция DotNext 2018 Moscow

Меньше недели осталось до конференции DotNext 2018 Moscow: она пройдет в конгресс-парке гостиницы «Рэдиссон Ройал Москва» 22-23 ноября. Между докладами будут вестись интервью с ключевыми спикерами конференции. По традиции, прямо на YouTube будет открыта бесплатная онлайн-трансляция первого зала (ссылка спрятана ...

Прерывания от внешних устройств в системе x86. Эволюция контроллеров прерываний

В данной статье хотелось бы рассмотреть механизмы доставки прерываний от внешних устройств в системе x86 и попытаться ответить на вопросы: что такое PIC и для чего он нужен? что такое APIC и для чего он нужен? Для чего нужны LAPIC ...