Linux? - Page 200

Ahhhh, c'est ça !!!!! Je ne m'étais jamais renseigné (Asus P5KC).

Pour poursuivre la discussion qui avait commencé ici :
topics/128625-f-ipad-informatique-et-high-tech/352#post-10554

Ça fait un moment que je n'avais pas suivi l'évolution de Linux et BSD question sécurité, mais je suis vraiment surpris par ce que dit Lionel. On sait pourquoi ils traînent les pieds à ce point sur ces sujets ? Ça m'étonne tout particulièrement pour OpenBSD, qui est censé être orienté sécurité...

Oui enfin pour OpenBSD il faut encore voir si c'est "vraiment" utile vu ce qui est mis en place :

https://en.wikipedia.org/wiki/OpenBSD_security_features#Memory_protection

On sait pourquoi ils traînent les pieds à ce point sur ces sujets ?

A mon sens, compatibilité avec le code existant, facilité d'utilisation et performance. Comme nous le savons, la caractéristique dite non-fonctionnelle "sécurité" rentre directement en conflit avec les trois, et pour la très grande majorité des utilisateurs, ce sont compatibilité + utilisabilité + performance qui gagnent devant sécurité... C'est aussi pour ça que MacOS X et Windows ne proposent pas non plus les features qui vont bien, et puis ils ne sont pas ouverts.
Les entreprises suivent, en ajoutant en plus le time to market bas et le coût monétaire bas, donc la sécurité est toujours le parent pauvre, et l'IoT nous prépare une belle pagaille...

Ça m'étonne tout particulièrement pour OpenBSD, qui est censé être orienté sécurité...

Censé, en effet. Mais spender les écharpe régulièrement pour leurs réinventions incomplètes, mal faites et avec des années de retard de PaX/grsecurity - dont justement le W^X, pâle copie de MPROTECT - et leur réputation persistante, mais partiellement usurpée, de soin apporté à la sécurité...
Que le kernel OpenBSD soit plus sécurisé que le kernel Linux standard, c'est assez clair, parce que c'est une base de code plus simple et plus limitée fonctionnellement. Il y a moins de drivers, moins de sous-systèmes.
Sous FreeBSD, la présence persistante du Giant Kernel Lock, des années après que Linux ait éliminé le Big Kernel Lock de même usage, simplifie également la correction du code, au détriment bien sûr de la performance sur systèmes multi-coeurs.

Ils sont plus populaires en proportion côté serveur, mais la contribution réelle des BSD et de PaX/grsecurity (certes partiellement intégré dans de plus en plus de distros, mais rarement comme kernel principal) à la sécurité de l'utilisateur final est limitée, puisque leur utilisation est limitée chez l'utilisateur final.

Lionel Debroux (./5974) :

On sait pourquoi ils traînent les pieds à ce point sur ces sujets ?

A mon sens, compatibilité avec le code existant, facilité d'utilisation et performance. Comme nous le savons, la caractéristique dite non-fonctionnelle "sécurité" rentre directement en conflit avec les trois, et pour la très grande majorité des utilisateurs, ce sont compatibilité + utilisabilité + performance qui gagnent devant sécurité...

En effet, vu l'argument Linus (Linux) vs. Andrew (Minix) concernant le "meatbag" des process micro-kernels, je pense que c'est toute la philosophie de Linus qui est à revoir, et nommer Andrew comme véritable visionnaire à long terme. Linux en compute-farm peut-être, mais Minix en véritable user-os.

Linux en compute-farm peut-être, mais Minix en véritable user-os.

C'est plutôt le contraire qui se produit: Linux et autres OS riches en user-facing, pour les features, et parfois, micro-kernels en tant qu'hyperviseurs en-dessous des OS riches
Pas tous les hyperviseurs ne sont des micro-kernels.

Sauf niches, les micro-kernels ont perdu la bataille il y a longtemps, pour des raisons partiellement mauvaises d'ailleurs. J'avais lu, à titre professionnel, parmi les rares papiers que j'ai lus, les papiers fondateurs SOSP'93 et SOSP'95 de Jochen Liedtke sur L4, qui expliquaient bien pourquoi les autres implémenteurs de micro-kernels, dans la fin des années 1980 et le début des années 1990, avaient fait n'importe quoi dans leurs implémentations lourdes (pression dans les I-Cache et D-Cache) et pas prévues pour tirer parti des capacités et spécificités du processeur. Un micro-kernel efficace pour 80486 et un micro-kernel efficace pour Pentium sont très différents.
Mais c'était déjà trop tard pour inverser la tendance, les kernels monolithiques avaient pris définitivement le pouvoir. L'héritage des travaux de Liedtke (mort quelques années plus tard, bien trop tôt) a survécu jusqu'à nos jours en OKL4 et seL4. OKL4 a même été un grand succès commercial - mais de façon totalement invisible du grand public, et la grande majorité des développeurs professionnels n'est pas au courant.

J'aimerai bien quand même que Linus me prétende, eye-to-eye, avec un aplomb poker-face que +1000% de gain en sécurité n'est pas justifié par 5% (au pire) de perte en performance. Je veux dire que le bon sens commun indique aussi clairement que possible que l'isolation des process et le message-passing sont des features future-compliant que certes les premiers CPU avaient peut être du mal à supporter, mais depuis l'avènement des MMU ou NX, les aspects sécuritaires étant dorénavant pris en charge au niveau matériel sans impact sur les performances, plus rien désormais ne justifie les architectures monolithiques.

On va voir ce qui va se passer cette année et l'année prochaine avec l'arrivée plus massive:
* des réseaux 40+ Gbps et des stockages de masse non volatiles rapides, pour lesquels la solution pour ne pas gaspiller bêtement les ressources est de se passer de transitions kernel space / user space, et donc de se passer au maximum du kernel, quel que soit sa philosophie. Les adaptations de Linux ont déjà bien commencé: DAX, etc.
* des unikernels, qui tournent sous vrai kernel ou hyperviseur, et peuvent être soit des micro-kernels, soit des kernels monolithiques modularisés, par exemple Rump kernel basé NetBSD ou LibOS basé Linux.

Merci pour les explications.

je comprends pas ce que fout ZFS sur des PC de madame michubuntu.

pour des clusters de stockage ok mais il est connu que ZFS ne marche pas correctement avec moins de 8 GB de RAM et je sais plus combien de volumes de disque.

Ubuntu concerne aussi les serveurs

Ils distribuent aussi le pilote NVidia qui est tout aussi illégal (module de noyau sous licence incompatible avec la licence GPLv2 du noyau Linux), donc pas étonnant qu'ils s'en foutent aussi dans ce cas.

Vache Lionel, t'en connais une tartine côté kernel, merci beaucoup c'était fort intéressant

Kevin > apparemment, c'est plus complexe que ça et le driver nVidia ne pose pas de problème de licence. Quelqu'un en parle dans les commentaires :
http://forums.theregister.co.uk/forum/1/2016/02/26/canonical_in_zfsonlinux_gpl_violation_spat/#c_2793485

La distinction entre EXPORT_SYMBOL et EXPORT_SYMBOL_GPL n'est pas universellement accepté, même parmi les contributeurs au noyau, et ils devraient tous être d'accord pour que ça ait valeur légale. Distribuer une combinaison linkée de code GPL et de code non-GPL est illégal quelles que soient les APIs utilisées.

Ou alors, on pourrait se retrouver avec toutes les cartes NVidia qui fonctionnent péniblement en 2D et certainement pas en 3D, ça serait fun aussi...

La 3D fonctionne très bien avec Nouveau de nos jours. Ça fait longtemps que Nouveau gère OpenGL.

Nouveau a été créé en faisant du reverse engineering, non ? Pour l'Autriche, je ne sais pas, mais en France, c'est illégal, et pour le coup, c'est inscrit dans une loi.
Entre une société qui propose à l'utilisation son module pas GPL pour fonctionner avec du GPL (à noter qu'ils ne mettent pas le couteau sous la gorge des utilisateurs, hein), et des codeurs qui scrutent à la loupe (pour pas réutiliser "reverse engineering") le matériel pour faire un module GPL-Compliant, je ne saurais dire lesquels sont les plus vils faquins.

Tel que je lis la loi, ça ne permettrait pas de créer un driver de carte graphique par reverse-engineering. (Une carte graphique n'étant pas un logiciel, et le reverse-engineering du driver n'ayant pas pour finalité l'utilisation du dit driver.)

Ben c'est le driver qui est revese engineeré, grâce à ces termes, non ?

indispensable pour obtenir les informations nécessaires à l'interopérabilité

Par analogie, si un fichier xls est une CG, et Excel un driver (celui qui l'exploite), il s'agit d'étudier son fonctionnement pour reproduire un excel-like (le driver) afin de permettre l'exploitation du xls.
M'enfin je suis pas avocat. Et j'imagine que si NVidia avait pu taper sur ceux qui ont fait Nouveau, ils ne se seraient pas gênés. ^^

Sauf si ça les ennuyait de maintenir le driver proprio et qu'ils voyaient d'un bon œil (non officiel) que quelqu'un le fasse à leur place sans avoir à délivrer publiquement les spécifications techniques de leurs CG

Folco (./5992) :
Et j'imagine que si Nvidia avait pu taper sur ceux qui ont fait Nouveau, ils ne se seraient pas gênés. ^^

pourquoi donc ?

Juste une supputation. S'ils n'ont pas voulu livrer la moindre info pendant très longtemps, c'est qu'ils ont dû estimer qu'un autre driver efficace pourrait leur faire du tort. Auquel cas, ils auraient eu intérêt à empêcher le développement d'un driver tiers.

Je pense pas que ce soit pour ça. Au fond, ils s'en fichent que les utilisateurs utilisent Nouveau plutôt que leur driver proprio : ce qu'ils vendent c'est du matériel, pas du soft. Un utilisateur de Nouveau, ça reste quelqu'un qui a acheté (ou achètera) une CG nVidia, et donc qui fait rentrer du fric.

La raison pour laquelle beaucoup de fabricants ne font pas de drivers open-source (outre le fait que ça n'est pas vraiment rentable, quand on fait le ratio du travail que ça représente par rapport au pourcentage d'utilisateurs d'OS open-source), c'est qu'ils ne veulent pas dévoiler leurs secrets à leurs concurrents. Et justement, le segment des cartes graphiques 3D est très concurrentiel, et une part non négligeable des performances est liée à l'optimisation des drivers. Ils ne peuvent pas empêcher Nouveau ou leurs concurrents de reverse-engineerer, mais ils ne vont pas non plus leur filer des infos sur un plateau.

[Cross]

Sauf si :
- Ce n'est pas le problème du driver tiers qui leur faisait garder leurs spécifications au chaud, mais plutôt le manque d'envie de laisser ATI y jeter un oeil ;
- Je ne vois pas en quoi un driver efficace qui va toucher moins de 2% (j'arrondis, hein) de leurs utilisateurs va leur changer la vie, d'autant que je ne vois pas non plus quel bénéfice ils peuvent retirer de l'exécution de leur driver plutôt qu'un autre. Si ils maintiennent leur driver proprio à jour, c'est à mon sens pour la même raison que les vendeurs de smartphones fournissent des mise à jour de l'OS : pour l'image de marque.

NVidia a longtemps fait comme si Nouveau n'existait pas. Je me rappelle comment, quand ils ont arrêté de développer l'antique pilote non-optimisé et obfusqué nv, ils ont conseillé d'utiliser vesa pour les nouvelles cartes non gérées par nv (le temps d'installer leur blob propriétaire), bref, tout sauf Nouveau.

Lionel Debroux (./5978) :
* des unikernels, qui tournent sous vrai kernel ou hyperviseur, et peuvent être soit des micro-kernels, soit des kernels monolithiques modularisés, par exemple Rump kernel basé NetBSD ou LibOS basé Linux.

J'avais jamais entendu parler des unikernels. J'ai cherché sous Wikipedia et j'ai eu une bonne tranche de rigolade Dans le genre réinvention de roue, c'est terrible (ou alors j'ai rien compris).

Tron (./5977) :
J'aimerai bien quand même que Linus me prétende, eye-to-eye, avec un aplomb poker-face que +1000% de gain en sécurité n'est pas justifié par 5% (au pire) de perte en performance.

Mmmm.... J'aimerais juste que tu me dises comment tu calcules ton gain en sécurité. Parce qu'il me semble bien qu'avoir ce chiffre de manière objective est bien ce qui manque pour que les features avancées de sécurité rentrent dans le kernel.

Je veux dire que le bon sens commun indique aussi clairement que possible que l'isolation des process et le message-passing sont des features future-compliant que certes les premiers CPU avaient peut être du mal à supporter,

C'est quoi des features future-compliant ?

mais depuis l'avènement des MMU ou NX, les aspects sécuritaires étant dorénavant pris en charge au niveau matériel sans impact sur les performances, plus rien désormais ne justifie les architectures monolithiques.

Pas compris . Le MMU et le NX sont gérés par Linux depuis des années...

Kevin Kofler (./5983) :
Ils distribuent aussi le pilote NVidia qui est tout aussi illégal (module de noyau sous licence incompatible avec la licence GPLv2 du noyau Linux), donc pas étonnant qu'ils s'en foutent aussi dans ce cas.

Au dernières nouvelles, il ne distribue que les sources du driver qui est compilé et lié au noyau par l'utilisateur final, la modification du programme est donc faire par l'utilisateur final et tout modification non-distribuée d'un programme GPLv2 n'a pas à être sous GPLv2. C'est donc légal de leur point de vue.

GoldenCrystal (./5991) :
Tel que je lis la loi, ça ne permettrait pas de créer un driver de carte graphique par reverse-engineering. (Une carte graphique n'étant pas un logiciel, et le reverse-engineering du driver n'ayant pas pour finalité l'utilisation du dit driver.)

Si, car il s'agit du firmware qui tourne sur la carte.

pedrolane (./5989) :
mais en France, c'est illégal, et pour le coup, c'est inscrit dans une loi.

Depuis quand c'est illégal en france ?

Folco (./5992) :
Et j'imagine que si NVidia avait pu taper sur ceux qui ont fait Nouveau, ils ne se seraient pas gênés. ^^

En fait, NVidia a totalement ignoré nouveau pendant de longues années. C'est juste à cause des puces mobiles que NVidia bosse sur nouveau.

J'aimerais juste que tu me dises comment tu calcules ton gain en sécurité. Parce qu'il me semble bien qu'avoir ce chiffre de manière objective est bien ce qui manque pour que les features avancées de sécurité rentrent dans le kernel.

Hmm... ce n'est pas du tout l'absence de métrique comme le gain en sécurité qui manquent pour l'inclusion des features de PaX/grsecurity dans Linux mainline, non.

Linus et les autres ne peuvent pas ne pas savoir qu'UDEREF, KERNEXEC, RANDSTRUCT et CONSTIFY empêchent la plupart des exploits dangereux, dont les PoC sont mentionnés et discutés sur LWN plusieurs fois par an. Souvent, chacun des quatre-là est individuellement suffisant pour transformer l'exploit kernel, en général privesc, en DoS de l'application sans impact sur le kernel. spender poste régulièrement cet état de fait dans les commentaires, et mingo lit traditionnellement LWN, comme Greg Kroah-Hartman ("gregkh"), par exemple.
PAX_MEMORY_SANITIZE trouve régulièrement des use after free, normalement non exploitables sur un kernel PaX/grsec parce que la sanitization fait pointer vers une plage spéciale du kernel space plutôt que vers des endroits potentiellement mappables en user-space, comme dans un kernel standard (j'ai lu ça quelque part récemment).
Plus rarement, REFCOUNT, autre vieille feature de PaX, empêche des exploits dangereux de fonctionner. Il y en a eu un il y a quelques semaines. Et les autres protections contre les integer overflows trouvent régulièrement de vrais problèmes dans le kernel, même s'ils trouvent aussi des endroits où le code fait un overflow mais ce n'est pas grave.
Et caetera.

Des gens comme Kees Cook ("kees") ou Andy Lutomirski ("luto"), ou Emese Revfy ("ephox"), maintenant qu'elle a apparemment trouvé un peu de financement par la Core Infrastructure Initiative pour le Kernel Self-Protection Project, essaient d'améliorer lentement les choses, ce qui commence en premier lieu pour kees ou luto par faire acter par Linus et les autres qu'il y a un vrai problème... A priori, kees et luto ont fini par obtenir un certain niveau de prise de conscience.
Mais Linus et les autres sont encore loin d'être dans le bon état d'esprit, voir Linus qui avait posté qu'il était content de ne pas avoir intégré UDEREF et KERNEXEC parce qu'il y a SMAP et SMEP... c'est complètement idiot !

EDIT: fix tag mismatch.