Efficient Fork-Linearizable Access to Untrusted Shared Memory Presented by: Alex Shraer (Technion) IBM Zurich Research Laboratory Christian Cachin IBM.

Slides:



Advertisements
Similar presentations
Security attacks. - confidentiality: only authorized parties have read access to information - integrity: only authorized parties have write access to.
Advertisements

Multi-Party Contract Signing Sam Hasinoff April 9, 2001.
CSE 486/586, Spring 2012 CSE 486/586 Distributed Systems Consensus Steve Ko Computer Sciences and Engineering University at Buffalo.
Brewer’s Conjecture and the Feasibility of Consistent, Available, Partition-Tolerant Web Services Authored by: Seth Gilbert and Nancy Lynch Presented by:
Linearizability Linearizability is a correctness criterion for concurrent object (Herlihy & Wing ACM TOPLAS 1990). It provides the illusion that each operation.
D u k e S y s t e m s Time, clocks, and consistency and the JMM Jeff Chase Duke University.
CSE 486/586, Spring 2014 CSE 486/586 Distributed Systems Consistency Steve Ko Computer Sciences and Engineering University at Buffalo.
Life after CAP Ali Ghodsi CAP conjecture [reminder] Can only have two of: – Consistency – Availability – Partition-tolerance Examples.
The Byzantine Generals Problem Leslie Lamport, Robert Shostak, Marshall Pease Distributed Algorithms A1 Presented by: Anna Bendersky.
DISTRIBUTED SYSTEMS II REPLICATION CNT. II Prof Philippas Tsigas Distributed Computing and Systems Research Group.
A Programming Language View of Transactional Memory Hagit Attiya, Technion Joint work with Sandeep Hans, Alexey Gotsman and Noam Rinetzky Published in.
Distributed Computing 8. Impossibility of consensus Shmuel Zaks ©
1 Venus: Verification for Untrusted Cloud Storage Christian Cachin Idit Keidar, Asaf Cidon, Yan Michalevsky, Dani Shaket IBM Research Zurch Technion, Israel.
Ordering and Consistent Cuts Presented By Biswanath Panda.
Eddie Bortnikov & Aran Bergman, Principles of Reliable Distributed Systems, Technion EE, Spring Principles of Reliable Distributed Systems Recitation.
CMPT 431 Dr. Alexandra Fedorova Lecture VIII: Time And Global Clocks.
CPSC 668Set 16: Distributed Shared Memory1 CPSC 668 Distributed Algorithms and Systems Fall 2006 Prof. Jennifer Welch.
Computer Architecture 2011 – coherency & consistency (lec 7) 1 Computer Architecture Memory Coherency & Consistency By Dan Tsafrir, 11/4/2011 Presentation.
Randomized Byzantine Agreements (Sam Toueg 1984).
FAUST: Fail-Aware Untrusted Storage Christian Cachin IBM Zurich Idit Keidar Technion Alex Shraer, Technion, Israel Joint work with:
1 Dynamic Atomic Storage Without Consensus Alex Shraer (Technion) Joint work with: Marcos K. Aguilera (MSR), Idit Keidar (Technion), Dahlia Malkhi (MSR.
Impossibility of Distributed Consensus with One Faulty Process Michael J. Fischer Nancy A. Lynch Michael S. Paterson Presented by: Oren D. Rubin.
Attested Append-only Memory: Making Adversaries Stick to their Word Distributed Storage Systems CS presented by: Hussam Abu-Libdeh.
Concurrency. Busy, busy, busy... In production environments, it is unlikely that we can limit our system to just one user at a time. – Consequently, it.
Distributed Systems Fall 2009 Replication Fall 20095DV0203 Outline Group communication Fault-tolerant services –Passive and active replication Highly.
Aran Bergman, Principles of Reliable Distributed Systems, Technion EE, Spring Principles of Reliable Distributed Systems Recitation 5: Reliable.
 Idit Keidar, Principles of Reliable Distributed Systems, Technion EE, Spring Principles of Reliable Distributed Systems Lecture 12: Impossibility.
Failure Resilience in the Peer-to-Peer-System OceanStore Speaker: Corinna Richter.
Social Networking with Frientegrity: Privacy and Integrity with an Untrusted Provider Prateek Basavaraj April 9 th 2014.
Project Presentation Students: Yan Michalevsky Asaf Cidon Supervisors: Alexander Shraer Assoc. Prof. Idit Keidar.
Distributed Algorithms – 2g1513 Lecture 9 – by Ali Ghodsi Fault-Tolerance in Distributed Systems.
CS4231 Parallel and Distributed Algorithms AY 2006/2007 Semester 2 Lecture 3 (26/01/2006) Instructor: Haifeng YU.
Reliable Communication in the Presence of Failures Based on the paper by: Kenneth Birman and Thomas A. Joseph Cesar Talledo COEN 317 Fall 05.
Consensus and Its Impossibility in Asynchronous Systems.
VICTORIA UNIVERSITY OF WELLINGTON Te Whare Wananga o te Upoko o te Ika a Maui SWEN 432 Advanced Database Design and Implementation Data Versioning Lecturer.
Byzantine fault-tolerance COMP 413 Fall Overview Models –Synchronous vs. asynchronous systems –Byzantine failure model Secure storage with self-certifying.
From Viewstamped Replication to BFT Barbara Liskov MIT CSAIL November 2007.
1 Chapter 9 Synchronization Algorithms and Concurrent Programming Gadi Taubenfeld © 2014 Synchronization Algorithms and Concurrent Programming Synchronization.
Presented by: Sanketh Beerabbi University of Central Florida.
DISTRIBUTED ALGORITHMS AND SYSTEMS Spring 2014 Prof. Jennifer Welch Set 11: Asynchronous Consensus 1.
1 © R. Guerraoui Regular register algorithms R. Guerraoui Distributed Programming Laboratory lpdwww.epfl.ch.
CS603 Clock Synchronization February 4, What is the best we can do? Lundelius and Lynch ‘84 Assumptions: –No failures –No drift –Fully connected.
Agenda Fail Stop Processors –Problem Definition –Implementation with reliable stable storage –Implementation without reliable stable storage Failure Detection.
Shared Memory Consistency Models. SMP systems support shared memory abstraction: all processors see the whole memory and can perform memory operations.
Linearizability Linearizability is a correctness criterion for concurrent object (Herlihy & Wing ACM TOPLAS 1990). It provides the illusion that each operation.
CS294, Yelick Consensus revisited, p1 CS Consensus Revisited
Max Registers, Counters, and Monotone Circuits Keren Censor, Technion Joint work with: James Aspnes, Yale University Hagit Attiya, Technion (Slides
POND: THE OCEANSTORE PROTOTYPE S. Rea, P. Eaton, D. Geels, H. Weatherspoon, J. Kubiatowicz U. C. Berkeley.
Linearizability Linearizability is a correctness criterion for concurrent object (Herlihy & Wing ACM TOPLAS 1990). It provides the illusion that each operation.
SysRép / 2.5A. SchiperEté The consensus problem.
Hwajung Lee.  Improves reliability  Improves availability ( What good is a reliable system if it is not available?)  Replication must be transparent.
Systems Research Barbara Liskov October Replication Goal: provide reliability and availability by storing information at several nodes.
Linearizability Linearizability is a correctness criterion for concurrent object (Herlihy & Wing ACM TOPLAS 1990). It provides the illusion that each operation.
CSCE 668 DISTRIBUTED ALGORITHMS AND SYSTEMS Fall 2011 Prof. Jennifer Welch CSCE 668 Set 16: Distributed Shared Memory 1.
CSE 486/586, Spring 2012 CSE 486/586 Distributed Systems Replication Steve Ko Computer Sciences and Engineering University at Buffalo.
Distributed Storage Systems: Data Replication using Quorums.
Fault tolerance and related issues in distributed computing Shmuel Zaks GSSI - Feb
“Distributed Algorithms” by Nancy A. Lynch SHARED MEMORY vs NETWORKS Presented By: Sumit Sukhramani Kent State University.
CS 425 / ECE 428 Distributed Systems Fall 2015 Indranil Gupta (Indy) Lecture 9: Multicast Sep 22, 2015 All slides © IG.
Group Communication A group is a collection of users sharing some common interest.Group-based activities are steadily increasing. There are many types.
CSE 486/586, Spring 2013 CSE 486/586 Distributed Systems Consistency Steve Ko Computer Sciences and Engineering University at Buffalo.
Lecturer : Dr. Pavle Mogin
CS 425 / ECE 428 Distributed Systems Fall 2017 Indranil Gupta (Indy)
Linearizability Linearizability is a correctness criterion for concurrent object (Herlihy & Wing ACM TOPLAS 1990). It provides the illusion that each operation.
(Slides were added to Keren’s original presentation. DH.)
Active replication for fault tolerance
From Viewstamped Replication to BFT
Constructing Reliable Registers From Unreliable Byzantine Components
(Slides were added to Keren’s original presentation. DH.)
Fault-Tolerant SemiFast Implementations of Atomic Read/Write Registers
Presentation transcript:

Efficient Fork-Linearizable Access to Untrusted Shared Memory Presented by: Alex Shraer (Technion) IBM Zurich Research Laboratory Christian Cachin IBM Zurich Abhi Shelat University of Virginia Joint work with:

Data in a storage system Users store data on remote storage Data integrity: Single user – hashing Single user – hashing Merkle hash trees for large data volume Merkle hash trees for large data volume Multi user – digital signatures Multi user – digital signatures Public key infrastructure is needed Public key infrastructure is needed Data consistency? What if the server is faulty? What if the server is faulty?

ServerModel Asynchronous system Clients C 1,…, C n correct communicate only with the server via reliable links have public/private key pair (stored data is signed) each client executes read/write operations sequentially Server S emulates n SWMR registers - client C i writes only to register i CANNOT BE TRUSTED - perhaps faulty

Consistency Model? Attempt 1: linearizable shared memory Requires a read to return the latest written value Requires a read to return the latest written value Impossible Impossible  σ is linearizable if exists a sequential permutation  that preserves 1. the real-time order of σ and 2. the sequential specification

Attempt 2: Sequential consistency Read does not have to return latest value For every process, the order in which its operations take effect must be preserved Example: time C1:C1: C2:C2: write (1, v)write (1, u) read (1) → u read (1) → v

Sequential consistency – Cont. Still impossible to implement ! Proof: write (1, u) read (2) → ┴ write (2, v) read (1) → ┴ time C1:C1: C2:C2:

Previously defined: (1) [Mazières, Shasha PODC 2002] (2) [Oprea, Reiter DISC 2006] The definition we use - similar to (2): A seq. of events  is fork-linearizable if for each client C i there exists a subsequence  i of  consisting only of completed operations and a sequential permutation  i of  i 1.All operations of client C i are in  i 2.  i preserves real-time order of  i 3.  I satisfies the sequential specification 4.If an operation op is in  I and  k then the sequence of operations that precede op in both groups is the same Fork-Linearizability Every client sees linearizable memory R1 W1 R2 W2R3 C2C2 C3C3 C1C1 By telling one lie to C 1 & C 2 and another to C 3, the server “forks” their views C 1 & C 2

Fork Linearizable Byzantine emulation (simplified) - every execution is fork-linearizable - every execution is fork-linearizable - if the server is correct - if the server is correct every operation completes every execution is linearizable Global Fork-Linearizability: a simpler and equivalent definition New on Fork-Linearizability

Some Motivation Guarantees a linearizable view for each client, and linearizable executions when the server is correct The server can hide operations from clients, but nothing worse! The server can hide operations from clients, but nothing worse! If the server forks the views of C 1 and C 2, their views are forked ever after (no join), i.e., they do not see each other’s further updates If the server forks the views of C 1 and C 2, their views are forked ever after (no join), i.e., they do not see each other’s further updates otherwise the run is not fork-linearizable, which can be detected by the clients (unlike in linearizability or sequential consistency) otherwise the run is not fork-linearizable, which can be detected by the clients (unlike in linearizability or sequential consistency) fork-linearizability is not a weak condition Linearizability is stronger Linearizability is stronger (New) Sequential consistency is not ! (New) Sequential consistency is not ! proof – in previous slides Linearizable Fork Linearizable Seq. Consistent Fork-Linearizability is the strongest known consistency that can be enforced with a possibly faulty server

Emulating fork-linearizable memory requires waiting Theorem: Every protocol has executions with a correct server where C i must wait for C j Formal proof in the paper. The idea: by contradiction, assume that no waiting is necessary r’(1) must return v since w’(1, v) might have completed The server can cause this run to be indistinguishable from Run 1 v cannot be returned r’(1) cannot return neither u nor v in Run 1 – it must wait… w(1, u)w’(1, v) r(1) → ur’(1) → ? C1C1 C2C2 w(1, u)w’(1, v) r(1) → ur’(1) → v C1C1 C2C2 Run 1: Correct server Run 2: Faulty server

Protocols Trivial method: Sign the complete history Server sends history with all signatures Client verifies all operations and signatures Client adds its operation and signs new history Message size proportional to system age [Mazières, Shasha PODC 2002] : Use n “version vectors” A blocking protocol and a concurrent protocol Communication complexity Ω(n 2 ) Message size ~400MB for 10’000 users Our results: A blocking protocol and a concurrent protocol Communication complexity O(n) Message size ~40KB for 10’000 users

Lock-Step with Correct Server (simplified) C1C Correct Server (val,1) C2C

Lock-Step with Faulty Server (simplified) , (┴,0) Faulty Server C1C1 C2C

What happened? Example 1Example 2 write 1 (1, val) start read 2 (1) → val write 1 (1, val) start read 2 (1) → ┴ The ≥ relation: V ≥ V’ if for all j, V[j] ≥ V’[j] B reads stale data of A B signs a version structure which cannot be ordered with what A signed Proof idea – based on “No-Join” property: no operation signs a version structure V s.t. V ≥ V A and V ≥ V B  i Subsequences  i can be constructed from the branch of C i in the fork-tree

Increasing concurrency Any protocol will sometimes block… Concurrent protocol – details in the paper Allow operations to complete concurrently A read must wait for a previously scheduled concurrent write to the same register to complete (at most one such operation) Message size: O(n)

Summary of Results On the notion of Fork-Linearizability Global Fork-Linearizability Fork-Linearizable Byzantine emulations Comparing Fork-Linearizability with seq. consistency Communication efficient protocols Lock-Step Lock-Step Concurrent Concurrent A proof that any Fork-Linearizable Byzantine emulation must sometime block As in and in our concurrent protocols As in [MS02] and in our concurrent protocolsQuestions?