Методика формирования Golden Baseline образа системы

1. Назначение Golden Baseline

Golden Baseline следует рассматривать не просто как «образ исправной SD-карты», а как воспроизводимый эталон устройства:

• аппаратная конфигурация;
• версии прошивок;
• загрузчик;
• Device Tree;
• ядро Linux;
• операционная система;
• установленные пакеты;
• systemd-сервисы;
• конфигурационные файлы;
• прикладное ПО;
• контрольные суммы;
• результаты приемочных испытаний;
• бинарный образ системного накопителя.

Сам бинарный образ является только одним из артефактов Golden Baseline.

Общий процесс формирования Golden Baseline:

Audit
  ↓
Stabilization
  ↓
Hardening
  ↓
Validation
  ↓
Freeze
  ↓
Imaging
  ↓
Verification
  ↓
Release

2. Фиксация исходного состояния устройства

До внесения любых изменений необходимо создать As-Is Baseline.

Это еще не Golden Image, а исходная точка, позволяющая проследить все дальнейшие изменения системы.

2.1. Аппаратная конфигурация

Необходимо зафиксировать:

• модель SBC/SoM;
• аппаратную ревизию;
• объем RAM;
• тип и объем eMMC/SD;
• CAN/CAN-FD/LIN-контроллеры;
• CAN/CAN-FD/LIN-трансиверы;
• LTE-модем;
• GNSS-приемник;
• USB-периферию;
• схему питания;
• версии прошивок MCU;
• версию прошивки LTE-модема;
• физическую разводку интерфейсов.

2.2. Состояние Linux

Создаем каталог:

mkdir -p /root/baseline-as-is

Сохраняем основную информацию:

uname -a > /root/baseline-as-is/uname.txt

cat /etc/os-release \
    > /root/baseline-as-is/os-release.txt

cat /proc/cmdline \
    > /root/baseline-as-is/cmdline.txt

Информация о накопителях:

lsblk -o NAME,SIZE,TYPE,FSTYPE,PARTUUID,UUID,MOUNTPOINTS \
    > /root/baseline-as-is/lsblk.txt

blkid \
    > /root/baseline-as-is/blkid.txt

df -hT \
    > /root/baseline-as-is/df.txt

mount \
    > /root/baseline-as-is/mount.txt

Список установленных пакетов:

dpkg-query -W -f='${binary:Package}\t${Version}\n' \
    > /root/baseline-as-is/packages.txt

Состояние systemd:

systemctl list-unit-files \
    > /root/baseline-as-is/systemd-unit-files.txt

systemctl --failed \
    > /root/baseline-as-is/systemd-failed.txt

Журналы:

dmesg -T \
    > /root/baseline-as-is/dmesg.txt

journalctl -b \
    > /root/baseline-as-is/journal-current-boot.txt

Сетевая конфигурация:

ip -details link show \
    > /root/baseline-as-is/ip-link.txt

ip addr show \
    > /root/baseline-as-is/ip-address.txt

ip route show table all \
    > /root/baseline-as-is/ip-route.txt

USB и PCI:

lsusb -v \
    > /root/baseline-as-is/usb.txt 2>&1

lspci -nnk \
    > /root/baseline-as-is/pci.txt 2>&1

Контрольные суммы /boot:

find /boot -type f -exec sha256sum {} \; \
    > /root/baseline-as-is/boot.sha256

1. Фиксация Device Tree

Для ARM-систем необходимо отдельно сохранить фактически загруженный Device Tree.

Например:

dtc -I fs -O dts /sys/firmware/devicetree/base \
    > /root/baseline-as-is/running-device-tree.dts

Это особенно важно при аудите:

• GPIO;
• SPI;
• IRQ;
• CAN;
• CAN-FD;
• UART;
• I2C;
• другой аппаратной периферии.

Необходимо анализировать не только исходный .dts, но и фактически загруженную конфигурацию Device Tree.

1. Создание исходного forensic-образа

До внесения исправлений рекомендуется снять полный raw-образ системного накопителя.

Он необходим для:

• расследования регрессий;
• восстановления исходной системы;
• сравнения с Golden Baseline;
• доказательства исходного состояния устройства.

Устройство необходимо корректно выключить, а накопитель подключить к отдельной Linux-системе.

Определяем накопитель:

lsblk -o NAME,MODEL,SERIAL,SIZE,FSTYPE,MOUNTPOINTS

Например, если это /dev/sdX:

sudo dd if=/dev/sdX \
        of=logger_AS-IS_20260928.img \
        bs=16M \
        status=progress \
        conv=fsync

Создаем SHA-256:

sha256sum logger_AS-IS_20260928.img \
    > logger_AS-IS_20260928.img.sha256

Важно: этот образ является AS-IS snapshot, а не Golden Image.

1. Проведение инженерного аудита

Golden Baseline формируется только после завершения инженерного аудита.

Пример структуры аудита:

Golden Baseline нельзя получать непосредственно из системы, которая еще находится в процессе аудита.

Сначала должны быть закрыты:

• Blocker;
• Critical;
• обязательные для релиза Major.

1. Формирование журнала изменений

Каждое отличие будущей Golden-системы от исходного состояния должно быть документировано.

Например:

GB-001  Disabled unused Bluetooth service
GB-002  Removed avahi-daemon
GB-003  Fixed CAN1 Device Tree configuration
GB-004  Changed CAN IRQ affinity
GB-005  Enabled application watchdog
GB-006  Added log rotation
GB-007  Disabled unused SSH password authentication
GB-008  Updated logger.service dependencies

Для каждого изменения рекомендуется фиксировать:

ID
Причина
Исходное состояние
Изменение
Полученное состояние
Метод проверки
Результат
Ссылка на замечание аудита

Таким образом Golden Baseline становится документированным результатом инженерного аудита.

1. Формирование Release Candidate

После исправления замечаний формируется Release Candidate:

Logger OS RC1

На этом этапе необходимо прекратить экспериментальные изменения системы.

Из Release Candidate удаляются:

• debug scripts;
• временные тестовые сервисы;
• временные файлы;
• tcpdump/candump captures;
• core dumps;
• тестовые базы данных;
• developer SSH keys;
• shell history;
• временные credentials;
• тестовые Wi-Fi credentials;
• старые конфигурационные файлы;
• *.bak;
• прочие артефакты разработки.

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

1. Создание inventory Release Candidate

Рекомендуется создать каталог:

/etc/golden-baseline/

Например:

/etc/golden-baseline/
├── manifest.txt
├── packages.txt
├── kernel.txt
├── boot.txt
├── device-tree.dts
├── systemd.txt
├── network.txt
├── hardware.txt
├── firmware.txt
├── application.txt
├── checksums.sha256
└── build-info.json

Машиночитаемый файл build-info.json может выглядеть следующим образом:

{
  "product": "Automotive Logger",
  "baseline": "GB-1.0",
  "build": "2026.09.28",
  "os": "Debian 12",
  "architecture": "arm64",
  "kernel": "...",
  "hardware_revision": "...",
  "application_version": "...",
  "audit_report": "...",
  "status": "RELEASE_CANDIDATE"
}

1. Проверка systemd

Проверяем наличие failed units:

systemctl --failed

Ожидаемый результат:

0 loaded units listed.

Проверяем цепочку загрузки:

systemd-analyze
systemd-analyze critical-chain
systemd-analyze blame

Проверяем прикладные сервисы:

systemctl status logger.service

Необходимо протестировать как минимум следующие сценарии:

Cold boot
Warm reboot
Power loss
Power restore
LTE unavailable
GNSS unavailable
CAN disconnected
CAN bus-off
S3 unavailable
Disk nearly full
Application crash

После каждого сценария устройство должно возвращаться в определенное рабочее состояние.

1. Проверка ядра Linux

После чистой загрузки:

dmesg --level=emerg,alert,crit,err,warn

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

FIXED

или:

ACCEPTED / JUSTIFIED

Требование полного отсутствия warning не всегда является технически обоснованным.

Главное требование — отсутствие необъясненных ошибок и предупреждений.

Для принятого предупреждения рекомендуется создавать запись:

Known Issue KI-003

Message: ...
Cause: ...
Impact: none
Decision: accepted

1. Functional Acceptance Test

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

Например:

ip -details link show can0
ip -details link show can1

Для CAN/CAN-FD проверяются:

• bitrate;
• data bitrate;
• прием;
• передача;
• счетчики ошибок;
• Bus-Off;
• автоматическое восстановление;
• потеря кадров;
• нагрузка на шину.

Необходимо проверять весь end-to-end тракт:

Vehicle CAN
       ↓
Transceiver
       ↓
CAN controller
       ↓
Linux SocketCAN
       ↓
Logger
       ↓
Buffer
       ↓
Storage
       ↓
Compression
       ↓
LTE
       ↓
S3

Наличие интерфейса can0 само по себе не означает успешного прохождения теста.

1. Stress Test

После функциональной проверки необходимо провести длительный стресс-тест.

Рекомендуемая длительность:

24 часа — предварительный тест
72 часа — qualification run

Одновременно создается нагрузка на:

• CAN/CAN-FD;
• CPU;
• RAM;
• накопитель;
• LTE;
• сеть;
• GNSS;
• приложение;
• log rotation.

Контролируются:

journalctl
dmesg
free
df
vmstat
iostat
ip -s link

Дополнительно необходимо контролировать:

• температуру SoC;
• thermal throttling;
• CAN errors;
• dropped frames;
• filesystem errors;
• application restarts;
• watchdog events;
• ошибки LTE;
• ошибки GNSS;
• потерю данных.

1. Power Cycle Test

Для автомобильного устройства Power Cycle Test является обязательным.

Пример:

100–1000 циклов

POWER ON
   ↓
BOOT
   ↓
WORK
   ↓
POWER OFF

Часть циклов должна имитировать реальное исчезновение автомобильного питания.

После испытаний проверяются:

fsck
journalctl
dmesg

Необходимо подтвердить отсутствие повреждений:

• файловой системы;
• базы данных;
• конфигурации;
• журналов;
• прикладных данных.

1. Freeze

После успешного Acceptance Test:

RC
 ↓
FROZEN

С этого момента любые изменения системы аннулируют текущего кандидата Golden Image.

Например:

apt install ...

или:

apt upgrade

означают изменение Release Candidate и необходимость повторного выполнения соответствующих тестов.

1. Удаление персонализируемых данных

Перед созданием Golden Image необходимо определить, какие данные должны быть одинаковыми для всех устройств, а какие должны генерироваться индивидуально.

Как правило, нельзя клонировать:

• SSH host keys;
• machine-id;
• device certificates;
• LTE/device credentials;
• серийный номер устройства;
• уникальные API credentials;
• индивидуальные S3 credentials.

Например:

truncate -s 0 /etc/machine-id
rm -f /var/lib/dbus/machine-id

SSH host keys также могут удаляться перед клонированием, если система provisioning гарантированно создает новые ключи при первом запуске.

Удаление уникальных идентификаторов допустимо только при наличии проверенного механизма first-boot provisioning.

1. Создание manifest

Перед окончательным выключением Release Candidate необходимо сохранить точное состояние системы.

Список пакетов:

dpkg-query -W -f='${binary:Package}\t${Version}\n' \
    > /etc/golden-baseline/packages.txt

Версия ядра:

uname -a \
    > /etc/golden-baseline/kernel.txt

Список systemd units:

systemctl list-unit-files \
    > /etc/golden-baseline/systemd.txt

Контрольные суммы критических файлов:

find /boot /etc /opt/logger \
    -type f \
    -exec sha256sum {} \; \
    > /etc/golden-baseline/files.sha256

Создавать контрольные суммы для постоянно изменяющихся runtime-каталогов, например всего /var, обычно не требуется.

1. Корректное выключение эталонной системы

После Freeze:

sync
shutdown -h now

После этого эталонный накопитель не следует снова загружать до снятия Golden Image.

Повторная загрузка изменяет:

• журналы;
• timestamps;
• runtime state;
• некоторые системные файлы.

1. Создание Golden Image

Накопитель подключается к доверенной Linux-машине.

Определяем устройство:

lsblk -o NAME,MODEL,SERIAL,SIZE

Например:

/dev/sdb

Создаем полный образ:

sudo dd if=/dev/sdb \
        of=LOGGER_GOLDEN_1.0.img \
        bs=16M \
        iflag=fullblock \
        status=progress

После завершения:

sync

Создаем SHA-256:

sha256sum LOGGER_GOLDEN_1.0.img

Сохраняем контрольную сумму:

sha256sum LOGGER_GOLDEN_1.0.img \
    > LOGGER_GOLDEN_1.0.img.sha256

1. Проверка восстановления Golden Image

Созданный образ нельзя считать Golden, пока не проверено его восстановление.

Берется другой накопитель.

Записываем образ:

sudo dd if=LOGGER_GOLDEN_1.0.img \
        of=/dev/sdX \
        bs=16M \
        oflag=direct \
        status=progress

sync

Устанавливаем накопитель в устройство.

Выполняем Golden Image Verification Test.

Пример checklist:

Boot                   PASS
Kernel                 PASS
Device Tree            PASS
GPIO                   PASS
SPI                    PASS
CAN0                    PASS
CAN1                    PASS
CAN-FD                  PASS
GNSS                    PASS
LTE                     PASS
Storage                 PASS
Logger service          PASS
Data logging            PASS
Compression             PASS
S3 upload               PASS
Watchdog                PASS
Power recovery          PASS
Unique provisioning     PASS

Только после успешного выполнения Verification Test образ получает статус:

GOLDEN

1. Проверка бинарной целостности

При необходимости можно выполнить дополнительную проверку записанного накопителя.

До первого запуска системы считываем его обратно:

dd if=/dev/sdX \
   of=verification.img \
   bs=16M \
   status=progress

После чего сравниваем соответствующие бинарные данные или SHA-256.

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

Поэтому выполняются две независимые проверки:

Image Integrity
      +
Functional Integrity

Image Integrity проверяется до первого запуска.

Functional Integrity проверяется после запуска системы.

1. Формирование Golden Baseline Package

Golden Baseline не должен состоять только из файла .img.

Рекомендуемая структура релиза:

LOGGER_GB_1.0/
│
├── image/
│   ├── LOGGER_GB_1.0.img
│   └── LOGGER_GB_1.0.img.sha256
│
├── manifest/
│   ├── build-info.json
│   ├── packages.txt
│   ├── files.sha256
│   ├── kernel.txt
│   ├── device-tree.dts
│   ├── systemd.txt
│   └── firmware.txt
│
├── audit/
│   └── Engineering_Audit_GB_1.0.pdf
│
├── tests/
│   ├── Acceptance_Test.pdf
│   ├── Stress_Test.pdf
│   ├── Power_Cycle_Test.pdf
│   └── Golden_Image_Verification.pdf
│
├── provisioning/
│   └── first-boot-provisioning.md
│
└── RELEASE_NOTES.md

Именно весь этот комплект следует рассматривать как Golden Baseline.

1. Версионирование Golden Baseline

Рекомендуемая схема:

GB-1.0.0

Например:

LOGGER-GB-1.0.0-20260928

Для каждого Golden Baseline необходимо фиксировать:

Golden Baseline ID
Hardware revision
PCB revision
OS version
Kernel version
Bootloader version
DTB version/hash
Application version
Configuration version
Firmware versions
Image SHA-256
Audit report revision
Acceptance test revision
Build date
Approval

Golden Baseline должен быть связан с конкретной аппаратной ревизией:

LOGGER HW 1.2
      ↕
LOGGER-GB-1.0.0

Нельзя автоматически считать один и тот же Golden Image валидированным для другой аппаратной ревизии.

1. Изменение Golden Baseline

Golden Image нельзя модифицировать «на месте».

Правильная процедура:

GB-1.0.0
   │
   ↓
Change Request
   │
   ↓
Development Image
   │
   ↓
RC-1.1.0
   │
   ↓
Regression Tests
   │
   ↓
Freeze
   │
   ↓
Image
   │
   ↓
Restore Test
   │
   ↓
GB-1.1.0

Предыдущая версия:

GB-1.0.0

остается неизменной и доступной для:

• восстановления;
• сравнения;
• расследования регрессий;
• анализа отказов.

1. Критерий готовности Golden Baseline

Golden Baseline — это зафиксированное, воспроизводимое и верифицированное состояние программно-аппаратной конфигурации устройства, успешно прошедшее инженерный аудит, функциональные, стрессовые и отказоустойчивые испытания и предназначенное для использования в качестве эталона при производстве, восстановлении, регрессионном тестировании и расследовании отказов.

1. Итоговая последовательность

                    ┌──────────────┐
                    │  Устройство  │
                    └──────┬───────┘
                           │
                           ▼
                    Фиксация AS-IS
                           │
                           ▼
                     AS-IS IMAGE
                           │
                           ▼
                  Инженерный аудит
                           │
                           ▼
                ┌──────────────────┐
                │ Найдены проблемы │
                └────────┬─────────┘
                         │
                         ▼
                     Исправление
                         │
                         ▼
                  Release Candidate
                         │
                         ▼
              Functional Acceptance
                         │
                         ▼
                    Stress Test
                         │
                         ▼
                  Power Cycle Test
                         │
                         ▼
                   Security Check
                         │
                         ▼
                       FREEZE
                         │
                         ▼
                Golden Image Capture
                         │
                         ▼
                  SHA-256 / Manifest
                         │
                         ▼
             Restore на чистый носитель
                         │
                         ▼
                 Verification Test
                         │
                         ▼
                ┌─────────────────┐
                │ GOLDEN BASELINE │
                │      1.0        │
                └─────────────────┘

1. Основной принцип

Golden Baseline должен обеспечивать одновременно четыре свойства:

1. Идентифицируемость — известно точное аппаратное и программное состояние устройства.
2. Воспроизводимость — из Golden Image можно получить эквивалентное рабочее устройство.
3. Верифицируемость — целостность образа и системы можно доказуемо проверить.
4. Трассируемость — каждое изменение относительно исходного состояния связано с результатами инженерного аудита, исправлением или утвержденным Change Request.

Таким образом, Golden Baseline является не просто резервной копией системы, а официальным эталонным состоянием изделия, относительно которого выполняются производство, приемка, обновление, регрессионное тестирование, восстановление и расследование отказов.