TLS a Linux kernelben

Kernel

A 4.13-as verzió kiadásával megérkezett egy hosszabb ideje vitatott funkció a Linux kernelbe: a TLS támogatás. Az eredeti RFC-t a Facebook alkalmazásában álló Dave Watson küldte be az LKML-re még 2015-ben. A funkció előnyei az alábbiak lehetnek:

That approach has a number of benefits, according to Watson. Using some additional code that was not part of his submission, he said the in-kernel TLS showed 2-7% better performance than the equivalent done in user space. The idea was inspired by some work [PDF] that Netflix did on FreeBSD to improve the performance of TLS. In addition, two other features could benefit from having TLS in the kernel, he said. The kernel connection multiplexer (KCM) needs access to unencrypted data in the kernel, which this would provide; offloading TLS encryption and decryption to NICs would also require TLS framing support in the kernel.

További részletek itt.

( _ventura_ v | 2017. 09. 04., h – 10:01 )

Már várom a systemd-t a kernelbe, mivel úgyis annyi mindenért felel simán ott a helye.

Fedora 25, Thinkpad x220

amúgy, ha bevágod egy konténerbe, akkor nem kva mindegy?
A docker is kb pont erről szól, hogy mondjuk webszervernél nem kell szarakodni, se jogosultsággal, se vhost-tal, default apache/www-data user, /etc/php.ini globál konfig, stb, aztán szevasz.
--
"Sose a gép a hülye."

( STP | 2017. 09. 04., h – 12:10 )

WinNT 3.0/3.5-ben még a video driver sem futott kernel szinten.
NT 4.0-ban -sebességnövekedés címszóval- már igen. Dőlt is jobbra-balra a cucc a xar driverek miatt.
Itt is hasonló a történet...

De ha a hálózat már része a kernelnek, a rajta levő titkosítás miért ne legyen az? Pláne, mikor manapság mindenütt az interneten erőltetik a titkosított adatforgalmat.
Amúgy nincs olyan helyzet, mikor a kernelnek a userland nélkül kellene, hogy kommunikáljon a külvilággal? Most nem a kémprogramokra gondolok :) hanem távdiagnosztika/távfelügyelet.
Esetleg az olcsóbb routereknél se jönne rosszul, ha gyorsabb lenne a TLS feldolgozása.
Tényleg csak laikusként gondolva/kérdezve.

( persicsb | 2017. 09. 04., h – 14:11 )

Menjen MINDEN a kernelbe, mert akkor hipergyors lesz minden.

( wachag | 2017. 09. 04., h – 16:37 )

Off:
Kövezzetek meg, olyanon már elgondolkodtam, hogy a kobject-származékokat tök logikus lenne D-BUS-on keresztül kiajánlani (megfelelő access controllal). Lényegében RMI alapon lehetne a drivereket birizgálni.
Ad absurdum eljutnánk oda, hogy a driverek userspace-ben vannak, és csak egy alap interface-t nyomkodnak üzeneteken keresztül.

Né, mikrokernel!

( arpi_esp v | 2017. 09. 05., k – 17:09 )

szerintem ez jo otlet. ott a helye, ahogy pl. a pppoe-nek es ipsec-nek is. (regen azok is userspacebe voltak)
es nem hinnem, hogy kotelezo lesz azt hasznalni, aki akar szophat tovabb az userspace agyonforkolt openssl klonokkal :)
ha pedig lesz hozza hw tamogatas (serveres halokartyakban elkepzelheto) az meg jobb.

A'rpi