Userspace linux что это

userspace vs kernelspace

Объясните, пожалуйста, смысл терминов userspace (userland) и kernelspace. Гугл, к сожалению, не помог: этими словами обильно пользуются в разных контекстах, но ни пояснения смысла, ни разницы мне найти не удалось.

Re: userspace vs kernelspace

обычно имеют в виду в том смысле, что например драйвер hda это kernelland, а hdparm это userland..

Re: userspace vs kernelspace

Все что выполняется в контексте ядра — это kernel space, все остальное, user space.

Re: Re: userspace vs kernelspace

> Все что выполняется в контексте ядра — это kernel space, > все остальное, user space.

Спасибо. А нельзя ли чуть подробнее? Особенно буду благодарен за ссылку на книжку/что-нибудь в интернете/прочие доки.

Re: Re: Re: userspace vs kernelspace

>Спасибо. А нельзя ли чуть подробнее? Особенно буду благодарен за ссылку на книжку/что-нибудь в интернете/прочие доки.

У как все запущено.

Пожалуй тут надо начинать с самых азов. Типа что есть ядро, что есть драйвер и т.п.
Про защиту памяти в i386 почитать и т.п.

Re: Re: Re: Re: userspace vs kernelspace

> У как все запущено.

Это точно, и мне очень стыдно.

> Пожалуй тут надо начинать с самых азов. Типа что есть ядро, > что есть драйвер и т.п. Про защиту памяти в i386 почитать > и т.п.

Где почитать? Книжку хорошую можете порекомендовать?

Автор первоначального постинга.

Re: Re: Re: Re: Re: userspace vs kernelspace

Re: Re: Re: Re: Re: userspace vs kernelspace

> Книжку хорошую можете порекомендовать?

Ю. Вахалия «UNIX изнутри»

Re: userspace vs kernelspace

Бах(UNIX), Макьюзик(4.3BSD или 4.4BSD), Вахалия(UNIX, реально то, что на нем построено).

Re: Re: userspace vs kernelspace

где взять?? Нигде не видел.
Макьюзик(4.3BSD или 4.4BSD)

Источник

Национальная библиотека им. Н. Э. Баумана
Bauman National Library

Персональные инструменты

Пользовательское пространство

Большинство операционных систем выделяют в виртуальной памяти ОС пространство ядра и пространство пользователя.

Пользовательское пространство («User space«) — адресное пространство виртуальной памяти операционной системы, в которой выполняются процессы пользователя и содержатся некоторые библиотеки [Источник 1] . В англоязычных источниках так же используется такой термин как «Userland» [1] , обозначающий весь код, не относящийся к ядру операционной системы.

Содержание

Характеристика

Пользовательское пространство — своего рода песочница, в которой пользователь может работать с различными программными продуктами. В него могут включаться различные программы, написанные на C, Java, Python, Ruby и других языках. В некоторых ОС, например Debian , существуют процессы, запускаемые в фоновом режиме (без участия пользователя), так называемые «демоны». Они так же являются частью пользовательского пространства. Отделение пользовательского пространства, от пространства ядра позволяет работать пользователю в среде, при этом не обращаться напрямую к сложному устройству пространства ядра, которое работает самостоятельно, обеспечивая работу самой ОС и взаимодействие с аппаратными средствами.

Разделение адресного пространства виртуальной памяти в ОС

Существуют несколько принципиально разных концепций разделения адресного пространства виртуальной памяти ОС.

Системы UNIX

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

В большинстве Unix-образных операционных системах каждый процесс в пользовательском пространстве обычно выполняется в собственной области виртуальной памяти, и при отсутствии явной необходимости, не может получить доступа к памяти, используемой другими процессами. Такой подход является основным для обеспечения защиты памяти большинства современных операционных систем и фундаментом для обеспечения права доступа.
В зависимости от привилегий процесс может запросить ядро отобразить часть адресного пространства другого процесса на своё, как, например, это делают отладчики. Программы также могут запрашивать для себя область разделяемой памяти совместно с другими процессами. [Источник 2] Пользовательские приложения так же не могут напрямую взаимодействовать с оборудованием, осуществлено это, опять же, по соображениям безопасности. Пространство ядра может быть доступно процессам пользователя только с помощью системных вызовов («System calls«).То есть, системные вызовы — это точки входа в ядро, так что ядро может выполнять работу от имени приложения [Источник 3] . Доступ пользователя к оборудованию так же может осуществляться посредством использования драйверов.

Единое пространство

В некоторых экспериментальных операционных системах используется другой подход — для всех программных продуктов используется единое адресное пространство, с учётом того, что реализация виртуальной машины обеспечивает невозможность произвольного доступа — приложения попросту не могут получить ссылки на объекты, к которым они не имеют доступа, этот подход был использован в таких операционных системах, как JXOS, Unununium, Phantom OS, Microsoft Singularity [Источник 2] .

Источник

Глубокое погружение в Linux namespaces

В этой серии постов мы внимательно рассмотрим один из главных ингредиентов в контейнере – namespaces. В процессе мы создадим более простой клон команды docker run – нашу собственную программу, которая будет принимать на входе команду (вместе с её аргументами, если таковые имеются) и разворачивать контейнер для её выполнения, изолированный от остальной системы, подобно тому, как вы бы выполнили docker run для запуска из образа.

Что такое namespace?

Linux namespace – это абстракция над ресурсами в операционной системе. Мы можем думать об namespace, как о ящике. В этом ящике находятся системные ресурсы, которые точно зависят от типа ящика (namespace). В настоящее время существует семь типов пространств имён (namespaces): Cgroups, IPC, Network, Mount, PID, User, UTS.

Например, Network namespace включает в себя системные ресурсы, связанные с сетью, такие как сетевые интерфейсы (например, wlan0 , eth0 ), таблицы маршрутизации и т.д., Mount namespace включает файлы и каталоги в системе, PID содержит ID процессов и так далее. Таким образом, два экземпляра Network namespace A и B (соответствующие двум ящикам одного типа в нашей аналогии) могут содержать различные ресурсы – возможно, A содержит wlan0 , тогда как B содержит eth0 и отдельную копию таблицы маршрутизации.

Пространства имён (namespaces) – не какая-то дополнительная фича или библиотека, которую вам нужно установить, например, с помощью пакетного менеджера apt. Они предоставляются самим ядром Linux и уже являются необходимостью для запуска любого процесса в системе. В любой данный момент времени любой процесс P принадлежит ровно одному экземпляру namespace каждого типа. Поэтому, когда ему требуется сказать «обнови таблицу маршрутизации в системе», Linux показывает ему копию таблицы маршрутизации namespace, к которому он принадлежит в этот момент.

Для чего это нужно?

Абсолютно ни для чег… конечно, я просто пошутил. Одним их замечательных свойств ящиков является то, что вы можете добавлять и удалять вещи из ящика и это никак не повлияет на содержимое других ящиков. Тут та же идея с namespaces – процесс P может «сойти с ума» и выполнить sudo rm –rf / , но другой процесс Q, принадлежащий другому Mount namespace, не будет затронут, поскольку они они используют отдельные копии этих файлов.

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

Ограничение — это забота

Мы можем видеть namespaces, которым принадлежит процесс! Типичным для Linux образом они отображаются как файлы в каталоге /proc/$pid/ns данного процесса с process id $pid :

Вы можете открыть другой терминал, выполнить ту же команду и это должно дать вам тот же результат. Это потому, что как мы упоминали ранее, процесс обязательно должен принадлежать некоторому пространству имён (namespace) и до тех пор, пока мы мы явно не зададим к какому, Linux добавляет его в namespaces по умолчанию.

Давайте немного вмешаемся в это. Во втором терминале мы можем выполнить что-то вроде этого:

Команда unshare запускает программу (опционально) в новом namespace. Флаг -u говорит ей запустить bash в новом UTS namespace. Обратите внимание, что наш новый процесс bash указывает на другой файл uts , тогда как все остальные остаются прежними.

Создание новых namespaces обычно требует доступа с правами суперпользователя. Здесь и далее мы будем считать, что как unshare , так и наша реализация выполняются с помощью sudo .

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

Но что, например, такое контейнер?

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

Например, когда вы набираете docker run —net=host redis , всё, что вы делаете — говорите докеру не создавать новый Network namespace для процесса redis. И, как мы видели, Linux добавит этот процесс участником дефолтного Network namespace, как и любой другой обычный процесс. Таким образом, с точи зрения сети процесс redis точно такой же, как и все остальные. Это возможность настройки не только сети, docker run позволяет вам делать такие изменения для большей части существующих namespaces. Тут возникает вопрос, что же такое контейнер? Остаётся ли контейнером процесс, использующий все, кроме одного, общие namespace? ¯\_(ツ)_/¯ Обычно контейнеры идут вместе с понятием изоляции, достигаемой через namespaces: чем меньше количество namespaces и ресурсов, которые процесс делит с остальными, тем более он изолирован и это всё, что действительно имеет значение.

Изолирование

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

В зависимости от области применения, мы сфокусируемся на User, Mount, PID и Network namespaces. Остальные же будут относительно тривиальны для реализации после того, как мы закончим (фактически, мы добавим поддержку UTS здесь в первичной реализации программы). А рассмотрение, например, Cgroups, выходит за рамки этой серии (изучение cgroups — другого компонента контейнеров, используемого для управления тем, сколько ресурсов может использовать процесс).

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

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

Реализация

Исходный код для этого поста можно найти здесь. Наша реализация isolate будет простой программой, которая считывает строку с командой из stdin и клонирует новый процесс, выполняющий её с указанными аргументами. Клонированный процесс с командой будет выполняться в собственном UTS namespace точно также, как мы делали это ранее с unshare . В следующих постах мы увидим, что namespaces не обязательно работают (или хотя бы обеспечивают изоляцию) из коробки и нам нужно будет выполнить некоторую настройку после их создания (но перед реальным запуском команды), чтобы команда действительно выполнялась изолированной.

Эта комбинация создания-настройки namespace потребует некоторого взаимодействия между основным процессом isolate и дочерним процессом запускаемой команды. В результате часть основной работы здесь будет заключаться в настройке связующего канала между обоими процессами — в нашем случае мы будем использовать Linux pipe из-за его простоты.

Нам нужно сделать три вещи:

1. Создать основной процесс isolate , читающий данные из stdin.
2. Клонировать новый процесс, который будет запускать команду в новом UTS namespace.
3. Настроить пайп таким образом, чтобы процесс выполнения команды начинал её запуск только после получения сигнала от основного процесса о завершении настройки namespace.

Вот основной процесс:

Обратите внимание на clone_flags , которые мы передаем в наш вызов clone . Видите, как просто создать процесс в его собственном namespace? Всё, что нам нужно сделать, это установить флаг для типа namespace ( CLONE_NEWUTS флаг соответствует UTS namespace), а Linux позаботится об остальном.

Далее процесс команды ожидает сигнала перед её запуском:

Наконец, мы может попробовать это запустить:

Сейчас isolate — это немногим больше, чем программа, которая просто форкает команду (у нас есть UTS, работающий для нас). В следующем посте мы сделаем еще один шаг, рассмотрев User namespaces заставим isolate выполнять команду в собственном User namespace. Там мы увидим, что на самом деле надо проделать некоторую работу, чтобы иметь пригодный к использованию namespace, в котором может выполняться команда.

Источник