книги хакеры / журнал хакер / 201_Optimized

				hang		e
			C				E
		X
	-							d
	F								t
	D								i
									r
P						NOW!			o
					BUY
				to
w Click										m
w
	w								o
	.							.c
		p					g
			df			n		e
				-xcha

Поддельный

YouTube, на кото-

рыйперенаправлял жертву червь

Koobface

				hang		e
			C				E
		X
	-							d
	F								t
	D								i
									r
P						NOW!			o
					BUY
				to
w Click										m
w
	w								o
	.							.c
		p					g
			df			n		e
				-x cha

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

ПОЧЕМУ НА САМОМ ДЕЛЕ UNIX-СИСТЕМЫ СВОБОДНЫ ОТ ВИРУСОВ

•Низкая популярность. Самая популярная UNIX-система Linux имеет долю пользователей на уровне 1% от общего числа домашних ПК. Этого явно мало, чтобы заинтересовать вирусописателей.

•Жесткая система разграничения прав. В отличие от Windows, в UNIX не принято постоянно сидеть под учеткой суперпользователя. Многие *nix-си- стемы и Linux-дистрибутивы явно запрещают это делать.

•Фрагментация. Существует огромное количество разных UNIX-систем

и Linux-дистрибутивов, что существенно усложняет разработку вирусов.

				hang		e
			C				E
		X
	-							d
	F								t
	D								i
									r
P						NOW!			o
					BUY
				to
w Click										m
w
	w								o
	.							.c
		p					g
			df			n		e
				-xcha

					hang		e
				C				E
			X
		-							d
		F								t
		D								i
										r
	P						NOW!			o
						BUY
					to
w Click											m
w
		w								o
		.							.c
			p					g
				df			n		e
					-x cha

•Нестабильный ABI. Разработчики UNIX-систем и в особенности Linux не слишком беспокоятся о сохранении обратной совместимости ABI, поэтому после обновления системы/ядра вирус может просто не заработать.

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

ВЫВОДЫ

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

				hang		e
			C				E
		X
	-							d
	F								t
	D								i
									r
P						NOW!			o
					BUY
											Unixoid
			df-xchan
w Click				to						m
w
	w								o
	.							.c
		p					g
								e

				hang		e
			C				E
		X
	-							d
	F								t
	D								i
									r
P						NOW!			o
					BUY
				to
w Click										m
w
	w								o
	.							.c
		p					g
			df			n		e
				-x cha

УВЕЛИЧИВАЕМ

ОБОРОТЫ

РАЗБИРАЕМСЯ С BCACHEFS — НОВОЙ ФАЙЛОВОЙ СИСТЕМОЙ ДЛЯ LINUX

Мартин

«urban.prankster»

Пранкевич [e-mail]

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

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

hang

e

hang

e

C

E

C

E

X

X

-

d

-

d

F

t

F

t

D

i

D

i

r

r

P

NOW!

o

P

NOW!

o

BUY

BUY

to

to

w Click

m

w Click

m

w

w

w

o

w

o

.

g

.c

.

g

.c

p

p

df

n

e

df

n

e

-xcha

-x cha

ЧТО ИМЕЕМ?

Традиционные технологии — использование кеша в ОЗУ и RAID 0, позволяющие наращивать скорость операций ввода-вывода, — уже не устраивают из-за слишком большого объема обрабатываемых данных и повышенного требования к надежности. Возможность вынести журнал на внешний SSD-диск, например в ext4, помогает увеличить производительность ФС, но глобально это не настолько влияет на ситуацию. И хотя все они по-прежнему распространены, технология совместного использования SSD + HDD оказалась наиболее интересной, так как позволяла нарастить производительность при относительно низкой цене. Идея в общем проста: SSD-накопители выступают в качестве кеширующего устройства к одному или нескольким медленным жестким дискам. При запросе данные сперва проверяются на наличие в кеше и, если они там есть, отдаются оттуда. Кеширование реализовано на уровне блочного устройства, что позволяет реализовать такую схему независимо от файловых систем и использовать везде, где есть необходимость в быстрых I/O-опера- циях: на рабочих станциях, серверах, в массивах хранения данных. Появились гибридные приводы, которые изначально сочетают обе технологии. Такие приводы поддерживаются Win 8.1 и выше, для Linux 3.19+ или с использованием патча. Интерес был очень высок, и в результате практически одновременно стартовали четыре проекта, имевшие сходные идеи.

Dm-cache — решение, основанное на блочном устройстве device mapper

иреализованное в виде модуля ядра. Зависит от модуля dm_mod.ko, появившегося в относительно новых ядрах (для старых есть патч). Может быть прозрачно подключено к любому устройству хранения, в том числе и к сетям SAN, iSCSI и AoE. Поддерживает LVM. С версии 3.9 добавлен в ядро, в дистрибутивах часто собран в виде модуля, поэтому ставится просто. Dm-cache заботится о долговечности SSD, для этого часто меняющиеся данные не записываются в кеш. В настоящее время поддерживается три политики кеширования: multiqueue, stochastic multiqueue (фактически улучшенная multiqueue, по умолчанию) и очистка. Основная проблема работы с dm-cache — это сложность настройки, ведь требуется три диска: с данными, для кеша и для метаданных кеша. Размер метаданных нужно правильно подсчитать. Поэтому его

ине очень любят. Но в случае, когда запись изменений в кеше откладывается (write-back), dm-cache показывает неплохой результат.

Flashcache создан в Facebook для решения проблем с масштабированием производительности InnoDB/MySQL, выпущен под лицензией GNU GPL. Реализован в виде модуля для ядра Linux (потребуется его сборка), работающего в стеке device mapper. Судя по активности на GitHub, основной код давно не обновлялся, хотя есть фиксы, устраняющие проблемы сборки с новыми ядрами третьей ветки. Не собирается в 32-битных Linux. Для использования на корневой файловой системе или LVM PV необходим модуль Dracut. Может

hang

e

hang

e

C

E

C

E

X

X

-

d

-

d

F

t

F

t

D

i

D

i

r

r

P

NOW!

o

P

NOW!

o

BUY

BUY

to

to

w Click

m

w Click

m

w

w

w

o

w

o

.

g

.c

.

g

.c

p

p

df

n

e

df

n

e

-xcha

-x cha

работать с двумя SSD, собранными как RAID 0 или RAID 1. Поддерживаются четыре политики кеширования: write-back (отложенная запись, данные пишутся на SSD, затем на медленный диск через время, определенное политиками), write-through (сквозная запись, данные пишутся на HDD, а затем в кеш), writearound (данные кешируются на SSD и сразу записываются на диск) и WriteOnly (вариант write-back, при котором кешируются только входящие данные). Настройке поддаются все параметры: размер блока, объем кеш-памяти, алгоритмы вытеснения FIFO или LRU (менее используемые блоки) и многое другое. Данные можно помечать как некешируемые.

EnhanceIO — форк flashcache, разрабатываемый в корпорации STEC и курируемый Дарриком Вонгом (Darrick Wong) из Oracle. Некоторые компоненты

иалгоритмы полностью изменены, в результате он потребляет меньше ресурсов и в режиме параллельной записи (write-through) работает быстрее. Здесь не используется device mapper, поэтому появляется возможность подключать

иотключать кеширование без остановки системы на лету. Может работать

слюбым устройством: диском, разделом, software RAID, RAID DAS, SAN. Реализовано три режима: read-only, write-through и write-back — и три политики замещения: random (фактически round-robin), FIFO и LRU. Планировалось включение в ядро 3.10, но пока придется собирать все самостоятельно.

Dm-cache входит в состав ядра Linux

Все эти проекты нельзя назвать заброшенными, но и активно они не развиваются. Для flashcache и EnhanceIO потребуется пересборка ядра, а dm-cache хотя и предлагается некоторыми хостерами, но все-таки сложен. Наиболее интересен Bcache и новое решение на его основе Bcachefs.

ПРОЕКТ BCACHEFS

В начале был Bcache (block cache) — проект, запущенный в 2010 году как личный проект Кента Оверстрита (Kent Overstreet). Позже он заинтересовал Google, и некоторое время Кент продолжал развитие Bcache, работая в этой корпорации. К 2012 году Bcache уже представлял собой вполне стабильный релиз, а с версии Linux ядра 3.10 (2013 год) входит в состав ядра. Реализован, как и прочие подобные решения, в виде блочного устройства. Доступны две основные политики кеширования: write-back и write-through (по умолчанию). При write-through операция записи считается завершенной после сохранения

hang

e

hang

e

C

E

C

E

X

X

-

d

-

d

F

t

F

t

D

i

D

i

r

r

P

NOW!

o

P

NOW!

o

BUY

BUY

to

to

w Click

w Click

m

w

w

w

o

w

o

.

g

.c

.

g

.c

p

p

df

n

e

df

n

e

-xcha

данных на обоих дисках. Это гарантирует целостность, но снижает скорость.

-x cha

Дополнительно реализован так называемый readahead, когда кеш наполняется

не только при записи, но и при операциях чтения. Чтобы повысить эффектив-

ность, последовательные обращения к большому объему данных не кеширу-

ются, в кеш попадают только операции случайного чтения и записи. Учитывая

ограниченный ресурс, случайные операции записи преобразуются с исполь-

зованием btree в последовательное заполнение накопителя. При сбросе дан-

ных на диск данные группируются с учетом минимизации перемещения головок

диска. Один SSD может кешировать несколько HDD, их количество при необ-

ходимости можно менять и устанавливать гарантируемый порог I/O, чтобы из-

бежать перегрузки SSD. Один важный момент. Чтобы нельзя было получить

доступ к этим разделам и нарушить кеш, Bcache требует явного переформа-

тирования разделов, поэтому его удобно разворачивать на чистую систему

или данные предварительно необходимо заархивировать.

Bcache включен

в ядро Linux

Постепенно развивая проект, разработчики пришли к выводу, что блочное устройство содержит компоненты файловой системы, поэтому, пересмотрев подход, можно убрать один уровень и обеспечить более простое использование и управление. Так и появился Bcache File System — Bcachefs. Цель проекта — создать файловую систему, соответствующую ext4 и XFS по производительности и надежности с некоторыми особенностями Btrfs и ZFS. Пока проект официально находится в альфа-стадии, но считается достаточно стабильным. В настоящее время разработчики реализовали большинство базовых возможностей POSIX ФС, в том числе xattrs и ACL. Плюс возможность включения в раздел нескольких устройств (пока только два), репликацию (RAID), кеширование, прозрачное сжатие данных (пока только gzip) и верификацию целостности по контрольным суммам. Файловая система основана на использовании механизма copy-on-write (COW), при котором один файл могут получить несколько устройств, а изменения не приводят к перезаписи данных: новое состояние записывается в новое место, после чего меняется указатель актуального состояния. Несколько устройств могут подключаться слоями, когда более быстрый накопитель используется для кеширования данных медленного диска с нижнего слоя. Необходима оптимизация — в тестах Bcachefs уже

hang

e

hang

e

C

E

C

E

X

X

-

d

-

d

F

t

F

t

D

i

D

i

r

r

P

NOW!

o

P

NOW!

o

BUY

BUY

to

to

w Click

m

w Click

m

w

w

w

o

w

o

.

g

.c

.

g

.c

p

p

df

n

e

df

n

e

-xcha

-x cha

заметно обгоняет Btrfs, но пока отстает от ext4. В будущем планируется добавить и другие атрибуты современной ФС: предварительное резервирование места (fallocate), квоты, снапшоты, SMR (Shingled Magnetic Recording) и RAW режим доступа к flash и другие.

ПРОБУЕМ

Для тестирования Bcachefs достаточно собрать ядро (на момент написания 4.1.0) и утилиту администрирования. Проект не предоставляет архив, поэтому все необходимое (приблизительно 700 Мбайт) качаем из Git.

Сам Bcachefs находится в ветке bcache-dev, утилиты — в dev (в Ubuntu ppa:g2p/ storage не подходит).

Собираем ядро, здесь в общем все стандартно. За основу конфигурации ядра с Bcachefs используем настройки текущего:

Ставим получившиеся deb-пакеты:

Можем перезагружаться с новым ядром. Для настроек Bcachefs используется bcacheadm (в Bcache — make-bcache). Ставим пакеты, необходимые для сборки:

И собираем:

				hang		e
			C				E
		X
	-							d
	F								t
	D								i
									r
P						NOW!			o
					BUY
				to
w Click										m
w
	w								o
	.							.c
		p					g
			df			n		e
				-xcha

Параметры bcacheadm

Теперь можем отформатировать раздел:

Форматируем раздел bcacheadm

					hang		e
				C				E
			X
		-							d
		F								t
		D								i
										r
	P						NOW!			o
						BUY
					to
w Click											m
w
		w								o
		.							.c
			p					g
				df			n		e
					-x cha

И примонтировать раздел, не забыв указать тип файловой системы:

hang

e

hang

e

C

E

C

E

X

X

-

d

-

d

F

t

F

t

D

i

D

i

r

r

P

NOW!

o

P

NOW!

o

BUY

BUY

to

to

w Click

m

w Click

m

w

w

w

o

w

o

.

g

.c

.

g

.c

p

p

df

n

e

df

n

e

-xcha

-x cha

Для включения контрольных сумм и сжатия при монтировании можно дополнительно задать -o data_checksum=crc32c,compression=gzip. Если диска два, их можно положить слоями с автоматическим кешированием между уровнями:

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

Например, возможно указать и бэкенд-устройство при помощи параметра -B:

Правда, такая схема пока не совсем работает. Параметр --cache-mode позволяет задать режим кеширования при форматировании. При необходимости его можно затем изменить, обратившись к /sys/fs/bcache.

Утилита bcacheadm имеет тринадцать основных параметров, но пока работают не все. Например, список устройств выдаст bcacheadm list.

ВЫВОД

Даже простые тесты показывают, что использование связки SSD + HDD дает существенный прирост производительности. В разных ситуациях различные решения приносят свой результат, поэтому следует ориентироваться на конкретную нагрузку и возможность простого развертывания. Bcachefs, вероятно, пока рано рекомендовать для продакшена. Но начинание весьма интересно, и главное, что, в отличие от конкурентов, проект активно развивается.

hang		e
C			E
X
-				d
F					t
D					i
						r
P		NOW!				o
	BUY
								UNIXOID
df-xchan
to							m
w Click
w
w						o
.				.c
p			g
				e		ДИЕТА ДЛЯ

ВЕРВЕТКИ Роман Ярыженко [e-mail]

				hang		e
			C				E
		X
	-							d
	F								t
	D								i
									r
P						NOW!			o
					BUY
				to
w Click										m
w
	w								o
	.							.c
		p					g
			df			n		e
				-x cha

УМЕНЬШАЕМ КОЛИЧЕСТВО ИСПОЛЬЗУЕМОЙ ПАМЯТИ В UBUNTU 15.04 БЕЗ ОГРАНИЧЕНИЯ ВИДИМОЙ ФУНКЦИОНАЛЬНОСТИ