tejaswanjari integrity memory data分布式系统中内存数据镜像性.pdfVIP

Problem Definition  In-memory data is changing  Disk checksums are for the older state  Mirroring cannot rely on disk checksums  Undetected corruptions are not acceptable  Reliability is prime (e.g. Backup/Recovery Systems) Sources of Corruption during Mirroring  System failure “Clean” shutdown and reboot  Hardware failure Redundant failover  Disks failure Disk/filesystem checksums  Process corruption  Avoiding copying without checksums work corruption Application/protocol checksums TCP Checksum Vulnerability  TCP Checksum: 4 bytes weak  Pr o False Positives (FPs) Wrong data, correct checksum  Failure probability: 1 in 16 million to 10 billion packets for 1526 bytes [Reference: [1] Stone et. al., When the CRC and TCP checksum disagree]  Implies 1 undetected TCP corruption in 20GB to 1.2TB data, approxima y Strong checksum in Application?  Performance overhead Application data-structures different fro work data-structures (e.g. B-tree data to fit into MTU) “Interconnect o work” is the vulnerability, not the application  End up reinventing transport protocol in application (over TCP!) Handling retransmissions, in-order delivery, gaps, etc. Ideal Solution  Zero-copying: avoid multiple copies without checksums  H/w redundancy for hardware failures  Clean shutdowns on system failures  Filesystem/block/disk checksums for disk reliability  Bridging the integrity gap in network/interconnect Protection in transport protocol Why reinvent the wheel?  RFC 2385: TCP MD5 Signature Option  Implemented in Linux Kernel as TCP_MD5SIG socket option  Linux im