LINUX.ORG.RU

NetBSD 10.0

 ,


1

4

Вышла версия операционной системы NetBSD 10.0.

Изменения новой версии:

  • Поддержка оборудования:

    • Добавлена поддержка Apple M1.
    • Добавлена поддержка Raspberry Pi 4.
    • Включен драйвер rkv1crypto на PINE64 Rock64 и NanoPi R2S.
    • Добавлена ​​поддержка spiflash на Rockchip RK3328.
    • Добавлена поддержка compat_linux для архитектуры AArch64.
  • Изменения в ядре:

    • Добавлена поддержка WireGuard.
    • Добавлена ​​реализация шифра Adiantum для эффективного шифрования диска с помощью cgd в системах без ускорения AES.
    • Шифрование подкачки теперь выполняется автоматически с использованием переменной vm.swap_encrypt=1 в sysctl.
    • Устройствам IEEE 802.11 (Wi-Fi) теперь требуется настройка SSID для связи с открытой точкой доступа.
    • По умолчанию отключена поддержка compat_linux.
    • База данных пакетов по умолчанию для новых установок была изменена на /usr/pkg/pkgdb для согласованности с другими платформами pkgsrc, заменив /var/db/pkg.
    • Модули ядра MIDI и секвенсора объединены в один модуль MIDI_seq.
  • Драйвера устройств:

    • urtwn — добавлена ​​поддержка беспроводного USB-адаптера TRENDnet TEW-648UBM.
    • Добавлен новый драйвер rge - для поддержки Ethernet-адаптера Realtek 8125 2.5
    • Добавлен новый драйвер ixl - для поддержки Ethernet-адаптеров Intel Ethernet 700 серии 10/25/40
    • Удален драйвер azaila, который был заменен в прошлых релизах на hdaudio.
    • ossaudio — добавлена ​​реализация API микшера OSSv4.
    • Обновлены драйверы DRM до версии 5.6.
  • Улучшение виртуализации:

    • В NVMM добавили поддержку suspend.
    • Добавлена ​​поддержка Xen PVH.
    • Добавлена ​​поддержка VirtIO 1.0 в драйвер virtio.
  • Улучшение производительности:

    • Улучшена производительность системных вызовов select и poll.
    • Более быстрый алгоритм поразрядного дерева для поиска страниц памяти.
    • Улучшена производительность планировщика, включая возможность более адекватно распределять нагрузку на медленные и быстрые ядра.
    • Улучшено отслеживание чистых/грязных страниц, на порядки ускорение работы fsync для больших файлов.

>>> Подробности



Проверено: hobbit ()
Последнее исправление: hobbit (всего исправлений: 2)

Ответ на: комментарий от jsforever

Подвержена. И старая, и новая.

Бэкдор конкретно целится в sshd, который не линкуется с liblzma напрямую, а потому единственный способ — через systemd, которого на *BSD быть не может, так как завязано оно на исключительно линуксовых фичах ядра — cgroups2.

mord0d ★★★★★
()
Ответ на: комментарий от mord0d

Да, поэтому что угодно подвержено этой уязвимости. А то, что оно таргетировано только на популярные сетапы - не является заслугой bsd или чего-либо ещё. Поэтому правильно писать будет не " bsd не подвержена", а «bsd повезло, потому как не популярно».

jsforever
()
Ответ на: комментарий от spbzip

Слится на старые версии - это ещё эпичнее, чем на «не являлось таргетом атаки». И да, не работает оно не из-за отсутствия/присутствия systemd, а из-за распространённости сетапа. Пойми уже это и успокойся.

jsforever
()
Ответ на: комментарий от jsforever

Нет, проблема не в популярнрсти. Проблема в том, что какой-то мутный libsystemd0 может линковаться к safety-critical сервису доступному из сети

mittorn ★★★★★
()
Ответ на: комментарий от mittorn

Лозунги для эникеев меня не интересуют. А так оно уже кучу времени линкуется, но почему-то проблем никаких не возникало. Почему?

Просто для протокола сообщу новость. Без линковки(точнее без уведомления) сервис нормально запустить нельзя. Такие дела.

jsforever
()
Ответ на: комментарий от jsforever

У меня ничего не линкуется и никакого libsystemd нет. И сервисы запускаются. ЧЯДНТ?
А вот касательно систем с systemd, если вообще рассматриватт их использование, что очень глупо - пускай делают нормальный механизм уведомлений, который не требует грузить сторонние библиотеки в процесс. Моожно сделать socket api (который уже есть скорее всего, только нет нормальной обёртки). Можно сделать файловый интерфейс. Можно сделать программу-утилиту, которая сделает уведомление для своего родителя или указанного pid. Но нет. Решили насрать своим говном в код. Как вообще так получилось что у libsystemd есть ещё какие-то внешние зависимости. Как так получилсоь что он линкуется динамически вообще? Никаких объяснений кроме намеренного создания дыры у меня нет.

mittorn ★★★★★
()
Последнее исправление: mittorn (всего исправлений: 1)
Ответ на: комментарий от mittorn

Нет, не запускаются. Ты не знаешь, что значит запускаться. А про свой колхоз не рассказывай - меньше позориться будешь.

пускай делают нормальный механизм уведомлений, который не требует грузить сторонние библиотеки в процесс

Что угодно можно сделать без библиотек. Зачем ты пытаешься рассуждать о чём-то, не обладая даже минимальными познаниями?

И да, «велосипеды не нужны» - каждый эникей говорил до, но вот для именно этого случая(когда уже всё вскрылось) теперь сообщают обратное - это просто оправдания.

Моожно сделать socket api (который уже есть скорее всего, только нет нормальной обёртки)

Если нужно без либы, то зачем нужна какая-то «обёртка»(т. е. либа)? Лозунги конфликтуют даже сами с собой, не говоря уже о реальности.

файловый интерфейс

Нет, нельзя. Подобное делается для самой простенькой скриптоты, когда никакие иные средства недоступны. И да, для этого интерфейса также будет либа.

Ладно, ты просто перечисляешь все известные тебе базворды. На мой вопрос не ответил. С очередным ботом разговаривать смысла нет.

jsforever
()
Ответ на: комментарий от mittorn

Ты слился и ответа не будет? Всё, успокойся. Клоунада уровня «причастен к произосшедшему» мне не интересна.

jsforever
()
Ответ на: комментарий от jsforever

Бот хорчет ответы....
притом, что несёт какую-то шизофазию

Если нужно без либы, то зачем нужна какая-то «обёртка»(т. е. либа)?

Подазумевается, что это дожно быть стабильное API и я эту обёртку/либу смогу как влинковать статически, не боясь, что этот интерфейс поломают, так и переписать. Потом в это целиком проходит аудит, а не загружает в проект сторонний код. sshd например имеет доступ к сети и ключам, то есть даже если процесс максимально огородить на уровне MAC белым списком сисколов - это не поможет.
Причём статическая линковка должна быть по умолчанию. Если они выносят его в shared, боясь уязвимости, то добро пожаловать, вот случай, когда shared либа подтягивает другую уязвимую либу...

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

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

И да, для этого интерфейса также будет либа.

4.2

Ну и на самоле простое решение - утилиту, которую можно будет будет дёрнть в отдельном процессе как одной строчкой с posix_spawn, так и из скриптов ты конечно же проигнорировал.

mittorn ★★★★★
()
Ответ на: комментарий от mittorn

Ну кстати, в случае с systemd не было никакой технической необходимости подгружать его либу в своё адресное пространство. Протокол для уведомления systemd документирован, можно было просто вкомпилировать весь нужный код.

wandrien ★★
()
Ответ на: комментарий от wandrien

тут у меня скорее претензия к тому, что это не делается по умолчанию.
Помимо потенциальнных проблем с безопасностью это приводит к тому, что любой бинарь, которому нужна демонизация линкует его динамичсески и не запускается на системах без systemd. Конечно, можно собрать libsystemd, но не использовать systemd в качестве инита, но во-первых, он глаза мозолит, во второых, лишняя solib зависимость ради такой банальной фичи просто не нужна. по-моему, варианты со статической линковкой или внешней утилитой куда лучше

mittorn ★★★★★
()
Ответ на: комментарий от mittorn

Ты опять выходишь на связь?

А так оно уже кучу времени линкуется, но почему-то проблем никаких не возникало. Почему?

На это ответ. Почему линковка была, а проблем не было.

влинковать статически

Ты болтал про что?

Проблема в том, что какой-то мутный libsystemd0 может линковаться к safety-critical сервису доступному из сети

«линкуется код systemd», ни про какое «статически» ты не болтал. А сейчас стало нечего ответить и ты решил съехать на «я имел ввиду другое»? Это сильно.

А скриптота не может быть сервисом?

Причём здесь не может? Твоё «файловый интерфейс» используется только вынуждено, когда никаких других средств не доступно. Когда доступно лучшее - никаких «файловый интерфейс» быть не может.

4.2

Нет, не «4.2». В задаче уведомления между локальным сокетом и файлом разницы нет. Для сокета имеем либу. Значит для файла либа также будет. Успокойся, эникей.

Ну и на самоле простое решение - утилиту, которую можно будет будет дёрнть в отдельном процессе как одной строчкой с posix_spawn, так и из скриптов ты конечно же проигнорировал.

Боже, откуда такие гении лезут. Ты там прочитал мой пост в теме и решил выдать за свой?

если бы код либы запускался только в отдельном процессе и оно физически не могло бы записывать в память основного процесса - вот тогда было бы не подвержено

Позорище.

jsforever
()
Ответ на: комментарий от jsforever

На это ответ. Почему линковка была, а проблем не было.

проблемы были. причём постоянно. Конечно, инжектить код никто не пытался, а вот зависимость от libsystemd в каком-нибудь собранном бинаре - постоянно

«линкуется код systemd», ни про какое «статически» ты не болтал. А сейчас стало нечего ответить и ты решил съехать на «я имел ввиду другое»? Это сильно.

Если libsystemd линкуется динамически - наверно есть на это причины, например этот сокетовый интерфейс поломать, или причина в том, что он слишком сложный. Уведомление должно делаться в одну-две строки кода, а не библиотекой

Причём здесь не может? Твоё «файловый интерфейс» используется только вынуждено, когда никаких других средств не доступно. Когда доступно лучшее - никаких «файловый интерфейс» быть не может.

влинковывать либу с подозрительными зависимостями - явно н лдучшее

Нет, не «4.2». В задаче уведомления между локальным сокетом и файлом разницы нет. Для сокета имеем либу. Значит для файла либа также будет.

ну давай, уведоми мн сервис простым shell скриптом

Успокойся, эникей.

Оскорбление участников дискуссии

Боже, откуда такие гении лезут. Ты там прочитал мой пост в теме и решил выдать за свой?

Я другие твои посты не считал. Ок, ты всё-таки понимаешь, что пихать какую-то левую либу в sshd нехорошо.
Я правда так и не понял, уязвимость в том, что libsystemd подтянуло lzma или сам systemd его инжектил? В любом случае троянец в pid1 это уже game over и что делает там liblzma, если не специально добавлено для понижения надёжности - мне неясно.

mittorn ★★★★★
()
Ответ на: комментарий от mittorn

проблемы были. причём постоянно. Конечно, инжектить код никто не пытался, а вот зависимость от libsystemd в каком-нибудь собранном бинаре - постоянно

Неверно. Речь о конкретной проблеме. Её не было. Всё, уязвимость не в системд.

Если libsystemd линкуется динамически - наверно есть на это причины, например этот сокетовый интерфейс поломать, или причина в том, что он слишком сложный. Уведомление должно делаться в одну-две строки кода, а не библиотекой

Отмазки мимо. Изначально проблемой заявлялось наличие кода системд в ccxд, а далее произошла подмена тезиса на «проблема в динамической линковке» - это просто попытка забалтывать.

влинковывать либу с подозрительными зависимостями - явно н лдучшее

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

ну давай, уведоми мн сервис простым shell скриптом

Зачем мне какой-то «shell скриптом»? Я не эникей. И да, зачем ты повторяешь сказанное мной ранее? Шелл скрипт - как раз случай когда лучшие средства не доступны/не удобны. Поэтому ты попытался съехать на шелл.

Ок, ты всё-таки понимаешь, что пихать какую-то левую либу в sshd нехорошо.

Она не левая. Какая ситуация - нужны уведомления, есть готовая либа. Варианты: написать руками или бахнуть либу. Вот выбрали последнее, чего-то нелогичного здесь нет. А то что в либе ещё куча всего - то не проблема именно libsystemd, все либы +/- такие. Либу на одну функцию(из пары строк) никто не делает.

jsforever
()
Ответ на: комментарий от jsforever

Неверно. Речь о конкретной проблеме. Её не было. Всё, уязвимость не в системд.

systemd не было? Ну тогда действительго не было проблемы, пока его не было. А как появился - заставили грузить/линковать какие-то либы.

Изначально проблемой заявлялось наличие кода системд в ccxд, а далее произошла подмена тезиса на «проблема в динамической линковке» - это просто попытка забалтывать.

Одного без другого бы не было. Я говорил об обёртке чисто для механизма уведомления. То что сейчас предлагают - линковать весь libsystemd. Ну допустим, можно влинковать статическую версию, которая не подтянет lzma т.к не будут использоваться функции, использующие lzma. Это как такой poor solution. Статическая линковка хотя бы пощволяет не линковать лишнее.

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

Все они хуже, потому что требуют большего объёма кода для работы с ними. Ну кроме разве что сокета. И даже тут во всех случаях header-only либо можно было бы сделать.

Зачем мне какой-то «shell скриптом»? Я не эникей

Но ты постоянно говоришь это слово. Я уже в этом сильно начинаю сомневаться

Она не левая. Какая ситуация - нужны уведомления, есть готовая либа.

Не нужны, а навязаны. Весь этот механизм с уведомлениями и прибиванием сессии при разлогине - навязанный поттерингом с его systemd буллщит. И т.к он уверен, что его поделие подойдёт везде и все им должны пользоваться, реализован механизм уведомления самым навязчивым способом - динамической линковкой. Почему? А потому что эго - «я пропихнул свой код везде, я молодец! 3 billion devices!»

mittorn ★★★★★
()
Ответ на: комментарий от spbzip

меня смущает js в нике, но да ладно, на первое апреля можно и по холиварить

mittorn ★★★★★
()
Ответ на: комментарий от jsforever

а «bsd повезло, потому как не популярно».

Не совсем. Дело в том, что разработчики FreeBSD при импорте в базу не использовали мутный билд тулинг с апстрима.

The main, stable/14, and stable/13 branches do include the affected version (5.6.0), but the backdoor components were excluded from the vendor import. Additionally, FreeBSD does not use the upstream’s build tooling, which was a required part of the attack. Lastly, the attack specifically targeted x86_64 Linux systems using glibc.

src

iron ★★★★★
()
Ответ на: комментарий от jsforever

«bsd повезло, потому как не популярно»

Из этого верно и обратное: популярность Linux не пошла на пользу.

mord0d ★★★★★
()
Ответ на: комментарий от jsforever

Ты несёшь какую-то дичь, например я могу аналогично сказать: «то что я не стал геем, не заслуга геев или иллюминатов, геям просто повезло, тк они просто не популярны»

dragon_djanic ★★
()
Ответ на: комментарий от dragon_djanic

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

Боже. Самое интересное тут то, что для условных 50%+ населения это утверждение верно, потому как большинство живёт просто повторяя мувы за другими. Поэтому да, открою тебе секрет, было бы это популярно - ты(50%+) стал бы.

И в том числе по этому(помимо технических и контр-пропагандистских причин) подобным движениям не дают набирать популярность. Если проще, снижают вероятность того, что ты(либо кто-то ещё) попадёт в «плохую компанию».

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

jsforever
()
Ответ на: комментарий от mittorn

Лол, так получается дыра не в xz, а в systemd? Я что-то сразу об этом не додумался!

Нет, бэкдор предоставляет именно xz/liblzma, целью является именно sshd, но так как напрямую sshd не линкуется с liblzma (ибо нафига), то оно через контролирующий процесс (systemd), который линкуется с нужной либой (liblzma), инжектит код в подконтрольный процесс (sshd).

НО! Если (бы?) этот бэкдор попал в прод, его авторы не ограничатся достигнутым и через какое-то время нашли другие лазейки в системах(!), даже если там нет systemd.

Это 146% заказной бэкдор, ибо слишком уж целенаправленно пропихивали. И я почему-то склоняюсь, что xz-utils это только один из множества. А может это был всего лишь отвлекающий манёвр, так как слишком уж быстро всё вскрылось.

mord0d ★★★★★
()
Ответ на: комментарий от mord0d

А сколько еще таких «Jia Tan»-ов по-тихому пакостит или ждёт своего часа в разных проектах…

Это 146% заказной бэкдор, ибо слишком уж целенаправленно пропихивали. И я почему-то склоняюсь, что xz-utils это только один из множества. А может это был всего лишь отвлекающий манёвр, так как слишком уж быстро всё вскрылось.

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

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

wandrien ★★
()
Ответ на: комментарий от wandrien

А сколько еще таких «Jia Tan»-ов по-тихому пакостит или ждёт своего часа в разных проектах…

И ты — один из них! ☺

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

Linux гонится за Windows, игры есть, вирусы есть, цель достигнута. ☺

mord0d ★★★★★
()
Ответ на: комментарий от mittorn

Ну если отвлекающий - ждём новые первоарельские приколы…

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

mord0d ★★★★★
()
Для того чтобы оставить комментарий войдите или зарегистрируйтесь.