<azonenberg_work>
pie_: look up some of the work sophia d'antoine did a year or two ago at usenix WOOT
<azonenberg_work>
on cross-VM data leakage using OoO side channels
<azonenberg_work>
I think her explanation of how the channel works is not 100% accurate, but the channel undeniably exists
<azonenberg_work>
basically by heavily loading certain resources in one VM you can cause instruction reordering changes in a different VM
<pie_>
yeah im seeing so much stuff on cache based side channels latwly heh
<pie_>
*letely
<pie_>
*lately
<pie_>
huh interesting.
<azonenberg_work>
I'm not convinced it's a true silicon side channel vs a hypervisor one, or possibly something based on memory operation reordering in the northbridge vs instruction reordering in the CPU proper
<azonenberg_work>
But the channel exists and i'm not disputing that
<pie_>
this "privileged silicon sidechannel" (my phrasing, just asspulled it) concept sounds rather interesting
<lain>
there was some articles lately about uhhh
<lain>
something about overclocking arm chips to cause trustzone to derp and flip a byte that allows privesc
<lain>
which sounded specious, so I checked the paper, and sure enough they say some shit like "All that is required is a malicious kernel driver"
<lain>
yeah ok last I checked that's not an easy thing to just slip into a mobile app :P
<lain>
am I missing something or is that less of a threat than the paper makes it out to be? they act like it's a huge silicon bug that kernel drivers can poke performance registers and cause an overclock...
<azonenberg_work>
Lool
<azonenberg_work>
well
<azonenberg_work>
what i see as interesting is, the kernel is not supposed to be able to see/modify trustzone state
<azonenberg_work>
So if the kernel can OC the chip to the point that TZ malfunctions, that is an issue for privesc/jailbreak type applications
<azonenberg_work>
It's not going to lead to RCE though
digshadow has left ##openfpga [##openfpga]
digshadow has joined ##openfpga
gnufan has left ##openfpga [##openfpga]
soylentyellow has quit [Ping timeout: 246 seconds]
<lain>
yeah
<lain>
I didn't read the whole paper to see how reliable their OC -> TZ privesc was
<lain>
I'm guessing "not very" but it'd be interesting if they managed to make it reliable somehow
<lain>
the articles suggested that they were using /userland/ code to OC, which would be disastrous if true, but the paper says it's a kernel driver
soylentyellow has joined ##openfpga
enriq has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
azonenberg_work has quit [Ping timeout: 240 seconds]
_whitelogger has joined ##openfpga
m_t has quit [Quit: Leaving]
<pie_>
ugh anyone know how to make freebsd-update go faster
<awygle>
I once built a server to do binary updates of freebsd hosts for exactly that reason
<mtp>
freebsd-update already does binary patching iirc
<awygle>
Huh, so it does.
<awygle>
Been a while. I think we were building world ourselves for some reason.
<awygle>
I may have actually built a local freebsd-update server, come to think
<awygle>
-shrug-
<mtp>
i like that that's supported tbh
<mtp>
in case you do patch your world
<mtp>
anyway there isn't really a way to make it go faster short of throwing faster resources at the bottleneck :P
<awygle>
I feel like the word "world" is really dramatic for some reason lol