Представлены (https://lkml.org/lkml/2011/5/9/490) очередные корректирующие релизы Linux-ядра: 2.6.38.6 (http://www.kernel.org/pub/linux/kernel/v2.6/ChangeLog-2.6.38.6) (44 исправления), 2.6.33.13 (http://www.kernel.org/pub/linux/kernel/v2.6/longterm/v2.6.33...) (47 исправлений) и 2.6.32.40 (http://www.kernel.org/pub/linux/kernel/v2.6/longterm/v2.6.32...) (147 исправлений). Как обычно, в анонсе выхода новых версий подчеркивается обязательность проведения обновления.
Из подсистем, в которых отмечены исправления, можно выделить: SCSI, KVM, drm/radeon, mac80211, ath9k, iwlwifi, v4l, USB, UBIFS, ALSA. Как минимум две из исправленных ошибок связаны с устранением уязвимостей: повышение привилегий через переполнение кучи из-за ошибки в реализации интерфейса /dev/mpt2ctl; возможность переполнения кучи через отправку устройству pmcraid специально оформленного ioctl (отправка данного запроса возможна только для пользователей с правами CAP_SYS_ADMIN, что зна...URL: https://lkml.org/lkml/2011/5/9/490
Новость: http://www.opennet.me/opennews/art.shtml?num=30504
а как же патч в 200 строк? то кричали что он прирост дает, то вдруг 39 ничем от 38 и 37 (а соответсвенно и 38 от 37) не отличается...в команде ядра тоже завелся маркетоид кричащий на каждую новую версию "быстрее! выше! сильнее!"
> а как же патч в 200 строк? то кричали что он прирост дает, то вдруг 39 ничем от 38 и 37 (а соответсвенно и 38 от 37) не отличается...ты это так сказал как будто понял
1) для какой деятельности дает прирост тот патч.
2) что меряют эти тесты.
Похороникс сравнивает не ядра Linux, а ядра Ubuntu (это такая "принципиально новая ОС").
Кроме того, не стоит забывать, что он ничего не понимает не то что в бенчмарках, а вообще в компах.
> что в бенчмарках, а вообще в компах.Д'Артаньян, перелогиньтесь!
> в команде ядра тоже завелся маркетоид кричащий на каждую новую версию "быстрее! выше! сильнее!"Отзывчивость и производительность - разные вещи. Правда сложно быть глупым? Столь очевидные вещи не доходят с первого раза.
Там вроде говорили не о производительности, а об повышении отзывчивости при одновременном запуске большого количества ресурсоёмких программ.
Патч в 200 строк не скорость а отзывчивость системы повышает при нагрузках.
>Как обычно, в анонсе выхода новых версий подчеркивается обязательность
> проведения обновления."Как обычно, Грэг КХ использует механизированный шаболон "all users must upgrade", не несущий никакого потайтого смысла. Обеспокоенным пользователям и форумным аналитегам рекомендуется следить за обновлениями ядра в своём дистрибутиве."" /fixed
Как обычно Грэг пользуется шаблоном что бы скрыть много ошибок безопасности присутствующих в обновлениях. Linux сообщество все больше сваливается к маркетоидам из MS.
"Вы обновитесь по быстрее - но мы вам не расскажем почему".
Тфу.. одна срамота.. Хотя да - признавать свои ошибки никто не любит - особенно такие звездные личности как Линукс Торвальдс - которые могут позволить себе назвать других идиотами или обезьянами - а ничего.. их фанаты все стерпят и восхвалять будут.
> фанаты все стерпят и восхвалять будут.Что - фанаты? Лог коммитов в гите не спрячешь. Ни от фанатов, ни от остальных.
Я не тот аноним но все таки:Чтобы замаскировать наличие исправления опасной уязвимости в череде обычных багфикс релизов достаточно каждый раз стандартно написать "обновление обязательно". Итог: пользователь предупрежден что исправлена опасная уязвимость, а вот где именно - ищите в этой череде, одна из них реально опасна (имхо, в 2.6.38.5). Формально совесть чиста. Неформально это сокрытие важной информации путем повышения важности всей остальной иначе несущественной информации. Так что отписка Грега в реальности ничего не означает, это просто шелуха призванная сокрыть под собой опасную информацию.
> Так что отписка Грега в реальности
> ничего не означаетИменно это я и написал. Я там ещё написал, что наше с Вами мнение в вопросах безопасности ядра исчезающе малозначимо.
>, это просто шелуха призванная сокрыть под собой опасную информацию.
Да, это _просто_. Про опасность ничего говорить не буду.
Вот берешь открываешь diff и смотришь:http://www.kernel.org/diff/diffview.cgi?file=%2Fpub...
Если ты не понимаешь, что там, толку тебе это объяснять?!
Ну сделали там доп. проверку на наличие установленного TCP соединения
перед приёмом датаграмы на сокет в протоколе AF_UNIX.
Легче стало? Иль те эксплойт надо с комментами?---
Кстати, в чанджлоге всё описано
commit 7a1bbc3614696ea5e90d728f570f3ded8d49b487
Author: Eric W. Biederman <ebiederm@xmission.com>
Date: Sun Apr 24 01:54:57 2011 +0000af_unix: Only allow recv on connected seqpacket sockets.
commit a05d2ad1c1f391c7f514a1d1e09b5417968a7d07 upstream.
This fixes the following oops discovered by Dan Aloni:
> Anyway, the following is the output of the Oops that I got on the
> Ubuntu kernel on which I first detected the problem
> (2.6.37-12-generic). The Oops that followed will be more useful, I
> guess.
>[ 5594.669852] BUG: unable to handle kernel NULL pointer dereference
> at (null)
> [ 5594.681606] IP: [<ffffffff81550b7b>] unix_dgram_recvmsg+0x1fb/0x420
> [ 5594.687576] PGD 2a05d067 PUD 2b951067 PMD 0
> [ 5594.693720] Oops: 0002 [#1] SMP
> [ 5594.699888] last sysfs file:The bug was that unix domain sockets use a pseduo packet for
connecting and accept uses that psudo packet to get the socket.
In the buggy seqpacket case we were allowing unconnected
sockets to call recvmsg and try to receive the pseudo packet.
That is always wrong and as of commit 7361c36c5 the pseudo
packet had become enough different from a normal packet
that the kernel started oopsing.
Do for seqpacket_recv what was done for seqpacket_send in 2.5
and only allow it on connected seqpacket sockets.
Tested-by: Dan Aloni <dan@aloni.org>
Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
> Вот берешь открываешь diff и смотришь:
> http://www.kernel.org/diff/diffview.cgi?file=%2Fpub...
> Если ты не понимаешь, что там, толку тебе это объяснять?!Еще одна быдло элита мнящая себя не известно кем - "а толку тебе объяснять".
Дядя - учился бы ты лучше, был проще и люди к тебе потянутся.> Ну сделали там доп. проверку на наличие установленного TCP соединения
> перед приёмом датаграмы на сокет в протоколе AF_UNIX.
> Легче стало? Иль те эксплойт надо с комментами?Надо коменты - это обычное исправление ошибки - или это возможно эксплуатировать.
И вобще нужно бы объяснять людям что происходит.
Хотя откуда это известно линуксоидам - они же элитарный клуб ;-)
>И вобще нужно бы объяснять людям что происходит.Нормальный линуксоид знает, где и что почитать или ты про то, чтобы ходить рядом с кондуктором в общественном транспорте и зачитывать "людям" исправления ядра? Не е6анулся ли ты? И да, кстати, учи русский язык на предмет пунктуации, дядя.
> Дядя - учился бы ты лучше, был проще и люди к тебе потянутся.Не печалься о том, что люди не знают тебя,
печалься о том , что ты не знаешь людей.
(с) Конфуций.
ты сможешь чем черевато null pointer dereference в ядре?
Можно экплуатировать ошибку в проверке границ или какое нить interger overflow ?сомневаюсь - а любую из этих ошибок можно легко скрыть под словами fixing ....
и умолчать сказав "обновление необходимо".Да да. Линукс сообщество становится обезьянами - которые бездумно обновляют ядра по свистку.
В то время когда поводырь обезьян скрывает причину почему это надо делать.Ничего - это быдло сожрет и так.
>Линукс сообщество становится обезьянами - которые бездумно обновляют ядра по свистку.Так толсто, что жир течет из всех щелей. Просто уйди и сиди тихо в своей винде с десятилетними дырами и невозможностью _вообще_ обновлять ядро и не имея _вообще_ никакого контроля над системой по большому счету.
Нет, все дела бросить и "быдлу", как вы говорите, каждое слово разжевывать...
А самому поработать глазами и головой - не судьба?
Все им кто-то чего-то обязан...
Твоему "быдлу" достаточно сказано английским по белому - обновись.
> Нет, все дела бросить и "быдлу", как вы говорите, каждое слово разжевывать...
> А самому поработать глазами и головой - не судьба?
> Все им кто-то чего-то обязан...
> Твоему "быдлу" достаточно сказано английским по белому - обновись.Да да. Какое самомнение, какое желание быть элитарным.. Я сейчас заплачу.
То есть какой нить врач который использует линукс уже быдло? ведь он не может глазами перебрать changelog и понять что происходит.Ведь да - это же элитарность - потратить 5 минут рассказать о самых важных изменениях.
Но ведь это ниже достоинства - как же так, пусть они поднимаются ко мне на вершину, чего это я спускаться буду..Эх вы.. быдло от линукса - спустились бы - к вам и люди потянутся.
да пусть хоть Линус кровь христианских младенцев по утрам пьёт. он всё равно останется отличным организатором, и, возможно, хорошим программистом.почему возможно? потому что я не могу оценить его проф. навыки, т.к. в этом не разбираюсь
Каждый фикс касается ath9k. Если кому интересно, есть проприетарный madwifi, который не меняется месяцами, потому что в нём и так всё реализованно. Он не поддерживает ath9k, только ath5k, но есть патч-бэкпорт из FreeBSD, который её добавляет. Нужно брать не последний SVN, а тот, который в имени патча (422 кажется). Плюс фикс для компиляции с ядром 2.6.35 и выше. У меня всё работает. Кому надо - тот найдёт.
берем фикс на патч, потом патч на фикс, потом ядро, потом фиксим, потом патчим, бэкпортим, добавляем, убираем, пересобираем и вуаля, все работает! :)
> берем фикс на патч, потом патч на фикс, потом ядро, потом фиксим,
> потом патчим, бэкпортим, добавляем, убираем, пересобираем и вуаля, все работает! :)Это зенитар. Дон Кихот нашего времени. Он всегда сперва создает себе какую-то проблему, а потом геороически ее зарубает. Дон Кихот vs мельницы - version 2.0 :)
Проблема в том, что вот уже полгода каждая новость про обновления ядра содержит "затронуты такие подсистемы как ath9k...". Наверное, здесь имеет место тот баг на роутерах. А тем временем madwifi был еще до появления открытого ath9k. Драйвер от производителя, который уже умеет все, и умеет правильно. Когда появился ath5k, многие еще ставили madwifi, потому что ath5k умел не все, хоть со временем это исправлялось. Что касается стабильности: на опеннете года 4 назад была статистика по сбоям драйверов Linux. Ну, лидер конечно же fglrx. У madwifi 1%. Но это было 4 года назад, а сейчас мы видим масштабное переделывание открытого, аж искры летят.
> Каждый фикс касается ath9k. Если кому интересно, есть проприетарный madwifi, который не
> меняется месяцами, потому что в нём и так всё реализованно.Врать нехорошо. И некрофилия - плохо. Что за унылый кадр?!
Во первых, MadWiFi - ТРУП. Он был основан на atheros'овском проприетарном HAL. На него все дружно забили. Нормальные дрова на перспективном и более-менее унифицированном ядерном фреймворке mac80211 - ath5k (для старых чипсетов, реверсеный) и ath9k(для современных чипсетов, основан на исходниках от атероса). Хватит уже насиловать труп. Его никто не будет развивать и он умрет как динозавр. За отсутствием поддержки новых адаптеров.Ну и в madWifi не хватает сущей ерунды:
- Он не знает уйму новых атеросовских адаптеров.
- Он напрочь не умеет стандарт .n и поэтому пригоден только для унылых и тормозных некрофилов.> Он не поддерживает ath9k, только ath5k, но есть патч-бэкпорт из FreeBSD, который
> её добавляет.А можно еще на ластах, в лыжной маске, в гамаке. А как тебе ath9k_htc для ath9k чипов на юсб? Какие там у вас ласты и гамаки предлагаются?
> Нужно брать не последний SVN, а тот, который в имени патча (422 кажется).
> Плюс фикс для компиляции с ядром 2.6.35 и выше. У меня всё работает.
> Кому надо - тот найдёт.На кой хрен нужна эта некрофилия? У меня на Atheros 928x отлично работает ath9k, цепляется .n и выжимает скорость раза в 3 больше чем .g режим в тех же условиях. Это сразу, из коробки. Что мне даст проделывание данных танцев с бубном? Зачем вообще этот геморрой? В ath9k чего-то не хватает?
В любом случае это интереснее, чем 50 сообщений на тему "ой, у линуксоидов опять ядро с критическими обновлениями вышло, и никто не знает с какими".