Mem write linux install

5 commands to check memory usage on Linux

Memory Usage

On linux, there are commands for almost everything, because the gui might not be always available. When working on servers only shell access is available and everything has to be done from these commands. So today we shall be checking the commands that can be used to check memory usage on a linux system. Memory include RAM and swap.

It is often important to check memory usage and memory used per process on servers so that resources do not fall short and users are able to access the server. For example a website. If you are running a webserver, then the server must have enough memory to serve the visitors to the site. If not, the site would become very slow or even go down when there is a traffic spike, simply because memory would fall short. Its just like what happens on your desktop PC.

1. free command

The free command is the most simple and easy to use command to check memory usage on linux. Here is a quick example

The m option displays all data in MBs. The total os 7976 MB is the total amount of RAM installed on the system, that is 8GB. The used column shows the amount of RAM that has been used by linux, in this case around 6.4 GB. The output is pretty self explanatory. The catch over here is the cached and buffers column. The second line tells that 4.6 GB is free. This is the free memory in first line added with the buffers and cached amount of memory.

Linux has the habit of caching lots of things for faster performance, so that memory can be freed and used if needed.
The last line is the swap memory, which in this case is lying entirely free.

2. /proc/meminfo

The next way to check memory usage is to read the /proc/meminfo file. Know that the /proc file system does not contain real files. They are rather virtual files that contain dynamic information about the kernel and the system.

Check the values of MemTotal, MemFree, Buffers, Cached, SwapTotal, SwapFree.
They indicate same values of memory usage as the free command.

3. vmstat

The vmstat command with the s option, lays out the memory usage statistics much like the proc command. Here is an example

The top few lines indicate total memory, free memory etc and so on.

4. top command

The top command is generally used to check memory and cpu usage per process. However it also reports total memory usage and can be used to monitor the total RAM usage. The header on output has the required information. Here is a sample output

Check the KiB Mem and KiB Swap lines on the header. They indicate total, used and free amounts of the memory. The buffer and cache information is present here too, like the free command.

5. htop

Similar to the top command, the htop command also shows memory usage along with various other details.

The header on top shows cpu usage along with RAM and swap usage with the corresponding figures.

RAM Information

To find out hardware information about the installed RAM, use the demidecode command. It reports lots of information about the installed RAM memory.

Provided information includes the size (2048MB), type (DDR2) , speed(667 Mhz) etc.

Summary

All the above mentioned commands work from the terminal and do not have a gui. When working on a desktop with a gui, it is much easier to use a GUI tool with graphical output. The most common tools are gnome-system-monitor on gnome and
ksysguard on KDE. Both provide resource usage information about cpu, ram, swap and network bandwidth in a graphical and easy to understand visual output.

A Tech Enthusiast, Blogger, Linux Fan and a Software Developer. Writes about Computer hardware, Linux and Open Source software and coding in Python, Php and Javascript. He can be reached at [email protected] .

66 thoughts on “ 5 commands to check memory usage on Linux ”

You have explained the topic very well. Thanks for sharing a nice article.

Thanks for these commands. It saved a lots of time.

How about explaining what we are looking for? Most people would know these commands. Waste of time.

Please correct the typo in “RAM Information” section. The command for viewing hardware info about RAM is “dmidecode” and not “demidecode”.
And it also requires root privileges.

Источник

Внутренности Linux: как /proc/self/mem пишет в недоступную для записи память

Странная причудливость псевдофайла /proc/*/mem заключается в его «пробивной» семантике. Операции записи через этот файл будут успешными даже если целевая виртуальная память помечена как недоступная для записи. Это сделано намеренно, и такое поведение активно используется проектами вроде компилятора Julia JIT или отладчика rr.

Но возникают вопросы: подчиняется ли привилегированный код разрешениям виртуальной памяти? До какой степени оборудование может влиять на доступ к памяти ядра?

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

Патчим libc с помощью /proc/self/mem

Как выглядит эта пробивная семантика? Рассмотрим код:

Здесь /proc/self/mem используется для записи в две недоступные для записи страницы памяти. Первая содержит сам код, а вторая принадлежит libc (функции getchar ). Последняя часть вызывает больший интерес: код записывает байт 0xcc (точка прерывания в приложениях под x86-64), который в случае своего исполнения заставит ядро предоставить нашему процессу SIGTRAP. Это буквально меняет исполняемый код libc. И если при следующем вызове getchar мы получим SIGTRAP, то будем знать, что запись была успешной.

Вот как это выглядит при запуске программы:

Работает! Посередине выводятся выражения, которые доказывают, что значение 0x41414140 было успешно записано и считано из памяти. Последний вывод показывает, что после патчинга наш процесс получил SIGTRAP в результате нашего вызова getchar .

Мы увидели, как эта возможность работает с точки зрения пользовательского пространства. Давайте копнём глубже. Чтобы полностью разобраться в том, как это работает, нужно посмотреть, как оборудование накладывает ограничения на память.

Оборудование

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

Первая настройка — бит защиты от записи, Write Protect bit (CR0.WP). Из руководства Intel (том 3, раздел 2.5) мы знаем:

Защита от записи (16-й бит CR0). Если задана, он не даёт процедурам уровня супервизора записывать в защищённые от записи страницы. Если бит пуст, то процедуры уровня супервизора могут записывать в защищённые от записи страницы (вне зависимости от настроек бита U/S; см. раздел 4.1.3 и 4.6).

Это не позволяет ядру записывать в защищённые от записи страницы, что, естественно, по умолчанию разрешено.

Вторая настройка — предотвращение доступа в режиме супервизора, Supervisor Mode Access Prevention (SMAP) (CR4.SMAP). Полное описание, приведённое в томе 3, в разделе 4.6, многословное. Если вкратце, то SMAP полностью лишает ядро способности записывать или читать из памяти пользовательского пространства. Это предотвращает эксплойты, которые наполняют пользовательское пространство зловредными данными, которые ядро должно прочитать в ходе исполнения.

Если код ядра использует для доступа к пользовательскому пространству только одобренные каналы ( copy_to_user и т.д.), то SMAP можно смело игнорировать, эти функции автоматически задействуют его до и после обращения к памяти. А что насчёт защиты от записи?

Если CR0.WP не задан, то реализация /proc/*/mem в ядре действительно сможет бесцеремонно записывать в защищённую от записи память пользовательского пространства.

Однако CR0.WP задаётся при загрузке и обычно живёт в течение всего времени работы систем. В этом случае при попытке записи будет выдаваться сбой страницы. Это, скорее, инструмент для копирования при записи (Copy-on-Write), чем средство защиты, поэтому не накладывает на ядро никаких реальных ограничений. Иными словами, требуется неудобная обработка сбоев, которая не обязательна при заданном бите.

Давайте теперь разберёмся с реализацией.

Как работает /proc/*/mem

Структура file_operations содержит функции обработчика, а функция mem_rw() полностью поддерживает обработчик записи. mem_rw() использует для операций записи access_remote_vm(). А access_remote_vm() делает вот что:

• Вызывает get_user_pages_remote() , чтобы найти физический фрейм, соответствующий целевому виртуальному адресу.
• Вызывает kmap() , чтобы пометить этот фрейм доступный для записи в виртуальном адресном пространстве ядра.
• Вызывает copy_to_user_page() для финального выполнения операций записи.

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

Рассмотрим каждый из этапов:

get_user_pages_remote()

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

Вызывающий предоставляет контекст и с помощью флагов меняет поведение get_user_pages() . Особенно интересен флаг FOLL_FORCE , который передаётся mem_rw() . Флаг запускает check_vma_flags (логику проверки доступа в get_user_pages() ), чтобы игнорировать запись в незаписываемые страницы и продолжить поиск. «Пробивная» семантика полностью относится к FOLL_FORCE (комментарии мои):

get_user_pages() стоже соблюдает семантику копирования при записи (CoW). Если определяется запись в таблицу незаписываемой страницы, то эмулируется сбой страницы с помощью вызова handle_mm_fault , основного обработчика страничных ошибок. Это запускает соответствующую подпрограмму обработки копирования при записи посредством do_wp_page , которая при необходимости копирует страницу. Так что если записи через /proc/*/mem выполняются приватным разделяемым маппингом, например, libc, то они видимы только в рамках процесса.

kmap()

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

На 64-битной платформе x86 вся физическая память отображается через область линейного отображения виртуального адресного пространства ядра. В этом случае kmap() работает очень просто: ему лишь нужно добавить начальный адрес линейного отображения в физический адрес фрейма, чтобы вычислить виртуальный адрес, в который отображён этот фрейм.

На 32-битной платформе x86 линейное отображение содержит подмножество физической памяти, так что функции kmap() может потребоваться отобразить фрейм с помощью выделения highmem-памяти и манипулирования таблицами страницы.

В обоих случая линейное отображение и highmem-отображение выполняются с защитой PAGE_KERNEL, которая позволяет запись.

copy_to_user_page()

Последний этап — выполнение записи. Это делается с помощью copy_to_user_page() , по сути — memcpy. Это работает, поскольку целью является записываемое отображение из kmap() .

Обсуждение

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

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

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

Источник

Получаем образ оперативной памяти

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

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

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

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

Для выполнения этой задачи будем использовать специальный дистрибутив Ubuntu CyberPack (IRF) 1.0, состоящий из минимального набора компонент, а именно, только те, которые необходимы для изъятия данных из памяти. Соответственно отсутствует и графический интерфейс.

Использование такого подхода к изъятию содержимого оперативной памяти имеет ряд преимуществ и недостатков сравнительно с другими перечисленными выше средствами.
Плюсы:
— использование Live-дистрибутива позволяет проводить действие не зависимо от того какая операционная система установлена на исследуемой машине;
— отсутствуют затраты на приобретение дорогостоящих специальных устройств, кабелей, плат, и др.
Недостаток:
— содержимое оперативной памяти будет неполным — ее часть будет перезаписана данными, необходимыми для запуска Live-дистрибутива (приблизительно 125 Мб).

Для использования доступны специально собранные дистрибутивы для машин с памятью объемом до 3 Гб (і386) и свыше 3 Гб (amd64). С их помощью можно создать загрузочный CD/DVD-диск или загрузочный USB-диск.

Замечания:
— второго шанса система нам не дает — у нас есть только одна попытка. т. е. при повторной перезагрузке исследуемого компьютера большая вероятность того что мы уже не найдем необходимой информации. Отсюда следует что не надо перезагружать его несколько раз, экспериментировать, прицеливаться.
Необходимо заранее подготовится и знать как компьютер себя поведет после перезагрузки.
Большинство современных компьютеров позволяют прямо при старте указать откуда производить загрузку, но если этого нет, тогда необходимого настроить BIOS машины на загрузку с CD/DVD-привода или USB-привода/накопителя, после чего загрузить Live-дистрибутив с указанного устройства.

Перезагружаем компьютер.
ВАЖНО: перезагрузка ни в коем случае не должна быть холодной (путем нажатия кнопки «ресет» или выключение\включение питания), а именно — перезагрузка должна быть осуществлена средствами самой работающей системы (например нажатием кнопок Ctrl-Alt-Del или путем выбора пункта «перезагрузка» в системе)

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

Подготовка к работе программы fmem заключается в выполнении следующих команд:
$ sudo -s
# cd /opt (переход в папку где находиться программа);
# ./run-fmem.sh (скрипт запуска модуля съема памяти);

Замечание: Для дальнейших действий понадобиться примонтировать заранее подготовленный носитель (внешний жесткий диск, флеш-накопитель) с файловой системой ext2/3/4, в который будет сохраняться файл с содержимым оперативной памяти.

Для того, что бы узнать какой идентификатор присоединенному носителю присвоила система, необходимо после его подключения к компьютеру ввести следующую команду:
# dmesg | tail (Команда выводит на экран информацию буфера сообщений ядра. Нас будет интересовать последняя запись.)
Как например вот это:
[16091.995428] sd 9:0:0:0: Attached scsi generic sg2 type 0
[16091.995996] sd 9:0:0:0: [sdb] 32096120 512-byte logical blocks: (16.4 GB/15.3 GiB)
[16091.998192] sd 9:0:0:0: [sdb] Write Protect is off
[16091.998205] sd 9:0:0:0: [sdb] Mode Sense: 0b 00 00 08
[16091.999433] sd 9:0:0:0: [sdb] No Caching mode page found
[16091.999447] sd 9:0:0:0: [sdb] Assuming drive cache: write through
[16092.003486] sd 9:0:0:0: [sdb] No Caching mode page found
[16092.003495] sd 9:0:0:0: [sdb] Assuming drive cache: write through
[16092.004251] sdb: sdb1
(где «sdb» — присвоенное обозначение физического накопителя, а «sdb1» — присвоенное обозначение логического раздела накопителя).

Далее следует примонтировать логический раздел накопителя к папке /tmp загруженной в Live-режиме операционной системы:

# mount /dev/sdb1 /tmp
(где
«mount» — команда монтирования устройства
«/dev/sdb1» — адрес файла логического раздела присоединенного накопителя
«/tmp» — папка в которую необходимо подключить накопитель).

Все подготовительные шаги сделаны — можно переходить к изъятию содержимого оперативной памяти:

# dd if=/dev/fmem of=/tmp/ram-image.mem bs=1K count=`head -1 /proc/meminfo | awk ‘‘`
(где
«dd» — команда создания образа
«if=/dev/fmem» — источник данных, а именно оперативная память
«of=/tmp/ram-image.mem» — запись в файл «ram-image.mem» в папку «/tmp»
«bs=1K» — размер блока информации — 1 Кб
«count=`head -1 /proc/meminfo | awk ‘‘`» — объем оперативной памяти, информация о которой извлекается из файла /proc/meminfo).

И ждем…
В результате удачного выполнения команды, мы получим сообщение похожее на это:

521453568 bytes (521 MB) copied, 158.405 s, 3.3 MB/s
(где
«521453568 bytes (521 MB) copied» — объем скопированной информации
«158.405 s» — время в течении которого проводилась операция
«3.3 MB/s» — скорость при которой проводилась операция)

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

P.S.
Также стоит обратить внимание что все современные системы используют в своей работе и swap-память (так называемый «файл подкачки»)
Файл подкачки – это своеобразное дополнение к оперативной памяти (которая занимается временным хранением данных для быстрой доставки их на обработку процессору) Вашего компьютера. Даже не столько дополнение, сколько её уширение или, можно сказать, продолжение. Дело в том, что когда не хватает оперативной памяти система может переносить данные из памяти на диск (так называемая дополнительная память), в котором соответственно также хранятся данные.
И для полной картины анализа памяти необходимо также получить и их.
Различные операционные системы используют разные способы их хранения.

В случае с Windows это обычно файлы в корне на системном диске С:
pagefile.sys для Win XP и Win 7 и достаточно просто скопировать файл

Для Linux — это отдельный раздел на носителе.
Например:
Команда sudo fdisk -l /dev/sda
покажет нам все разделы в системе
/dev/sda1 * 2048 78125055 39061504 83 Linux
/dev/sda2 78125056 117186559 19530752 82 Linux своп / Solaris
/dev/sda3 117186560 625141759 253977600 83 Linux
Исходя из чего мы видим что раздел подкачки находиться в /dev/sda2
Скопировать его можно также с помощию команды dd.
Например:
dd if=/dev/sda2 of=/media/ /linux-swap.dd

Для MacOS необходимо скопировать все файлы из директории /private/var/vm/swapfile*

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

Источник