LINUX.ORG.RU

Переполнение кучи в glibc и другое

 ,


0

4

Рунет сегодня ожил, а тут свежачок подвезли:

https://sourceware.org/git/?p=glibc.git;a=commitdiff;h=6bd0e4efcc78f3c0115e5ea9739a1642807450da;hp=8aeec0eb5a18f9614d18156f9d6092b3525b818c

И ещё другие баги в glibc 2.37 типа порчи памяти в qsort.

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

Перемещено hobbit из talks

★★★★★

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

Смотрим на цепочку сообщений.

Нахови хотя бы один крупный проект на расте который приобрёл популярность на уровне нынешнего популярного софта написанного на других языках

Огнелис. Дискорд. Думаю, fish достаточно популярен, как альтернатива bash.

Смотрим на «цитирование» пациентом этой цепочки.

– Приведи примеры популярных проектов, использующих раст

– Вот они

– Вы все врётиии!!! Ваши проекты – гавно!!!111111

На этом можно заканчивать. Если пропагандист раста открыл рот – он лжет. «На расте» здесь только бэкенд Discord, по утверждениям Discord Inc. Сколько там Rust реально – неизвестно.

А проекты и вправду «гавно». Fish может быть еще туда-сюда.

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

Настолько успешно

Да, имел приличный market share, одно время даже доминировал. Потом появился Google Chrome, который был лучше по всем критериям, и остается таким до сих пор. Сейчас преимущество FF исключительно в относительно нишевых фичах типа контейнеров.

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

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

Потому что если из плюсов выкинуть си и добавить щепотку окамла, то получится… Rust!

Это кстати еще одна порция бреда. Если из плюсов выкинуть плюсы, и добавить джаву (с некоторым налетом OCaml, но не более) – вот тогда получится Rust.

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

Да, имел приличный market share, одно время даже доминировал.

Нет, у огнелиса никогда больше 30-35% не было.

Потом появился Google Chrome, который был лучше по всем критериям, и остается таким до сих пор. Сейчас преимущество FF исключительно в относительно нишевых фичах типа контейнеров.

Особенно по тому, как Google платит кучу денег CEO тормозиллы в карман.

Это кстати еще одна порция бреда. Если из плюсов выкинуть плюсы, и добавить джаву (с некоторым налетом OCaml, но не более) – вот тогда получится Rust.

Осталось только понять, что именно в Rust взято из жабы. Потому что из окамла там взято практически… всё? Кроме синтаксиса и некоторых штук с указателями. Ну и трейты – явно из хаскелла.

Открытием этот факт может быть только для некоторые ЛОРовских АНАЛитиков, которые видимо пропустили то, что автор Rust упарывался окамлом по самые гланды и что изначально компилятор Rust был написан на этом самом окамле.

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

Нет, у огнелиса никогда больше 30-35% не было.

Да, вот только у осла в этом время было 50%. Соответственно на все остальные браузеры приходилось 15-20%.

Особенно по тому, как Google платит кучу денег CEO тормозиллы в карман.

Платит. «Что этим хочет сказать автор?»

Осталось только понять, что именно в Rust взято из жабы.

Советую посмотреть на ранний раст, который был буквально жабой/свифтом.

Потому что из окамла там взято практически… всё?

Практически огрызки синтаксиса. Де-факто это дефолтная паскалятина с закосом под ML.

Ну и трейты – явно из хаскелла.

Вообще нет. Вернее, возможно да – но в формате точно такого же огрызка, как и все остальное.

изначально компилятор Rust был написан на этом самом окамле.

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

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

Представь себе, например, проц с сотнями мелких ядер, у каждого из которых своя адресуемая память + доступ к общему банку.

https://www.greenarraychips.com/ https://habr.com/ru/companies/ua-hosting/articles/318144/

Правда не эрланг, а железная форт машина.

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

Нет, у огнелиса никогда больше 30-35% не было.

Да, вот только у осла в этом время было 50%. Соответственно на все остальные браузеры приходилось 15-20%.

Ну и? А потом из мозилки выпнули Эйха, туда пришла нынешняя Митчелл Бейкер, и всё пошло-поехало.

Особенно по тому, как Google платит кучу денег CEO тормозиллы в карман.

Платит. «Что этим хочет сказать автор?»

Что популярность Firefox не связана с Rust, но связана с упорными попытками CEO мозиллы всячески делать из мозилки полуживой труп.

Осталось только понять, что именно в Rust взято из жабы.

Советую посмотреть на ранний раст, который был буквально жабой/свифтом.

А что там из жабы-то? Расскажи нам, мы поржём. Может, объектная модель? Или модель исполнения через байткод? А может, сборщик мусора?

Потому что из окамла там взято практически… всё?

Практически огрызки синтаксиса. Де-факто это дефолтная паскалятина с закосом под ML.

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

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

Да, имел приличный market share, одно время даже доминировал. Потом появился Google Chrome, который был лучше по всем критериям, и остается таким до сих пор. Сейчас преимущество FF исключительно в относительно нишевых фичах типа контейнеров.

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

Qui-Gon ★★★★
()
Ответ на: комментарий от firkax

и они один тред размазывают поровну на все ядра даже если он влезает на одно

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

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

Платит. «Что этим хочет сказать автор?»

Что популярность Firefox не связана с Rust, но связана с упорными попытками CEO мозиллы всячески делать из мозилки полуживой труп.

Все правильно. Популярность Firefox не может быть связана с Rust, потому что Rust там единицы процентов кодовой базы, и это считая затянутые в репу 3rd-party зависимости.

А что там из жабы-то?

Или модель исполнения через байткод?

В яблочко. Rust это язык, определенный исключительно через байткод LLVM. То, что LLVM потом пережевывает этот байткод в нативный код, на свойства Rust как языка не влияет никак – он все еще ничего не знает (и не может знать) про реальный таргет.

А может, сборщик мусора?

В каком-то смысле. БЧ это тупой и прямолинейный статический сборщик мусора.

Но главное, что в Rust из жабы – это область применения. Она у них ровно одна и та же.

Писать на Rust низкоуровневый код невозможно физически. Достаточно открыть распиаренный Rust-on-Linux, и выпасть в осадок от километров (до раскрытия макросов) лапши, реализующей базовую функциональность, на которую в сишке уходит пара сотен строк. А еще в блоках unsafe все правила Rust продолжают действовать, и нарушать их – UB, о чем не все адепты знают. Хотя в методичке об этом написано.

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

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

Стесняюсь спросить, ты на хоть одном из трех (C++, ML, Rust) языков писал? У синтаксисов раста и крестов разве что императивность общая. Все остальное подчистую слизано с ML.

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

Rust это язык, определенный исключительно через байткод LLVM. То, что LLVM потом пережевывает этот байткод в нативный код, на свойства Rust как языка не влияет никак – он все еще ничего не знает (и не может знать) про реальный таргет.

ты вообще не знаешь что такое llvm, похоже.

Писать на Rust низкоуровневый код невозможно физически

И поэтому он в линуксовом ядре, помимо всяких других ОС на нём. ЛОРовские иксперды не разочаровывают!

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

ты вообще не знаешь что такое llvm, похоже.

Эксперт ушел в отрицание – бывает.

Смотрим на то, как пациент цитирует:

Писать на Rust низкоуровневый код невозможно физически

И поэтому он в линуксовом ядре, помимо всяких других ОС на нём. ЛОРовские иксперды не разочаровывают!

Смотрим на то, что написано:

Писать на Rust низкоуровневый код невозможно физически. Достаточно открыть распиаренный Rust-on-Linux, и выпасть в осадок от километров (до раскрытия макросов) лапши, реализующей базовую функциональность, на которую в сишке уходит пара сотен строк. А еще в блоках unsafe все правила Rust продолжают действовать, и нарушать их – UB, о чем не все адепты знают. Хотя в методичке об этом написано.

Интересно, какие фантазии начнутся, если я скину эксперту ссылки на раст в ядре Linux, на которое он ссылается как на пример low-level кода, а потом на эквивалентную сишку в этом же ядре.

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

и выпасть в осадок от километров (до раскрытия макросов) лапши, реализующей базовую функциональность, на которую в сишке уходит пара сотен строк

Знаешь почему так? Потому что функциональность, на которую в сишке уходит пара сотен строк, оборачивается ментальной нагрузкой на программиста, который держит ненаписанные километры лапши у себя в голове. Шаг влево, шаг вправо – сегфолт.

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

Дада, то, что проще, на самом деле сложнее, потому что там невидимые никому тонкие поля, аура и биополе! Как это прозрачное и в лоб можно не видеть!

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

Вот и я спрашиваю, какая дакини тебе объявила терму про «ненаписанные километры лапши».

Ты просто не понимаешь насколько много в голове приходится держать в параллельном программировании на сишке.

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

Дада, то, что проще, на самом деле сложнее, потому что там невидимые никому тонкие поля, аура и биополе! Как это прозрачное и в лоб можно не видеть!

На вот тебе простой пример use after free:

void pkt_timeout(struct timer_list *t)
{
	struct packet *pkt = from_timer(pkt, t, timer);

	printk("%x\n", pkt->id);
}

void do_something_with_pkt(struct packet *pkt)
{
	usleep_range(X, Y);
	kref_put(&pkt->ref, pkt_free);
}

void pkt_fn(struct work *work)
{
	struct packet *pkt = containter_of(work, struct packet, work);

	timer_setup(&pkt->timer, pkt_timeout, 0);
	mod_timer(&pkt->timer, N);

	mutex_lock(&pkt->lock);
	do_something_with_pkt(pkt);
	mutex_unlock(&pkt->lock);
}

void process_packet(struct packet *pkt)
{
	if (!kref_get_unless_zero(&pkt->ref))
		return;

	INIT_WORK(&pkt->work, pkt_fn);
	schedule_work(&pkt->work);
}
cumvillain
()
Ответ на: комментарий от Siborgium

Популярность Firefox

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

Rust это язык, определенный исключительно через байткод LLVM

Так llvm как раз и есть абстракция для реализации независимого от платформы низкоуровненового кода, clang не даст соврать. Это все равно что кричать что какой-то язык реализован только для x86, это вполне допустимо и реально для старта. Ну и новые реализации без llvm для раста вполне хоть и не шустро появляются: https://github.com/bytecodealliance/wasmtime/tree/main/cranelift https://github.com/Rust-GCC/gccrs

БЧ это тупой и прямолинейный статический сборщик мусора.

Скорее RAII такой сборщик, так что С++ тоже тогда со сборкой мусора.

Стесняюсь спросить, ты на хоть одном из трех (C++, ML, Rust) языков писал? У синтаксисов раста и крестов разве что императивность общая. Все остальное подчистую слизано с ML.

Я писал на всех троих (из ML OCaml) OCaml вполне нормальный императивный язык, просто в нем не принято так писать, но если нужно никаких сложностей с этим нет, не хуже паскаля точно. А синтаксис раста согласен кроме скобок и блоков кода ближе к OCaml, чем к си.

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

оборачивается ментальной нагрузкой на программиста

А ты привык программировать не приходя в сознание, так же как и комментарии на ЛОРе писать?

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

ты вообще не знаешь что такое llvm, похоже.

Эксперт ушел в отрицание – бывает.

Да-да, ты туда и ушёл. Ты ещё скажи, что у сишки куча общего с жабой, потому что основной компилятор для llvm – это clang.

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

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

В яблочко. Rust это язык, определенный исключительно через байткод LLVM. То, что LLVM потом пережевывает этот байткод в нативный код, на свойства Rust как языка не влияет никак – он все еще ничего не знает (и не может знать) про реальный таргет.

ты вообще не знаешь что такое llvm, похоже.

каким шоком для тебя будет, когда ты узнаешь, что в gcc есть такой же «байткод виртуальной машины», в который разные фронты транслируют исходники. Только в gcc он не выставлен наружу.

Стадия отрицания закончилась, началась стадия торга. Пациент убеждает себя, что байткод там и байткод тут это одно и то же, так как называется одинаково. Что же будет, если ему рассказать, что в процессе компиляции что в gcc, что в LLVM, что в любом другом компиляторе (да даже в rustc – фронтенде для LLVM, прости Господи) используется множество промежуточных представлений.

Вот только писал я не про это. Если прочитать мой комментарий не жопой, то окажется, что посыл был про ограниченность раста возможностями LLVM (а также зависимость от LLVM во всех аспектах) и полной оторванности от реального таргета. Концептуально это именно язык с VM наподобие Java. И именно с этим связаны проблемы с const и const generics, которые в rustc пришлось чинить через хаки кодогенератора. И именно с этим связана безумно долгая компиляция.

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

Ну и новые реализации без llvm для раста вполне хоть и не шустро появляются

В списке разве что cranelift можно считать сколь-нибудь работающим. Вот только он для WASM, и тоже с огромным количеством оговорок. Но дело не в этом. Я уже ответил про проблемы раста. И даже если самостоятельная реализация их чинит – в языке они остаются, т.е. пользователь все так же не может сделать decltype просто потому, что концептуально язык так сделать не может.

Скорее RAII такой сборщик, так что С++ тоже тогда со сборкой мусора.

Нет, речь не об этом, а о механизме работы БЧ.

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

Полюбуемся сперва на замечательный безопасный vtable

static const struct dma_fence_ops vgem_fence_ops = {
  .get_driver_name = vgem_fence_get_driver_name,
  .get_timeline_name = vgem_fence_get_timeline_name,
  .release = vgem_fence_release,

  .fence_value_str = vgem_fence_value_str,
  .timeline_value_str = vgem_fence_timeline_value_str,
};
pub(crate) struct Fence {}

#[vtable]
impl FenceOps for Fence {
    const USE_64BIT_SEQNO: bool = false;

    fn get_driver_name<'a>(self: &'a FenceObject<Self>) -> &'a CStr {
        c_str!("vgem")
    }

    fn get_timeline_name<'a>(self: &'a FenceObject<Self>) -> &'a CStr {
        c_str!("unbound")
    }

    fn fence_value_str(self: &FenceObject<Self>, output: &mut dyn Write) {
        let _ = output.write_fmt(format_args!("{}", self.seqno()));
    }

    fn timeline_value_str(self: &FenceObject<Self>, output: &mut dyn Write) {
        let value = if self.is_signaled() { self.seqno() } else { 0 };
        let _ = output.write_fmt(format_args!("{}", value));
    }
}

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

Или давайте почитаем, что же было влито в Linux 6.4 в качестве «Rust for Linux». Посчитать соотношения «строк макросов/строк кода» и «строк кода после macro expansion/строк кода до macro expansion» оставляю в качестве упражнения для читателя.

Процитирую лишь

fn new_example() -> Result<Pin<Box<Example>>> {
    Box::pin_init(pin_init!(Example {
        value <- new_mutex!(0),
        value_changed <- new_condvar!(),
    }))
}

Кстати, крайне рекомендую прочитать километры макропоноса в определениях pin_init!, new_mutex!, new_condvar! и stack_pin_init!.

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

Иии? Половина ядерных макросов выглядит так же. А показанные части vtable вообще не эквивалентны, потому что в первом случае только присваивание, без собственно тела функции.

cumvillain
()
Последнее исправление: cumvillain (всего исправлений: 2)
Ответ на: комментарий от Siborgium

Что же будет, если ему рассказать, что в процессе компиляции что в gcc, что в LLVM, что в любом другом компиляторе (да даже в rustc – фронтенде для LLVM, прости Господи) используется множество промежуточных представлений.

Капитан!

Вот только писал я не про это.

Конечно. Никто кроме тебя же не понимает, что ты пишешь тут.

посыл был про ограниченность раста возможностями LLVM (а также зависимость от LLVM во всех аспектах)

Ограничен ли C возможностями LLVM? Как насчёт C++?

полной оторванности от реального таргета

Что это вообще значит? Оторван ли C от таргета? А если использовать для сборки gccrs, будет ли такая же оторванность от таргета?

Концептуально это именно язык с VM наподобие Java.

Концептуально ты баклажан.

hateyoufeel ★★★★★
()