1
00:00:11,360 --> 00:00:15,930
hello hey thanks for the introduction

2
00:00:13,980 --> 00:00:18,330
so hello everyone my name is Sheena Tai

3
00:00:15,930 --> 00:00:19,980
from Purdue University so today I'm

4
00:00:18,330 --> 00:00:23,220
going to talk about our project PI

5
00:00:19,980 --> 00:00:25,140
theorem Oh Oracle for the mazes so this

6
00:00:23,220 --> 00:00:26,520
is a joint walk with Professor matheus

7
00:00:25,140 --> 00:00:30,480
pair from epfl

8
00:00:26,520 --> 00:00:32,460
and my advisor in town from UCSD so let

9
00:00:30,480 --> 00:00:34,650
me start my talk by discussing that has

10
00:00:32,460 --> 00:00:36,030
sent a little bit here so there isn't a

11
00:00:34,650 --> 00:00:38,400
security it's really important

12
00:00:36,030 --> 00:00:40,890
especially more and more data a process

13
00:00:38,400 --> 00:00:43,350
and manage inside and within a big data

14
00:00:40,890 --> 00:00:44,940
center in the last few years so the

15
00:00:43,350 --> 00:00:46,649
lesson that has been the place of attack

16
00:00:44,940 --> 00:00:50,250
it's really important to protect our

17
00:00:46,649 --> 00:00:51,870
data in telecenter so let us take a look

18
00:00:50,250 --> 00:00:54,269
what it has in the needs and recent

19
00:00:51,870 --> 00:00:56,730
chance so there are no demands faster

20
00:00:54,270 --> 00:00:59,760
network large memory and also low sip

21
00:00:56,730 --> 00:01:02,250
utilizations that's why our DMA fits

22
00:00:59,760 --> 00:01:04,319
this chain so let me introduce our DMA

23
00:01:02,250 --> 00:01:07,290
here so our DMA stands for remote

24
00:01:04,319 --> 00:01:09,179
directly memory access so in comparison

25
00:01:07,290 --> 00:01:11,520
of traditional classic communications

26
00:01:09,180 --> 00:01:13,560
it's the classic communication goes

27
00:01:11,520 --> 00:01:16,199
through the user space applications a

28
00:01:13,560 --> 00:01:17,820
trap into kernel go to and the request

29
00:01:16,200 --> 00:01:20,369
arrives at the remote site it would

30
00:01:17,820 --> 00:01:21,089
process by the CPU and back to the

31
00:01:20,369 --> 00:01:25,080
memory again

32
00:01:21,090 --> 00:01:26,700
so in our DMA the request is issue from

33
00:01:25,080 --> 00:01:28,200
the user space application goes through

34
00:01:26,700 --> 00:01:30,360
the library and interact with the

35
00:01:28,200 --> 00:01:32,369
hardware directly when the requests

36
00:01:30,360 --> 00:01:35,100
arrive at the remote site you interact

37
00:01:32,369 --> 00:01:37,439
assess the memory directly therefore no

38
00:01:35,100 --> 00:01:41,189
longer kernel and CPU are involved in

39
00:01:37,439 --> 00:01:43,979
our DMA so with our DMA this design can

40
00:01:41,189 --> 00:01:46,199
read and write remote memory it bypassed

41
00:01:43,979 --> 00:01:49,710
kernel at both local and remote I

42
00:01:46,200 --> 00:01:52,470
finally offers memory zero copy because

43
00:01:49,710 --> 00:01:55,439
of Lee's design technique our DMA offers

44
00:01:52,470 --> 00:01:59,280
low latency high throughput and low CPU

45
00:01:55,439 --> 00:02:01,770
utilization because of the performance

46
00:01:59,280 --> 00:02:03,420
benefit of our DMA recently more in

47
00:02:01,770 --> 00:02:05,250
monitoring our centers adopt our DMA

48
00:02:03,420 --> 00:02:07,350
technology to improve the applications

49
00:02:05,250 --> 00:02:07,920
performance for example like Microsoft

50
00:02:07,350 --> 00:02:10,440
Azure

51
00:02:07,920 --> 00:02:14,310
they move to our DMA and also Alibaba

52
00:02:10,440 --> 00:02:16,290
cloud they stopped our DMA so there are

53
00:02:14,310 --> 00:02:18,090
also a lot of our DMA based data center

54
00:02:16,290 --> 00:02:18,989
implications in both academia and

55
00:02:18,090 --> 00:02:21,810
industrial

56
00:02:18,989 --> 00:02:22,830
however most of them either focus on

57
00:02:21,810 --> 00:02:26,670
performance

58
00:02:22,830 --> 00:02:27,540
scalability and usability so then what

59
00:02:26,670 --> 00:02:29,910
about security

60
00:02:27,540 --> 00:02:31,920
it's really important data centers so

61
00:02:29,910 --> 00:02:35,520
let me present you the path eeeh the

62
00:02:31,920 --> 00:02:37,140
first session attack on our DMA so let

63
00:02:35,520 --> 00:02:39,060
me introduce our threat model first

64
00:02:37,140 --> 00:02:42,929
before I go into the detail of our

65
00:02:39,060 --> 00:02:45,090
design so they are two sizing our model

66
00:02:42,930 --> 00:02:47,850
the client side which includes the

67
00:02:45,090 --> 00:02:50,580
victim may also an attacker then outside

68
00:02:47,850 --> 00:02:53,489
server side so server side host data

69
00:02:50,580 --> 00:02:57,720
inside the memory exported to users by

70
00:02:53,490 --> 00:02:59,730
our DMA so the attacker and the victim

71
00:02:57,720 --> 00:03:01,740
can be on different machines and the

72
00:02:59,730 --> 00:03:04,200
attackers want to learn the SS pattern

73
00:03:01,740 --> 00:03:06,210
of the victim for example victim says

74
00:03:04,200 --> 00:03:07,980
get key 50 then the attackers want to

75
00:03:06,210 --> 00:03:12,540
know think the victim really s at least

76
00:03:07,980 --> 00:03:14,130
key so we assume that attackers cannot

77
00:03:12,540 --> 00:03:15,720
observe the network traffic from the

78
00:03:14,130 --> 00:03:18,990
client side otherwise it can tell us the

79
00:03:15,720 --> 00:03:21,060
answer directly so now we are using our

80
00:03:18,990 --> 00:03:23,220
DMA therefore all the process and other

81
00:03:21,060 --> 00:03:25,950
requests will be processed by the how

82
00:03:23,220 --> 00:03:30,420
we're NIC our DMM Inc so let's just look

83
00:03:25,950 --> 00:03:32,100
into what is inside the our DMA Inc so

84
00:03:30,420 --> 00:03:34,019
we can see the classic communication

85
00:03:32,100 --> 00:03:36,090
first so in classic communications

86
00:03:34,020 --> 00:03:39,090
because all the requests are handled by

87
00:03:36,090 --> 00:03:41,820
CPU or processors therefore request will

88
00:03:39,090 --> 00:03:44,790
goes into a regular NIC and pass for CPU

89
00:03:41,820 --> 00:03:47,190
then we let us if you do the address

90
00:03:44,790 --> 00:03:49,739
address mapping information tracking and

91
00:03:47,190 --> 00:03:52,230
resource isolations so because there's

92
00:03:49,739 --> 00:03:54,650
the massive overhead of using classic

93
00:03:52,230 --> 00:03:58,890
communication because CPU is involved

94
00:03:54,650 --> 00:04:02,820
so in our DMA we because no longer we

95
00:03:58,890 --> 00:04:05,309
need CPU here so we need a stronger we

96
00:04:02,820 --> 00:04:07,980
have a stronger argument NIC and also

97
00:04:05,310 --> 00:04:09,840
more complicated so we in our DMA it

98
00:04:07,980 --> 00:04:12,179
relies on a concept which is called

99
00:04:09,840 --> 00:04:13,620
memory region to handle the address

100
00:04:12,180 --> 00:04:16,590
mapping information tracking and all

101
00:04:13,620 --> 00:04:18,570
things so now the card does the address

102
00:04:16,589 --> 00:04:21,000
translation which is handled by CPU

103
00:04:18,570 --> 00:04:23,040
before so in the memory regions there

104
00:04:21,000 --> 00:04:25,560
are two main things the first thing is

105
00:04:23,040 --> 00:04:27,630
our key and L key so our key is a key

106
00:04:25,560 --> 00:04:29,250
who to provide to remote client to let

107
00:04:27,630 --> 00:04:32,310
it do the permission checking

108
00:04:29,250 --> 00:04:35,310
so the Nico would check the key when the

109
00:04:32,310 --> 00:04:36,719
request arrived also the address is used

110
00:04:35,310 --> 00:04:38,819
for the address translation

111
00:04:36,719 --> 00:04:41,729
so let us look into lisa mejia date a

112
00:04:38,819 --> 00:04:43,919
little bit more so our mainly nique

113
00:04:41,729 --> 00:04:45,989
there are three types of metadata the

114
00:04:43,919 --> 00:04:48,089
first type is cue pairs which handles

115
00:04:45,989 --> 00:04:49,979
the connections the second type is

116
00:04:48,089 --> 00:04:51,539
memory regions which does the address

117
00:04:49,979 --> 00:04:55,110
translation and permission checking

118
00:04:51,539 --> 00:04:57,089
Farley is page table entries so thus the

119
00:04:55,110 --> 00:04:57,809
address translations because of the time

120
00:04:57,089 --> 00:05:00,449
limitations

121
00:04:57,809 --> 00:05:02,219
I will mainly focus on page table page

122
00:05:00,449 --> 00:05:06,389
table entries today which is also called

123
00:05:02,219 --> 00:05:08,429
PDE so when our DMA request comes in a

124
00:05:06,389 --> 00:05:11,189
rice at the remote site it includes a

125
00:05:08,429 --> 00:05:13,409
virtual address and a key then our

126
00:05:11,189 --> 00:05:14,939
diamonique would check the keys and does

127
00:05:13,409 --> 00:05:16,619
the address translation and get a

128
00:05:14,939 --> 00:05:19,219
physical address and access the memory

129
00:05:16,619 --> 00:05:22,139
accordingly so let us see this example

130
00:05:19,219 --> 00:05:24,089
when requests come when we request a

131
00:05:22,139 --> 00:05:27,119
rise of the remote machines it would

132
00:05:24,089 --> 00:05:29,219
check that the NIC check the cache by

133
00:05:27,119 --> 00:05:31,110
the metadata it's the heat then you

134
00:05:29,219 --> 00:05:34,169
access the memory so it's really fast

135
00:05:31,110 --> 00:05:37,549
it's really fast so let us look at

136
00:05:34,169 --> 00:05:40,318
another example what request comes in he

137
00:05:37,549 --> 00:05:42,719
found its miss so all Omaha data are not

138
00:05:40,319 --> 00:05:43,289
inside the RDMA cache an aria may need

139
00:05:42,719 --> 00:05:45,119
cash

140
00:05:43,289 --> 00:05:46,860
therefore he needs to fetch from the

141
00:05:45,119 --> 00:05:50,729
host machine to get the PD and other

142
00:05:46,860 --> 00:05:52,499
metadata you'll get a one by one so at

143
00:05:50,729 --> 00:05:54,508
least part creates a little bit slower

144
00:05:52,499 --> 00:05:57,239
after bringing all the men how they have

145
00:05:54,509 --> 00:05:59,789
fetched back to the audio Minnick you

146
00:05:57,239 --> 00:06:02,068
can finally access the memory so these

147
00:05:59,789 --> 00:06:03,889
parts create the timing difference this

148
00:06:02,069 --> 00:06:07,169
is just a channel with this cover

149
00:06:03,889 --> 00:06:09,929
it's a side channel so let me introduce

150
00:06:07,169 --> 00:06:12,448
the PI Thea is a set of sectional

151
00:06:09,929 --> 00:06:15,688
attacks that we introduced on our DMA so

152
00:06:12,449 --> 00:06:18,269
the basic of PI C is a big big and real

153
00:06:15,689 --> 00:06:21,239
o for example like if we let the victim

154
00:06:18,269 --> 00:06:22,979
s as a submissive page through DMA you

155
00:06:21,239 --> 00:06:27,058
will bring the metadata into the area

156
00:06:22,979 --> 00:06:30,239
meaning land attacker evict to clean the

157
00:06:27,059 --> 00:06:32,159
metadata well wait a little bit if the

158
00:06:30,239 --> 00:06:34,799
victim has the page again you will bring

159
00:06:32,159 --> 00:06:36,869
them in our data into the Nick again the

160
00:06:34,800 --> 00:06:39,119
attacker does the real oo operations and

161
00:06:36,869 --> 00:06:41,489
timeless operations if it's fast

162
00:06:39,119 --> 00:06:44,369
it means SS the victim access list page

163
00:06:41,489 --> 00:06:46,529
in the last time window let us look into

164
00:06:44,369 --> 00:06:47,909
another example victim Isis first

165
00:06:46,529 --> 00:06:50,460
attacker evict

166
00:06:47,909 --> 00:06:53,640
victim SS some other pages

167
00:06:50,460 --> 00:06:55,590
well technically low it would be slow

168
00:06:53,640 --> 00:06:58,830
it means the victim didn't as at least

169
00:06:55,590 --> 00:07:01,140
page before so title can read read read

170
00:06:58,830 --> 00:07:03,359
Ulis attack round but again and again

171
00:07:01,140 --> 00:07:07,620
then the attacker can learn the SS in

172
00:07:03,360 --> 00:07:09,750
pattern of the big team so why we do

173
00:07:07,620 --> 00:07:12,300
reverse engineering because we found out

174
00:07:09,750 --> 00:07:14,910
like the basic in V big every low is

175
00:07:12,300 --> 00:07:17,250
slow because now we cross the network

176
00:07:14,910 --> 00:07:19,560
it's already ma so the best thing evn

177
00:07:17,250 --> 00:07:22,770
reload takes around 25 milliseconds not

178
00:07:19,560 --> 00:07:24,780
70 minutes so after our reverse

179
00:07:22,770 --> 00:07:27,510
engineering we improved efficiency by

180
00:07:24,780 --> 00:07:29,789
500 times now we only need 15

181
00:07:27,510 --> 00:07:34,560
microseconds to do one round of pi/3

182
00:07:29,790 --> 00:07:36,240
attack so now I will introduce how we

183
00:07:34,560 --> 00:07:38,010
did our reverse engineering however

184
00:07:36,240 --> 00:07:40,320
because of the time limitation I will

185
00:07:38,010 --> 00:07:41,880
not go into detail today so please check

186
00:07:40,320 --> 00:07:44,070
our paper for more details

187
00:07:41,880 --> 00:07:45,930
so we suppose that our Dominique cash

188
00:07:44,070 --> 00:07:49,140
will be similar to a CPU cache less

189
00:07:45,930 --> 00:07:52,380
there are certain ways so we use

190
00:07:49,140 --> 00:07:54,780
different we use the sets fixed size to

191
00:07:52,380 --> 00:07:57,150
find out in despot and we also use

192
00:07:54,780 --> 00:07:59,909
different eviction set size to find out

193
00:07:57,150 --> 00:08:03,750
the potential ways Tolley we found out

194
00:07:59,910 --> 00:08:06,060
is a K and 128 now we see that we found

195
00:08:03,750 --> 00:08:09,300
a prefetch effect inside the REM unique

196
00:08:06,060 --> 00:08:10,860
when a page when a page is SS you will

197
00:08:09,300 --> 00:08:13,230
also bring the clothes may have data

198
00:08:10,860 --> 00:08:16,080
into the REM unique which facilitated

199
00:08:13,230 --> 00:08:19,340
computation also the SS so at least we

200
00:08:16,080 --> 00:08:22,289
found out that there are 1k set and

201
00:08:19,340 --> 00:08:24,659
we've we also found out that some of the

202
00:08:22,290 --> 00:08:28,170
pages the accuracy when we use our model

203
00:08:24,660 --> 00:08:31,440
to be big is not a high it's only 75% so

204
00:08:28,170 --> 00:08:35,039
if our layer may be another set so we

205
00:08:31,440 --> 00:08:37,830
find we found the high index so the

206
00:08:35,039 --> 00:08:39,750
metadata will either be in the index

207
00:08:37,830 --> 00:08:41,850
who either be in the set pointed or

208
00:08:39,750 --> 00:08:44,250
directed by the law index with high

209
00:08:41,850 --> 00:08:46,860
index therefore in order to improve the

210
00:08:44,250 --> 00:08:52,110
accuracy by Thea attack evict both set

211
00:08:46,860 --> 00:08:54,330
to have a good accuracy so Lee speakers

212
00:08:52,110 --> 00:08:56,520
summarize what we discover with reverse

213
00:08:54,330 --> 00:08:59,580
engineering so this is the completely

214
00:08:56,520 --> 00:09:03,240
out of our knee our Dominique we observe

215
00:08:59,580 --> 00:09:03,779
from experiment so let me show you the

216
00:09:03,240 --> 00:09:05,879
speaker

217
00:09:03,779 --> 00:09:08,850
this is a timing discern this is a PDF

218
00:09:05,879 --> 00:09:11,249
figure which discussed the latency so

219
00:09:08,850 --> 00:09:16,259
the excesses is latency microsecond the

220
00:09:11,249 --> 00:09:18,089
y-axis is person its percentile so the

221
00:09:16,259 --> 00:09:20,699
greater and the right hand side is

222
00:09:18,089 --> 00:09:23,490
greater licensees so we know that what

223
00:09:20,699 --> 00:09:25,519
our DMA request requires page table

224
00:09:23,490 --> 00:09:28,589
entries and also the keys to do the page

225
00:09:25,519 --> 00:09:30,899
translations so if all the metadata is

226
00:09:28,589 --> 00:09:32,939
inside the RDM unique this translation

227
00:09:30,899 --> 00:09:36,420
will be fast so it would be a black line

228
00:09:32,939 --> 00:09:38,519
means heat if page table entries are not

229
00:09:36,420 --> 00:09:40,589
inside the RDM anique it takes a little

230
00:09:38,519 --> 00:09:42,779
bit take some time to fetch it from the

231
00:09:40,589 --> 00:09:45,360
host machines memory you build green

232
00:09:42,779 --> 00:09:47,100
lines a little bit slower finally if all

233
00:09:45,360 --> 00:09:49,350
the metadata include the memory regions

234
00:09:47,100 --> 00:09:51,899
are not inside the RDM Aneke we need to

235
00:09:49,350 --> 00:09:53,519
fetch all that you'll be yellow line so

236
00:09:51,899 --> 00:09:55,889
we can see a clean separation between

237
00:09:53,519 --> 00:09:58,139
these three assets so this is the side

238
00:09:55,889 --> 00:10:00,689
channel we discover so this is not only

239
00:09:58,139 --> 00:10:03,209
in the connect export the NIC lab we use

240
00:10:00,689 --> 00:10:05,519
we also found the same issues on the

241
00:10:03,209 --> 00:10:07,378
different generations of our DMM mix for

242
00:10:05,519 --> 00:10:09,600
example like the latest available our

243
00:10:07,379 --> 00:10:11,819
Dominic's from our next connects 5 we

244
00:10:09,600 --> 00:10:14,250
can see the same things even in the cow

245
00:10:11,819 --> 00:10:18,029
lab which is a public cloud we see the

246
00:10:14,250 --> 00:10:20,459
same issue now we show that pi Thea can

247
00:10:18,029 --> 00:10:22,529
also deploy can also be deployed on Rio

248
00:10:20,459 --> 00:10:24,479
applications therefore we attack the Rio

249
00:10:22,529 --> 00:10:26,639
plication which is called Apache Krell

250
00:10:24,480 --> 00:10:29,459
so CRO is the research project

251
00:10:26,639 --> 00:10:32,189
originated from IBM and it's a Java

252
00:10:29,459 --> 00:10:33,869
based storage platform so we picked a

253
00:10:32,189 --> 00:10:36,180
key value store interface and also the

254
00:10:33,870 --> 00:10:38,610
RDMA communication and to show our path

255
00:10:36,180 --> 00:10:40,888
via attack so how to attack creo

256
00:10:38,610 --> 00:10:43,170
so in our project they are three

257
00:10:40,889 --> 00:10:45,420
different types of attack different ways

258
00:10:43,170 --> 00:10:48,240
to attack Krell the first way is called

259
00:10:45,420 --> 00:10:51,209
Emma base so in my theory my based

260
00:10:48,240 --> 00:10:52,800
attack we need a helper process on the

261
00:10:51,209 --> 00:10:56,969
machine which is co-located with the

262
00:10:52,800 --> 00:10:59,279
cloud service provider so we like the

263
00:10:56,970 --> 00:11:01,980
victim access a page through krell first

264
00:10:59,279 --> 00:11:06,480
you bring them are may have data into

265
00:11:01,980 --> 00:11:08,160
the RDM Annique then the attacker will

266
00:11:06,480 --> 00:11:09,990
in communicate with the helper process

267
00:11:08,160 --> 00:11:12,420
to evict all the memory region may have

268
00:11:09,990 --> 00:11:14,730
data from the NIC the attacker does the

269
00:11:12,420 --> 00:11:17,209
reuleaux these part leaks the SS in

270
00:11:14,730 --> 00:11:19,730
pattern through the side Channel

271
00:11:17,210 --> 00:11:21,770
for the page table entry based attack he

272
00:11:19,730 --> 00:11:25,640
also requires a helper process on the

273
00:11:21,770 --> 00:11:27,590
prowl service provider but now we use a

274
00:11:25,640 --> 00:11:29,540
page table entries metadata's it brings

275
00:11:27,590 --> 00:11:31,700
the page table entry area into our

276
00:11:29,540 --> 00:11:33,920
Dominique the helper process evict

277
00:11:31,700 --> 00:11:37,000
metadata's attacker does a reuleaux

278
00:11:33,920 --> 00:11:39,319
these parts list as SS in patterns

279
00:11:37,000 --> 00:11:41,570
finally we have a chi based attack

280
00:11:39,320 --> 00:11:43,670
pythonic tile based attack on Krell

281
00:11:41,570 --> 00:11:46,010
so in this attack is more powerful than

282
00:11:43,670 --> 00:11:48,829
the previous two so now we don't use

283
00:11:46,010 --> 00:11:50,840
only the Krell client to attack we no

284
00:11:48,830 --> 00:11:53,720
longer need to wrong any helper process

285
00:11:50,840 --> 00:11:57,020
and crayon machines which is fully a

286
00:11:53,720 --> 00:11:59,540
remote attack so in Lisa attack the when

287
00:11:57,020 --> 00:12:01,550
waiting when victim has a page through

288
00:11:59,540 --> 00:12:04,670
crown you bring the meta data into the

289
00:12:01,550 --> 00:12:09,229
our diamonique land attackers just issue

290
00:12:04,670 --> 00:12:12,589
a set of a set of Crayola quest really

291
00:12:09,230 --> 00:12:16,340
request like it can evict the victims SS

292
00:12:12,590 --> 00:12:18,020
Minnow data then reloj then leaks the

293
00:12:16,340 --> 00:12:20,780
ssing pattern so this is the most

294
00:12:18,020 --> 00:12:22,880
powerful one so let me show you the

295
00:12:20,780 --> 00:12:24,680
speaker this is a same figure swallow

296
00:12:22,880 --> 00:12:28,130
illustrate before is still timing these

297
00:12:24,680 --> 00:12:31,489
different speakers so you can see the XS

298
00:12:28,130 --> 00:12:34,580
is the latency even with the Java and

299
00:12:31,490 --> 00:12:36,050
also application overhead we can still

300
00:12:34,580 --> 00:12:38,150
see the timing difference between

301
00:12:36,050 --> 00:12:40,280
different assets so this is the side

302
00:12:38,150 --> 00:12:42,380
channel we discover so based on this

303
00:12:40,280 --> 00:12:45,410
side based on this side channels and

304
00:12:42,380 --> 00:12:46,610
timing difference we have list result so

305
00:12:45,410 --> 00:12:49,730
let me show you the client base that

306
00:12:46,610 --> 00:12:52,760
hacker result so the XSS is timeline in

307
00:12:49,730 --> 00:12:55,040
milliseconds the y-axis is the SS

308
00:12:52,760 --> 00:12:57,439
probabilities so the attacker will keep

309
00:12:55,040 --> 00:13:00,439
predicting the SS probability of victim

310
00:12:57,440 --> 00:13:03,500
whether the victim is a specific page in

311
00:13:00,440 --> 00:13:05,360
the last time window so we let the

312
00:13:03,500 --> 00:13:08,840
victim around zippy and workload a

313
00:13:05,360 --> 00:13:11,420
million or a million pages so through

314
00:13:08,840 --> 00:13:14,630
creo so the inter arrival time of each

315
00:13:11,420 --> 00:13:17,209
SS is based on Facebook keyboard store

316
00:13:14,630 --> 00:13:19,280
work law the inter arrival time so the

317
00:13:17,210 --> 00:13:23,420
Red Cross means the victim assess the

318
00:13:19,280 --> 00:13:25,910
success specific page so the black tile

319
00:13:23,420 --> 00:13:27,680
is the attacker keeps using the PI 3

320
00:13:25,910 --> 00:13:30,020
attack with client base to see whether

321
00:13:27,680 --> 00:13:31,160
the victim is or not so you can see

322
00:13:30,020 --> 00:13:32,930
lesser overlapping

323
00:13:31,160 --> 00:13:35,150
the Red Cross and also the black dog

324
00:13:32,930 --> 00:13:38,569
leashed means the Pythian client-based

325
00:13:35,150 --> 00:13:42,350
attack can really observe the victims as

326
00:13:38,570 --> 00:13:45,590
icing patterns so we introduced the

327
00:13:42,350 --> 00:13:48,350
attack of the RDMs I channel the section

328
00:13:45,590 --> 00:13:50,780
of text on our DMA so let me discuss how

329
00:13:48,350 --> 00:13:52,520
to mitigate least I channel attacks so

330
00:13:50,780 --> 00:13:54,770
the first idea is to do the client-side

331
00:13:52,520 --> 00:13:57,590
mitigations we can introduce noise

332
00:13:54,770 --> 00:14:00,530
inside the software for example because

333
00:13:57,590 --> 00:14:02,900
this is a timing channel attack a timing

334
00:14:00,530 --> 00:14:05,449
difference attack therefore if we put a

335
00:14:02,900 --> 00:14:07,670
noise inside the krail we can mix the

336
00:14:05,450 --> 00:14:11,090
sizegenetics harder this is the first

337
00:14:07,670 --> 00:14:12,979
idea second ways is we do the network

338
00:14:11,090 --> 00:14:14,630
traffic monitoring inside at a network

339
00:14:12,980 --> 00:14:16,940
side it could either be in a hub or in

340
00:14:14,630 --> 00:14:20,900
the switch to see earlier any malicious

341
00:14:16,940 --> 00:14:23,030
section attacks requests so finally is

342
00:14:20,900 --> 00:14:24,860
the server side mitigation

343
00:14:23,030 --> 00:14:27,050
this is stronger than the class I also

344
00:14:24,860 --> 00:14:28,760
the network side because the overhead so

345
00:14:27,050 --> 00:14:32,120
server side has lower overhead and

346
00:14:28,760 --> 00:14:33,830
doesn't requires it can also avoid to

347
00:14:32,120 --> 00:14:36,410
use the Machine which is controlled by

348
00:14:33,830 --> 00:14:38,240
the attacker the class I so a server

349
00:14:36,410 --> 00:14:40,490
size we use the huge we can use huge

350
00:14:38,240 --> 00:14:42,740
page or physical memory registration

351
00:14:40,490 --> 00:14:45,590
with so it means avoid get rid of the

352
00:14:42,740 --> 00:14:47,480
virtual memory registrations so this can

353
00:14:45,590 --> 00:14:49,330
reduce the overhead of the or address

354
00:14:47,480 --> 00:14:52,190
translations which can make their

355
00:14:49,330 --> 00:14:53,660
side-channel attacks harder so the

356
00:14:52,190 --> 00:14:57,350
second idea is to do the hardware

357
00:14:53,660 --> 00:14:59,900
resource isolations on our DMA neke like

358
00:14:57,350 --> 00:15:02,090
like what I mentioned both in the mi

359
00:14:59,900 --> 00:15:04,160
base attack and also the PT base attack

360
00:15:02,090 --> 00:15:06,230
it requires on the helper it requires a

361
00:15:04,160 --> 00:15:08,630
helper process running with the crown

362
00:15:06,230 --> 00:15:11,090
machine on the crown machine therefore

363
00:15:08,630 --> 00:15:13,250
if we can have the resource isolations

364
00:15:11,090 --> 00:15:16,490
we can avoid these two types of tag

365
00:15:13,250 --> 00:15:18,380
which can improve the security finally

366
00:15:16,490 --> 00:15:20,450
the separate resource

367
00:15:18,380 --> 00:15:22,550
between different connections and which

368
00:15:20,450 --> 00:15:24,380
is called protection domain when we

369
00:15:22,550 --> 00:15:27,349
disclosed list vulnerabilities to

370
00:15:24,380 --> 00:15:29,480
Melnick's the audio main providers they

371
00:15:27,350 --> 00:15:32,150
hinted demarest engineers hinted our

372
00:15:29,480 --> 00:15:34,400
list solutions the production domains to

373
00:15:32,150 --> 00:15:37,069
however we found out as far as we know

374
00:15:34,400 --> 00:15:40,730
most of the RDMA based applications they

375
00:15:37,070 --> 00:15:43,220
only use one production domains because

376
00:15:40,730 --> 00:15:44,810
using multiple production domains would

377
00:15:43,220 --> 00:15:47,960
bring the performance loss

378
00:15:44,810 --> 00:15:50,180
in our experiment we can see 15 to 25

379
00:15:47,960 --> 00:15:53,840
percent performance overhead when you

380
00:15:50,180 --> 00:15:56,329
use multiple production domains so let

381
00:15:53,840 --> 00:15:58,130
me conclude today's talk so we know the

382
00:15:56,330 --> 00:16:00,110
Rema performance is really good

383
00:15:58,130 --> 00:16:01,850
that's why data center engineers and

384
00:16:00,110 --> 00:16:03,740
also the managers I want to bring the

385
00:16:01,850 --> 00:16:06,860
Rema into data center to improve the

386
00:16:03,740 --> 00:16:09,110
applications performance however how to

387
00:16:06,860 --> 00:16:11,600
add the security guarantees to our DMA

388
00:16:09,110 --> 00:16:13,640
will be really challenging the main

389
00:16:11,600 --> 00:16:15,650
issues because there's also traders

390
00:16:13,640 --> 00:16:18,800
trade-off between the performance and

391
00:16:15,650 --> 00:16:21,560
security our DMA is attractive because

392
00:16:18,800 --> 00:16:24,050
of its good performance once we add the

393
00:16:21,560 --> 00:16:26,329
security guarantee we add overhead into

394
00:16:24,050 --> 00:16:28,219
the our DMA the argument performance

395
00:16:26,330 --> 00:16:30,440
would be a little bit slower where our

396
00:16:28,220 --> 00:16:33,890
DMS still be attractive to data center

397
00:16:30,440 --> 00:16:36,110
engineers when we have long a little bit

398
00:16:33,890 --> 00:16:37,819
lower performance this is what we need

399
00:16:36,110 --> 00:16:41,030
to think about and to decide the whole

400
00:16:37,820 --> 00:16:43,430
system carefully so thank you very much

401
00:16:41,030 --> 00:16:44,930
and if you are interested in Python code

402
00:16:43,430 --> 00:16:46,790
it will be open source on this github

403
00:16:44,930 --> 00:16:47,989
link so please check out what website

404
00:16:46,790 --> 00:16:49,819
and also our report if you are

405
00:16:47,990 --> 00:16:56,990
interested I'm happy to take the

406
00:16:49,820 --> 00:16:58,550
question now and thank you okay so we

407
00:16:56,990 --> 00:17:02,660
have time for two or three questions

408
00:16:58,550 --> 00:17:05,180
please Simpson University of Washington

409
00:17:02,660 --> 00:17:07,069
great work I'm so excited to see some

410
00:17:05,180 --> 00:17:10,339
attention to our DMA at a security

411
00:17:07,069 --> 00:17:11,750
conference I know that in some of the

412
00:17:10,339 --> 00:17:15,889
papers in the systems and networks

413
00:17:11,750 --> 00:17:18,709
community that they've said oh well if

414
00:17:15,890 --> 00:17:20,959
you know one client that has access to

415
00:17:18,709 --> 00:17:23,540
these servers are key in the data center

416
00:17:20,959 --> 00:17:26,209
gets compromised then game over we don't

417
00:17:23,540 --> 00:17:28,940
have to care about security do you have

418
00:17:26,209 --> 00:17:30,980
a so to execute your side-channel tax

419
00:17:28,940 --> 00:17:34,220
your attacker needs to have our key have

420
00:17:30,980 --> 00:17:35,740
access do you have good answer for the

421
00:17:34,220 --> 00:17:39,290
folks in the other communities who are

422
00:17:35,740 --> 00:17:43,640
saying oh if they get it at all then we

423
00:17:39,290 --> 00:17:45,590
don't have to care so I'm asking about

424
00:17:43,640 --> 00:17:47,660
should we use one out key for all the

425
00:17:45,590 --> 00:17:48,919
applications for all their users or

426
00:17:47,660 --> 00:17:52,340
separated there are cases between

427
00:17:48,920 --> 00:17:54,110
different users I guess another way of

428
00:17:52,340 --> 00:17:57,649
phrasing might be how did your attacker

429
00:17:54,110 --> 00:18:01,370
get an R key to be able to

430
00:17:57,650 --> 00:18:04,430
do the one-sided reads and writes to the

431
00:18:01,370 --> 00:18:07,699
server so in Alfred model because

432
00:18:04,430 --> 00:18:09,350
attacker is another client so it has all

433
00:18:07,700 --> 00:18:12,080
the information that regular clients

434
00:18:09,350 --> 00:18:14,750
have so if the if regular clients can

435
00:18:12,080 --> 00:18:16,639
access some page it has the are key

436
00:18:14,750 --> 00:18:20,600
therefore the attacker has the are key

437
00:18:16,640 --> 00:18:23,480
as other time so it's no extra privilege

438
00:18:20,600 --> 00:18:32,300
for the attackers did I answer your

439
00:18:23,480 --> 00:18:34,850
question i Joe from UC Irvine very

440
00:18:32,300 --> 00:18:38,570
interesting work so I want to ask about

441
00:18:34,850 --> 00:18:41,540
the other like scenarios for our DMA I

442
00:18:38,570 --> 00:18:43,970
recently heard that you can do the RTM

443
00:18:41,540 --> 00:18:45,830
way between GPUs so have you look into

444
00:18:43,970 --> 00:18:48,920
that perspective or do you see any

445
00:18:45,830 --> 00:18:51,290
security issues there so using our DME 2

446
00:18:48,920 --> 00:18:56,000
SS GPU I remember it's called GPU direct

447
00:18:51,290 --> 00:18:58,399
so it's under filter mvvm lnx so we

448
00:18:56,000 --> 00:19:01,310
didn't look into the GPU direct so far

449
00:18:58,400 --> 00:19:03,950
but we said once these issues would

450
00:19:01,310 --> 00:19:07,669
happen not only in regular DMA it may be

451
00:19:03,950 --> 00:19:09,620
also happen a other place because the PI

452
00:19:07,670 --> 00:19:11,240
design you need to catch the metadata

453
00:19:09,620 --> 00:19:13,219
inside you are dominick to handle all

454
00:19:11,240 --> 00:19:16,100
the things but we haven't looked into

455
00:19:13,220 --> 00:19:16,820
the GPU direct it will be interesting to

456
00:19:16,100 --> 00:19:22,490
look at it

457
00:19:16,820 --> 00:19:26,870
thank you ok the last one I had one at

458
00:19:22,490 --> 00:19:29,180
one other question which is so for when

459
00:19:26,870 --> 00:19:30,830
the metadata gets off the SRAM of the

460
00:19:29,180 --> 00:19:33,560
NIC and it's slower

461
00:19:30,830 --> 00:19:35,149
I assume the application developers try

462
00:19:33,560 --> 00:19:38,270
to avoid that since they're wanting to

463
00:19:35,150 --> 00:19:41,120
make the RDMA as fast as possible do you

464
00:19:38,270 --> 00:19:45,110
have any intuitions for in practice how

465
00:19:41,120 --> 00:19:49,399
often the important metadata gets pushed

466
00:19:45,110 --> 00:19:51,709
off the SRAM so I didn't have the number

467
00:19:49,400 --> 00:19:55,250
here but from one paper which is called

468
00:19:51,710 --> 00:19:57,710
form that's as I said through more

469
00:19:55,250 --> 00:20:00,670
memory it's mentioned they have a number

470
00:19:57,710 --> 00:20:04,220
to show how what is the frequency of

471
00:20:00,670 --> 00:20:06,530
metadata will be move out from evicted

472
00:20:04,220 --> 00:20:09,350
from the our DMA link so even in a

473
00:20:06,530 --> 00:20:10,760
regular SS not the attackers once the

474
00:20:09,350 --> 00:20:13,399
memory region sizes of

475
00:20:10,760 --> 00:20:16,070
larger than 16 megabyte and with a

476
00:20:13,400 --> 00:20:20,120
random SS within the 60 megabyte we can

477
00:20:16,070 --> 00:20:22,070
see the metadata is evicted so some

478
00:20:20,120 --> 00:20:25,909
numbers can be seen in that paper also

479
00:20:22,070 --> 00:20:27,649
in the light paper in SOS P okay I think

480
00:20:25,910 --> 00:20:32,540
it's time for us to enjoy the coffee

481
00:20:27,650 --> 00:20:35,440
break so please thank all the speakers

482
00:20:32,540 --> 00:20:35,440
for the great doors