TDDD82 Secure Mobile Systems Lecture 5: Dependability Mikael - - PowerPoint PPT Presentation

TDDD82 Secure Mobile Systems Lecture 5: Dependability

Mikael Asplund Real-tjme Systems Laboratory Department of Computer and Informatjon Science Linköping University

Based on slides by Simin Nadjm-Tehrani

Dependability

Property of a computing system which allows

reliance to be justifiably placed on the service it delivers.

[Avizienis et al.] The ability to avoid service failures that are more frequent or more severe than is acceptable.

Dependability taxonomy

Fault-tolerant Distributed Systems

Redundancy

• Necessary for fault-tolerance!
• Increase overall complexity
• Statjc

– Error masking propertjes

• Dynamic

– Error detectjng propertjes

Dependability & Distributjon

• Making systems fault-tolerant typically uses

redundancy

– Redundancy in space leads to distributjon – But distributed systems are not necessarily fault- tolerant!

Replicatjon

• Passive replicatjon

– Primary – backup – Cold/Warm/Hot

• Actjve replicatjon

– Group membership

Implementjng replica consistency

• Message ordering

– Use the before relatjon (i.e., by using Lamport clocks)

• Agreement

– For passive replicatjon

• Controlled by the master
• Stjll requires agreement of when the primary is down...

– Actjve replicatjon

• Agreement for every operatjon

Agreement is not just for replicatjon

The consensus problem

• Processes p1,…, pn take part in a decision

– Each pi proposes a value vi – All correct processes decide on a common value v that is equal to

• ne of the proposed values
• Desired propertjes

– Terminatjon: Every correct process eventually decides – Agreement: No two (correct) processes decide difgerently – Validity: If a process decides v then the value v was proposed by some process

Fault model

Normality Tolerated faults Non-tolerated faults

Recall from previous lecture

• Node/Channel failures

–

Crash

–

Omission

–

Timing

–

Byzantine/arbitrary

• System model

–

Synchronous

–

Asynchronous

Basic impossibility result

[Fischer, Lynch and Paterson 1985]

• There is no deterministjc algorithm solving the consensus

problem in an asynchronous distributed system with a single crash failure.

Naïve approaches

• Wait for all to agree

– Node crash

• Wait for a majority to agree

– What about confmicts?

• When to move on?

Assume synchrony

• If a node does not respond within tjme t, it

will not respond at tjme t+d

• Partjal synchrony

– Bounds exist but are not known

• Powerful abstractjon:

– Unreliable failure detectors

For the project

• Passive replicatjon
• Need to think carefully about your fault

model!

Hints for your dependability analysis

• 1. Model the system

– What is the logical structure? – What are your assumptjons?

• 2. Consider what types of faults that could occur (part of risk

analysis)

– Nodes (crash, byzantjne, ...) – Links

• 3. If possible, measure parameters such the frequency of faults,

and tjme to recovery, combine with historical data

– htups://doi.org/10.1109/TDSC.2009.4 – htup://liu.diva-portal.org/smash/record.jsf?pid=diva2%3A1034002

• 5. Derive esimates for dependability atuributes of your system

For the future

• Dependability is important!

– Take it seriously when building systems

• Fault-tolerance is non-trivial
• Create simple and easy-to-understand

systems (at least the cores)