论文Summary03——TAP规则脆弱性静态修复——AutoTap & TAPInspector

AutoTap可以自动生成TAP规则，能检测什么样的冲突？用户定义的policy，保证安全，但是没有考虑诸如tardy attribute，extended action中止（只是模拟没判断？）。利用上下文生成一条新的 TAP 规则以去除状态机(automation graph)里冲突的那条 bridge edge（在状态机里的特点是 infinte 和 accepting node），但无法处理需要生成多条 TAP 规则进行修复的场景。
AutoTap currently does not consider issues like actions failing to complete or not taking effect immediately

property-specification interface

用户输入系统需要满足或者不要出现的规则（如下雨时窗户要关闭），将规则归类为下图7类template并转换为对应的LTL，如always转为G(state)，never转为!F(state)

V. TAP synthesis

用户的输入property ∅、原本的TAP规则、设备的capability-------------->有∅冲突的自动机
原本的TAP规则、设备的capability A(s)，¬∅的A(¬∅)------------->A(有∅冲突)
¬∅对应的Fig 6(a)？
保留满足∅的，提出TAP规则能消去自动机里（一个映射）违反∅的

V-A Model Construction

device selection 选取和∅有关的设备进行建模，应该是每次针对一个∅去做验证
引入time-related，防止大规模，引入timer变量(范围0-t)模拟 事件e发生在过去t（秒）内 和 ap至少在t（秒）内为真，只是模拟了T2A latancy的一个delay
和本文所说缺点的关系？但是没有考虑诸如tardy attribute，extended action中止（只是模拟没判断？）

V-B Patching the Automaton 状态机层面解决冲突

是从Automaton层面观察到冲突往往会infinite node和对应的bridge，所以才想了去bridge的方法
V-B是识别自动机里的，V-C是映射为TAP
an execution accepted的定义？visit accepting node无限次
cut edge要挑选property-compliant 、accommodating、valid的
valid(不可能阻止自然条件的发生；不能修改用户需求∅、对应的A(¬∅)和device specification)
如自然的event stop raining可以通过官方capability文档中带不带"command"关键词区分
property-compliant 对应无限,去除无限次的就能property-compliant
cut 连接un-accepting node和accepting node(图中◎)的bridge edge 保证property-compliant
满足∅的不会经过any bridge 保证accommodating
Rain.on->Win.closed会产生bridge

为啥stuck，因为没TAP就没transition

所以连接accepted node的transition中，不是Rain.on & Win.closed的就消失了
A¬∅应该是类似fig6(b)只是省略了

A中的node是As和A(¬∅)的笛卡尔积

我的想法，如果安全敏感的设备出现冲突，应该要修改，可能一些不痛不痒的就不改

V-C TAP Synthesis TAP规则层面解决冲突

将自动机里的变化(去边)映射为上层的TAP变化（像我说的）

fixing algorithm

一句话概括refine：对于修复rule要在bridge处触发而不在其它地方误触，现有rule不在bridge处触发而在其它地方触发，这就要求修复rule的trigger比AP弱，越弱越会走到bridge处，同时要修复rule的trigger event和现有rule的trigger event冲突，一种可行的方法是narrow现有rule的trigger event。同时，修复rule的action也有自己的方法。

简单的修正：edit or add conditions or triggers，disable a rule

If @RAIN.ON（start to rain）导致冲突的行为 while 冲突前状态 then 规避错误的action
发生时的original bridge edge
例子：没TAP规则的As

If e1 while AP1 Then e2
为了cut e in A，需要cut es in A(s)
前后只各连接一点的情况，对无TAP进行建模

AP1:precondition of the bridge
e1,es event associated with AP2
e2 event associated with succeding edge

refine trigger state AP1
要求：保证在bridge这，不在任何non-bridge situations
比AP1 (precondition of the bridge) weaker 比如只取某部分
在其它trigger event会发生的地方，pre-condition要和rule的trigger state冲突，防误触，还要分析AP1前其它trigger会发生的地方的AP’，用hitting set problem的贪心算法

refine action e2
若后面连接的不止一点，则e2不唯一
如何选action：1）不能是自然 2）引起其它冲突的action不选 3）与trigger违背就不选
For example, if the trigger event is turning on the air conditioner(AC), AutoTap will not suggest a rule that turns off the AC unless there are no other choices.

refine existing rule r
r trigger一个与es有关的event
narrowing r’s triggering state至pre-condition的trigger state ，拆解为多个 edge-specific TAP规则， delete the edge-specific rule
r不在es这触发，但在其它地方触发
associated with the bridge edge and keep the remaining ones

rule merging
merge TAP rules with the same trigger event and rule action, or even similar trigger states

各种edge的定义
bridge edges
bridge

正常是

                                     event / action
state1(由多个ap组成，如一些attribute)------------->state2

TAPInspector里，:后是下一个state node，:前是上一个state node + trasition边，trasition是event/action，在smv里对应着新老变量!=的值变更操作

一个失败的例子：

实验：进行mutation

能Handling 彼此不冲突的Multiple Properties

limitation
无法处理需要生成多条 TAP 规则以cut bridge,如前面失败的oven例子，改变不了自然因素也算

---

idea

从问题图生成系统行为。 将系统行为与现象指令对照表中的相关条目进行对照后才能生成最终的 TAP规则

smv如果没引入latency，不冲突，可达。如果引入，extended action，冲突，不可达

if it begins to rain(与安全有关的属性不完整) then close the window
应该加if it’s raining & window open then close the window

把状态机拆分的思想

平行边，状态重复

---

---

TAPInspector

5个特点 unstable T2A latency及其对应的Vnlnerablity ; liveness property for extended action； concurrency（TAP规则可能同时触发）；tardy chennel interaction；connection-based
都是为了更真实地来模拟
Model Slicing
State Compression
SmartThings TAP rules are coded as Apps in Groovy

Vnlnerablity Detection

tardy-chennel rule blocking 的检测：
1.都温度相关 2.条件有交集 3.action冲突（heater和open window冲突不是直接可以判断的，需要人工去定义有关系，方法是温度相关且趋势不一样）

修复：用户本意是不想让温度继续上升，这里开窗不是为了通风，因为通风不和温度相关

检测的Vnlnerablity种类：Action duplication；Action conflict ；9类Vnlnerablity原先的+扩展后的
在语法层面发现Vnlnerablity，将其转为对应的policy去model check确认真实存在

还有几类缺陷，如trigger,state不完整

G,F限制区间问题，red always followed by green or yellow
G(color.red->X(color.green 或 yellow)) ->有当前、未来一步和未来之意？