quelques notes de lectures (pas très beau, histoire de l'avoir sur le git)
This commit is contained in:
Amaury
Amaury JOLY
parent
ef0e2b3e45
commit
028ef5f9f2
0
recherches/Raynal18.md
Normal file → Executable file
0
recherches/Raynal18.md
Normal file → Executable file
405
recherches/Stage.bib
Executable file
405
recherches/Stage.bib
Executable file
@ -0,0 +1,405 @@
|
||||
|
||||
@article{van_der_linde_practical_2020,
|
||||
title = {Practical client-side replication: weak consistency semantics for insecure settings},
|
||||
volume = {13},
|
||||
issn = {2150-8097},
|
||||
url = {https://dl.acm.org/doi/10.14778/3407790.3407847},
|
||||
doi = {10.14778/3407790.3407847},
|
||||
shorttitle = {Practical client-side replication},
|
||||
abstract = {Client-side replication and direct client-to-client synchronization can be used to create highly available, low-latency interactive applications. Causal consistency, the strongest available consistency model under network partitions, is an attractive consistency model for these applications.},
|
||||
pages = {2590--2605},
|
||||
number = {12},
|
||||
journaltitle = {Proceedings of the {VLDB} Endowment},
|
||||
shortjournal = {Proc. {VLDB} Endow.},
|
||||
author = {Van Der Linde, Albert and Leitão, João and Preguiça, Nuno},
|
||||
urldate = {2023-06-06},
|
||||
date = {2020-08},
|
||||
langid = {english},
|
||||
annotation = {Fiche Lecture
|
||||
Résumé:
|
||||
Le papier spécifie une amélioration de la cohérence causale, rajoutant des propriétés en renforçant la sécurité. Ils comparent ensuite différentes implémentations de leurs solutions en axant sur le besoin d'une faible latence pour privilégier l'interactivité.
|
||||
Plan:
|
||||
|
||||
|
||||
Présente les attaques possibles sur la cohérence causale. \$3
|
||||
|
||||
|
||||
Définissent les propriétés d'une cohérence causale sécurisée répondant aux attaques. \$4
|
||||
|
||||
|
||||
Définit de nouvelles classes de cohérence étendant la cohérence causale. \$5
|
||||
|
||||
|
||||
Définit des algorithmes pour implémenter ces classes de cohérence. \$5
|
||||
|
||||
|
||||
Présente des résultats de performance de ces algorithmes. \$6
|
||||
|
||||
|
||||
Détails du document
|
||||
Types d'attaques
|
||||
|
||||
|
||||
Tempering: un nœud soumet une opération pour anticiper une opération en attente qui n'a pas encore été exécutée par le système.
|
||||
|
||||
|
||||
Omitting dependencies: un nœud n'utilise qu'un sous-ensemble des opérations dans la dépendance. Il sera en mesure de soumettre une tâche concurrente au système.
|
||||
|
||||
|
||||
Unseen dependencies (également appelé add): un nœud soumet une opération qui dépend d'une opération qu'il n'a pas vue. Il permet à l'attaquant d'anticiper une opération. (C'est différent du tempering car dans ce cas l'opération n'existe pas encore).
|
||||
|
||||
|
||||
Combining omitting and unseen: un nœud peut omettre une dépendance et soumettre une opération qui dépend d'une opération qu'il n'a pas vue.
|
||||
|
||||
|
||||
Sibbling generation: créer deux opérations différentes avec le même id. L'attaquant pourrait créer une divergence permanente entre les nœuds.
|
||||
|
||||
|
||||
Propriétés d'une cohérence causale sécurisée
|
||||
|
||||
|
||||
Immutable History: Chaque opération est envoyée avec son passé causal à chaque nœud valide. (Contrecarre le tempering)
|
||||
|
||||
|
||||
No Future Dependencies Chaque opération est envoyée avec son état de connaissance de l'état des nœuds du système. (Contrecarre l'unseen dependencies puisque l'opération sera considérée par l'ensemble du système comme "en retard" et sera donc ignorée)
|
||||
|
||||
|
||||
Causal Execution: Toute opération \$o\_i\$ appartenant au passé causal d'une opération \$o\$ doit être sérialisable t.q. : \$o\_i {\textless} o\$. (Force une sorte de synchronisation entre les nœuds)
|
||||
|
||||
|
||||
Eventual Sibling Detection: Chaque opération doit être considérée comme une faute éventuelle et doit donc avoir la possibilité d'être révoqué. La révocation ne peut se produire qu'après l'exécution de l'opération. (Assure que si deux opérations sont créées avec un même identifiant et crée une divergence, alors les nœuds auront toujours un moyen de retourner à un état convergent. Contrecarre **en partie** le sibling generation)
|
||||
|
||||
|
||||
Limitted Omission:
|
||||
|
||||
|
||||
{\textless}!-- {OLD}
|
||||
\# Practical Client-side Replication: Weak Consistency Semantics for Insecure Settings
|
||||
\#\# Authors: van der Linde, Leitao, Preguica
|
||||
\#\# Definition
|
||||
causal consistency: model enforcing clients to observe a state that respects the causal order of operations. (this is the case for decentralized and peer to peer systems)
|
||||
Attacks on causal consistency:
|
||||
- Tempering: a node submit an operation to anticipate a pending operation actually not yet executed by the system.
|
||||
- Omitting dependencies: a node used only a subset of the operations in the dependency. He will be able to submit a concurrent task to the system.
|
||||
- Unseen dependencies (also called add): a node submit an operation that depends on an operation that he didn't see. It can be usefull for the attacker to anticipate the operation. (This is different from tempering because in this case the operation does not exist yet).
|
||||
- Combining omitting and unseen: a node can omit a dependency and submit an operation that depends on an operation that he didn't see.
|
||||
- Sibbling generation: creating two differents operations with the same id. The attacker could create a permanent state divergence between the nodes.
|
||||
\#\# Summary
|
||||
\#\#\# Solutions used in the paper
|
||||
\#\#\#\# Secure Causal Consistency
|
||||
Autors defined the properties of a secure causal consistency: Immutable History, No Future Dependencies, Causal Executions, Limitted Omission, and Eventual Sibling Detection.
|
||||
The algorithms they propose used the following solutions for each property:
|
||||
- Immutable History: The nodes sign the operations and the dependencies. The nodes can't temper the history because they can't sign the operation.
|
||||
- No Future Dependencies: Each operations includes a hash of all direct causal dependencies. The nodes can't omit dependencies because they can't sign the operation.
|
||||
- Causal Executions: The nodes need to verify, before executing an operation, that all the dependencies are executed.
|
||||
- Limitted Omission: It's by design impossible due to the metadata (hash of the dependencies).
|
||||
- Eventual Sibling Detection: Many mechanism are used:
|
||||
- a node is able to detect when two operations with the same id are send from differents paths.
|
||||
- a node is able than the hash of the dependencies is different with the hash provide by the operation.
|
||||
- the nodes are comparing the dependencies of the operation between them. If they are different, they are able to detect the sibbling generation.
|
||||
\#\#\#\# Secure Strict Causal Consistency
|
||||
The Secure Strict Causas Consistency is a variant of the Secure Causal Consistency who is using a trusted service. Such as the enclave in Intel {SGX}. Thus the usage of a hash of the dependencies is unnecessary.
|
||||
An issue of this solution is the cost of the connection to the trusted service. A possible attack would be to connect and disconnect a lot of time of the trusted service to make the system slow.
|
||||
This sollution was not explored in the paper due to this issue. --{\textgreater}
|
||||
|
||||
},
|
||||
file = {Van Der Linde et al. - 2020 - Practical client-side replication weak consistenc.pdf:/home/amaury/Zotero/storage/5TJ3SA56/Van Der Linde et al. - 2020 - Practical client-side replication weak consistenc.pdf:application/pdf},
|
||||
}
|
||||
|
||||
@book{perrin_concurrence_2017,
|
||||
title = {Concurrence et cohérence dans les systèmes répartis},
|
||||
isbn = {978-1-78405-295-9},
|
||||
abstract = {La société moderne est de plus en plus dominée par la société virtuelle, le nombre d’internautes dans le monde ayant dépassé les trois milliards en 2015. A la différence de leurs homologues séquentiels, les systèmes répartis sont beaucoup plus difficiles à concevoir, et sont donc sujets à de nombreux problèmes.La cohérence séquentielle fournit la même vue globale à tous les utilisateurs, mais le confort d\&\#39;utilisation qu\&\#39;elle apporte est trop coûteux, voire impossible, à mettre en oeuvre à grande échelle. Concurrence et cohérence dans les systèmes répartis examine les meilleures façons de spécifier les objets que l’on peut tout de même implémenter dans ces systèmes.Cet ouvrage explore la zone grise des systèmes répartis et dresse une carte des critères de cohérence faible, identifiant plusieurs familles et démontrant comment elles peuvent s’intégrer dans un langage de programmation.},
|
||||
pagetotal = {194},
|
||||
publisher = {{ISTE} Group},
|
||||
author = {Perrin, Matthieu},
|
||||
date = {2017-09-01},
|
||||
langid = {french},
|
||||
note = {Google-Books-{ID}: 6DRlDwAAQBAJ},
|
||||
annotation = {Fiche Lecture
|
||||
Réflexions
|
||||
Un peu de mal à comprendre les bornes de cohérence.
|
||||
Ça veut dire quoi composable ?
|
||||
Définitions
|
||||
Système réparti : Collection d'entités de calcul autonomes connectées en vue d'accomplir une tâche commune.
|
||||
Entités de calcul : (ou processus). Entité d'un réseau capable de décision en fonction de stimuli.
|
||||
Cohérence forte : Les objets ciblés cachent la concurrence et se comportent comme si tous les accès était séquentiels.
|
||||
Introduction
|
||||
Un système réparti est caractérisé par :
|
||||
|
||||
|
||||
L'échelle du système
|
||||
|
||||
|
||||
Les moyens d'interactions
|
||||
|
||||
|
||||
Gestion des fautes (c.f. : reynal18 attacks) (et nombre de fautes acceptables)
|
||||
|
||||
|
||||
Rapport au temps (y a-t-il une horloge partagée ?)
|
||||
|
||||
|
||||
Les histoires concurrentes
|
||||
Une histoire concurrente est un ensemble d'événements partiellement ordonnés par un ordre de processus et étiquetés par des opérations.
|
||||
3 primitives possibles :
|
||||
|
||||
|
||||
Broadcast (diffusion fiable) :
|
||||
|
||||
|
||||
Validité : tout message reçu est émis par un processus
|
||||
|
||||
|
||||
Uniformité : tout message reçu par un processus est reçu par tous les autres processus
|
||||
|
||||
|
||||
{FIFO} Broadcast (idem Broadcast) :
|
||||
|
||||
|
||||
Réception {FIFO} : tout message reçu par un processus est reçu dans l'ordre d'émission
|
||||
|
||||
|
||||
Causal Broadcast (idem {FIFO} Broadcast) :
|
||||
|
||||
|
||||
Réception causale : Tout message \$m'\$ envoyé par un processus après réception d'un message \$m\$ est aussi reçu après \$m\$ chez tous les autres processus
|
||||
|
||||
|
||||
|
||||
|
||||
Composabilité
|
||||
La compossibilité définit la possibilité pour deux types de données abstraits différents, cohérente pris de manière unitaire, de pouvoir être combinés tout en gardant leurs cohérences.
|
||||
Décomposable
|
||||
La décomposabilité définit la possibilité pour deux types de données abstraits différents cohérents si considérés "ensemble" de rester cohérent si considérés séparément.
|
||||
Localité
|
||||
La localité est le respect simultané de la composabilité et de la décomposabilité.
|
||||
Modèles
|
||||
Cohérence forte impossible dans des environnements crédibles de cloud. (Trop de risques de déni de services)
|
||||
Ci-dessous une liste des différents paradigmes de modélisation de système répartis :
|
||||
Cohérence Séquentiel (Décomposable, Fort)
|
||||
Cohérence Séquentiel ({SC}) : Les objets ciblés cachent la concurrence et se comportent comme si tous les accès était séquentiels.
|
||||
Le but est de mimer le comportement "comme si" un serveur centralisait et ordonnait l'information. (Ça peut être le cas ou non, il faut juste que la propriété soit respectée).
|
||||
Il y a un débat sur une notion de la cohérence séquentielle. La première formalisation de ce type de cohérence formulé par Lamport oublie de mentionner la notion de "synchronisation". Ce qui peut conduire a des comportements non cohérents. Elle permet par exemple l'existence d'histoires infinies qui viennent s'ajouter les unes derrières les autres. Ce qui serait absurde dans un système réel. (Exemple : infinité de lectures suivie d'une infinité d'écritures).
|
||||
Il y a donc débat sur la notion de cohérence séquentielle avec une école qui considère ce cas comme plausible et une autre qui souhaite rajouter une notion de synchronisation.
|
||||
Linéarisabilité ()
|
||||
Il y a ici un lien fort entre l'ordre d'action du processus et son intégration au système. Il y a une synchronicité plus forte.
|
||||
Ici lorsqu'un processus souhaite accéder à un objet, s'il ne rentre pas en conflit avec aucune action d'écriture, il récupère la valeur antérieure à son exécution. (propriété : Registre Sûr).
|
||||
Si plusieurs processus veulent accéder à un objet, et entrent en concurrence avec une écriture, alors ils ne peuvent retourner seulement la valeur avant ou après l'écriture (propriété : Registre Régulier).
|
||||
Si deux lectures ne sont pas concurrentes, alors elles doivent retourner une valeur au moins aussi récente que la lecture antérieure. (propriété : Registre Atomique).
|
||||
Sérialisabilité (Décomposable, Faible)
|
||||
{ACID} : Atomicité (une transaction est soit complètement acceptée soit complètement avortée), Cohérence (Une transaction exécutée dans un état correct emmène vers un état correct), Isolation (Les transactions n'interfèrent pas entre elles), Durabilité (une transaction acceptée n'est pas remise en cause).
|
||||
La sérialisabilité est similaire à la linéarisabilité, à la différence que des transactions peuvent être avortés. Cela à pour effet de rendre le système moins "fort" en termes de consistance.
|
||||
Convergence (Composable, Faible)
|
||||
La convergence est une notion de cohérence faible. Elle définit un système qui peut à un instant \$t\$ être divergent, mais qui finira sur un temps infini à converger vers un état commun.
|
||||
Convergence forte (Composable, Faible)
|
||||
La convergence forte est une extension de la convergence où notre histoire est divisée en plusieurs états. Chaque transaction se trouve dans un état avec d'autres transactions avec qui elle partage un "passé commun". On définit le passé commun comme la base de connaissance antérieur à l'exécution de la transaction.
|
||||
Data type pour la convergence
|
||||
Les types de données vues pour les autres modèles sont peu adapté pour modéliser les interactions dans le cas de la convergence. On privilégie plutôt des types de données qui permettent de définir des états (ex : {OR}-{SET}).
|
||||
Intention
|
||||
L'intention est une notion qui tend à appliquer la cohérence en fonction de l'intention des utilisateurs. Elle trouve son sens particulièrement dans l'édition collaborative lors d'écritures concurrentes. Mais sa spécification reste floue et c'est un concept qui semble difficile à appliquer.
|
||||
Cohérence pipeline (Décomposable, Faible)
|
||||
La cohérence pipeline consiste une cohérence ne garantissant pas l'ordre des états finaux. C'est donc une cohérence faible. La chose la plus notable est que le résultat n'est pas garantit pour deux histoires concurrentes équivalentes.
|
||||
Cohérence de Cache (Composable, Décomposable, Fort)
|
||||
On imagine que chaque type de donnée abstraite utilise une seule et même mémoire qu'il partage avec tous les processus de l'histoire concurrente. Chaque mémoire respecte une cohérence séquentielle.
|
||||
Cohérence d'écriture (Faible)
|
||||
Un aspect manquant de la convergence est l'absence de cohérence d'écriture. C'est-à-dire que rien ne garantit que les données écrites par un processus soient bien celles lue à la fin par les lectures infinies.
|
||||
Le concept de cohérence d'écriture vise donc à spécifier cette propriété.
|
||||
Cohérence d'écriture forte (Faible)
|
||||
La cohérence d'écriture forte est une extension de la cohérence d'écriture qui rajoute un ordre dans les opérations d'écriture. Ceci permet d'assurer que chaque opération soit faites dans le même état et assure donc une convergence plus "rapide".
|
||||
Cohérence causale
|
||||
Cohérence Causale Faible
|
||||
Cohérence directe avec son passé local et respect de cette cohérence avec les autres processus par transitivité. Aucune préservation de l'ordre des opérations.
|
||||
Résultat potentiellement divergent ?
|
||||
Convergence Causale
|
||||
Rajout de la notion d'ordre totale. Qui permet de garantir la convergence du résultat.
|
||||
Cohérence Causale
|
||||
Cohérence avec les écritures du passé causal et des lectures du passé local.
|
||||
},
|
||||
file = {Perrin - 2017 - Concurrence et cohérence dans les systèmes réparti.pdf:/home/amaury/Téléchargements/Perrin - 2017 - Concurrence et cohérence dans les systèmes réparti.pdf:application/pdf},
|
||||
}
|
||||
|
||||
@article{somasekaram_high-availability_2022,
|
||||
title = {High-Availability Clusters: A Taxonomy, Survey, and Future Directions},
|
||||
volume = {187},
|
||||
issn = {01641212},
|
||||
url = {http://arxiv.org/abs/2109.15139},
|
||||
doi = {10.1016/j.jss.2021.111208},
|
||||
shorttitle = {High-Availability Clusters},
|
||||
abstract = {The delivery of key services in domains ranging from finance and manufacturing to healthcare and transportation is underpinned by a rapidly growing number of mission-critical enterprise applications. Ensuring the continuity of these complex applications requires the use of software-managed infrastructures called high-availability clusters ({HACs}). {HACs} employ sophisticated techniques to monitor the health of key enterprise application layers and of the resources they use, and to seamlessly restart or relocate application components after failures. In this paper, we first describe the manifold uses of {HACs} to protect essential layers of a critical application and present the architecture of high availability clusters. We then propose a taxonomy that covers all key aspects of {HACs} -- deployment patterns, application areas, types of cluster, topology, cluster management, failure detection and recovery, consistency and integrity, and data synchronisation; and we use this taxonomy to provide a comprehensive survey of the end-to-end software solutions available for the {HAC} deployment of enterprise applications. Finally, we discuss the limitations and challenges of existing {HAC} solutions, and we identify opportunities for future research in the area.},
|
||||
pages = {111208},
|
||||
journaltitle = {Journal of Systems and Software},
|
||||
shortjournal = {Journal of Systems and Software},
|
||||
author = {Somasekaram, Premathas and Calinescu, Radu and Buyya, Rajkumar},
|
||||
urldate = {2023-06-06},
|
||||
date = {2022-05},
|
||||
eprinttype = {arxiv},
|
||||
eprint = {2109.15139 [cs, eess]},
|
||||
keywords = {Computer Science - Distributed, Parallel, and Cluster Computing, Computer Science - Networking and Internet Architecture, Electrical Engineering and Systems Science - Systems and Control},
|
||||
annotation = {Interet du papier
|
||||
Pas sur que ce soit dans le sujet. Ca semble prendre le sujet plus largement sans parler de la cohérence.
|
||||
},
|
||||
file = {arXiv.org Snapshot:/home/amaury/Zotero/storage/B4KCP9BG/2109.html:text/html;Somasekaram et al. - 2022 - High-Availability Clusters A Taxonomy, Survey, an.pdf:/home/amaury/Zotero/storage/K3LQZLC8/Somasekaram et al. - 2022 - High-Availability Clusters A Taxonomy, Survey, an.pdf:application/pdf},
|
||||
}
|
||||
|
||||
@thesis{kumar_fault-tolerant_2019,
|
||||
title = {Fault-Tolerant Distributed Services in Message-Passing Systems},
|
||||
institution = {Texas A\&M University},
|
||||
type = {phdthesis},
|
||||
author = {Kumar, Saptaparni},
|
||||
date = {2019},
|
||||
annotation = {Fiche Lecture
|
||||
Connexes
|
||||
Comprendre la théorie derrière le Failure Detector. \_\_T. D. Chandra and S. Toueg, “Unreliable failure detectors for reliable distributed systems,” J. {ACM}, vol. 43, no. 2, pp. 225–267, 1996.\_\_
|
||||
Definition
|
||||
Fault-Tolerence: The service remains uninterrupted even if some component in the network fail.
|
||||
Distributed System: A collection of computers (or nodes) that communicate amongst themselves [...] to perform a given task.
|
||||
Distributed Computing: The use of a Distributed System to solve a computational problems.
|
||||
Static system: The system composition is fixed.
|
||||
Dynamic system: nodes may enter, leave or move in the system with time.
|
||||
{FLP} impossibility result: It is impossible to design a distributed system that is both asynchronous and fault-tolerant.
|
||||
{ADD} (Average Delayed/Dropped): model used to describe realisticly the network.
|
||||
Data-Strcutures:
|
||||
|
||||
|
||||
linearizability: a data structure is said to be linearizable if it guarantees that all operations appear to happen at a single pointin time between the invocation and response of the operation.
|
||||
|
||||
|
||||
Shared Register: [a data strcuture] that stores a value and has two opérations: read [...] and write.
|
||||
|
||||
|
||||
Fault-Tolerent Register: Linearizable (atomic) Shared register.
|
||||
|
||||
|
||||
Attacks:
|
||||
|
||||
|
||||
crash: a node halts, but was working correctly until it halts.
|
||||
|
||||
|
||||
omission: a node fails to receive incoming messages or send outgoing messages.
|
||||
|
||||
|
||||
timing: a node's message delivery lies outside of the specified delivery time interval.
|
||||
|
||||
|
||||
Byzantine: Malicious attacks, operator mistake, software errors and conventional crash faults.
|
||||
|
||||
|
||||
churn: change in system composition due to nodes entering and leaving.
|
||||
|
||||
|
||||
Usefull terms:
|
||||
|
||||
|
||||
shared memory/message-passing model
|
||||
|
||||
|
||||
synchronous/asynchronous systems
|
||||
|
||||
|
||||
static/dynamic systems
|
||||
|
||||
|
||||
Algorithms of sharded registers:
|
||||
|
||||
|
||||
{RAMBO}
|
||||
|
||||
|
||||
{DynaStore}
|
||||
|
||||
|
||||
Baldoni et Al.
|
||||
|
||||
|
||||
Chapter 1
|
||||
He's began to define the terms of distributed systemsn and the possibles uses cases.
|
||||
He define synchronous message-passing systems as giving the best guarantees. Opposite to asynchronous message-passing systems.
|
||||
Failure Detectors
|
||||
He's defining te concept of Failure Detectors as an oracle able to identify the failed nodes. And how they can be used to circumvent the {FLP} impossibility result.
|
||||
Actually the Failure Detectors needs a certain level of synchronicity to work. And two lines of research are proposed to solve this problem: The first one is to implement the Failure Detector on a increasingly weaker system model. And the second one is to find the weakest Failure Detector.
|
||||
Fault-Tolerant Register
|
||||
He defined a "shared register" and explained how it's complicated to implementing them due to the possibility of faulty nodes. And he present the solution who's the Fault-Tolerant Register. He also present the "linearizability" property and how it's used to define the Fault-Tolerant Register.
|
||||
Finally he introduce two implementation of the Fault-Tolerant Register: one who's crash-tolerent and the other one who's Byzantine-tolerent.
|
||||
Chapter 2
|
||||
He precised the context of the implementation. We are on an arbitrary, partitionnable network composed of Average Delayed/Dropped channels ({ADD}).
|
||||
The failure detectors can be defined by their accuracy and completness tel que:
|
||||
|
||||
|
||||
Strong completeness is satisfied if the failure detector of each node eventually suspects all nodes that are crashed.
|
||||
|
||||
|
||||
Eventual strong accuracy is satisfied if the failure detector of every node eventually stops suspecting all nodes that are correct.
|
||||
|
||||
|
||||
He described he's algorithm.
|
||||
Chapter 3.1
|
||||
He purposed a new Fault-Tolerant Register who's crash-tolerent and churn proof.
|
||||
The algorithm is tolerent of node who could crash or leave the system.
|
||||
There is no hierarchy between the nodes. And the algorithm emulated a shared memory using the message-passing model.
|
||||
Chapter 3.2
|
||||
He purposed a new Fault-Tolerant Register who's crash-tolerent and churn and Byzantin proof.
|
||||
The model add a notion of server in the previous model (where we had only clients). And a system of asymetric signature.
|
||||
Also he proved than it's impossible with thiss model to determine the number of Byzantin server as a fraction of the total number of servers.
|
||||
},
|
||||
file = {Kumar - 2019 - Fault-Tolerant Distributed Services in Message-Pas.pdf:/home/amaury/Zotero/storage/Q9XK77W9/Kumar - 2019 - Fault-Tolerant Distributed Services in Message-Pas.pdf:application/pdf;Snapshot:/home/amaury/Zotero/storage/7JB26RAJ/1.html:text/html},
|
||||
}
|
||||
|
||||
@incollection{goos_causal_1995,
|
||||
location = {Berlin, Heidelberg},
|
||||
title = {From causal consistency to sequential consistency in shared memory systems},
|
||||
volume = {1026},
|
||||
isbn = {978-3-540-60692-5 978-3-540-49263-4},
|
||||
url = {http://link.springer.com/10.1007/3-540-60692-0_48},
|
||||
pages = {180--194},
|
||||
booktitle = {Foundations of Software Technology and Theoretical Computer Science},
|
||||
publisher = {Springer Berlin Heidelberg},
|
||||
author = {Raynal, Michel and Schiper, André},
|
||||
editor = {Thiagarajan, P. S.},
|
||||
editorb = {Goos, Gerhard and Hartmanis, Juris and Leeuwen, Jan},
|
||||
editorbtype = {redactor},
|
||||
urldate = {2023-06-06},
|
||||
date = {1995},
|
||||
langid = {english},
|
||||
doi = {10.1007/3-540-60692-0_48},
|
||||
note = {Series Title: Lecture Notes in Computer Science},
|
||||
file = {Raynal et Schiper - 1995 - From causal consistency to sequential consistency .pdf:/home/amaury/Zotero/storage/B8UNWUSA/Raynal et Schiper - 1995 - From causal consistency to sequential consistency .pdf:application/pdf},
|
||||
}
|
||||
|
||||
@article{mosberger_memory_1993,
|
||||
title = {Memory consistency models},
|
||||
volume = {27},
|
||||
issn = {0163-5980},
|
||||
url = {https://dl.acm.org/doi/10.1145/160551.160553},
|
||||
doi = {10.1145/160551.160553},
|
||||
abstract = {This paper discusses memory consistency models and their influence on software in the context of parallel machines. In the first part we review previous work on memory consistency models. The second part discusses the issues that arise due to weakening memory consistency. We are especially interested in the influence that weakened consistency models have on language, compiler, and runtime system design. We conclude that tighter interaction between those parts and the memory system might improve performance considerably.},
|
||||
pages = {18--26},
|
||||
number = {1},
|
||||
journaltitle = {{ACM} {SIGOPS} Operating Systems Review},
|
||||
shortjournal = {{SIGOPS} Oper. Syst. Rev.},
|
||||
author = {Mosberger, David},
|
||||
urldate = {2023-06-06},
|
||||
date = {1993-01},
|
||||
langid = {english},
|
||||
file = {Mosberger - 1993 - Memory consistency models.pdf:/home/amaury/Zotero/storage/VF2ZNK6A/Mosberger - 1993 - Memory consistency models.pdf:application/pdf},
|
||||
}
|
||||
|
||||
@article{lamport_how_1979,
|
||||
title = {How to Make a Multiprocessor Computer That Correctly Executes Multiprocess Programs},
|
||||
volume = {C-28},
|
||||
issn = {1557-9956},
|
||||
doi = {10.1109/TC.1979.1675439},
|
||||
abstract = {Many large sequential computers execute operations in a different order than is specified by the program. A correct execution is achieved if the results produced are the same as would be produced by executing the program steps in order. For a multiprocessor computer, such a correct execution by each processor does not guarantee the correct execution of the entire program. Additional conditions are given which do guarantee that a computer correctly executes multiprocess programs.},
|
||||
pages = {690--691},
|
||||
number = {9},
|
||||
journaltitle = {{IEEE} Transactions on Computers},
|
||||
author = {{Lamport}},
|
||||
date = {1979-09},
|
||||
note = {Conference Name: {IEEE} Transactions on Computers},
|
||||
keywords = {Computer design, concurrent computing, hardware correctness, multiprocessing, parallel processing},
|
||||
annotation = {Annotations
|
||||
« A correct execution is achieved if the results produced are the same as would be produced by executing the program steps in order » (Lamport, 1979, p. 1) Première définition de "coherence séquentiel"
|
||||
},
|
||||
file = {IEEE Xplore Abstract Record:/home/amaury/Zotero/storage/IVGSSPNE/1675439.html:text/html;Lamport - 1979 - How to Make a Multiprocessor Computer That Correct.pdf:/home/amaury/Zotero/storage/GY8CWGUV/Lamport - 1979 - How to Make a Multiprocessor Computer That Correct.pdf:application/pdf},
|
||||
}
|
||||
0
recherches/perrin.md
Normal file → Executable file
0
recherches/perrin.md
Normal file → Executable file
37
recherches/vanDerLindeLeitaoPreguica.md
Normal file → Executable file
37
recherches/vanDerLindeLeitaoPreguica.md
Normal file → Executable file
@ -2,6 +2,41 @@
|
||||
|
||||
## Authors: van der Linde, Leitao, Preguica
|
||||
|
||||
## Résumé:
|
||||
|
||||
Le papier spécifie une amélioration de la cohérence causale, rajoutant des propriétés en renforçant la sécurité. Ils comparent ensuite différentes implémentations de leurs solutions en axant sur le besoin d'une faible latence pour privilégier l'interactivité.
|
||||
|
||||
## Plan:
|
||||
|
||||
1. Présente les attaques possibles sur la cohérence causale. $3
|
||||
2. Définissent les propriétés d'une cohérence causale sécurisée répondant aux attaques. $4
|
||||
3. Définit de nouvelles classes de cohérence étendant la cohérence causale. $5
|
||||
4. Définit des algorithmes pour implémenter ces classes de cohérence. $5
|
||||
5. Présente des résultats de performance de ces algorithmes. $6
|
||||
|
||||
## Détails du document
|
||||
|
||||
### Types d'attaques
|
||||
|
||||
- Tempering: un nœud soumet une opération pour anticiper une opération en attente qui n'a pas encore été exécutée par le système.
|
||||
- Omitting dependencies: un nœud n'utilise qu'un sous-ensemble des opérations dans la dépendance. Il sera en mesure de soumettre une tâche concurrente au système.
|
||||
- Unseen dependencies (également appelé add): un nœud soumet une opération qui dépend d'une opération qu'il n'a pas vue. Il permet à l'attaquant d'anticiper une opération. (C'est différent du tempering car dans ce cas l'opération n'existe pas encore).
|
||||
- Combining omitting and unseen: un nœud peut omettre une dépendance et soumettre une opération qui dépend d'une opération qu'il n'a pas vue.
|
||||
- Sibbling generation: créer deux opérations différentes avec le même id. L'attaquant pourrait créer une divergence permanente entre les nœuds.
|
||||
|
||||
### Propriétés d'une cohérence causale sécurisée
|
||||
|
||||
- **Immutable History**: Chaque opération est envoyée avec son passé causal à chaque nœud valide. (Contrecarre le tempering)
|
||||
- **No Future Dependencies**: Chaque opération est envoyée avec son état de connaissance de l'état des nœuds du système. (Contrecarre l'unseen dependencies puisque l'opération sera considérée par l'ensemble du système comme "en retard" et sera donc ignorée)
|
||||
- **Causal Execution**: Toute opération $o_i$ appartenant au passé causal d'une opération $o$ doit être sérialisable t.q. : $o_i < o$. (Force une sorte de synchronisation entre les nœuds)
|
||||
- **Eventual Sibling Detection**: Chaque opération doit être considérée comme une faute éventuelle et doit donc avoir la possibilité d'être révoqué. La révocation ne peut se produire qu'après l'exécution de l'opération. (Assure que si deux opérations sont créées avec un même identifiant et crée une divergence, alors les nœuds auront toujours un moyen de retourner à un état convergent. Contrecarre **en partie** le sibling generation)
|
||||
- **Limitted Omission**:
|
||||
|
||||
<!-- OLD
|
||||
# Practical Client-side Replication: Weak Consistency Semantics for Insecure Settings
|
||||
|
||||
## Authors: van der Linde, Leitao, Preguica
|
||||
|
||||
## Definition
|
||||
|
||||
causal consistency: model enforcing clients to observe a state that respects the causal order of operations. (this is the case for decentralized and peer to peer systems)
|
||||
@ -36,4 +71,4 @@ The algorithms they propose used the following solutions for each property:
|
||||
|
||||
The Secure Strict Causas Consistency is a variant of the Secure Causal Consistency who is using a trusted service. Such as the enclave in Intel SGX. Thus the usage of a hash of the dependencies is unnecessary.
|
||||
An issue of this solution is the cost of the connection to the trusted service. A possible attack would be to connect and disconnect a lot of time of the trusted service to make the system slow.
|
||||
This sollution was not explored in the paper due to this issue.
|
||||
This sollution was not explored in the paper due to this issue. -->
|
||||
|
||||
Loading…
Reference in New Issue
Block a user