1.1, Аноним (1), 10:59, 31/03/2020 [ответить] [﹢﹢﹢] [ · · · ]
| +22 +/– |
Они думали, что они боженьки, и что вот у них-то точно получится затащить виртуальную машину с JIT в ядро, и в ней не будет дыр и граблей, на которые наступала Java.
| |
|
2.5, Я (??), 11:16, 31/03/2020 [^] [^^] [^^^] [ответить]
| +11 +/– |
нет. они знали что дыры будут и что их придётся не раз фиксить как и любую другую технологию.
| |
|
|
4.37, КО (?), 12:42, 31/03/2020 [^] [^^] [^^^] [ответить]
| +18 +/– |
Не рут, а ядро. Рут по новым правилам слегка ограничен - а тут полная воля. :)
| |
|
3.121, Аноним (121), 06:09, 01/04/2020 [^] [^^] [^^^] [ответить]
| +2 +/– |
> они знали что дыры будут
Скажем больше, они специально JIT в ядро засунули, чтобы эти дыры там были.
| |
|
|
1.2, Аноним (2), 11:00, 31/03/2020 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Сайт арча не знает об уязвимости, значит её нет на моей арч установке.
| |
|
2.12, Чебур (?), 11:33, 31/03/2020 [^] [^^] [^^^] [ответить]
| +4 +/– |
Арчу вообще стоит молчать об любых уязвимостях пока у них есть aur-помойка
| |
|
|
4.57, Michael Shigorin (ok), 14:18, 31/03/2020 [^] [^^] [^^^] [ответить]
| +1 +/– |
Как и с любой помойкой, которой то размахивают -- "вот у нас сколько всего", то чуть что -- "...только не пользуйся".
| |
|
5.83, Аноним (83), 16:49, 31/03/2020 [^] [^^] [^^^] [ответить]
| +2 +/– |
Да ладно, просто арчеводу нужно было срочно сказать всем, что у него арч.
| |
|
|
3.102, виндотролль (ok), 19:08, 31/03/2020 [^] [^^] [^^^] [ответить]
| –1 +/– |
> Арчу вообще стоит молчать об любых уязвимостях пока у них есть aur-помойка
А где-то есть статистика по количеству малвари в ауре?
| |
|
4.112, Lex (??), 21:54, 31/03/2020 [^] [^^] [^^^] [ответить]
| +2 +/– |
Когда-то была, но, поскольку на серваке с ней стоял арч ...
| |
|
|
2.118, iPony129412 (?), 05:09, 01/04/2020 [^] [^^] [^^^] [ответить]
| –1 +/– |
> Сайт арча не знает об уязвимости
Уже знает.
Ну не починили к тому времени. А так представь два раза с дивана вставать – сначала страницу создавать, что не починено, а потом править её же, что починено.
А так хитро – сразу "вот есть таоке и всё починено"
| |
|
|
2.64, Аноним (64), 15:03, 31/03/2020 [^] [^^] [^^^] [ответить]
| +5 +/– |
Всё же лучше, чем позволять загружать в ядро нативный машинный код обработчиков для трассировки, анализа работы подсистем и управления трафиком. Да ещё и непривилегированным пользователям.
| |
|
|
2.14, Аноним (14), 11:49, 31/03/2020 [^] [^^] [^^^] [ответить]
| –3 +/– |
Уже пишут. Redox OS.
Будет весело, если там таки найдут уязвимость)
| |
|
3.17, нах. (?), 11:52, 31/03/2020 [^] [^^] [^^^] [ответить]
| +2 +/– |
Но таких неленивых, кому зачем-то сдался совершенно неуловимый джо - вряд ли найдется.
| |
|
2.27, Gogi (??), 12:23, 31/03/2020 [^] [^^] [^^^] [ответить]
| –13 +/– |
У Линуса проблема была не в языке (хотя и в нём тоже), а в принципиальной архитектуре. Не зря Танненбаум макал Трольвадса в ошибки. Но.... как об стенку горох - Линус накодил то, на что хватило интеллекта. И вот он вырос - Линукс, самое безобразное поделие в ИТ.
| |
|
3.33, Аноним (33), 12:38, 31/03/2020 [^] [^^] [^^^] [ответить]
| +9 +/– |
Топ-500 суперкомпьютеров в мире используют ТОЛЬКО линукс.
Этот человек уже вписал себя в историю в отличии от диванных экспертов уход из жизни которых никто и не заметит.
| |
|
4.104, Аноним (104), 19:52, 31/03/2020 [^] [^^] [^^^] [ответить]
| –1 +/– |
Это корпорации себя вписали в историю, если ты не в курсе. И хотелось бы знать а топ рабочих компьютеров какую ос использует?
| |
|
5.117, анонимуслинус (?), 04:34, 01/04/2020 [^] [^^] [^^^] [ответить]
| –1 +/– |
если ты о топ, то это эппл мак ос))) потому как все топ и не только стараются прикупить их компы. и телефоны. хотя... она была топ системой во время power G процессоров и osx 9. сейчас это нечто немногим лучше винды, но с более отработанным интерфейсом.
| |
|
6.131, Аноним (130), 11:46, 01/04/2020 [^] [^^] [^^^] [ответить]
| +1 +/– |
> все топ и не только стараются прикупить их компы
Какие-то влажные фантазии с ароматом яблоневого сада.
| |
|
7.134, анонимуслинус (?), 14:32, 01/04/2020 [^] [^^] [^^^] [ответить]
| +/– |
это не фантазии , а реальность. неплохая работа рекламщиков эппл. правда раньше их телефоны и компьютеры сами себя рекламировали качеством, но увы с переходом на интелл все ближе к хламу. но все верят в их "элитарность")))
| |
|
|
|
|
3.34, Fyjy (?), 12:38, 31/03/2020 [^] [^^] [^^^] [ответить]
| +11 +/– |
Вот только Таненбаум при этом ничего рабочего не создал, а паразитирует на грантах ЕС, а ядро Linux работает по всему миру во всех устройствах от мобил и домашних роутеров до серверов и суперкомпьютеров.
| |
|
4.36, Аноним (33), 12:41, 31/03/2020 [^] [^^] [^^^] [ответить]
| +3 +/– |
Тот кто умеет - делает, а кто не умеет обсуждает и советуют другим как надо было бы сделать
| |
|
5.41, Fyjy (?), 12:54, 31/03/2020 [^] [^^] [^^^] [ответить]
| +1 +/– |
Именно так. Таненбаум только советовать может и паразитировать на грантах, ничего реального он сделать не может.
| |
|
6.43, Аноним (43), 13:04, 31/03/2020 [^] [^^] [^^^] [ответить]
| +7 +/– |
Ядро Таненбаума используется в каждом PC в чипах для массовой слежки, ты просто не в курсе :-)
| |
|
7.66, Fyjy (?), 15:22, 31/03/2020 [^] [^^] [^^^] [ответить]
| –1 +/– |
Вот только это со слов самого Таненбаума и не в каждом, а только в интеловских процах. Никаких доказательств, что его код где-то используется нет, просто он это соврал в одном из интервью и не более
| |
|
8.113, Lex (??), 21:58, 31/03/2020 [^] [^^] [^^^] [ответить] | –1 +/– | Кагбэ, третий и первый для реального применения миникс, все дела Кажись, ка... текст свёрнут, показать | |
|
9.139, Fyjy (?), 00:05, 03/04/2020 [^] [^^] [^^^] [ответить] | +/– | Нет, гранты которые он прожрал 2 миллиона евро выделялись на портирование Postg... текст свёрнут, показать | |
|
|
|
|
|
4.50, Аноним (50), 13:30, 31/03/2020 [^] [^^] [^^^] [ответить]
| +/– |
Intel ME летище Таненбаума так-то.
Не говоря о том, что на уроках Таненбаума выросли десятки тысяч программистов.
| |
|
5.67, Fyjy (?), 15:24, 31/03/2020 [^] [^^] [^^^] [ответить]
| –2 +/– |
> Intel ME летище Таненбаума так-то.
> Не говоря о том, что на уроках Таненбаума выросли десятки тысяч программистов.
Про Intel ME это только вранье самого Эндрю в одном из интервью, без доказательств. Да и там он говорит типа «мне один знакомый рассказал, что его знакомый слышал от знающего человека»
Про программистов выросших… Ну да. Они точно знают что и как НЕ нужно делать.
| |
|
|
3.58, Michael Shigorin (ok), 14:20, 31/03/2020 [^] [^^] [^^^] [ответить]
| –5 +/– |
Вы правда готовы предъявить свою (не профессорскую, а свою) разработку в области ядер ОС?
Если нет -- заткнитесь.
Если интеллекта не хватает понять, почему -- могу объяснить.
| |
|
4.88, Fyjy (?), 17:02, 31/03/2020 [^] [^^] [^^^] [ответить]
| +1 +/– |
Миша, ты что-то сегодня слишком агрессивный. Тебе вынули крепкий путинский стержень из седалища что ли и ты обиделся?
Таненбаум — теоретик, чьи теории практикой были проверены и показали себя ничтожными.
| |
|
5.105, нах. (?), 20:44, 31/03/2020 [^] [^^] [^^^] [ответить]
| –1 +/– |
ну почему - l4 был вполне работающий. А он, в общем, теориям не противоречит. (эппловский mach не совсем микро, и не совсем ядро. И написан то ли в одно время с таненбаумовским учебником, то ли еще раньше даже, так что не считается.)
| |
|
6.138, Fyjy (?), 00:04, 03/04/2020 [^] [^^] [^^^] [ответить]
| +/– |
Вот только нишевая на 100% и в реальной жизни не встречается
| |
|
|
|
3.70, Анолинукс (?), 16:12, 31/03/2020 [^] [^^] [^^^] [ответить]
| +3 +/– |
Весь спор Танненбаума с Линусом сводился к тому что идеальная микроядерная архитектура
в реальном мире будет работать крайне тормозно из-за накладных расходов.
Монолитное ядро - это не идеальное, но реально работающее решение, кстати в 1990 году,
на 386 процессоре.
| |
|
4.110, Fracta1L (ok), 21:32, 31/03/2020 [^] [^^] [^^^] [ответить]
| –4 +/– |
Для начала: идеальная микроядерная архитектура никогда не будет работать, потому что не будет реализована в сколь-нибудь обозримое время. За пруфами можно обратиться к Столлману, он уже полбороды себе выдрал от осознания того, в какой тупик завёл HURD выбор микроядра в качестве основы.
| |
|
5.122, Аноним (122), 09:13, 01/04/2020 [^] [^^] [^^^] [ответить]
| +/– |
В Symbian прекрасно работало микроядро, до известных событий в истории.
| |
|
|
3.84, Аноним (84), 16:57, 31/03/2020 [^] [^^] [^^^] [ответить]
| –1 +/– |
Ну ничего, зато поделие Таненбаума как минимум во всех процессорах интела.
| |
|
2.42, Анонимъ (?), 12:58, 31/03/2020 [^] [^^] [^^^] [ответить]
| +6 +/– |
Даже если Rust уменьшает количество ошибок, ведущих к уязвимостям, это совершенно не значит, что уязвимостей не будет совсем. Это я как ярый любитель растишки говорю.
| |
|
3.48, 54t45yh (?), 13:18, 31/03/2020 [^] [^^] [^^^] [ответить]
| +/– |
На сколько уменьшает? Упустить утечку памяти и прочее трудно достижимо?
| |
|
4.119, leap42 (ok), 05:25, 01/04/2020 [^] [^^] [^^^] [ответить]
| +1 +/– |
> На сколько уменьшает?
Mozilla считала, но пруф мне лень искать: примерно на 2/3 если переписывать со смеси Си и С++. При этом сами привели пример ошибки на плюсах, которую пофиксили, но при переписывании на Rust уже не помнили, и она проявилась опять. Т.Е. по факту иногда переписывание на Rust превносит ошибки работы с памятью. Это не говоря об ошибках в borrow checker (в этом году по-моему одну такую пофиксили), когда программист надеется что компилятор на 100% страхует от проблем при работе с памятью, а он на самом деле нет.
| |
|
|
|
3.63, Аноним (-), 14:57, 31/03/2020 [^] [^^] [^^^] [ответить]
| +1 +/– |
в я.п. Rust явное разделение на safe-код и unsafe-код, правильно?
| |
|
4.106, нах. (?), 20:45, 31/03/2020 [^] [^^] [^^^] [ответить]
| +/– |
" вы когда границу пересекали - такой большой красный флаг что, не увидели?!"
| |
|
|
|
|
|
3.11, And (??), 11:33, 31/03/2020 [^] [^^] [^^^] [ответить]
| –4 +/– |
Когда Лобачевский говорил: параллельные прямые пересекаются, крутили пальцем у виска. А сейчас уже ничего, что пересекаются и даже сумма углов треугольника в 270 градусов норм и не смущает.
| |
|
4.20, gogo (?), 11:58, 31/03/2020 [^] [^^] [^^^] [ответить]
| +7 +/– |
какой жирный пример демагогии )
"параллельные прямые" микроядер пересекаются в умозрительном пространстве, но не в реальном эвклидовом
| |
|
5.32, Аноним (31), 12:36, 31/03/2020 [^] [^^] [^^^] [ответить]
| –2 +/– |
Микроядра не могут физически реализоваться посмотри на ГНУ Хурд, например.
| |
|
|
7.91, Аноним (91), 17:23, 31/03/2020 [^] [^^] [^^^] [ответить]
| –1 +/– |
Вопрос в том на каких архитектурах он работает. Ну и еще с какой производительностью...
| |
7.107, нах. (?), 20:46, 31/03/2020 [^] [^^] [^^^] [ответить]
| –1 +/– |
"загружается".
Насчет работает - не надо сказок, он только падает и виснет хорошо.
В основном, вероятно, потому что линуксным драйверам 1998го года (которые там в основном) немного поплохело от переписывания в userspace. Но это неточно.
| |
|
6.60, Аноним (-), 14:27, 31/03/2020 [^] [^^] [^^^] [ответить]
| +/– |
Minix3 уже сколько лет существует, причём есть в Intel IME.
Google разрабатывает о.с. Fuchsia на микроядре Zircon
| |
6.61, Anonymqwe (?), 14:42, 31/03/2020 [^] [^^] [^^^] [ответить]
| +2 +/– |
Я предлагаю вам посмотреть на QNX. Она нишевая, но мы же сейчас не говорим о распространённости.
| |
|
7.108, нах. (?), 20:47, 31/03/2020 [^] [^^] [^^^] [ответить]
| –2 +/– |
нишевая - это не только распространенность, это еще и работопригодность.
Для какой практической цели ВАМ бы пригодилась - qnx?
| |
|
|
9.133, нах. (?), 12:53, 01/04/2020 [^] [^^] [^^^] [ответить] | +/– | дык это понятно что для поднятия - а как это к делу-то какому за зарплату примен... текст свёрнут, показать | |
|
|
|
|
|
4.65, Аноним (64), 15:15, 31/03/2020 [^] [^^] [^^^] [ответить]
| +1 +/– |
>Когда Лобачевский говорил: параллельные прямые пересекаются, крутили пальцем у виска.
Лобачевский говорил, что через точку вне заданной прямой можно провести множество прямых, параллельных заданной. А то, что вы написали, говорил Риман.
| |
|
5.73, Аноним (73), 16:21, 31/03/2020 [^] [^^] [^^^] [ответить]
| +2 +/– |
Риман тоже такой чуши сказать не мог. Параллельные прямые не могут пересекаться потому что это и есть определение параллельных прямых - прямые которые не пересекаются.
| |
|
4.132, Аноним (130), 11:57, 01/04/2020 [^] [^^] [^^^] [ответить]
| +/– |
Ты опять выходишь на связь?
Геометрия Лобачевского допускает, что на одной плоскости может находиться сразу несколько прямых линий, не пересекающихся друг с другом. Улавливаешь разницу?
| |
|
3.28, Аноним (-), 12:26, 31/03/2020 [^] [^^] [^^^] [ответить]
| +/– |
если 2+2=5, тогда есть сомнения, что какие-то проблемы с арифметикой.
| |
|
4.46, A.Stahl (ok), 13:10, 31/03/2020 [^] [^^] [^^^] [ответить]
| +/– |
Арифметика бывает разной. В том числе и такой где 2+2=5 и даже такой где выражение 2+2 вообще не несёт смысла.
| |
|
|
2.10, Аноним (73), 11:33, 31/03/2020 [^] [^^] [^^^] [ответить]
| +1 +/– |
И как микроядерная архитектура спасает от слабоумных разработчиков которые решают выполнять JIT-код в привелигерованном кольце?
| |
|
3.16, нах. (?), 11:52, 31/03/2020 [^] [^^] [^^^] [ответить]
| +/– |
Микроядерная архитектура предназначена для того, чтобы ты мог выполнять код залетного васяна в кривом драйвере в непривелигированном кольце ;-)
"теперь мне не нужно взламывать ядро системы - достаточно подсунуть что-то драйверу в userspace!"
это ли не прогресс науки и технологий?!
| |
|
|
5.54, КО (?), 13:52, 31/03/2020 [^] [^^] [^^^] [ответить]
| +/– |
С другой стороны, делая данный JIT для общего случая - ему же дадут права для доступа к остальным драйверам и данным. И собственно ядро все...
| |
5.72, Анолинукс (?), 16:19, 31/03/2020 [^] [^^] [^^^] [ответить]
| +/– |
Кольца безопасности поддерживаются аппаратно - процессором.
В Intel-e x86 - 2 кольца, больше было у SUN SPARK, если правильно помню.
Програмная реализация этой фигни - это будет надстройка еще раз убивающая
производительность и практическую полезность этой системы
| |
|
6.74, Совершенно другой аноним (?), 16:22, 31/03/2020 [^] [^^] [^^^] [ответить]
| +3 +/– |
> Кольца безопасности поддерживаются аппаратно - процессором.
> В Intel-e x86 - 2 кольца, больше было у SUN SPARK, если
> правильно помню.
> Програмная реализация этой фигни - это будет надстройка еще раз убивающая
> производительность и практическую полезность этой системы
Вообще-то аппаратных в x86 именно 4.
| |
|
7.99, Аноним (98), 18:52, 31/03/2020 [^] [^^] [^^^] [ответить]
| +1 +/– |
Так изначально и было, емнип даже начиная с 286-го, а потом amd решило - а накуя? - и оптимизировало до двух в amd64. И п#зда xen-у, и понеслось всё на костылях.
| |
|
|
5.116, JL2001 (ok), 01:57, 01/04/2020 [^] [^^] [^^^] [ответить]
| +/– |
> Ещё один минус - микроядерный
> подход более сложный - прийдётся чётко выверять протоколы между всеми компонентами
> и "Stable API nonsense" уже не очень получится, т.е. что-то поменять
> уже становится сложнее.
как вообще (не)стейблАпи соотносится с (микро)ядерностью??? вы можете выкатить два апи для юзерленда - один для всех, второй для дров которые в вашем дереве исходников, и его перекраивать каждый релиз
| |
|
6.124, Совершенно другой аноним (?), 10:12, 01/04/2020 [^] [^^] [^^^] [ответить]
| +/– |
>> Ещё один минус - микроядерный
>> подход более сложный - прийдётся чётко выверять протоколы между всеми компонентами
>> и "Stable API nonsense" уже не очень получится, т.е. что-то поменять
>> уже становится сложнее.
> как вообще (не)стейблАпи соотносится с (микро)ядерностью??? вы можете выкатить два апи
> для юзерленда - один для всех, второй для дров которые в
> вашем дереве исходников, и его перекраивать каждый релиз
В том-то и дело, что с точки зрения системы нет такого разделения - драйвера это такие-же процессы, как и другие, и всем доступно одинаковое API. Если говорить про конкретику - например в QNX - есть базовый механизм IPC - Send()/Receive()/Reply() - всё в системе на самом деле обменивается сообщениями, и даже когда Вы говорите open("/home/my_file", O_RDONLY); то на самом деле от Вашего, прикладного процесса, посылается сообщение, в котором закодировано, что надо выполнить операцию открытия такого-то файла и посылает это сообщение соответствующему менеджеру. Определением необходимого менеджера может потребовать посылку других сообщений какому-нибудь "менеджеру менеджеров" который знает, кто за какую часть файловой системы отвечает.
Т.е. в итоге для каждой компоненты системы, будь то файловый менеджер, сетевой менеджер ещё кто-нибудь, есть чётко определённый набор запросов и ответов. Менеджеры тоже могут общаться между собой (например NFS или SMB, который вроде как файловый, но потом обращается к сетевому). И вот вы добавили что-то дополнительное в запрос. В Linux, как я понимаю, эти доп. признаки обработаются где-то на уровне входа в системный вызов и драйвера про него может даже и не узнают. В QNX надо этот новый флаг добавлять во все соответствующие сообщения, или плодить, как в linux - новые сообщения для open(), new_open(), new_new_open() и придумывать как в динамике определять есть этот new_new_open() или нет . В общем, имхо, много проблем на пустом месте.
| |
6.129, Совершенно другой аноним (?), 11:04, 01/04/2020 [^] [^^] [^^^] [ответить]
| +/– |
про Stable API - внутри ядра Linux можно всё менять как угодно, как угодно переделывать взаимодействующие подсистемы - это всё одно большое ядро. В "микроядерном" подходе - каждая из подсистем - это отдельный ВНЕШНИЙ модуль, независимый от других и с чёткими интерфейсами - (если говорить про QNX - какие он сообщения понимает и какие ответы может выдать". Считайте, что каждый раз, когда Вы правите ядра, вам приходится дружно править и весь прикладной уровень - все программы, которые, например, используют данный вызов. Сорри, возможно как-то сумбурно излагаю, но надеюсь, что смысл я смог донести - при микроядерном подходе в прикладной уровень уезжает то, что раньше было в ядре и менять его становится тяжелее. Править приходится всё вместе централизовано. В принципе все более-менее удачные микроядерные системы закрыты и развиваются каждая своей компанией.
| |
|
|
4.76, Аноним (73), 16:26, 31/03/2020 [^] [^^] [^^^] [ответить]
| –1 +/– |
Вы, господа, говорите конечно все верно только не понимаете что юзкейс этого конкретного JIT-а в ядре - иметь доступ ко всему зоопарку который в привелигированном кольце живет. И то что само по себе это решение совершенно безответственное и некомпетентное с точки зрения безопасности вне зависимости от архитектуры ядра и что подобные васяны среди разработчиков системы способны наговнокодить такое же решение и для микроядра, дай им волю.
| |
|
|
2.26, Gogi (??), 12:22, 31/03/2020 [^] [^^] [^^^] [ответить]
| +/– |
Вместо **** из кустов, надо озвучивать конктретные аргументы, товарищ плоскоземельщик.
| |
|
3.29, Аноним (-), 12:28, 31/03/2020 [^] [^^] [^^^] [ответить]
| +1 +/– |
вроде философия микроядра в том, чтобы ядро было минималистичным, а не в том, чтобы в ядро всё подряд добавлять, в том числе jit ?
| |
|
4.35, Аноним (31), 12:41, 31/03/2020 [^] [^^] [^^^] [ответить]
| +/– |
Не в него, а рядом с ним. И да добавят и JIT и ты никогда не разберешься безопасно его реализовали или нет.
| |
|
5.53, Совершенно другой аноним (?), 13:49, 31/03/2020 [^] [^^] [^^^] [ответить]
| +/– |
Если оно будет "рядом с ядром" то и сломать что-то в самом ядре уже не сможет, а только то, к чему у него будет доступ, а т.к. суть микроядра - явное разграничение и разбивка на модули - то и заломать оно только самое себя.
| |
5.59, Аноним (-), 14:23, 31/03/2020 [^] [^^] [^^^] [ответить]
| –1 +/– |
>> никогда не разберешься безопасно его реализовали или нет.
почему? в микроядре мало кода, а чем меньше кода, тем меньше ошибок, недостатков
| |
|
6.81, Аноним (73), 16:38, 31/03/2020 [^] [^^] [^^^] [ответить]
| +1 +/– |
А каким образом в микроядре с JIT может быть мало кода если там есть JIT?
Можно мне пример имплементации JIT-а где мало кода?
| |
|
7.128, Ordu (ok), 10:47, 01/04/2020 [^] [^^] [^^^] [ответить]
| +1 +/– |
> А каким образом в микроядре с JIT может быть мало кода если там есть JIT?
Микроядро, что в этом слове тебе непонятно? Там всё ядро -- это планировщик задач и, может быть, памяти. Всё остальное реализуется процессами, каждый из которых живёт в собственном адресном пространстве. В том числе и драйвер сетевухи. В том числе и стек TCP/IP. И файрволл. И даже отдельные правила файрволла можно вынести в отдельные процессы. И естественно все эти процессы имеют лишь необходимый им минимум привилегий.
Там единственное ограничение на отпочковывание процессов под разные задачи -- это производительность получающейся системы: накладные расходы на взаимодействие между процессами никто не отменял.
| |
|
|
|
|
3.78, Аноним (73), 16:33, 31/03/2020 [^] [^^] [^^^] [ответить]
| +/– |
См. пост выше, юзкейс eBPF в ядре для того чтобы использовать их для мониторинга и performance-каунтеров которые в том числе должны иметь доступ к адресному пространству того процесса который ты хочешь мониторить или профилировать. Так что чтобы получить функционал такой же какой сейчас имеется в ядре прыщей в самой замечательной микроядреной архитектуре придется нанизать на нефритовый стержень всю изоляцию и безопасность. Что конечно совершенно нельзя делать но совершенно никак не остановит убогоньких девелоперов написать подобное решение даже для микроядерной архитектуры, ведь никто из них никакого понимая безопасности не имеет.
| |
|
|
1.22, gogo (?), 12:02, 31/03/2020 [ответить] [﹢﹢﹢] [ · · · ]
| +3 +/– |
Прочитал заголовок новости и подумал: "что-то долго искали дыру в BPF, давно пора было найти..." )
| |
1.39, 54t45yh (?), 12:46, 31/03/2020 [ответить] [﹢﹢﹢] [ · · · ]
| –1 +/– |
Как там NetBSD с Lua поживает? А ведь в недавней новости кто-то смеялся про Lua в её ядре.
| |
|
2.49, Crazy Alex (ok), 13:26, 31/03/2020 [^] [^^] [^^^] [ответить]
| +2 +/– |
Я смеялся, и буду. Потмоу что специализированный интерпретатор байткода можно здорово ограничить, и дыр в нём при прочих равных будет меньше, чем если пихать в ядро полный интерпретатор для языка общего назначения, тем более вместе с парсером.
Впрочем, я вообще предвзят, так как не люблю пермиссивщиков разве что чуточку меньше, чем проприетарщиков, и искренне желаю всем BSD скорейшей смерти.
| |
|
3.56, Совершенно другой аноним (?), 14:06, 31/03/2020 [^] [^^] [^^^] [ответить]
| +/– |
Пока, похоже, BPF-у наоборот дают всё больше и больше возможностей - вон обещали и функции завезти с возможностью замены и памяти добавить, так-что это дело, похоже, наживное. В самом LUA понятия указателя нет - вроде как полезть куда попало так-сразу тоже не получится. Поддержка байт-кода, вроде там тоже какая-то была.. если не путаю, да и jit тоже был, правда сторонним проектом.
| |
3.62, Анонас (?), 14:47, 31/03/2020 [^] [^^] [^^^] [ответить]
| –2 +/– |
Действительно. Вместо зрелого проверенного продукта с 27-летней историей, отличной кастомизацией, высокой скоростью работы, большим сообществом программистов возьмем да слепим свой велосипед. Ох уж эти кернел хакеры.
| |
|
4.79, Crazy Alex (ok), 16:35, 31/03/2020 [^] [^^] [^^^] [ответить]
| –1 +/– |
Учитывая, что то, что они делают, у кернел хакеров получается хорошо - не вижу причин им не доверять. Ресурсов им явно хватает, а раз так - смысл брать универсальное решение, когда можно сделать специализированное? Разного рода "большие сообщества" здесь только во вред, так как получается амёба вместо хорошо спроектированного продукта с понятными задачами. Что до возраста и прочего - ну так и эта штука созреет, главное что архитектурно это более осмысленный вариант.
| |
|
|
|
1.47, PnD (??), 13:10, 31/03/2020 [ответить] [﹢﹢﹢] [ · · · ]
| –1 +/– |
unprivileged_bpf:
CVE-2017-16996,CVE-2017-16995,CVE-2020-8835,...
Ничего не забыл?
| |
1.69, Аноним (69), 15:49, 31/03/2020 [ответить] [﹢﹢﹢] [ · · · ]
| –1 +/– |
выход за пределы буфера из-за ошибки в вычислении границы буфера...
штош, они хотя бы попытались
| |
1.71, Аноним (71), 16:16, 31/03/2020 [ответить] [﹢﹢﹢] [ · · · ]
| +1 +/– |
> запретить выполнение BPF-приложений непривилегированными пользователями
А можно пример такого приложения? Которое выполняется такими пользователями...
| |
|
2.85, Нанобот (ok), 16:59, 31/03/2020 [^] [^^] [^^^] [ответить]
| +/– |
допустим, веб-сервер, который принимает соединения с одних адресов и не принимает с других, да так, чтобы соединения с неправильных адресов фильтровалось на уровне ядра и не доходили до веб-сервера. раньше такое делали на файрволе (т.е. требовались root-права), сейчас можно делать в самом приложении (теоретически). в качестве дополнительного бонуса - возможность менять список адресов прямо через веб-интерфейс того же веб-сервера.
или ssh-сервер, который сам банит по айпи после десяти неудачных попыток. без добавления своих правил в файрвол.
| |
|
1.95, soarin (ok), 17:43, 31/03/2020 [ответить] [﹢﹢﹢] [ · · · ]
| –1 +/– |
Решил проверить Opennet на безопасность.
Emoji нельзя в пароль вводить. Вот вам и секурность 😮
| |
1.100, Вебмакака (?), 18:56, 31/03/2020 [ответить] [﹢﹢﹢] [ · · · ]
| –2 +/– |
И вот опять баг с буфером подбросили в ядро враги. Настоящие сишники-разработчики ядра никогда не совершили бы такой детской ошибки.
| |
1.101, Аноним (101), 19:08, 31/03/2020 [ответить] [﹢﹢﹢] [ · · · ]
| –2 +/– |
Из серии - включить, ввести sudo bash и пароль суперпользователя, сотворить зло. Какая уязвимость!
| |
1.103, Алекс (??), 19:10, 31/03/2020 [ответить] [﹢﹢﹢] [ · · · ]
| –1 +/– |
Ну теперь те, кто обкакивал Убунту из за ошибки ядра извинятся? Дурацкий вопрос, конечно нет!
| |
1.120, Аноним (121), 06:05, 01/04/2020 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
> Уязвимость присутствует в подсистеме eBPF, позволяющей запускать обработчики для трассировки, анализа работы подсистем и управления трафиком, выполняемые внутри ядра в специальной виртуальной машине с JIT.
Там где JIT - там дыра!
Ох не даром собираю ядра без BPF.
| |
|
2.127, Аноним (127), 10:43, 01/04/2020 [^] [^^] [^^^] [ответить]
| +/– |
> Там где JIT - там дыра!
Там где нет JIT - там две дыры в самом софте! Без дыр - никуда...
| |
|
3.136, Аноним (136), 10:16, 02/04/2020 [^] [^^] [^^^] [ответить]
| +/– |
> Там где нет JIT - там две дыры в самом софте! Без дыр - никуда...
Если нет JIT можно запретом выделения памяти в режиме WX отсеять сразу целые классы уязвимостей. Например уязвимости связанные с переполнение буфера невозможно будет проэксплуатировать.
Наличие JIT дает гарантию возможности эксплуатации некоторых уязвимостей.
| |
|
|
|