Ядро жиреет

Ну компилять именно этот модуль для себя не обязательно же.

Судя по коду с гитхаба, целиком они туда реализацию TLS всё равно не запихнули, для хэндшейка всё равно юзерспейсный OpenSSL или gnutls нужен

Непонятно, зачем подобное пихают в ядро. Жило бы в виде отдельного проекта.

Целиком реализация и не нужна. Хендшейк один раз в сессию, можно потерпеть и юзерспейс. А вот для потока данных кернелспейсное шифрование будет быстрее.

А ты ядра с каким BMI находишь наиболее привлекательными?

спасибо за новость

Такое чувство, что в ядро запихают всё, что нужно энтерпрайзу, вот монстр получится

Ну и чо? Никто тебя не просит собирать ядро со всем тем, что там есть, да так никто и не делает. А места на диске не жалко, пусть хоть гиг весит.

теперь heartbleed еще и в ядре будет?

нет, в юзерспейсе останется, судя по всему

bleed to the core, однако ;)

А нет ли тут намеков на уязвимости? Слишком высокоуровневые вещи запихиваются

А вот для потока данных кернелспейсное шифрование будет быстрее.

Не быстрее ли будет вытащить сетевой стек в юзерспейс?

Может, пора откопать Hurd?

Можно куда угодно. Главное минимизировать смену контекстов, количество системных вызовов и копирования буферов. При этом перед впиливанием регрессионные тесты гоняют.

Жду браузер в ядре.

Добавлена реализация протокола TLS на уровне ядра (KTLS)

На самом деле нет. Блочный шифр перетащили в ядро, чтобы можно было sendfile() делать в TLS соединения.

заглянул в экспериментальную репу там только 4.13.0-rc7, не люблю я эти rc - дождусь окончательного варианта, сам больше компилировать не буду - надоело херней заниматься...

Не быстрее ли будет вытащить сетевой стек в юзерспейс?

Быстрее и проще, если твое приложение — единственное взаимодействующее с сетью на машине.

да тут не намеки. Как там часто в openssl уязвимости находят?

А вот для потока данных кернелспейсное шифрование будет быстрее

И почему же, разреши поинтересоваться?

Чтобы отослать мегабайт данных из файла, эти данные нужно скопировать в юзерспейс, там зашифровать, затем скопировать обратно в ядро. Если шифрование в ядре, достаточно просто зашифровать. Это одно копирование вместо трёх, и намного меньше перескоков из ядра и обратно.

да тут не намеки. Как там часто в openssl уязвимости находят?

Как часто в AES уязвимости находят?

Такое тоже делают

а Thread Local Storage реализована поддержка? или это на уровне проца все?

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

когда у тебя kernel_4.XXX_drivers.cab.p7z.rpm будет весить под 15 гигов, тогда и поговорим про жир 8-)

Судя по тому, как ты задал вопрос, тебе не нужен ответ, ты просто хотел показаться умнее, чем есть.

Зачем ждать? Пиши. Кроме тебя некому.

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

в TLS 1.3 хэндшейк ещё и по ключам. там вообще один раз обмен всей дребеденью с шифрованием на весь период действия ключа. получается весьма экономно.

Проблема с wifi решилась?

как-то пока я не углублялась. в 4.13 сигнал фиговый. надо конпелять девелоперскую ветку, похоже. и разбираться, что там не так. я не хотела углубляться, но, вероятно, придётся. хочу пощупать 4.13 c TLS 1.3, но у меня на нём вайфай едва жив. так что пока откатилась на 4.11 и буду посмотреть, что там за проблема такая странная.

Непонятно, зачем подобное пихают в ядро. Жило бы в виде отдельного проекта.

чтобы в один прекрасный момент освободится от приставки GNU в названии ОС - GNU/Linux

Давно уже. Крупные конторы запизивают туда только то, что им нужно. А сообщество - то, что нужно сообществу. Вот и вся история развития ядра.

Судя по тону твоего ответа, тебе и сказать-то нечего.

Я уже сказал Ядро жиреет (комментарий)
Бисера дальше метать не намерен.

Это одно копирование вместо трёх, и намного меньше перескоков из ядра и обратно

Вроде убедил: и для sendfile, и для splice уходят два копирования kernel=>user, user=>kernel, что не может быть плохо.

На FreeBSD 11.1:

> du /boot/kernel
 56M	/boot/kernel

я про объём сорцов. я не измеряла, сколько оно собирается. на самом деле, зависит от конфига. если оставить только специфические дрова для конкретной машины - соберётся за пару минут, я думаю. я одно время собирала очень узкозаточенные ядра для эмбеддеда - они вообще быстро собирались даже на слабом Core i5. ну и плюс многое зависит от скорости работы винта: там не так много работы компилятора, сколько дёрганий винта на чтение и запись. я запускала обычную полновесную сборку, в бэкграунде на Core i7, но с довольно слабой производительностью. скорость сборки меня не очень интересует - я запускаю такие вещи либо когда сплю, либо когда ухожу куда-то в магазин или спортзал. вероятно, тоже где-то полчаса или около этого, но не замеряла. меня больше беспокоит объём на винте, который зажирается при сборке. увы, при куче мелких файлов это неизбежное зло.

А у вас возможно организовать сжатие tmpfs в памяти? Я бы предложил использовать это, если ОЗУ много и процессор достаточно мощный. А так - только SSD спасёт ситуацию.

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

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