The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]



"В ядро Linux 7.1 добавлена поддержка Realtime-режима для 32-разрядных систем ARM"
Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Изначальное сообщение [ Отслеживать ]

"В ядро Linux 7.1 добавлена поддержка Realtime-режима для 32-разрядных систем ARM"  +/
Сообщение от opennews (ok), 27-Апр-26, 23:10 
В состав ядра Linux 7.1, релиз которого ожидается в середине июня, приняты изменения,  добавляющие возможность использования режима реального времени (PREEMPT_RT) на 32-разрядных процессорах ARM. Ранее поддержка PREEMPT_RT была обеспечена для архитектур x86 и x86-64, ARM64, RISC-V и LoongArch...

Подробнее: https://www.opennet.ru/opennews/art.shtml?num=65302

Ответить | Правка | Cообщить модератору

Оглавление

Сообщения [Сортировка по ответам | RSS]

1. Сообщение от Страдивариус (ok), 27-Апр-26, 23:10   +1 +/
А реалтайм вообще возможен в системе, где устройство может стать bus master'ом и захватить шину на столько (а-ля PCI)? Или где в самый нужный и ответственный момент случается SMI и все такие: "Ой, пацаны, у нас тут минус первое кольцо, расходимся."
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #3, #4, #5, #23

2. Сообщение от Аноним (2), 27-Апр-26, 23:29   –2 +/
А патчи на видеопамять не принимают от валва?
Ответить | Правка | Наверх | Cообщить модератору

3. Сообщение от Ы (?), 28-Апр-26, 00:14   +2 +/
этого на arm32 нет и да - qos и приоритеты для мастеров настраиваются
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1

4. Сообщение от warlockemail (??), 28-Апр-26, 00:25   +/
SMI можно отключить (переключить на SCI).
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1 Ответы: #29

5. Сообщение от Аноним (-), 28-Апр-26, 01:59   +5 +/
>  А реалтайм вообще возможен в системе, где устройство может стать bus master'ом

Даже в этом моем STM32 (микроконтроллер, надеюсь достаточно реалтаймно уже?) - его DMA - может стать bus master и захватить шину... но, правда, ненадолго - round robin с процессорным ядром при клещах все же будет.

Однако жестким использованием DMA можно заметно нагнуть все даже на мк. Реалтайм дизайн системы - многофакторная штука, bus mastering (и вообще contention и рубка за ресурсы) лишь 1 из кучи аспектов.

Сам по себе "сферический bus mastering в вакууме" - не обязывает те или иные процессорные ядра вставать колом и перестать реагировать на события. А у более актуального PCIe линки так то peer to peer и что вы там захватывать собрались? Свой линк? И кому от этого плохо кроме вас самих?

> и захватить шину на столько (а-ля PCI)? Или где в самый нужный и ответственный
> момент случается SMI и все такие: "Ой, пацаны, у нас тут минус первое
> кольцо, расходимся."

"И тут я проснулся и заметил что это ARM у которого нет никакиз SMI# и ring -1" :D. И да, это повод предпочесть ARM непонятной хрени с ring -1 и мутноблобом обрабатывающим это, ибо лично отвечать за хзкакой блоб делающий хзчто раздавая оружающим гарантии свойств системы на основе хзчего - нафиг надо!

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1 Ответы: #16, #30, #32

6. Сообщение от Аноним (6), 28-Апр-26, 02:12   +/
Но 32-бита на x86 всё равно дропнут. В отличиии от 32-битных альтернативных архитектур, у быдла на руках слишком много 32-битных селеронов и атомов, конкурируют с современным DRMнутым хламом.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #19

7. Сообщение от Аноним (7), 28-Апр-26, 02:15   +2 +/
Лучше бы миррорс кернел орг починили, уже 6 дней как никаких обновлений по всем дистрам. apt даже пометил его как протухший, ибо срок жизни TUF-канарейки стёк.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #8, #41

8. Сообщение от Аноним (8), 28-Апр-26, 03:06   +/
Не всем https://mirrors.edge.kernel.org/archlinux/ 27 Apr - вчера, а вот Debian да, протухший
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #7 Ответы: #9

9. Сообщение от Аноним (8), 28-Апр-26, 03:09   +/
Теперь ясно, что случилось у них https://social.kernel.org/notice/B3FpxSKAReX7S2ePfE
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #8 Ответы: #10

10. Сообщение от Аноним (8), 28-Апр-26, 03:14   +/
Цитата:

"Should we start occasionally breaking mirrors.kernel.org so that people identify and fix these dependencies? Maybe. But I'm slightly terrified of unintended consequences that may impact real people's lives."

В общем не используйте mirrors.kernel.org на продакшене

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #9 Ответы: #11, #14

11. Сообщение от Аноним (11), 28-Апр-26, 07:17   +/
>В общем не используйте скурвившийся Debian, намеренно создающий условия для взлома aptа спецслужбами путём редиректа с https на http и не фиксингга архитектуры самого апта с in-band signalling и сокетами

Ясно. Но что тогда использовать, может Apple MacOs или Windows 11? Эти давно подписали допуск к гостайне, и х специалисты сами тебе бэкдор зальют. Кстати, в прошлом году произошёл случай, нескольким менеджерам ИИ-отделов из корпораций из кремниевой долины присвоили звание полковников и привели к воинской присяге. Знаешь, мне кажется, что это далеко не первый случай, просто ИИ - горячая тема, этим можно понтоваться "вот наши военные всерьёз модернизируют нашу армию с помощью ИИ". А аналогичные присвоения званий тем, кто отвечает за помощь в шпионаже - о них широкую публику и не извещают.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #10 Ответы: #13

12. Сообщение от кукпоп (?), 28-Апр-26, 07:38   +/
Весьма хорошая новость.
Ответить | Правка | Наверх | Cообщить модератору

13. Сообщение от Аноним (13), 28-Апр-26, 08:27   +/
> редиректа с https на http

Стоп, что? Откуда такая информация?

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #11 Ответы: #17

14. Сообщение от Аноним (14), 28-Апр-26, 08:35   +/
А что теперь клоны редхат использовать?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #10

16. Сообщение от Смузихлеб забывший пароль (?), 28-Апр-26, 08:37   +1 +/
Дело не в этом, а в том, что линь сам по себе слишком жирная штука чтобы быть с этим хоть в чём-то уверенным. Помимо того что туда требуется затащить гору сторонних пакетов которые вообще ничего не гарантируют. Это примерно как трактору с прицепом куда навалены брёвна, приделать руль как у гоночного авто и всерьёз называть это "гоночная тачка"

Даже куда более компактная РТОСь вроде ФриРТОС - и то, вызывает много вопросов по своей РТОСности, т.к в действительности не может ничего гарантировать и иные события там рандомно могут обрабатываться куда дольше чем ожидалось. А более продвинутая её версия - СейфРТОС уже распространяется не бесплатно, ещё и без исходников

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #5 Ответы: #28, #33

17. Сообщение от Аноним (17), 28-Апр-26, 09:05   +/
Зашёл браузером по адресу репозитория на дебиан орг, на https, меня редиректнуло на http.
Не я один такой. В интернете даже обсуждали, что в apt нет защиты от такого редиректа, хотя должна быть, городили сами на уровне файрвола, но это неправильно.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #13 Ответы: #18, #35

18. Сообщение от Аноним (18), 28-Апр-26, 09:42   +/
В дебиане пакеты не подписываются ключом мейнтейнера? Подсовывай, какой хочешь, и апт радостно сжуёт?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #17 Ответы: #20, #25

19. Сообщение от Аноним (19), 28-Апр-26, 09:55   –3 +/
Так 32-битные АРМы ещё явно много где используются, а быдло с атомами тольо и может кричать "дай, давй".
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #6

20. Сообщение от Аноним (20), 28-Апр-26, 10:09   +/
радости тебе с этой подписи, если вместо пакета твой апт получит от твоего провайдера 302 редирект на рекламную страницу.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #18 Ответы: #22, #39

22. Сообщение от Аноним (18), 28-Апр-26, 10:18   +/
Повод сменить провайдера.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #20 Ответы: #24, #34

23. Сообщение от Аноним (23), 28-Апр-26, 10:38   +/
SMI, как бы, и QNX'у помешать может.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1 Ответы: #31

24. Сообщение от Аноним (24), 28-Апр-26, 14:43   +/
Даже если шарик сменить, взяв с собою только своих единомышленников, проблемы в долгосрочной перспективе никуда не денутся.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #22

25. Сообщение от Аноним (25), 28-Апр-26, 15:00   +/
Вы бы хоть Интернет по теме почитали, там всё давно расписано, это очевидные вещи. Для вас видимо неочевидные, поэтому расскажу. Вот именно пакеты - не подписываются. Да и дело в другом, нам в Дебиане одну и ту же байку рассказывают год за годом "метаданные подписаны, палёный пакет не подсунут". И раз ра разом одна и та же уязвимность, инъекция в in-band signalling апта, дающая тем или иным образм RCE, в последнем публично известном случае - да, взяли и через http подменили сигнал aptа о том, что хеш пакета сходится. И каждый раз отмечалось, что если бы был TLS - то только владелец зеркала мог бы проводить такую атаку, а не кто попало на проводе. Разумеется выпиливать in-band signalling не будут, как и вводить TLS.
Почему? Очень просто, если они эти бэкдоры закроют, от них потребуют более активное участие в той активности, которая уголовно наказуема в правовом государстве, это в том, где работники Celebrite в тюрьме бы сидели на несколько пожизненных по сумме, вместе с Hacking Team и прочими уголовниками, но в мафиозном государстве - избирательное правоприменение, разведка и прочие полицаи, и их контракторы и союзники - по факту имунны. А вовлечённость в эту активность - это уже другое количество тайн этих уголовников, и другой уровень взаимодействия с их ОПГ. Есть такая пословица, популярная в определённых кругах - "меньше знаешь - дольше живёшь". Зачем проекту Дебиан вовлекаться в это дерьмо больше, чем минимально приходится, если можно создать условия, по сути бэкдор, который позволить определённым службам заниматься их криминальной деятельностью, при этом проект Дебиан в неё не посвещая, и Дебиан в случае чего может утверждать "мы тут ни при чём, в apt просто очередное CVE"?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #18 Ответы: #26

26. Сообщение от Аноним (18), 28-Апр-26, 15:22   +/
Другим дистрибутивам не мешает. А дистрибутиву, в котором будут голосовать до принятия нужного результата, почему-то, мешает. Может быть, всё проще и без конспирологических теорий?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #25 Ответы: #27

27. Сообщение от Аноним (27), 28-Апр-26, 16:34   +/
Да, да, знаем. То что Сноуден принёс - это тоже была "конспирологическая теория".
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #26

28. Сообщение от Сусанин (?), 28-Апр-26, 18:36   +/
Поэтому для реального времени можно рассматривать только голое железо - baremetal, да и то, даже в этом случае ещё надо постараться получить реальное время.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #16

29. Сообщение от Страдивариус (ok), 28-Апр-26, 20:50   +1 +/
> SMI можно отключить (переключить на SCI).

На обычном писюке нельзя.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #4

30. Сообщение от Страдивариус (ok), 28-Апр-26, 20:52   +/
> "И тут я проснулся и заметил что это ARM у которого нет
> никакиз SMI# и ring -1" :D. И да, это повод предпочесть
> ARM непонятной хрени с ring -1 и мутноблобом обрабатывающим это, ибо
> лично отвечать за хзкакой блоб делающий хзчто раздавая оружающим гарантии свойств
> системы на основе хзчего - нафиг надо!

Родной, а ты текст новости читал кроме заголовка? Написано же тебе, что якобы это уже есть для x86 и x86_64. Я про арм ничего не спрашиваю, а спрашиваю про то, как на этом дерьме оно может работать?

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #5 Ответы: #36

31. Сообщение от Страдивариус (ok), 28-Апр-26, 20:54   +/
> SMI, как бы, и QNX'у помешать может.

Может, поэтому что одной ОСью риал-тайм нельзя гарантировать - это комплекс аппаратных и софтварных мер. Но как они на x86 могут вообще про риал-тайм говорить?

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #23 Ответы: #38

32. Сообщение от Страдивариус (ok), 28-Апр-26, 20:56   +/
> Сам по себе "сферический bus mastering в вакууме" - не обязывает те
> или иные процессорные ядра вставать колом и перестать реагировать на события.
> А у более актуального PCIe линки так то peer to peer
> и что вы там захватывать собрались? Свой линк? И кому от
> этого плохо кроме вас самих?

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

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #5 Ответы: #37

33. Сообщение от Аноним (-), 28-Апр-26, 21:21   +/
>  Дело не в этом, а в том, что линь сам по себе слишком жирная штука

Даже в обычном STM32 можно в ряде случаев заказать суммарные потоки данных по шинам + DMA больше, чем шина технически вообще могла обеспечить - и получить довольно интересные факапы.

Так что стопроцентные гарантии вам в этом мире вообще никто и никогда не дает. А там где это важно - должен быть какой-то plan B. Уповать на непогрешимость 1 юнита там где его отказ критичен - вообще моветон.

> чтобы быть с этим хоть в чём-то уверенным. Помимо того что туда требуется затащить
> гору сторонних пакетов которые вообще ничего не гарантируют.

1) Гарантии обеспечивают те кто делал интеграцию. Они првоеряют что все работает как надо, оценивают worst case, подгоняют все проблемные места, тюнят систему и проч.

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

3) Это никак не мешает "вот этому демону" работающему с гарантиями шедулинга что "на интервале X получит не менее Y времени CPU" обработать вон ту ситуацию. Ессно его придется написать самому. И максимально аккуратно. Абы какая программа в этой роли ессно может подвести, и придется обыграть множество системных аспектов.

4) Никто не запрещает 2-уровневый дизайн системы и подпор наиболее критичных вещей вторым уровнем защиты с МК и возможно подстраховкой оного жесткой логикой. Т.е. Linux вовсе не обязан overcurrent сам рюхать, МК может все отключить до него, а если он облажается то хардварная защита. Но линуху неплохо бы быть в курсе о проблеме за обозримое время и среагировать на это за предсказуемое время. А не через полчаса.

А суммарно - не боги горшки обжигают. И если кто ссытся с мелкого 32 бит апликушного ARM, ему вообще реалтайм в более-менее крупных системах не светит совсем.

> Это примерно как трактору с прицепом куда навалены брёвна, приделать руль
> как у гоночного авто и всерьёз называть это "гоночная тачка"

Вы такие умные, что у вас поезда в результате до сих пор бы ходили наверное с электромеханическими сигналами. Но вроде AFAIK даже РЖД какие-то более продвинутые системы деплоит уже. И да, не вижу проблем если плк и сервера будут с линухом - кого еще для нормальной сетевой конективити ставить?

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #16

34. Сообщение от Аноним (20), 28-Апр-26, 21:38   +/
Не на что менять. В тех е..нях только один опсос, которого нагнули по разнарядке поставить там базовую станцию, в рамках "ликвидации цифрового неравенства". Ты, небось, даже и предполагал, что бывают такие места, да?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #22

35. Сообщение от Аноним (35), 28-Апр-26, 21:39   +/
А вы не в браузере смотрите, а перехватите запросы apt, например через mitmproxy.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #17 Ответы: #40

36. Сообщение от Аноним (-), 28-Апр-26, 21:51   +/
> Родной, а ты текст новости читал кроме заголовка? Написано же тебе, что
> якобы это уже есть для x86 и x86_64. Я про арм
> ничего не спрашиваю, а спрашиваю про то, как на этом дерьме
> оно может работать?

Родной, я эту новость - написал. Так что ты феерично поумничал - прямо на автора новости. И да, мой пойнт в том что на произвольно взятом писюке с хзчей мутноблоб BIOS/EFI - с хз каким SMM# Handler - ну попробуй дать гарантии его поведения. И с какого бы потолка ты данные о worst case его поведения возьмешь?

Однако если взять 2 из 3 и подстраховать каким МК попроще - даже это сможет полететь в космос как бортовой компьютер, ни много ни мало. Элон маск проверил. В общем у реалтайма и требований к нему - много ипостасей.

ARM просто сильно проще и там нет вот этого ring -1 с абы каким обработчиком в который по SMI# вышибает - безусловно, немаскируемо, и единственное что ос может вообще сделать - это констатировать что "X времени украл обработчик SMI#" - уже ПОСТФАКТУМ, что немного поздняк для гарантий. Вот этот элемент дизайна x86 как кархитектуры - крайне неудачен для RTOS, особенно - на наобум взятом компе с абы какой некооперативной системной фирмварью. Если у вас там coreboot какой и обработчик SMI# лично ваш - это совсем другой коленкор уже. Только врядли у вас ТАКОЕ есть. Сильно продвинутые типа элонмаска на такое могут и подраспереться если им надо станет.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #30

37. Сообщение от Аноним (-), 28-Апр-26, 21:55   +/
> Не поможет в общем случае. Один девайс полез мастерить другой девайс, а
> в этот момент CPU решил помастерить первый - и ква.

Что - ква? В общем случае проц как ядро вообще не обязан встать на паузу от этого и тем более до состояния когда он не может контекст переключить и заняться чем-то иным. Не говоря о том что ядер нынче более 1.

А мастеринг кто кого и как - iommu нынче есть так то даже у ARM нынче, ага. Даже у 32-битных есть которые не сильно ископаемые. Там вообще эта активность будет - то что хост позволит вообще.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #32

38. Сообщение от Аноним (-), 28-Апр-26, 22:47   +/
>> SMI, как бы, и QNX'у помешать может.
> Может, поэтому что одной ОСью риал-тайм нельзя гарантировать - это комплекс аппаратных
> и софтварных мер. Но как они на x86 могут вообще про
> риал-тайм говорить?

С той или иной степенью условности и допущений. Ну скажем если у вас системная фирмварь это coreboot какой - там вы можете и быть в курсе что SMI# обработчик сделает. А наобум взятый писюшник - ессно такой себе реалтайм, на свою бошку. Ибо откуда вы знаете насколько и когда его фирмваре руль отберет? :)


Ответить | Правка | Наверх | Cообщить модератору
Родитель: #31

39. Сообщение от Аноним (-), 28-Апр-26, 22:59   +/
> радости тебе с этой подписи, если вместо пакета твой апт получит от
> твоего провайдера 302 редирект на рекламную страницу.

Ну он и с TLS от тебя получит - ресет соединения или что там у главжандарма в тренде, если это не медвежьиуслуги.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #20

40. Сообщение от Аноним (40), 29-Апр-26, 01:33   +/
А смысл? Даже если они не делают это в конкретный момент для апта, то что они делают это для браузера, и что в апте нет встроенного https-only режима, и что апт вообще ходит по редиректам - это всё не в пользу Дебиана. Доверия к их репозиториям нет. То есть я пока-что не очень верю, что они стали бы подставлять малварь сами, но сравнительно отрицаемыми способами помочь "Родине" - у меня нет сомнений, что прогнутся.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #35

41. Сообщение от Аноним (41), 29-Апр-26, 04:07   +/
Кажись обновилось.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #7


Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2026 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру