Много, потому что сервер едва ли что-то делает, а запись небольших данных с использованием надёждых файловых систем даёт значительный write amplification. Я бы хотел снизить это значение до 10 гигабайт.
Я за эти же четыре года ссд два раза поменял по независящим от износа причинам
А я за последние 12 лет трижды износил SSD до невозможности комфортного использования (многосекундные задержки при записи, медленная скорость чтения в районе единиц-десяток мегабайт в секунду), зарабатывал на восстановлении оборудования, которое затёрло NAND-флеш до дыр (переразметкой области флеша или его заменой), исследовал работу памяти и контроллеров в дешевых MicroSD-картах, чтобы уменьшить степень износа и read disturbance со временем, а также имел смартфон, который спустя множество циклов перезаписи флеша держал заряд всего от нескольких месяцев от пол года.
Так там речь не о сервере, а о диске, который работает только в режиме чтения. В целях экономии ресурса.
Речь не об экономии ресурса, а об обновлении ячеек. Заряд у любой NAND флеш-памяти утекает в тех или иных условиях (температура записи, температура хранения, износ ячейки, износ соседних ячеек в блоке (!), и т.п.), и его периодически нужно обновлять, по-хорошему. Утечка происходит и в момент чтения, т.е. постоянное чтение приведёт к невозможности чтения, если не обновлять заряд (не перезаписывать ячейки).
Если вы отвечали только в контексте обновления заряда самим диском, то я вас не так понял, он скорее всего незначителен. Но в целом ресурс записи у NAND-память очень конечен, чтобы не задумываться о нём.
Чем больше циклов записи в ячейку, тем хуже она хранит заряд (тем больше он утекает и тем чаще его необходимо перезаписывать).
Возьмите два диска одной модель из одной партии. На один запишите данные и оставьте его лежать, а другой серьёзно износите записью, затем запишите данные и оставьте желать. Первый, скорее всего, будет работать и через 10 лет, второй, скорее всего, уже через полгода будет едва восстанавливать ecc-данные и читать со скоростью улитки, если вообще.
Тормоза на смартфонах вызваны в немалой мере снижением скорости чтения и записи флеша со временем. А лет 6-8 назад вообще срок службы флеша в бюджетных моделях был около 3 лет, когда «прошивка слетала».
А вы прикидывали хотя бы приблизительно на сколько десятилетий хватает ресурса ссд без всяких экономий?
Не знаю, о каких дисках и каких объёмах вы говорите, но на моём слабозагруженном сервере после череды оптимизаций удалось достигнуть записи порядка 30-50 ГБ/день. За 4 года на диск записалось половина от гарантийного TBW — это много. На десктопе за полтора года записано 27 ТБ, тоже немало.
Технология называется 6to4, сейчас считается depricated, но по факту еще работает
Очень много где не работает, увы: шлюзы всё ещё анонсируют anycast 192.88.99.1 по BGP, но сам сервис (шлюзы) отключён. Я писал нескольким компаниям, чтобы хотя бы убрали анонс, но без ответа. Это, однако, было больше года назад, может сейчас что-то поменялось.
Уже год одна фирма пытается заставить ФСТЭК вести базу данных прошивок различного IoT-оборудования и прочей электроники. Пока безуспешно, насколько вижу.
Системные компоненты естественно с перезагрузкой. При А/B обновлении у вас две копии ОС, и обновления устанавливаются в ту, которая на текущий момент не запущена.
Прочитайте статью по моей ссылке выше, она разъяснит все моменты.
Ключ сейчас по умолчанию только один — Майкрософтовский. На части материнских плат есть еще ключи от Red Hat, Canonical. Они хранятся в HSM (аппаратном хранилище), украсть их нетривиально, просто так утечь не могут.
Чтобы отозвать работу Linux-ПО в UEFI, достаточно отозвать всё до определённой версии через SBAT.
Или вы про rootfs, если поставщик будет его подписывать, и этот ключ утечёт? Можно, чтобы локальный ключ пользователя дополнительно подписывал цепочку загрузки, но не видел, чтобы такое реализовывали (что-то похожее на подписи локально компилируемых DKMS-модулей должно быть, наверное).
Их в любой момент можно отключить, не удаляя из системы, при необходимости отладки. И это не отдельные пакеты, а немногочисленные логические группы (наборы) ПО, которые, например, можно откатить на предыдущую версию единым целым, а не отдельными библиотеками и пакетами.
Атомарно обновляемые системы можно реализовать разными способами, сейчас все пытаются придумать наиболее удобные сочетания. Посмотрим, какой из них в итоге обретёт наибольшую популярность.
Вы про Secure Boot? Эту проблему решили в shim'е специальным маркером версии под названием SBAT: https://github.com/rhboot/shim/blob/main/SBAT.md Позволяет массово отзывать старые версии разных вендоров, не отзывая их ключ.
В более широком смысле, но в предыдущем сообщении я имел конкретно безопасность на этапах загрузки (secure boot, trusted boot, verified boot).
Банально даже такая вещь, как Secure Boot, которая корректно реализована на macOS и Windows лет 12, наверное, в Linux фактически только защищает и верифицирует ядро, а что там в initramfs — доверенном юзерспейсе, который может и PID'ы запущенного ПО скрывать, и файлы на файловой системе перезаписывать, и keylogger установить, и обращаться ко всем системам ядра от root'а, естественно — уже никого не волнует, он не верифицируется во время загрузки.
Шифрование диска с использованием аппаратного доверенного хранилища тоже реализовано в обоих системах, а в Linux по умолчанию TPM никак не используется, а настройка verified boot состоит из костылей и подпорок. Благо опять же Леннарт исправляет эту ситуацию внедрением UKI, чтобы избавиться от проблемы с непроверяемым initramfs. TPM cryptenroll также он реализовал ранее.
И вот в Linux с безопасностью почти везде так — подсистемы в принципе существуют, но ими пользуются только профессионалы из считанных компаний, потому что для их корректного и безопасного использования нужно быть экспертом. А Windows и macOS делают так, что можно раскатывать по умолчанию на миллиарды пользователей.
Это разные инструменты. Снапшот делает слепок вашего текущего состояния всей ОС (файловой системы, каким бы оно ни было, в каком бы состоянии оно ни находилось), а принцип неизменяемого rootfs+слёв его просто исключает: у вас есть версии, и всё (ну разве что состояние ваших собственных слоёв/developer-слоя, если он включён).
Иными словами, после установки обычной ОС состояние файловой системы — головная боль администратора системы (пользователя), а в случае слоёв — поставщика слоёв (разработчика дистрибутива). В первом случае состояние недетерминировано (у меня Fedora 43 и у вас Fedora 43, но я обновлялся на прошлой неделе, а вы сегодня — у нас разный набор пакетов разных версий, и чтобы определить проблему, нужно скрупулёзно сверять всё установленное ПО), а в случае Atomic-дистрибутива у меня Fedora 43.123, и у вас Fedora 43.123, с абсолютно одинаковым набором файлов у всех пользователей конкретной версии.
На практике с этим подходом также применяют A/B-обновления: новые данные записываются в другой слот, и следующая перезагрузка загрузит обновлённую версию. А если что-то пошло не так, автоматика это поймёт и загрузит предыдущий, старый и рабочий слот.
rootfs поставляется производителем дистрибутива в минимальном виде, вместе со всеми метаданными и чексуммами (CAS; dm-verity/fs-verity, заверенный ключом поставщика), обновляется единым целым;
по сети передаётся минимум данных благодаря Content‑Addressable Store (CAS): сначала ваш существующий rootfs хешируется маленькими блоками, а затем с сервера скачивается только разница между новым rootfs и существующим, поблочно (блоки могут быть в разных местах, главное совпадение хеша);
все немногочисленные дополнительные системные пакеты переустанавливаются при каждом обновлении, формируя доп. слой поверх rootfs (почти как docker build);
Вы всегда видите разницу (можете сделать diff) между эталонным образом и вашими изменениями (dev-слоя, например). Если что-то сломалось, можете отбросить dev-слой и загрузиться в неизменённую систему. Dev-слоев может быть несколько (и в глубь, и в ширь), можете безопасно экспериментировать с системой, нужны в переустановке не возникнет никогда, потому что снизу у вас эталонный неизменяемый образ.
Сейчас в подавляющем большинстве дистрибутивов у вас нет понятия эталонной файловой системы, вы не можете посмотреть только ваши изменения поверх ФС, не можете легко их откатить.
При этом rootfs-образ может быть изначально оптимизирован под порядок чтения с него (блоки расположены в том порядке, в котором система к ним обращается во время загрузки, из-за чего с диска производится быстрое последовательное чтение вместо медленного случайного), сжат. Преимуществ много.
Если вы не специалист по безопасности и не отслеживаете индустрию, со стороны здраво оценить состояние дел не представляется возможным: многие критические уязвимости просто не попадают в поле зрения технических СМИ, а другие не расписываются понятным для обычного человека языком, и становятся информационным шумом, а не полезной новостью, на которую можно отреагировать осмысленным действием.
Security-журналистика, нацеленная на простых смертных, мертва. Не уверен, что она вообще существовала.
Вы переусложнением считаете что-то конкретное? В Embedded-индустрии применяется многое, о чём он пишет, да и разрабатываемые, но ещё не мейнстримные дистрибутивы Fedora Atomic / Ubuntu Core Desktop реализуют большинство из описываемого.
Linux в плане безопасности (и удобства использования подсистем безопасности) отстает на годы от конкурентов, увы.
Много, потому что сервер едва ли что-то делает, а запись небольших данных с использованием надёждых файловых систем даёт значительный write amplification. Я бы хотел снизить это значение до 10 гигабайт.
А я за последние 12 лет трижды износил SSD до невозможности комфортного использования (многосекундные задержки при записи, медленная скорость чтения в районе единиц-десяток мегабайт в секунду), зарабатывал на восстановлении оборудования, которое затёрло NAND-флеш до дыр (переразметкой области флеша или его заменой), исследовал работу памяти и контроллеров в дешевых MicroSD-картах, чтобы уменьшить степень износа и read disturbance со временем, а также имел смартфон, который спустя множество циклов перезаписи флеша держал заряд всего от нескольких месяцев от пол года.
Речь не об экономии ресурса, а об обновлении ячеек. Заряд у любой NAND флеш-памяти утекает в тех или иных условиях (температура записи, температура хранения, износ ячейки, износ соседних ячеек в блоке (!), и т.п.), и его периодически нужно обновлять, по-хорошему. Утечка происходит и в момент чтения, т.е. постоянное чтение приведёт к невозможности чтения, если не обновлять заряд (не перезаписывать ячейки).
Если вы отвечали только в контексте обновления заряда самим диском, то я вас не так понял, он скорее всего незначителен. Но в целом ресурс записи у NAND-память очень конечен, чтобы не задумываться о нём.
Чем больше циклов записи в ячейку, тем хуже она хранит заряд (тем больше он утекает и тем чаще его необходимо перезаписывать).
Возьмите два диска одной модель из одной партии. На один запишите данные и оставьте его лежать, а другой серьёзно износите записью, затем запишите данные и оставьте желать.
Первый, скорее всего, будет работать и через 10 лет, второй, скорее всего, уже через полгода будет едва восстанавливать ecc-данные и читать со скоростью улитки, если вообще.
Тормоза на смартфонах вызваны в немалой мере снижением скорости чтения и записи флеша со временем. А лет 6-8 назад вообще срок службы флеша в бюджетных моделях был около 3 лет, когда «прошивка слетала».
Не знаю, о каких дисках и каких объёмах вы говорите, но на моём слабозагруженном сервере после череды оптимизаций удалось достигнуть записи порядка 30-50 ГБ/день. За 4 года на диск записалось половина от гарантийного TBW — это много.
На десктопе за полтора года записано 27 ТБ, тоже немало.
TLC (Triple-Level Cell) это подтип MLC (Multi-Level Cell), как и QLC. У TLC 3 бита заряда, у QLC 4.
Очень много где не работает, увы: шлюзы всё ещё анонсируют anycast 192.88.99.1 по BGP, но сам сервис (шлюзы) отключён. Я писал нескольким компаниям, чтобы хотя бы убрали анонс, но без ответа. Это, однако, было больше года назад, может сейчас что-то поменялось.
Неправильная гальваническая развязка убила пользователю компьютер: https://github.com/sipeed/NanoKVM/issues/40#issuecomment-2400855308
Я подключил устройство к сети и получил ssh root:root, доступный отовсюду: https://github.com/sipeed/NanoKVM/issues/198
Это типичная китайская поделка, увы.
Уже год одна фирма пытается заставить ФСТЭК вести базу данных прошивок различного IoT-оборудования и прочей электроники. Пока безуспешно, насколько вижу.
А зачем:
https://4pda.to/forum/index.php?showtopic=1074858&view=findpost&p=138757647
https://4pda.to/forum/index.php?showtopic=1074858&view=findpost&p=138761715
https://www.ferra.ru/news/tv/umnye-televizory-yandeksa-stali-aktivnee-zakhvatyvat-khakery-v-botnety-22-12-2024.htm
Системные компоненты естественно с перезагрузкой.
При А/B обновлении у вас две копии ОС, и обновления устанавливаются в ту, которая на текущий момент не запущена.
Прочитайте статью по моей ссылке выше, она разъяснит все моменты.
Ключ сейчас по умолчанию только один — Майкрософтовский. На части материнских плат есть еще ключи от Red Hat, Canonical.
Они хранятся в HSM (аппаратном хранилище), украсть их нетривиально, просто так утечь не могут.
Чтобы отозвать работу Linux-ПО в UEFI, достаточно отозвать всё до определённой версии через SBAT.
Или вы про rootfs, если поставщик будет его подписывать, и этот ключ утечёт? Можно, чтобы локальный ключ пользователя дополнительно подписывал цепочку загрузки, но не видел, чтобы такое реализовывали (что-то похожее на подписи локально компилируемых DKMS-модулей должно быть, наверное).
Их в любой момент можно отключить, не удаляя из системы, при необходимости отладки. И это не отдельные пакеты, а немногочисленные логические группы (наборы) ПО, которые, например, можно откатить на предыдущую версию единым целым, а не отдельными библиотеками и пакетами.
Атомарно обновляемые системы можно реализовать разными способами, сейчас все пытаются придумать наиболее удобные сочетания. Посмотрим, какой из них в итоге обретёт наибольшую популярность.
Вы про Secure Boot?
Эту проблему решили в shim'е специальным маркером версии под названием SBAT: https://github.com/rhboot/shim/blob/main/SBAT.md
Позволяет массово отзывать старые версии разных вендоров, не отзывая их ключ.
Это системный компонент, поэтому нет. Полагаю, он будет в составе слоя "такой-то-desktop", который монтируется поверх rootfs.
Ubuntu'вский Snap подходит и для системных компонентов (он может «добавлять» симлинки в /usr/bin и подобные системные директории на свои snap'ы)
Это пользовательское ПО и оно устанавливается в домашнюю директорию (или какую-то общую директорию с ПО), а не в систему.
В Ubuntu Core это Snap'ы.
В более широком смысле, но в предыдущем сообщении я имел конкретно безопасность на этапах загрузки (secure boot, trusted boot, verified boot).
Банально даже такая вещь, как Secure Boot, которая корректно реализована на macOS и Windows лет 12, наверное, в Linux фактически только защищает и верифицирует ядро, а что там в initramfs — доверенном юзерспейсе, который может и PID'ы запущенного ПО скрывать, и файлы на файловой системе перезаписывать, и keylogger установить, и обращаться ко всем системам ядра от root'а, естественно — уже никого не волнует, он не верифицируется во время загрузки.
Шифрование диска с использованием аппаратного доверенного хранилища тоже реализовано в обоих системах, а в Linux по умолчанию TPM никак не используется, а настройка verified boot состоит из костылей и подпорок. Благо опять же Леннарт исправляет эту ситуацию внедрением UKI, чтобы избавиться от проблемы с непроверяемым initramfs. TPM cryptenroll также он реализовал ранее.
И вот в Linux с безопасностью почти везде так — подсистемы в принципе существуют, но ими пользуются только профессионалы из считанных компаний, потому что для их корректного и безопасного использования нужно быть экспертом. А Windows и macOS делают так, что можно раскатывать по умолчанию на миллиарды пользователей.
Это разные инструменты.
Снапшот делает слепок вашего текущего состояния всей ОС (файловой системы, каким бы оно ни было, в каком бы состоянии оно ни находилось), а принцип неизменяемого rootfs+слёв его просто исключает: у вас есть версии, и всё (ну разве что состояние ваших собственных слоёв/developer-слоя, если он включён).
Иными словами, после установки обычной ОС состояние файловой системы — головная боль администратора системы (пользователя), а в случае слоёв — поставщика слоёв (разработчика дистрибутива).
В первом случае состояние недетерминировано (у меня Fedora 43 и у вас Fedora 43, но я обновлялся на прошлой неделе, а вы сегодня — у нас разный набор пакетов разных версий, и чтобы определить проблему, нужно скрупулёзно сверять всё установленное ПО), а в случае Atomic-дистрибутива у меня Fedora 43.123, и у вас Fedora 43.123, с абсолютно одинаковым набором файлов у всех пользователей конкретной версии.
Десктопы: macOS, Windows (в плане защиты ядра). Смартфонные Android и iOS давно впереди любой десктопной ОС, про них и говорить не стоит.
На практике с этим подходом также применяют A/B-обновления: новые данные записываются в другой слот, и следующая перезагрузка загрузит обновлённую версию. А если что-то пошло не так, автоматика это поймёт и загрузит предыдущий, старый и рабочий слот.
rootfs поставляется производителем дистрибутива в минимальном виде, вместе со всеми метаданными и чексуммами (CAS; dm-verity/fs-verity, заверенный ключом поставщика), обновляется единым целым;
по сети передаётся минимум данных благодаря Content‑Addressable Store (CAS): сначала ваш существующий rootfs хешируется маленькими блоками, а затем с сервера скачивается только разница между новым rootfs и существующим, поблочно (блоки могут быть в разных местах, главное совпадение хеша);
все немногочисленные дополнительные системные пакеты переустанавливаются при каждом обновлении, формируя доп. слой поверх rootfs (почти как docker build);
Вы всегда видите разницу (можете сделать diff) между эталонным образом и вашими изменениями (dev-слоя, например). Если что-то сломалось, можете отбросить dev-слой и загрузиться в неизменённую систему. Dev-слоев может быть несколько (и в глубь, и в ширь), можете безопасно экспериментировать с системой, нужны в переустановке не возникнет никогда, потому что снизу у вас эталонный неизменяемый образ.
Сейчас в подавляющем большинстве дистрибутивов у вас нет понятия эталонной файловой системы, вы не можете посмотреть только ваши изменения поверх ФС, не можете легко их откатить.
При этом rootfs-образ может быть изначально оптимизирован под порядок чтения с него (блоки расположены в том порядке, в котором система к ним обращается во время загрузки, из-за чего с диска производится быстрое последовательное чтение вместо медленного случайного), сжат. Преимуществ много.
Если вы не специалист по безопасности и не отслеживаете индустрию, со стороны здраво оценить состояние дел не представляется возможным: многие критические уязвимости просто не попадают в поле зрения технических СМИ, а другие не расписываются понятным для обычного человека языком, и становятся информационным шумом, а не полезной новостью, на которую можно отреагировать осмысленным действием.
Security-журналистика, нацеленная на простых смертных, мертва. Не уверен, что она вообще существовала.
Вы переусложнением считаете что-то конкретное?
В Embedded-индустрии применяется многое, о чём он пишет, да и разрабатываемые, но ещё не мейнстримные дистрибутивы Fedora Atomic / Ubuntu Core Desktop реализуют большинство из описываемого.
Linux в плане безопасности (и удобства использования подсистем безопасности) отстает на годы от конкурентов, увы.