Представлены (https://lkml.org/lkml/2011/4/21/395) очередные корректирующие релизы Linux-ядра (http://www.kernel.org/): 2.6.38.4 (http://www.kernel.org/pub/linux/kernel/v2.6/ChangeLog-2.6.38.4) (72 исправления), 2.6.32.39 (http://www.kernel.org/pub/linux/kernel/v2.6/longterm/v2.6.32...) (28 исправлений), 2.6.33.12 (http://www.kernel.org/pub/linux/kernel/v2.6/longterm/v2.6.33...) (26 исправлений). Как обычно, в анонсе выхода новых версий подчеркивается обязательность проведения обновления.
Из подсистем, в которых зафиксированы важные исправления, следует упомянуть: USB, Bluetooth, radeon kms, vfs, UBIFS, ramfs, vlan, pppoe, l2tp, ALSA, cifs. Отдельно можно отметить устранение незначительной уязвимости в реализации функции "next_pidmap()", которая может привести к инициированию краха ядра через обращение к системному вызову "getdents()" с определенным набором параметров.
Еще три уязвимости пока исправлены только в Git-репозитории:
- Возможн...URL: https://lkml.org/lkml/2011/4/21/395
Новость: http://www.opennet.me/opennews/art.shtml?num=30336
на 2.6.36 уже забили?
2.6.37 тоже не видно.
> 2.6.37 тоже не видно.Де-сить-но! http://lwn.net/Articles/435667/
ЗЫЖ Впрочем, у вас (обоих!) есть шанс стяжать лавров Энди Клина: http://lwn.net/Articles/416656/ -> http://lwn.net/Articles/419937/ ,- и подхватить брошенное Грэгом КХ знамя .37 и .36, соответственно. Нет? А чего так??
Что забили?
> на 2.6.36 уже забили?
О каких уязвимостях идёт речь? Если Грег говорит об обязательном обновлении, это не значит, что в этих ядрах наёдены уязвимости — он так говори обо всех обновлениях, где больше 15 патчей.
> О каких уязвимостях идёт речь? Если Грег говорит об обязательном обновлении, это
> не значит, что в этих ядрах наёдены уязвимости — он так
> говори обо всех обновлениях, где больше 15 патчей.Ну так правильно говорит. Кроме секурити бывают и иные неприятные баги. Врядли кому понравится разрушение данных или кернелпаник. Даже если они и не ведут к проблемам безопасности, это не значит что их не надо запатчить.
Когда на хомячках хотят протестировать что-то новое, их всегда пугают уязвимостями. Складывается впечатление, что 20 лет Linux из одних только уязвимостей состоял, а умники, способные их исправить, появились только теперь. И так со всем софтом, не только с ядром Linux.
Я тебе секрет открою. Весь софт и состоит из уязвимостей, многие находят через годы, а большинство просто не найдено. В практически любой сложной программе уязвимости есть прямо в данный момент времени, но узнать мы о них может очень не скоро.Из сложных программ, единственная мне известная (которая, скорее всего) без ошибок — это TeX, но его писал сам Кнут и лет 15 платил всем, кто находил в нём ошибки.
Невозможно говорить о чем либо с человеком, у которого огонек проповедника СПО в глазах.
> Невозможно говорить о чем либо с человеком, у которого огонек проповедника СПО
> в глазах.научись) делов то.
Теория: "Любая программа более двух строк содержит ...". Так что на сегодняшний день ядро Linux наиболее отлаженое из всех операционных систем.
Ни на чем не основанное заявление. Тебе бы этого хотелось, но не факт, что это так и есть.
> Из сложных программ, единственная мне известная (которая, скорее всего) без ошибок —
> это TeX, но его писал сам Кнут и лет 15 платил всем, кто находил в нём ошибки.Еще есть несколько программ от D.J. Berstein. Наиболее известные - qmail и djbdns. Если задаться целью, можно написать программу почти без ошибок. К сожалению, это требует такого уровня паранои что все остальные цели сместятся на второй план. Упомянутые программы это подтверждают.
Видите ли, исходный текст многих современных операционок не покрыт ни модульными, ни функциональными тестами вообще. На уязвимости натыкаются случайно, как на упавшие грабли в тёмном сарае. Такова культура системного софтостроения, что ж поделаешь.Не хотите обновляться — за вами будут следить всякие приходящие посторонние люди, будете вовремя обновляться — за вами будут следить только нужные люди. Такова жизнь.
> Видите ли, исходный текст многих современных операционок не покрыт ни модульными, ни функциональными тестами вообще.Как Вы себе представляете юнит тест в ядре? Нагромождение десятков уровней абстракции в ядре существенно понизит его производительность. Это вам не ява, где всегда можно купить ещё одну планку оперативы или пару процессоров.
>> Видите ли, исходный текст многих современных операционок не покрыт ни модульными, ни функциональными тестами вообще.
> Как Вы себе представляете юнит тест в ядре?Никак. Тестовый код вызывает функции ядра и проверяет корректность результатов с предполагаемыми разработчиком. Основной рабочий код ядра ничего не знает о тестах.
> Нагромождение десятков уровней абстракции
Модульные тесты не относятся к сложным абстракциям и не провоцируют их. Тесты должны быть максимально просты и понятны всем разработчикам.
> в ядре существенно понизит его производительность.
Тесты не влияют на производительность, так как код тестов не вызывается в готовой работающей системе.
> Это вам не ява, где всегда можно купить ещё одну планку оперативы или пару процессоров.
Java тут не причём. Принципы модульного тестирования и подтверждения/доказательства правильности программ появились задолго до Java.
> Тестовый код вызывает функции ядра и проверяет корректность результатов с предполагаемыми разработчиком.Вы не поняли мой вопрос. Какой функционал ядра Вы предлагаете покрывать юнит-тестами? Какую часть багзиллы ядра можно будет покрыть регрессионными тестами, к примеру?
Драйвера устройств (а это бОльшая часть ядра) отпадают ввиду необходимости эмулировать физические устройства со _всеми_ их багами и особенностями. А с ними связано и множество других решений (например, те же барьеры в ext4).
Плюс не забываем, что .config содержит огромное количество параметров, что приводит к большому числу различных конфигураций. Кроме того, некоторые ошибки (привет, 12309!) являются результатом "совместной деятельности" нескольких подсистем, и отловить их юнит-тестами не получится.
> Тесты не влияют на производительность, так как код тестов не вызывается в готовой работающей системе.
Необходимость поддерживать тесты повлияет на архитектуру ядра и, как следствие, на производительность. У тестируемых функций придётся добавлять параметры, позволяющие передавать mock-объекты вместо реальных ресурсов. А там, где некая функция вызывалась напрямую, придётся эмулировать виртуальную функцию.
> Видите ли, исходный текст многих современных операционок не покрыт ни модульными, ни
> функциональными тестами вообще.Практика показала: юнит-тесты и функциональные тесты - это, конечно, здорово. Но прорва ошибок остается и после них. Линукс удивительно стабилен на фоне его огромного размера кода. C качеством кода у него порядок. Упомянутые в новости баги - вообще ни о чем: их степень опасности - крайне низкая. Кстати в freebsd недавно находили уязвимость с монтированием NFS. Не хочешь ее за это почморить?
>> Видите ли, исходный текст многих современных операционок не покрыт ни модульными, ни
>> функциональными тестами вообще.
> Практика показала: юнит-тесты и функциональные тесты - это, конечно, здорово. Но прорва
> ошибок остается и после них.Да, куда ж без этого, если каждая третья ошибка связана с родовым свойством языка C: прорыв стека через элементарное переполнение буфера. Здесь нужны интерактивные инструменты по наблюдению за утечками памяти типа Visual VM и нагрузочное тестирование по типу Apache JMeter, хотя бы.
> Линукс удивительно стабилен на фоне его
> огромного размера кода. C качеством кода у него порядок.Те, кто сравнивали код Linux и FreeBSD, о первом отзываются не очень хорошо: во-первых, качество кода "гуляет" к в сторону полного крапа, так и в сторону гениальных находок (во FreeBSD код в массе своей средненький, но изобилует подробными комментариями, что хотел разработчик); во-вторых, ~15% кода ядра Linux не имеют авторского происхождения и комментариев, как-будто код кто-то написал и выложил без указания, кем он написан и зачем.
> Упомянутые в
> новости баги - вообще ни о чем: их степень опасности -
> крайне низкая.При крайне низкой степени опасности не нужно давать настаивать на обязательном обновлении.
> Кстати в freebsd недавно находили уязвимость с монтированием NFS.
> Не хочешь ее за это почморить?Нет.
> Да, куда ж без этого, если каждая третья ошибка связана с родовым
> свойством языка C: прорыв стека через элементарное переполнение буфера.Кто виноват что операционки только на си и получается писать? Остальные языки настолько высокопарны что не дают достаточных механизмов для влезания в системные внутренности.
> Здесь нужны интерактивные инструменты по наблюдению за утечками памяти типа Visual VM
Средства для гламурных дебилов ядерщикам не требуются - не надо по тупым жабистам их равнять. У ядерщиков мозги на месте. И инструментарий слегка другой.
> и нагрузочное тестирование по типу Apache JMeter, хотя бы.
У меня сервер полгода без ребута работает. Утечек памяти не вижу. Паник нет. Это за нагрузочное тестирование не считается? А у вас часто проводится нагрузочное тестирование вашего софта длительностью полгода, в реальных условиях? Без единого рестарта и перезапуска софта?
[много трепа ни о чем удалено]
> При крайне низкой степени опасности не нужно давать настаивать на обязательном обновлении.Т.е. если например, данные разрушаются или там паника случается, апдейтиться не будем? Продолжайте дальше тем же курсом.
>> Не хочешь ее за это почморить?
> Нет.Двойные стандарты - модный тренд нашего времени.
> Кто виноват что операционки только на си и получается писать? Остальные языки настолько высокопарны что не дают достаточных механизмов для влезания в системные внутренности.Да даже на ассемблере безопаснее писать. Другое дело, что код получается не портируемый...
> Да даже на ассемблере безопаснее писать.На ассемблере можно отправить всю систему в нокдаун одной неверной командой.
> Другое дело, что код получается не портируемый...
Более того, реальные образцы, например Win95 с точки зрения архитектуры ос похожи на полное УГ.
что не неделя, то стопка дыр в linux kernel.. к счастью хоть локальные уязывимости, а не ремотные..
ой, прям стопка! )) Посмотри, сколько обновлений в венике приходит :) и сколько не приходит, не известно ещё :) А это так... мелкие фиксы...
> ой, прям стопка! )) Посмотри, сколько обновлений в венике приходит :) и
> сколько не приходит, не известно ещё :) А это так... мелкие
> фиксы...Тебе бы хотелось так считать. Опять-таки, не факт, что фиксы - мелкие. Ну казалось бы - какая мелочь, переполнение буфера! Так нет же - главный жупел операционостроителей последних 15 лет.
фтему http://ibigdan.livejournal.com/8443330.html
Давайте уж всех маргиналов осчастливим ссылками на opennet.Впрочем, после упоминания C++ какие-то комментарии стали излишними.
Ну и, разумеется, забыт один нюанс. Проблема, которая требует перезагрузки, случается у каждого хомячка практически ежедневно, переустановки - чуть ли не ежемесячно. Проблема, при которой нужно знать C, случается у сурового энтерпрайза раз в год, и, в отличие от, они всё таки смогут решить эту проблему.
Ну а уж "возвращаемся на винду или мак" звучит как "позанимался спортом? не вставило? возвращаемся на вино или наркотики!". В мировоззрении бухарей-наркоманов, разумеется жизни без бухла и наркотиков просто нет, они её просто представить себе не могут.
Гы, а в ядре, которое использует сертифицированный ФСТЭК альт, эти дыры есть?
Гы, а вы разломайте что-нибудь на практике через эти дыры. Тогда и приходите.
ну и вдобавок: через НФС-ные папки фряхи получить доступ
> Гы, а вы разломайте что-нибудь на практике через эти дыры. Тогда и
> приходите.Целая армия хаксоров уже ищет. Правда, сюрприз? И оповестить тебя они отнюдь не будут спешить.
> Целая армия хаксоров уже ищет. Правда, сюрприз? И оповестить тебя они отнюдь
> не будут спешить.Результат деятельности хаксоров должен быть заметен в любом случае. Не вижу очевидных методов получить много профита с этой чепухи.
персы тоже очевидных методов не видели, пока всех центрифуг не лишились
> Гы, а вы разломайте что-нибудь на практике через эти дыры. Тогда и
> приходите.трьщкптан, а вы готовы поставить свои погоны и личные деньги на кон, что никто не поломает ОченьВажнуюЖелезку через эти дыры?
Будешь как на винде теперь жить с дырами месяцами, потому так как после применения патчей я так понимаю надо опять проходить сертификацию.
> Будешь как на винде теперь жить с дырами месяцами, потому так как
> после применения патчей я так понимаю надо опять проходить сертификацию.Такова жестокая реальность мира СПО.
Сертификация венды тоже слетает после обновлений. Внезапно да?
А еще внезапнее скажу, что поддержка сертифицированного альта предусматривает предоставление _сертифицированных_ обновлений, в отличие от.>Система может быть использована как Рабочая станция и как Сервер, в сертифицированный комплект входят версии для двух архитектур и купон технической поддержки на 1 компьютер, дающий право на бесплатное получение регулярных сертифицированных обновлений.
Забавно в этой истории только одно. Линуксоиды так гордились своей свободой и что они могут сами в любой момент взять и вмешаться в систему и сделать так как им надо. А получилось как?Свободу эту они теперь могут засунуть куда подальше, сменили m$ выньдос на "национальную ОС" в которой все видишь ли "засертифицировано" в бинарном виде. И самому менять ничего нельзя. Почему в сертифицированном Linux постгресс 8.4.4, а не 8.4.8 ? А может мне 9-ый хочется. И такая ситуация со многими пакетами. Это нормально когда государство засунуло свой нос, и указало кому и чем пользоваться?
И кстати, раз уж Вы в теме, разъясните такую ситуацию. Добрым дядям регуляторам которые могут припереться в офис с 1 июля 2011 года, я так понял главное не то что на серваке их сертифицированный Linux стоит, а главное чтобы бумажка была, что этот Linux куплен за денежку. И вот насчет апдейтов, я так понял в документах есть некий формулярчик в котором перечислены контрольные суммы. При установке сертифицированных апдейтов от ALT Linux, будут каждый раз рассылать этот формулярчик по почте?
I.1. Контрольные сумм могут считаться только сертифицированной утилитой.
2. Эта утилита есть только под DOS/Windows.
3. Она есть под Linux.
4. Но под Linux она сама не сертифицирована :)II.
Сертифицированный или лицензионный софт, за этим следят различные органы.
За пираццкую венду тебя могут посадить, за не сертифицированный софт - расстрелять :)
> Будешь как на винде теперь жить с дырами месяцами,patch и GCC вам в руки, если вы еще не совсем отупели.
Товарищ капитан, Вы главное ссылку не палите где качать такой GCC после сборки которым будут получаться сразу сертифицированные бинарники. А то нам денег никто не принесет больше за сертификацию, а мне еще виллу надо достраивать в Испании. :)
> Возможность разыменования NULL-указателя
> Целочисленное переполнениеБольше на Си программируйте, и не такое будет.
да вот заждались уже ведра от айзена на жабе.
может ты поможешь?