«上一篇 下一篇»
  计算机工程  2019, Vol. 45 Issue (7): 170-175  DOI: 10.19678/j.issn.1000-3428.0051549
0

引用本文  

杜军龙, 金俊平, 周剑涛. 具备完整性追溯的系统数据容灾机制[J]. 计算机工程, 2019, 45(7), 170-175. DOI: 10.19678/j.issn.1000-3428.0051549.
DU Junlong, JIN Junping, ZHOU Jiantao. System Data Disaster Tolerant Mechanism with Integrity Traceability[J]. Computer Engineering, 2019, 45(7), 170-175. DOI: 10.19678/j.issn.1000-3428.0051549.

基金项目

“核高基”重大专项“工业互联网安全操作系统产业化及规模化应用”(2017ZX01038103)

作者简介

杜军龙(1978-), 男, 高级工程师, 主研方向为信息安全、电子政务, E-mail:dujl@jiangxi.gov.cn;
金俊平, 研究员;
周剑涛, 工程师

文章历史

收稿日期:2018-05-14
修回日期:2018-06-22
具备完整性追溯的系统数据容灾机制
杜军龙 , 金俊平 , 周剑涛     
江西省信息中心, 南昌 330001
摘要:针对通用Linux平台因遭受异常攻击、破坏、宕机与病毒感染导致系统无法启动的问题,提出一种系统数据容灾机制(DDTM)。以安全上下文为宿主对象,基于可配置形式涵盖挂载预设、容灾粒度与改写策略库,通过文件完整性的追溯构建动态改写链。在DDTM形式化定义的基础上,给出细粒度的实现算法。实验结果表明,该机制可靠性高、实用性强。
关键词数据容灾    系统异常    文件安全上下文    完整性追溯    动态改写    
System Data Disaster Tolerant Mechanism with Integrity Traceability
DU Junlong , JIN Junping , ZHOU Jiantao     
Jiangxi Information Center, Nanchang 330001, China
Abstract: This paper proposes a system Data Disaster Tolerant Mechanism(DDTM) to address the problem that general Linux platforms suffer from abnormal attacks, damage, downtime, and virus infection, which leads to system startup failure. The security context is used as a host object, and the configurable form covers the mount preset, the disaster tolerance granularity, and the rewriting policy library. A dynamic rewriting chain is built by traceability of file integrity.Based on the formal definition of DDTM, a fine-grained implementation algorithm is given.Experimental results show that the mechanism is of high reliability and practicability.
Key words: data tolerance    system abnormal    file security context    integrity traceability    dynamic rewriting    
0 概述

随着信息技术的发展, 越来越多的数据存储于通用Linux平台中, 据IDC在数字宇宙的研究报告中指出, 预计到2020年, 全球数字量将达到35 ZB, 而中国将占据1/5[1-2]。在不同行业中, 集中式的数据存储方式给企业、单位、团体与个人都带来极大的便利, 但平台的容灾可靠性面临巨大的挑战。

目前, 通用Linux平台在遭受网络(病毒)攻击时, 当系统管理员误执行操作(命令)时, 如在专用领域移动作业过程中机器震荡(瞬时掉电)宕机时, 均可导致平台无法再次正常启动[3-5]。当企业、团体或个人PC机等平台发生此类问题, 会带来不同程度的经济损失。因此, 研究通用Linux平台在发生异常情况时的容灾措施具有重要意义。

面对平台的异常容灾问题, 国内外学者进行了大量研究。在抵抗网络攻击破坏的容灾方面, 文献[6]在智能网络存储系统上, 提出自免疫容灾恢复算法和后备智能网络磁盘容灾恢复算法, 将每一个智能网络磁盘(Intelligent Network Disk, IND)分成相等的记录区与备份区, 以多磁盘与多分区形式, 实现平台异常容灾的数据恢复。文献[7]构建了一种持续数据保护机制, 可以持续对系统所发生的任何改变进行捕捉和目标跟踪。文献[8]以纠删码对TFS中存放原数据的block块进行编码并生成冗余信息, 当异常发生, 借助冗余信息进行数据恢复。文献[9]以矩阵编码对存放原始数据进行不同磁盘域的标记, 当异常发生, 借助标记对数据进行高效率恢复。考虑到特殊情况下本地数据具有彻底损毁的可能性, 文献[10-11]给出一种通过异地备份的方法, 异地备份原理是依照预先设计的调度分配算法将数据资源在备份节点中进行文件副本拷贝, 以此避免数据的丢失。在防止异常掉电对系统造成影响的容灾方面, 文献[12]提出基于硬件实现的容灾机制, 借助LDO稳压器技术, 当系统异常掉电时, 可提供更加充足的时间, 以便随机存取存储器(Random Access Memory, RAM)与磁盘数据进行同步, 避免系统中索引节点数据不一致导致系统无法启动问题。文献[13]设计一款多电源信号处理保护电路, 一旦发现电源状态异常, 便给出供电切换信号, 确保系统后续正常工作。

目前,数据容灾相关研究主要集中在系统中“用户”的数据上,而对系统自身数据容灾的相关研究较少。本文提出一种具备完整性追溯的系统数据容灾机制(Data Disaster Tolerant Mechanism, DDTM), 并对该机制进行了容灾模型设计、形式化语言描述与细粒度算法实现。

1 DDTM设计

为使平台能在发生各种系统异常情况下, 有足够的可靠性与可用性, 本文提出一种具备完整性追溯的系统数据容灾机制。DDTM主要由保护实体(Protected Entity, PE)、构造客体(Construct Object, CO)、保护策略(Protection Strategy, PS)与动态改写链(Dynamic Rewriting Chain, DRC)共4部分组成, 其概念模型如图 1所示。

Download:
图 1 DDTM概念模型

保护实体作为DDTM设计的初始发散点与校验回归点, 具有独特的结构特征(文件系统的层级嵌套)、操作属性(r, w, x)与应用功能(配置文件、脚本、动态库、可执行文件与KO模块等)。研究PE结构形式[14], 以树形集合概念刻画的PE结构特征可分为复合实体(cps, DDTM层次化的宏观表述)与原子实体(atm, DDTM微层次化粒子表述)2类。复合实体(PEcps=PEscpsPEatm)可层级嵌套子复合实体与原子实体。

构造客体是PE在DDTM模式下的有效增量累积, 其结构特征、操作属性、应用功能与保护实体PE相同, 为方便模型区别表述, 构造客体中称为复合客体与原子客体。在CO中, 复合客体与原子客体是PE中复合实体与原子实体的动态增量叠加, 其内容统一而物理位置分离。为支持CO的完整性追溯查询, CO中的构造客体和原子客体存活周期有临时(系统重启时, 经过文件完整性比对校验后, 自动消失)、暂存(系统重启时, 经过文件完整性比对校验后, 进行周期内的保存, 如支持30 d内的历史追溯查询)与永久(系统重启时, 经过文件完整性比对校验后, 对CO进行永久保存, 支持后续的历史追溯查询)3种形式, 可根据实际查询需求进行策略配置。

保护策略作为DDTM关键模块, 其延续了传统产品设计的可配置策略思想, 根据具体项目保护PE需求, 以作用点边界为切入对系统数据容灾机制完成挂载预设。根据系统启动过程, 挂载预设可选取initrd(在虚拟内存中进行截弧, 实现数据容灾机制)与sysinit(内核启动完成后, 实现数据容灾机制)。容灾粒度与改写策略库是PS的重要考虑因素, 粒度的粗细由立项需求中受保护实体PE而定, 具有被动性, 而改写策略库则是DDTM方案的实现细节体现, 由CO存活周期、挂载策略、改写路径、打标算法、安全检测(Y/N)与改写白名单共同组成, 具有主动性, 同时, 为避免策略库中数据存储依赖性, 均以配置文件形式存储。

动态改写链, 在容灾机制进行数据恢复之前对系统数据进行了完整性追溯的可信校验, 同时, 借助安全上下文为宿主对象将完整性计算结果进行了存储隐藏, 进而提供一套高耦合、高可靠的数据改写功能。高耦合体现在前期在CO的文件安全上下文动态打标与后期完整性追溯校验的组合实现。其中, 动态打标借助内核hook技术, 在file_permission中截弧, 获取当前操作文件名称与全路径, 同时记录到用户层的改写白名单中, 然后由守护进程daemon查阅该白名单, 并判断是否符合PS中改写路径范畴, 若符合, 则在文件关闭状态的前提下, 对文件进行完整性计算, 并将计算结果存贮于文件安全上下文中; 若不符, 则略过, 如图 1中kernel部分所示。高可靠体现在后期完整性追溯的可信校验, 完整性追溯是打标的逆向工程, 首先判别PS中的改写路径与改写白名单文件是否可信, 若可信则结合改写路径与改写白名单, 对文件进行完整性计算, 然后与文件安全上下文中存贮值做对比, 相同则改写覆盖, 不同则略过。若不可信, 追溯并继续采用上次可信系统源数据。

2 DDTM形式化定义与算法实现

本节基于DDTM概念模型基础上, 给出形式化定义, 同时, 在容灾机制实现的关键节点给出细粒度算法。

定义1 (保护实体) 设PE是保护实体集合, 则每一个保护实体pe定义为一个四元组, 即:

$ p e=<i d_{p e}, { struct }, {attr}, { func}> $

其中, 标识符idpeID1(ID1为保护实体标识符集合), 结构特征structStruct, Struct={cps, scps atm}体现了系统文件层级嵌套与包含关系, 如:{<sda1, sda2, …, sdan>,</etc, /var, …, /tmp>,</etc/*, /var/*, …, /tmp/*>}, 操作属性attrAttribute, Attribute={r, w, x}有读、写与执行共计3种形式, 应用功能funcFunction是系统中文件功能属性统称, 有配置文件、系统库文件、脚本文件、可执行文件与KO模块等。

定义2 (构造客体) 设CO是构造客体集合, 则每一个构造客体co定义为一个五元组, 即:

$ c o=<i d_{c o}, {struct}, {attr}, { func, live }> $

其中, 标识符idcoID2(ID2为构造客体标识符集合), structattrfunc同PE定义(保护实体)相同, 存活周期livepolicycycle由保护策略PS定义5设定。

定义3 (保护实体与构造客体逻辑关系)  设relation为系统数据容灾机制中PECO的量化关系表示符, relation=<pe, co, union>, 其中, pePE, coCO, union表示peco的联合。具体到系统文件, 设有文件名称为afile, 那么有:

1) peafilecoafile=afile

2) peafilecoafile=Ø。

定义4 (保护策略)  设PS是保护策略集合, 则每一个保护策略ps可定义为一个四元组, 即:

$ p s=<i d_{p s}, {request}, {point}, {policy}> $

其中, 标识符idpsID3(ID3为保护策略标识符集合), 项目需求requestRequest是不同用户根据平台实际应用场景进而对项目立项实现功效的量化指标, 作用点pointPoint, Point={initrd, sysinit}, 改写策略库policePolicy, Policy以文件形式存储, 包含CO存活周期、挂载策略、改写路径、打标算法、安全检测(Y/N)与改写白名单。

定义5 (改写策略库) 设PSpolicy为改写策略库集合, 则policy可定义为一个六元组, 即:policy=<cycle, mount, chgpath, algorithm, check, whitelist>其中, CO存活周期cycleCycle, Cycle={temp, ltime, forever}, temp为临时文件模式, 仅支持一次完整性比对校验追溯, ltime为暂存文件模式, 支持周期内完整性比对校验追溯, forever为永久文件模式, 支持后续历史的完整性比对校验追溯, 挂载策略mountMount, Mount={ram, partition, folder}, ram是以内存形式作为系统数据容灾机制模式下的rw空间, partition是以硬盘分区形式作为rw空间(双分区策略), folder是以文件夹重构形式做为rw空间, 改写路径chgpathChgpath, Chgpath默认设置为default, defaultall状态值为全部改写, nil为不改写, 具体改写路径依据规则自行添加, 如etc&var, 则为仅改写/etc和/var路径, 打标算法algorithmAlgorithm, 默认采用md5算法, 如特殊需求支持自定义扩展, 安全检测checkCheck, Check={Y, N}, Y表示动态改写链启用完整性检测, N表示动态改写链不启用完整性检测, 改写白名单whitelistWhitelist, Whitelist={path, filename, status}, path为改写文件路径, filename为文件名, status表示是否已打标完成。

根据定义5, 算法1给出以作用点为边界切入实现系统数据容灾机制的可达性算法。

算法1 系统数据容灾机制可达性算法

输入 保护实体PEcpsPEatm, 保护策略PS, 项目立项需求PSrequest, 作用点PSpoint与改写策略库PSpolicy及所属

输出 容灾机制执行结果

#define MYCORCT   0

#define MYERROR   -1

1.switch(PSrequest)//挂载预设

2.case "PEcps(sda/b/c)"

thenpointinitrd←point, flag=1;

3.case "PEcps (/etc, /var…/sys) ‖ PEatm\

(grub.conf, …, passwd)"

then pointsysinit←point, flag=2;

4.default:return MYERROR;

5.if flag==1 //容灾策略挂载实现

mount -o ro PEcps ramdisk/ro/; //选取挂载策略

6.select policymount{ram, partition}

7.if policymount==ram

then applicate mem space; //生成CO读写区间

mount -o rw ram ramdisk/rw/;

8.else if policymount==partition

then mkfs.ext4 sd._rw;

mount -o rw /sd._rw ramdisk/rw/;

9.mount -t unionFS ramdisk/ro/=ro, ramdisk/rw/= rw, sysroot/; //双区联合挂载

10.chroot sysroot/; return MYCORRECT

11.else if flag==2

12.then point=pointsysinit;

mv PEcps‖PEatm PEcps=ro‖PEatm=ro &&\

mkdir PEcpsrw‖PEatmrw

13.chroot sysroot/; return MYCORRECT

14.else return MYERROR;

定义6 (动态改写链)  设DC是动态改写链集合, 则每一次动态改写dc可定义为一个五元组, 则:dc=<iddc, policydc, label, compare, cover>。其中, 标识符iddcID4(ID4为动态改写链标识符集合), 改写策略policydcPSpolicy, 涉及策略库中改写路径policychgpath、打标算法policyalgorithm、安全检测policycheck与改写白名单policywihtelist, 打标labelLabel, Label是对文件安全上下文的动态打标, 比对compareCompare, 通过对文件完整性计算与文件安全上下文中的基准值做对比, 改写coverCover, 根据改写路径与配置白名单对文进行动态改写。

定义7 (完整性)  完整性是指系统数据的配置文件、系统库文件、脚本文件、可执行文件与KO模块被破坏或篡改的程度, 系统数据的完整性可表示为integrity, 且0≤integrity≤1。当未被破坏或篡改时, integrity=1;当部分信息被破坏或篡改时, 0<integrity<1;当完全被篡改或破坏时, integrity=0。

定义8 (完整性追溯)  为确保系统数据容灾的高可靠性, 在完整性定义的基础上, 设读写区间中CO的可信度为reliability, reliability∈[integritymin, integritymax], 那么在打标时刻t1和校验时刻t2, 满足如下条件:

1) 若在t1t2时刻, n=m, (< afile, t1>→n &<afile, t2>→m)/(afile, t1, t2>)→true

2) 若在t1t2时刻, nm, (< afile, t1>→n &<afile, t2>→m)/(< afile, t1, t2>)→false

定义9 (容灾机制约束条件)  为使系统数据容灾机制具有可达性, 那么容灾机制的实现, 在读写区间中有容量(capacity), 恢复时间(time), 应满足式(1)和式(2)约束条件。

$ \sum\limits_{i=1}^{n} \sum\limits_{j=1}^{m}\left(c o_{i}, t_{j}\right) \leqslant capacity $ (1)
$ \sum\limits_{i=1}^{n} {hash}\left(c o_{i}\right)+\sum\limits_{i=1}^{n}\left(c o_{i} \rightarrow p e_{i}\right)= time $ (2)

式(1)表示在容灾机制下, capacity应满足构造客体在t1, t2, …, tm时刻的所有总量存储上限界值。式(2)恢复时间是完整性追溯与改写时间总和, 与CO数量有直接关系。

根据定义9, 基于文件完整性追溯, 算法2给出数据容灾机制改写算法。

算法2 数据容灾机制改写算法

输入 改写路径policychgpath, 打标算法policyalgorithm, 安全检测policycheck与改写白名单policywihtelist

输出 容灾机制执行结果result

#define MYCORCT 0

#define MYERROR -1

//获取内核安全域地址

1.struct security_operations *sec_ops=look_up_\

symbol("security_ops");

if(!sec_ops) the return MYERROR;

2.sec_ops->file_permission (struct file *file, \int mask); //通过钩子截弧文件名

3.filename=file->f_path.dentry->d_iname;

4.filepath=dentry_path_raw(file->f_path.dentry, \buf, buflen); //通过钩子截弧文件路径

5.if((NULL==filename)‖ (NULL==filepath))

then return MYERROR;

6.for each policydc∈(policyalgorithm&policycheck\&policychgpath){

//判断文件是否属于保护范畴

if file policydc

write filename & filepath >policywihtelist; }

7.for each file ∈policywihtelist{

//对文件进行完整性度量

value←hash_damon (file);

filecontext←setattr value;

}

8.for each file ∈policywihtelist{

//对文件完整性进行追溯

value1←getattr filecontext;

value2←hash_damon (file);

if(compare(value1, value2)==0)

//对文件进行恢复改写

then cover.sh (file);

}

9.return MYCORCT;

3 DDTM实现与验证

为验证系统数据容灾机制DDTM的可行性, 本文在满足实际项目需求的前提下, 按照DDTM设计思路, 在通用Linux平台中进行了定制产品化的实现与性能试验。为缩短开发周期, 实现过程中的policymount部分并没有完全自主研发, 而是借助了开源项目overlayfs的部分技术[15]

3.1 DDTM功能实现

通过研究Linux平台启动过程, 平台无法启动的原因在于系统数据遭到异常的完整性破坏[16], 考虑到在满足项目PSrequest前提下, 尽可能迎合不同客户的系统数据容灾需求, 选取保护实体PE为平台根($root)目录, PE层级嵌套子复合实体(PEcps=/etc, /boot, …, /var)与原子实体(PEatm=/etc/file*, /boot/file*, …, /var/run/file*)。PEattr={r, w, x}涵盖读、写与执行权限。PEfunc涵盖配置文件、系统库文件、脚本文件、可执行文件与KO模块。

参照DDTM与平台启动的映射关系, 遵循保护周期最大化原则, 选取作用点PSpoint=initrd。根据定义5知, policymount={ram, partition, folder}, 由于PE整体相对较大, 牺牲ram空间换取的rw挂载, 势必导致平台运行性能降低, 因此双区联合挂载的partition策略为最佳抉择。采用双区联合挂载, 构造客体CO则动态建立在sda_rw分区中, COPE动态生成的有效增量累积, COattrCOfuncPE中相同。为便于系统数据容灾模式下改写的回滚溯源, COlive选取了ltime模式, 设定有效追溯周期为30 d。具体掉电保护实现流程如图 2所示。

Download:
图 2 系统数据容灾流程

系统数据库容灾流程具体描述如下:

1) 系统开机启动, 首先进行BIOS加电自检, 然后经过系统MBR和grub引导进入initrd的虚拟内存盘。

2) 在虚拟内存盘中, 对系统文件mount过程截弧(systemV与systemD两种启动方式的截弧思路相同, 嵌入过程略有不同), 将默认系统磁盘区间的挂载策略替换为policymount, 根据系统数据容灾机制可达性算法1, 在policymountpartition双区联合挂载方式时, 执行mkfs.ext4将rw分区进行格式化, 然后借助overlayfs技术, 执行命令mount -t overlayfs -olowerdir=$root, upperdir=sda_rw sysroot/, 将$root分区和sda_rw分区联合挂载, 作为系统根分区。

3) 紧接着加载系统数据容灾的ddtm.ko模块, 此时改写file_permission钩子生效。ddtm.ko模块监控PEcpsPEatm文件行为, 一旦用户对之操作, KO模块便将PEcpsPEatm文件名称与路径写到policywhitelist中, 等待守护进程ddtm_daemon操作。

4) 守护进程ddtm_daemon首先读取policycheck, 如果policycheck设置为0, 表示不启用完整性追溯检测; 如果policycheck设置为1, 表示执行完整性追溯检测, 然后读取policychgpath, 对policychgpath路径中policywhitelist文件进行状态检测, 按照policyalgorithm算法, 完成文件安全上下文的动态打标。

5) 当系统发生系统异常情况时, 再次启动系统。根据数据容灾机制改写算法2, 读取policycheck, 若为1, 则读取policychgpath&& policywhitelist, 按照policyalgorithm对文件进行完整性计算, 如果值与文件安全上下文中存储的值相同, 则执行动态改写链中的改写操作; 如果不同, 则略过改写操作。若为0, 表示不启用完整性追溯检测功能。

3.2 DDTM性能分析

为验证本文系统数据容灾机制的性能损耗与改写所用时间, 在Linux通用系统平台中进行以下实验。

3.2.1 系统功耗

本文系统功耗性能验证步骤描述如下:

步骤1  选用2台同型号硬件机器, CPU为Intel(R) Core(TM) Duo E8400 3.0 GHz, Memory为4.00 GB, 操作系统为x86_64, 其他参数均视为理想状态值, 忽略其影响。

步骤2 在2台机器系统正常条件下, 执行1×103次、5×103次、1×104次、5×104次与1×105次的文件打开与关闭操作, 同时记录全程消耗时间, 每组重复执行3次, 取均值。

步骤3 对2台机器进行系统数据容灾机制部署, 保护系统数据均按最小保护策略实现, 不涉及用户自定义保护数据。

步骤4 将2台机器分别执行执行103次、5×103次、1×104次、5×104次与1×105次的文件打开与关闭操作, 同时记录全程消耗时间, 每组重复执行3次, 取均值。

两组数据结果对比如图 3所示。

Download:
图 3 系统性能对比

与未添加DDTM机器相比, 本文提供的系统数据容灾机制, 在相同工作压力的情况下, 效率分别降低1.6%、1.5%、1.2%、1.1%和1.1%, 平均系统性能损耗为1.3%, 均在系统损耗偏差可接受范围内。

3.2.2 系统改写时间

系统改写时间验证步骤描述如下:

步骤1  2台测试机均已署系统数据容灾机制, 保护系统数据均按最小保护策略, 不涉及用户自定义保护数据。

步骤2 在2台机器正常情况下, 执行5次重启动操作, 全程记录启动时间。

步骤3 在2台机器的保护策略目录下, 以超级管理员权限执行rm -rf $root/(bin、dev、etc、lib、lib64、media、opt、sbin、sys、tmp、usr、var)进行破坏, 每台机器均执行5次, 全程记录系统重启动时间。

步骤4 在2台机器的保护策略目录下, 以超级管理员权限分别设置可改写1×103、5×103、1×104、5×104与1×105个文件, 同时记录全程消耗时间, 每组重复执行3次, 取均值。

系统开机时间结果对比如图 4所示。

Download:
图 4 系统开机时间对比

以超级管理员权限执行rm -rf $root/*操作的系统启动时间与正常机器相比几乎相同, 因为在执行完删除操作后, 在可读写区间中没有CO的相关文件记录, 所以在打标时, 无文件可操作, 在下次启动时, 根据DDTM策略, 直接追溯启用上一次正常启动的系统数据。与正常机器相比, 以超级管理员权限在进行系统数据可改写操作时的系统启动时间, 与改写系统的数据量成正相关性。

针对通用Linux平台依照DDTM进行系统数据容灾机制的设计与实现, 经上述产品化实现与性能验证, 具有以下特点:

1) 可靠:避免平台被异常攻击、破坏、宕机与病毒感染致使无法启动的异常情况, 提高平台可靠性。

2) 安全:对系统保护数据改写前进行完整性校验, 增强了系统数据改写安全性。

3) 实用:在各行业中, 企业、团体以及个人的Linux平台均可部署此种数据容灾机制, 部署完成后该机制立即生效, 实用性强。

4 结束语

为解决通用Linux平台在遭受异常攻击、破坏、宕机与病毒感染后系统无法启动的问题, 本文通过构建概念模型辅以形式化定义和细粒度算法描述, 提出一种切实可行的、高可用的且具备完整性追溯的系统数据容灾机制DDTM。将系统数据与环境要素进行了量化分离, 通过完整性追溯, 对系统数据进行完整性检测, 充分保证该容灾机制的可用性与可靠性。下一步将对系统用户数据的容灾与数据恢复效率进行扩展和优化, 为用户构建一个从应用层到系统层的数据容灾保护机制。

参考文献
[1]
周殷华, 范璐, 沈小白. 我国Linux发展的成功模式:政府引导的产学研战略合作联盟——以中科红旗公司为例[J]. 中国软科学, 2008(8): 85-92. DOI:10.3969/j.issn.1002-9753.2008.08.012 (0)
[2]
GANTZ J F.The diverse and exploding digital universe[EB/OL].[2018-04-13].https://www.ifap.ru/library/book268.pdf. (0)
[3]
凌杭, 吴震, 杜之波. 基于汉明重的EPCBC代数侧信道攻击[J]. 计算机工程, 2017, 43(8): 156-160, 168. DOI:10.3969/j.issn.1000-3428.2017.08.026 (0)
[4]
莫樱.基于病毒行为分析的特征码的提取与检测[D].成都: 电子科技大学, 2011. http://cdmd.cnki.com.cn/Article/CDMD-10614-1011194256.htm (0)
[5]
柯圣财, 赵永威, 李弼程, 等. 基于卷积神经网络和监督核哈希的图像检索方法[J]. 电子学报, 2017, 45(1): 157-163. DOI:10.3969/j.issn.0372-2112.2017.01.022 (0)
[6]
周云霞, 赵跃龙, 杨希. 智能网络磁盘存储系统的容灾研究[J]. 计算机研究与发展, 2012, 49(7): 1587-1592. (0)
[7]
刘正伟, 张华忠, 文中领. 海量数据持续数据保护技术研究及实现[J]. 计算机研究与发展, 2012, 49(1): 37-41. (0)
[8]
王子伟, 王晓京. 基于低密度随机纠删码的TFS容灾优化方案[J]. 计算机应用, 2016, 36(s2): 66-68, 81. (0)
[9]
滕鹏国, 张景中, 陈亮. 随机阵列码:一种高容灾易扩展的RAID存储容灾方法[J]. 工程科学与技术, 2017, 49(3): 110-116. (0)
[10]
林国勇, 黄帆. 一种用于云计算的数据容灾分配算法的改进[J]. 科学技术与工程, 2017, 17(1): 260-264. DOI:10.3969/j.issn.1671-1815.2017.01.047 (0)
[11]
ALSHAMMARI M M, ALWAN A A, NORDIN A, et al. Disaster recovery with minimum replica plan for reliability checking in multi-cloud[J]. Procedia Computer Science, 2018, 130: 247-254. DOI:10.1016/j.procs.2018.04.036 (0)
[12]
程万前, 阮慧, 郭少艾, 等. LDO稳压器对嵌入式系统掉电保护作用的研究[J]. 电源技术, 2016, 40(6): 1290-1292. DOI:10.3969/j.issn.1002-087X.2016.06.043 (0)
[13]
杨毓军, 苏晨, 张俊安, 等. 一种多电源信号处理系统的保护电路设计[J]. 微电子学, 2013, 43(3): 401-404. DOI:10.3969/j.issn.1004-3365.2013.03.023 (0)
[14]
蔡德明. 鸟哥的Linux私房菜[M]. 北京: 人民邮电出版社, 2010. (0)
[15]
OverlayFS[EB/OL].[2018-04-13].https://en.wikipedia.org/wiki/OverlayFS. (0)
[16]
WOLFGANG M.深入Linux内核架构[M].郭旭, 译.北京: 人民邮电出版社, 2010. (0)