Revised version of the SafeFS slides, targeting MSc students at the UFSM (Brasil).

1. SafeFS:A Modular Architecture
for Secure User-Space File Systems
(One FUSE to rule them all)
Invited Talk - UFSM, Santa Maria, Brasil
02 February 2018
Rogério Pontes1, Dorian Burihabwa2, Francisco Maia1, João Paulo1,
Valerio Schiavoni2, Pascal Felber2, Hugues Mercier2, Rui Oliveira1
1High Assurance Software Lab, INESC TEC and University of Minho, Portugal
2University of Neuchâtel, Switzerland
(previously: SYSTOR’17, Haifa, Israel)

2. Valerio Schiavoni - University of Neuchatel! UFSM - 02/02/2018SafeFS
but first…where is Neuchâtel?
2

3. Valerio Schiavoni - University of Neuchatel! UFSM - 02/02/2018SafeFS
• Data is growing at an unprecedented rate
• Cloud storage is the de facto choice for millions of
users and enterprises
• reduced costs
• availability
• ease of use
Cloud Storage
3

4. Valerio Schiavoni - University of Neuchatel! UFSM - 02/02/2018SafeFS
• Heterogeneous interfaces for applications
• Data control belongs to the cloud
• according to a European study conducted in 2015
• 67% of the population is concerned with data privacy
• only 15% of users think to be in control of their data
• Cloud data is vulnerable to
• hackers, storage providers, governmental agencies
• other (possibly unknown) threats
4
not in this talk
Cloud Storage

5. Valerio Schiavoni - University of Neuchatel! UFSM - 02/02/2018SafeFS
• Abstract third-party interfaces
• e.g., multi-cloud file system
• Support data processing at the client premises
before uploading it to cloud services
• data encryption
• replication, deduplication, caching
Current Solutions
5

6. Valerio Schiavoni - University of Neuchatel! UFSM - 02/02/2018SafeFS
• Traditional filesystems follow a monolithic design
• Different applications have specific requirements
• performance
• dependability
• security
• ➡ different storage features
Challenges
6
ext3 ext4 encFS CryFS

7. Valerio Schiavoni - University of Neuchatel! UFSM - 02/02/2018SafeFS
• Stackable file system solutions improve flexibility
• Their design is still limited:
• focused on the modularity of a specific feature
• decisions (kernel vs user-space)
7
source: hypem.com
Challenges

8. Valerio Schiavoni - University of Neuchatel! UFSM - 02/02/2018SafeFS
• SafeFS: A modular user-space secure file system
• layered design with two-dimensional modularity
• self-contained, stackable and reusable layers
• easy implementation & reuse of layers
• support for single and multiple storage backends
• adaptability to different application workloads
• transparency for applications
Contributions
8

9. Valerio Schiavoni - University of Neuchatel! UFSM - 02/02/2018SafeFS
•Architecture
•Life of a SafeFS operation
•Some implementation details
•Some evaluation results
•Conclusion
The rest of this talk
9
😈
🏛
📖 🖋
🔬(
🎬

10. Valerio Schiavoni - University of Neuchatel! UFSM - 02/02/2018SafeFS
• Layers
• processing vs storage
• stackable
• common API (FUSE)
• Drivers
• extended flexibility
• common API
Architecture
10
User Application
FUSE User-Space Library
SafeFS
Processing
FUSE
Virtual Filesystem
.
.
.
Processing
FUSE
Processing
FUSE
Processing
FUSE
Processing
FUSE
Storage
FUSE
Storage
FUSE
Privacy-Preserving
Layer
Drivers
AES DET
FUSE
FUSE Kernel ModuleKernel
Space
User
Space
Layer 0
Layer 1
Layer N-2
Layer N-1
Layer N
.
.
.
...
request reply

11. Valerio Schiavoni - University of Neuchatel! UFSM - 02/02/2018SafeFS
Storage requests flow
11
User Application
Fuse User-Space Library
SafeFS
Processing
FUSE API
Virtual Filesystem
Fuse Kernel Module
Kernel
Space
User
Space
Storage
FUSE API
Storage
FUSE API
➑
➋ ➐
➏
➎
➍
➌
➎
request reply
➊
➍

12. Valerio Schiavoni - University of Neuchatel! UFSM - 02/02/2018SafeFS
SafeFS - Implementation
12
SafeFS
Privacy-Preserving Layer
Drivers
AES DET ...
Granularity-Oriented Layer
Drivers
Block ID
Multiple-backend Layer
Drivers
REP XOR ER
NFS Dropbox
Other
Storage
...
FUSE
...
• 3 Supported layers
• Granularity-Oriented
• Privacy-Preserving
• Multiple-Backend
• Layers and drivers chosen
at mount time
• Implemented in C

13. Valerio Schiavoni - University of Neuchatel! UFSM - 02/02/2018SafeFS
SafeFS - Configuration
13
• Possible combinations of layers and drivers
Granularity-Oriented Privacy-Preserving Multiple-Backend
Groups Stack Block Id AES Det Id Simple XOR Erasure
Baseline
FUSE ⇥ ⇥ ⇥ ⇥ ⇥
p
,1 ⇥ ⇥
Identity ⇥
p
⇥ ⇥
p p
,1 ⇥ ⇥
Privacy
AES
p
⇥
p
⇥ ⇥
p
,1 ⇥ ⇥
Det
p
⇥ ⇥
p
⇥
p
,1 ⇥ ⇥
XOR ⇥ ⇥ ⇥ ⇥ ⇥ ⇥
p
,3 ⇥
Redundancy
Rep ⇥ ⇥ ⇥ ⇥ ⇥
p
,3 ⇥ ⇥
Erasure
p
⇥ ⇥ ⇥ ⇥ ⇥ ⇥
p
,3
Table 2: The di↵erent SafeFS stacks deployed in the evaluation. Stacks are divided in three distinct groups: Baseline
Privacy, Redundancy. The table header holds the three SafeFS layers. Below each layer we show the respective drivers. Fo
each stack, we indicate the active drivers (the
p
symbol). Layers without any active drivers are not used in the stack. Th
ndices for Multiple-Backend drivers indicate the number of storage backends used to write data.
tively to a standard and a deterministic encryption mecha-
nism. The AES stack is expected to be less e cient than Det
as it generates a di↵erent IV for each block. However, Det
has the weakest security guarantee. The third stack, named
XOR, considers a di↵erent trust model where no single stor-
age location is trusted with the totality of the ciphered data.
Data is stored across distinct storage back-ends in such a
way that unless an attacker gains access simultaneously to
We ran several workloads for each considered file system (4
third-party file systems and 7 SafeFS stacks). The result
have been grouped according to the workloads. First, w
present the results of using db_bench, then filebench and
finally, we describe the results of running latency analysi
for SafeFS layers.
Microbenchmark: db bench. We first present the re
sults obtained with db_bench. We pick 7 workloads, each
• Each offering different guarantees in terms of
• security
• dependability
• performance

14. Valerio Schiavoni - University of Neuchatel! UFSM - 02/02/2018SafeFS
• Multiple benchmarks and workloads
• filebench
• db_bench
• Third-party filesystems and SafeFS configurations
• 7 SafeFS setups
• 4 filesystems (CryFS, LessFS, MetFs and eCryptFS)
• Experimental setup
• Virtual Machines with 4 Cores, 4GB RAM and HDD drives
Experimental Evaluation
14

15. Valerio Schiavoni - University of Neuchatel! UFSM - 02/02/2018SafeFS
Filebench results
15
0
0.2
0.4
0.6
0.8
➀ ➁ ➂ ➃ ➄ ➅ ➆ ➀ ➁ ➂ ➃ ➄ ➅ ➆ ➀ ➁ ➂ ➃ ➄ ➅ ➆ ➀ ➁ ➂ ➃ ➄ ➅ ➆ ➀ ➁ ➂ ➃ ➄ ➅ ➆ ➀ ➁ ➂ ➃ ➄ ➅ ➆
Ratioagainstnativ
0
0.2
0.4
0.6
0.8
1
1.2
➀ ➁ ➂ ➃ ➄ ➅ ➆ ➀ ➁ ➂ ➃ ➄ ➅ ➆ ➀ ➁ ➂ ➃ ➄ ➅ ➆ ➀ ➁ ➂ ➃ ➄ ➅ ➆ ➀ ➁ ➂ ➃ ➄ ➅ ➆ ➀ ➁ ➂ ➃ ➄ ➅ ➆ ➀ ➁ ➂ ➃ ➄ ➅ ➆
Ratioagainstnative(ext4)
➀ File-server ➁ Mail-server ➂ Web-server ➃ filemicro_rread_4K ➄ filemicro_rwrite_4K ➅ filemicro_seqread_4K ➆ filemicro_seqwrite_4K
SAFEFS AES SAFEFS Det SAFEFS Erasure SAFEFS FUSE SAFEFS Identity SAFEFS Rep SAFEFS XOR
Figure 5: Relative performance of filebench workloads against native.
0
0.2
0.4
0.6
0.8
1
AES
Det
Erasure
FUSE
Identity
Rep
XOR
AES
Det
Erasure
FUSE
Identity
Rep
XOR
AES
Det
Erasure
FUSE
Identity
Rep
XOR
AES
Det
Erasure
FUSE
Identity
Rep
XOR
AES
Det
Erasure
FUSE
Identity
Rep
XOR
AES
Det
Erasure
FUSE
Identity
Rep
XOR
AES
Det
Erasure
FUSE
Identity
Rep
XOR
fill100K fillrandom fillseq overwrite readrandom readreverse readseq
ExecutionTime(%)
multi_write sfuse_write align_write multi_read sfuse_read align_read
Figure 6: Execution time breakdown for di↵erent SafeFS stacks.
As expected, the time spent in each layer varies according
to the tasks performed by the layers. The 3 most CPU-
facilitate future choices for practitioners and researchers.
We envision to extend SafeFS along three main direc
• Evaluation of SafeFS setups with 7 filebench workloads
• Throughput compared against ext4
• red (below 25%)
• orange (up to 75%)
• yellow (up to 95%)
• green (>= 95%)
0
0.2
0.4
0.6
0.8
➀ ➁ ➂ ➃ ➄ ➅ ➆ ➀ ➁ ➂ ➃ ➄ ➅ ➆ ➀ ➁ ➂ ➃ ➄ ➅ ➆ ➀ ➁ ➂ ➃ ➄ ➅ ➆ ➀ ➁ ➂ ➃ ➄ ➅ ➆ ➀ ➁ ➂ ➃ ➄ ➅ ➆
0
0.2
0.4
0.6
0.8
1
1.2
➀ ➁ ➂ ➃ ➄ ➅ ➆ ➀ ➁ ➂ ➃ ➄ ➅ ➆ ➀ ➁ ➂ ➃ ➄ ➅ ➆ ➀ ➁ ➂ ➃ ➄ ➅ ➆ ➀ ➁ ➂ ➃ ➄ ➅ ➆ ➀ ➁ ➂ ➃ ➄ ➅ ➆ ➀ ➁ ➂ ➃ ➄ ➅ ➆
➀ File-server ➁ Mail-server ➂ Web-server ➃ filemicro_rread_4K ➄ filemicro_rwrite_4K ➅ filemicro_seqread_4K ➆ filemicro_seqwrite_4K
SAFEFS AES SAFEFS Det SAFEFS Erasure SAFEFS FUSE SAFEFS Identity SAFEFS Rep SAFEFS XOR
Figure 5: Relative performance of filebench workloads against native.
0
0.2
0.4
0.6
0.8
1
AES
Det
Erasure
FUSE
Identity
Rep
XOR
AES
Det
Erasure
FUSE
Identity
Rep
XOR
AES
Det
Erasure
FUSE
Identity
Rep
XOR
AES
Det
Erasure
FUSE
Identity
Rep
XOR
AES
Det
Erasure
FUSE
Identity
Rep
XOR
AES
Det
Erasure
FUSE
Identity
Rep
XOR
AES
Det
Erasure
FUSE
Identity
Rep
XOR
fill100K fillrandom fillseq overwrite readrandom readreverse readseq
multi_write sfuse_write align_write multi_read sfuse_read align_read
Figure 6: Execution time breakdown for di↵erent SafeFS stacks.
As expected, the time spent in each layer varies according
o the tasks performed by the layers. The 3 most CPU-
tensive stacks (AES, Det and Erasure) concentrate their
facilitate future choices for practitioners and researchers.
We envision to extend SafeFS along three main direc-
tions. First, we plan to smooth the e↵orts to integrate any

16. Valerio Schiavoni - University of Neuchatel! UFSM - 02/02/2018SafeFS
Filebench results
16
0
0.2
0.4
0.6
0.8
➀ ➁ ➂ ➃ ➄ ➅ ➆ ➀ ➁ ➂ ➃ ➄ ➅ ➆ ➀ ➁ ➂ ➃ ➄ ➅ ➆ ➀ ➁ ➂ ➃ ➄ ➅ ➆ ➀ ➁ ➂ ➃ ➄ ➅ ➆ ➀ ➁ ➂ ➃ ➄ ➅ ➆
Ratioagainstnativ
0
0.2
0.4
0.6
0.8
1
1.2
➀ ➁ ➂ ➃ ➄ ➅ ➆ ➀ ➁ ➂ ➃ ➄ ➅ ➆ ➀ ➁ ➂ ➃ ➄ ➅ ➆ ➀ ➁ ➂ ➃ ➄ ➅ ➆ ➀ ➁ ➂ ➃ ➄ ➅ ➆ ➀ ➁ ➂ ➃ ➄ ➅ ➆ ➀ ➁ ➂ ➃ ➄ ➅ ➆
Ratioagainstnative(ext4)
➀ File-server ➁ Mail-server ➂ Web-server ➃ filemicro_rread_4K ➄ filemicro_rwrite_4K ➅ filemicro_seqread_4K ➆ filemicro_seqwrite_4K
SAFEFS AES SAFEFS Det SAFEFS Erasure SAFEFS FUSE SAFEFS Identity SAFEFS Rep SAFEFS XOR
Figure 5: Relative performance of filebench workloads against native.
0
0.2
0.4
0.6
0.8
1
AES
Det
Erasure
FUSE
Identity
Rep
XOR
AES
Det
Erasure
FUSE
Identity
Rep
XOR
AES
Det
Erasure
FUSE
Identity
Rep
XOR
AES
Det
Erasure
FUSE
Identity
Rep
XOR
AES
Det
Erasure
FUSE
Identity
Rep
XOR
AES
Det
Erasure
FUSE
Identity
Rep
XOR
AES
Det
Erasure
FUSE
Identity
Rep
XOR
fill100K fillrandom fillseq overwrite readrandom readreverse readseq
ExecutionTime(%)
multi_write sfuse_write align_write multi_read sfuse_read align_read
Figure 6: Execution time breakdown for di↵erent SafeFS stacks.
As expected, the time spent in each layer varies according
to the tasks performed by the layers. The 3 most CPU-
facilitate future choices for practitioners and researchers.
We envision to extend SafeFS along three main direc
• Evaluation of SafeFS setups with 7 filebench workloads
• Throughput compared with ext4
0
0.2
0.4
0.6
0.8
➀ ➁ ➂ ➃ ➄ ➅ ➆ ➀ ➁ ➂ ➃ ➄ ➅ ➆ ➀ ➁ ➂ ➃ ➄ ➅ ➆ ➀ ➁ ➂ ➃ ➄ ➅ ➆ ➀ ➁ ➂ ➃ ➄ ➅ ➆ ➀ ➁ ➂ ➃ ➄ ➅ ➆
0
0.2
0.4
0.6
0.8
1
1.2
➀ ➁ ➂ ➃ ➄ ➅ ➆ ➀ ➁ ➂ ➃ ➄ ➅ ➆ ➀ ➁ ➂ ➃ ➄ ➅ ➆ ➀ ➁ ➂ ➃ ➄ ➅ ➆ ➀ ➁ ➂ ➃ ➄ ➅ ➆ ➀ ➁ ➂ ➃ ➄ ➅ ➆ ➀ ➁ ➂ ➃ ➄ ➅ ➆
➀ File-server ➁ Mail-server ➂ Web-server ➃ filemicro_rread_4K ➄ filemicro_rwrite_4K ➅ filemicro_seqread_4K ➆ filemicro_seqwrite_4K
SAFEFS AES SAFEFS Det SAFEFS Erasure SAFEFS FUSE SAFEFS Identity SAFEFS Rep SAFEFS XOR
Figure 5: Relative performance of filebench workloads against native.
0
0.2
0.4
0.6
0.8
1
AES
Det
Erasure
FUSE
Identity
Rep
XOR
AES
Det
Erasure
FUSE
Identity
Rep
XOR
AES
Det
Erasure
FUSE
Identity
Rep
XOR
AES
Det
Erasure
FUSE
Identity
Rep
XOR
AES
Det
Erasure
FUSE
Identity
Rep
XOR
AES
Det
Erasure
FUSE
Identity
Rep
XOR
AES
Det
Erasure
FUSE
Identity
Rep
XOR
fill100K fillrandom fillseq overwrite readrandom readreverse readseq
multi_write sfuse_write align_write multi_read sfuse_read align_read
Figure 6: Execution time breakdown for di↵erent SafeFS stacks.
As expected, the time spent in each layer varies according
o the tasks performed by the layers. The 3 most CPU-
tensive stacks (AES, Det and Erasure) concentrate their
facilitate future choices for practitioners and researchers.
We envision to extend SafeFS along three main direc-
tions. First, we plan to smooth the e↵orts to integrate any
➁ ➂ ➃ ➄ ➅ ➆ ➀ ➁ ➂ ➃ ➄ ➅ ➆ ➀ ➁ ➂ ➃ ➄ ➅ ➆ ➀ ➁ ➂ ➃ ➄ ➅ ➆ ➀ ➁ ➂ ➃ ➄
eCryptFS EncFS MetFS SAFEFS AES SAFEFS Det
➂ ➃ ➄ ➅ ➆ ➀ ➁ ➂ ➃ ➄ ➅ ➆ ➀ ➁ ➂ ➃ ➄ ➅ ➆ ➀ ➁ ➂ ➃ ➄ ➅ ➆ ➀ ➁ ➂ ➃ ➄ ➅ ➆ ➀ ➁ ➂ ➃ ➄
➂ Web-server ➃ filemicro_rread_4K ➄ filemicro_rwrite_4K ➅ filemicro_seqread_4K ➆ filemicro_seqwri
FS Det SAFEFS Erasure SAFEFS FUSE SAFEFS Identity SAFEFS Rep SAFEFS XO

17. Valerio Schiavoni - University of Neuchatel! UFSM - 02/02/2018SafeFS
Other results
17
• DB_bench experiments
• significant overhead in write requests
• read requests performance close to ext4
• uniform results across SafeFS and other
filesystems
• Time spent in each SafeFS layer
• Setups using encryption or erasure coding
require significant processing time and CPU in the
respective layers
• The Granularity-Oriented layer is time-
demanding specially for write requests

18. Valerio Schiavoni - University of Neuchatel! UFSM - 02/02/2018SafeFS
• Strict combinations of storage features cannot fulfil
the requirements of distinct applications
• SafeFS addresses this challenge with
• a modular layer and driver design
• a common API for easily stacking layers
• Allows to create
• combinations of storage features based on applications
requirements
• to reduce the cost and complexity of reusing or
implementing new layers
Conclusion /1
18

19. Valerio Schiavoni - University of Neuchatel! UFSM - 02/02/2018SafeFS
• Our experiments show that
• different SafeFS setups are easily deployable
• a layered approach has similar performance to other
monolithic privacy-preserving filesystems
• Future Work
• Workload-aware and automatic configuration of layers
• Run-time configuration of layers and drivers
• Encryption keys management and access control
Conclusion /2
19
Open source, Available at
https://github.com/safecloud-project/SafeFS

20. SafeFS:A Modular Architecture
for Secure User-Space File Systems
(One FUSE to rule them all)
Invited Talk - UFSM, Santa Maria, Brasil
02 February 2018
Rogério Pontes1, Dorian Burihabwa2, Francisco Maia1, João Paulo1,
Valerio Schiavoni2, Pascal Felber2, Hugues Mercier2, Rui Oliveira1
1High Assurance Software Lab, INESC TEC and University of Minho, Portugal
2University of Neuchâtel, Switzerland