"votre parti semble prôner la sortie de la France de l'UE"
Une lecture plus attentive du site de l'UPR (www.upr.fr) vous aurait permis de transformer ce peu assuré "semble" en l'assertion "l'UPR prône la sortie de l'UE, de l'euro et de l'OTAN"
Des nuées ardentes et autres pluies de batraciens devaient s'abattre sur le Royaume-Uni au lendemain du Brexit, ce n'est pas arrivé donc êtes-vous sûr qu'il faille attendre une hypothetique catastrophe britannique pour que le peuple français reprenne sa destinée en main et sorte de l'état actuel catastrophique dans lequel notre pays s'enfonce.
Personnellement je crains plus un non-respect par les politiciens anglo-saxons du vote populaire (donc in-fine un non-Brexit) un peu suivant le scénario français qui suivi le referendum de 2005.
Je ne souhaite pas plus longtemps transformer ce fil de commentaires un lieu de débat politique. Chacun est libre, connaissant un lien, de le consulter honnetement (calmement, sans préjugés, en y accordant du temps pas une lecture diagonale) , et de se faire sa propre opinion, en conscience, en regard de ses valeurs personnelles.
"Je ne vois pas trop en quoi des choix faits sur un CPU des années 70 pourraient s'appliquer correctement aux architectures actuelles."
Mais des choix faits sur les CPU des années 70 sont dans les architectures actuelles. Rien n'est crée ex-nihilo et quoiqu'en dise la chanson, du passé on ne peut pas faire table rase.
Pour preuve
"Fenghua Yu submitted a series of patches to the upstream Linux kernel implementing support for a new Intel CPU feature: Supervisor Mode Execution Protection (SMEP). This feature is enabled by toggling a bit in the cr4 register, and the result is the CPU will generate a fault whenever ring0 attempts to execute code from a page marked with the user bit."
voir blog de Dan Rosenberg
a rapprocher de
"Hardware supported rings were among the most revolutionary concepts introduced by the Multics operating system, a highly secure predecessor of today's UNIX family of operating systems." (voir article Wikipedia reference + haut)
« Rien ne naît ni ne périt, mais des choses déjà existantes se combinent, puis se séparent de nouveau » Anaxagore de Clazomènes
Concernant les buffer overflow ce papier de 2002 http://www.acsac.org/2002/papers/classic-multics.pdf indique
"However, when you look at the published history of Multics security problems
[20, 28-30], you find essentially no buffer overflows.
Multics generally did not suffer from buffer overflows, both because of the choice of implementation language and because of the use of several hardware features.
These hardware and software features did not make buffer overflows impossible, but they did make such errors much less likely."
et plus loin
"In the case of the x86 processors, although the necessary segmentation features are
present, they are almost never used, except for operating systems specifically designed for security, such as GEMSOS[32]."
Donc j'ai franchement tendance à penser que tout est là pour "faire de la sécurité" et qu'il faut réinventer la roue (donc multics -> unix -> linux -> ? pour remplacer ce ? je propose linics mais je ne suis pas sûr cela plairait à Linus ... ça sonne trop minix)
"les futurs processeurs Intel auront un bit de sécurité nommé SMEP. Cette fonction « Supervisor Mode Execution Protection » (évoquée dans ce journal LinuxFr) va générer une erreur quand le noyau essaiera d’exécuter du code depuis une page marquée avec le bit user."
se rapproche fortement du concept de ring
"protection rings, are a mechanism to protect data and functionality from faults (fault tolerance) and malicious behaviour (computer security). "
Pour info, cela était opérationnel dans les années 1965/1970 sur le couple Multics + GE645
D'ou mon couplet de vieux snock (c'était mieux avant et patati et patata ...)
D'aprés l'article sur les rings, les X86 en auraient 4, non utilisés par les OS actuels. A creuser
Quant aux débordements d'entiers tout bon processeur se doit d'avoir un bit d'overflow sur les opérations entiéres, c'est le cas des X86.
Donc charge aux développeurs de s'en servir (ou d'avoir les moyens de ...)
Il en sera de même du futur bit SMEP
Pour les débordements de buffer il me semble que c'est de la pure responsabilité du software
sauf à créer des tampons pur-silicium autogérés ... encore une décennie ou deux soit patient ;-) !
Pour finir un petit pour participer à l'éducation de nos jeunes lecteurs http://www.multicians.org/
multics -> unix -> linux
[^] # Re: TAFTA : toujours bien vivant
Posté par dominique dechamps . En réponse à la dépêche Revue de presse de l'April pour la semaine 35 de l'année 2016. Évalué à -1.
"votre parti semble prôner la sortie de la France de l'UE"
Une lecture plus attentive du site de l'UPR (www.upr.fr) vous aurait permis de transformer ce peu assuré "semble" en l'assertion "l'UPR prône la sortie de l'UE, de l'euro et de l'OTAN"
Des nuées ardentes et autres pluies de batraciens devaient s'abattre sur le Royaume-Uni au lendemain du Brexit, ce n'est pas arrivé donc êtes-vous sûr qu'il faille attendre une hypothetique catastrophe britannique pour que le peuple français reprenne sa destinée en main et sorte de l'état actuel catastrophique dans lequel notre pays s'enfonce.
Personnellement je crains plus un non-respect par les politiciens anglo-saxons du vote populaire (donc in-fine un non-Brexit) un peu suivant le scénario français qui suivi le referendum de 2005.
Je ne souhaite pas plus longtemps transformer ce fil de commentaires un lieu de débat politique. Chacun est libre, connaissant un lien, de le consulter honnetement (calmement, sans préjugés, en y accordant du temps pas une lecture diagonale) , et de se faire sa propre opinion, en conscience, en regard de ses valeurs personnelles.
[^] # Re: TAFTA : toujours bien vivant
Posté par dominique dechamps . En réponse à la dépêche Revue de presse de l'April pour la semaine 35 de l'année 2016. Évalué à -2.
Pas de polémique inutile. A chacun de juger en toute conscience. Point
[^] # Re: TAFTA : toujours bien vivant
Posté par dominique dechamps . En réponse à la dépêche Revue de presse de l'April pour la semaine 35 de l'année 2016. Évalué à 0.
Je souscris entièrement à votre analyse. La duplicité de nos hommes politiques de tous bords ne connait plus aucune limite. Je suggère de lire l'analyse suivante qui rejoint la notre
http://www.upr.fr/actualite/europe/faut-croire-a-pretendue-mort-ttip-tafta
J'espère que les modos de linuxfr.org ont ce minimum de respect de la pluralité qui malheureusement n'existe plus dans le milieu journalistique
[^] # Re: Pendant ce temps, en Python...
Posté par dominique dechamps . En réponse à la dépêche Dans les kiosques cet été 2011. Évalué à 0.
voir http://mail.python.org/pipermail/tutor/2007-January/052358.html
[^] # Re: SMEP et la segmentation
Posté par dominique dechamps . En réponse à la dépêche Le noyau Linux est disponible en version 3.0. Évalué à 2.
"Je ne vois pas trop en quoi des choix faits sur un CPU des années 70 pourraient s'appliquer correctement aux architectures actuelles."
Mais des choix faits sur les CPU des années 70 sont dans les architectures actuelles. Rien n'est crée ex-nihilo et quoiqu'en dise la chanson, du passé on ne peut pas faire table rase.
Pour preuve
"Fenghua Yu submitted a series of patches to the upstream Linux kernel implementing support for a new Intel CPU feature: Supervisor Mode Execution Protection (SMEP). This feature is enabled by toggling a bit in the cr4 register, and the result is the CPU will generate a fault whenever ring0 attempts to execute code from a page marked with the user bit."
voir blog de Dan Rosenberg
a rapprocher de
"Hardware supported rings were among the most revolutionary concepts introduced by the Multics operating system, a highly secure predecessor of today's UNIX family of operating systems." (voir article Wikipedia reference + haut)
« Rien ne naît ni ne périt, mais des choses déjà existantes se combinent, puis se séparent de nouveau » Anaxagore de Clazomènes
Trop fort Anaxagore! ;-)
[^] # Re: SMEP et la segmentation
Posté par dominique dechamps . En réponse à la dépêche Le noyau Linux est disponible en version 3.0. Évalué à 1.
Il semble que les X86 aient une instruction into qui permet de lever des exceptions sur bit d'overflow (voir http://www.gamedev.net/topic/310538-integer-overflow-exception/)
Concernant les buffer overflow ce papier de 2002 http://www.acsac.org/2002/papers/classic-multics.pdf indique
"However, when you look at the published history of Multics security problems
[20, 28-30], you find essentially no buffer overflows.
Multics generally did not suffer from buffer overflows, both because of the choice of implementation language and because of the use of several hardware features.
These hardware and software features did not make buffer overflows impossible, but they did make such errors much less likely."
et plus loin
"In the case of the x86 processors, although the necessary segmentation features are
present, they are almost never used, except for operating systems specifically designed for security, such as GEMSOS[32]."
Donc j'ai franchement tendance à penser que tout est là pour "faire de la sécurité" et qu'il faut réinventer la roue (donc multics -> unix -> linux -> ? pour remplacer ce ? je propose linics mais je ne suis pas sûr cela plairait à Linus ... ça sonne trop minix)
[^] # Re: SMEP et la segmentation
Posté par dominique dechamps . En réponse à la dépêche Le noyau Linux est disponible en version 3.0. Évalué à 3.
Et pourtant
"les futurs processeurs Intel auront un bit de sécurité nommé SMEP. Cette fonction « Supervisor Mode Execution Protection » (évoquée dans ce journal LinuxFr) va générer une erreur quand le noyau essaiera d’exécuter du code depuis une page marquée avec le bit user."
se rapproche fortement du concept de ring
"protection rings, are a mechanism to protect data and functionality from faults (fault tolerance) and malicious behaviour (computer security). "
Pour info, cela était opérationnel dans les années 1965/1970 sur le couple Multics + GE645
D'ou mon couplet de vieux snock (c'était mieux avant et patati et patata ...)
D'aprés l'article sur les rings, les X86 en auraient 4, non utilisés par les OS actuels. A creuser
Quant aux débordements d'entiers tout bon processeur se doit d'avoir un bit d'overflow sur les opérations entiéres, c'est le cas des X86.
Donc charge aux développeurs de s'en servir (ou d'avoir les moyens de ...)
Il en sera de même du futur bit SMEP
Pour les débordements de buffer il me semble que c'est de la pure responsabilité du software
sauf à créer des tampons pur-silicium autogérés ... encore une décennie ou deux soit patient ;-) !
Pour finir un petit pour participer à l'éducation de nos jeunes lecteurs
http://www.multicians.org/
multics -> unix -> linux
[^] # Re: SMEP et la segmentation
Posté par dominique dechamps . En réponse à la dépêche Le noyau Linux est disponible en version 3.0. Évalué à 2.
Multics le retour ?
SMEP me rappelle les anneaux de Multics
http://en.wikipedia.org/wiki/Ring_%28computer_security%29
"A quand un CPU ayant des pointeurs 96 bits (64bit d'adressage et 32bit de segments)?"
ça s'appellait un mainframe ...
La roue tourne et on la réinvente !