Reprise du message précédent :
Je crois bien qu'ils peuvent utiliser la stack IP d'Open BSD justement, ils en ont parlé mais je me souviens plus exactement comment c'était agencé vis à vis de leur micro kernel.

edit : yavait aussi un IDS dans le flow de sortie des paquets

C'est la stack IP du linux qui fait hyperviseur du coup.
Facile à auditer/modifier/blinder si besoin.

Y'a bien une solution simple que je vois a faire : encapsulation dans une stack tierce, mais ça reste du firewalling, rajoute de l'overhead sur les MTU (+22bits a chaque niveaux) et dépendant de la stack qui encapsule.
Bref, le chien qui se mord la queue.
Et hormis a aller taper un full µkernel custom, t'es dépendant du patchset appliqué et/où des modifs d'isolation process (type SE Linux, Grsec, où encore la stack d'isolation LXC)
Sans compter qu'il faut remonter si éventuellement ils ont un lancement via busybox ou initrd (qui as aussi une stack qui reste loadée.) ou encore la stack EUFI, voir carrément l'isolation hard du style bit NX (qui, on le sait sur certains proc intels -a minima- est vérolée) voir les redirections VT liées aux firmware (asus, lenovo avec leurs modules custom)
 
Bref, faut maîtriser le hard et le soft là (=firmware) et du coup, je deviens curieuse de savoir comment ils ont sécurisés leurs stack de A à Z.

Tu chiffres le message avant envoi.
Comme ça tu en as plus rien à faire des stacks par lesquelles il passe

 
Raté, t'es quand même soumis a la stack du firmware UEFI (qui sait que t'es en VT et donc sait décoder les flux des machines virtuelles, puisque sans qu'il sache, il ne peut pas rediriger les appels IRQ vers les bonnes machines virtuelles.)
Faut donc jouer du tianocore/avoir accès aux sources dev firmware et les outils kivonbieng de chez AMI/Phoenix-Award/Insyde (et donc être channel partner et avoir accès a certains sources soumis a ADND-illégaux en France mais osef-), où encore carrément passer sous freeBIOS/coreboot qui est un EDK-II/Tianocore rebrandé dans le meilleurs des cas et donc dépendant des modules que tu as.
Une solution pour contourner c'est de modifier les tables par injection via loader UEFI (utilisé par exemple pour les hackintosh). Après, tout dépend de la taille de la structure et ses capacités financières/homogénéité de parc.
A titre perso j'ai des injecteurs de tables sur un module tianocore/duet (qui me sert aussi a convertir en UEFI des vieilles cartes mères). A titre pro, j'ai bossée avec un workflow AMI (cartes intel, tyan, supermicro et asus) pour des clients.

Oui, ça je sais, mais est ce qu'ils l'ont réellement fait de façon sérieuse ?

Vue le monsieur, la réponse serait : en grande partie oui.
Edit : sa conf que Ploum a du voir : http://xenprojectdevelopersummit20 [...] d1I4_ntlBd

redface is red.

Bon, visiblement vous faut des exemple concret de matos susceptible d'être vérolé a bas niveau.
 
http://www.bunniestudios.com/blog/?p=3554
J'ai des exemples de firmware en stock du même acabit. Et ça se fou bien que t'encode ou pas tes flux, avant, après, pendant, rien a foutre : c'est dans le firmware (rappel : firmware = association du hard et du soft de manière embarquée pour qu'un système puisse fonctionner "out of the box", généralement non modifiable et en binaire uniquement).
 

REDFACE IS RED.
 
(c'est plus lisible là ?)

Je traduis : « c'était ironique, je sais très bien ce qu'il est possible de faire sur du matos vérolé »
 

Ah, okay
Edit : j'ai le cerveau un peu endommagé, faut pas m'en vouloir.

On ta hacké le firmware du cerveau ? T'es plus fiable du tout alors

Non, les têtes de lecture ont touchées les plateaux, ça a été restauré de justesse. Mais y'a des secteurs défectueux.

Congélo, ça marche bien dans ces cas là

Tu sous entend que je suis devenue de la viande froide ? <_<

Je disais juste que pour les HDD ça marche bien le congélo J'en ai d'ailleurs « sauvé » un temporairement (dumoins assez longtemps pour récup les données !) la semaine dernière.

Vos histoires de firmwares vérolés, ça me rappelle ça, tiens

Plop https://xen-orchestra.com/blog/xen-orchestra-4-4/

Tiens Oauth2, moi qui doit justement l’implanter sur un projet la semaine pro..pas trop relou à mettre en place ?

Ce qui a été relou c'est d'intégrer Passport. Maintenant une stratégie/fournisseur à intégrer ça va prendre 10 minutes. À plus qu'à

Okay  

Tiens au fait un peu de lecture sur Xenserver :
http://dev.tranquil.it/wiki/Xenserver

J'crois que je les ai croisé plusieurs fois au FOSDEM, les gars de cette boîte

edit : en même temps, des mecs calés sur XenServer en France et basé à Nantes, y'en a pas des masses

 
 
Je confirme.  

Tu bosses chez eux ?

 
Oui.  :

Pro tip : on ouvre notre portail de Partner (revendeur quoi) dans la journée
 
https://xen-orchestra.com/#!/partner
 

Sinon la 4.5 arrive à grands pas : https://github.com/vatesfr/xo-web/milestones/4.5
 
La console s'affiche beaucoup plus vite à présent : https://xen-orchestra.com/blog/faster-consoles-in-xo/

Heureusement qu'ils sont calés Mais on a loupé une suite d'échanges sympathiques sur HFR
 
XaT

A quand l'azerty dans les consoles vnc ?

 
c'est déjà le cas en PV hein
 
Pour le reste, je penche soit pour un pb QEMU, soit un pb noVNC. Dans tous les cas, c'est pas nous directement

Achète un clavier qwerty, noob !

 
Oui oui, je sais.  
 
Peut être un début de réponse: https://github.com/OpenXenManager/o [...] /issues/21
 

 
Mouai.    merci.

4.5 en approche. Petit extrait d'une nouvelle feature : https://xen-orchestra.com/blog/trac [...] roperties/

Pour XO, XAPI ou XCP?
 
merci

XCP c'est le projet avant que XenServer soit ouvert. Normalement, ya plus lieu d'être, donc XAPI buildroot sur GitHub.
 
M'enfin je build pas tous les jours donc j'ai pas essayé récemment

je suis pas sur que de partir d'une centos 6,7 soit une bonne idée, les versions de opam and co sont trop vieilles... je vais tenter avec une deb jessie

Pour moi c'est encore plus compliqué avec du Debian. Et du CentOS 7 ? (Dundee, la prochaine de XenServer sera basé dessus d'ailleurs)

CentOS7 pas de xen dispo dans le repo, donc obligé de passer tout les rpm à la main, de plus, soucis de lib python