Some more information has come out, and it looks like this is _not_ just an ASLR break - it appears that, at very least, it is possible to read arbitrary kernel memory: https://twitter.com/brainsmoke/status/948561799875502080 The PoC in that post is given an address with kernel-only page permissions (here, the address of the syscall table), and then uses the vulnerability to extract the value at that address (here, the first entry in the table - the address of the read syscall implementation) via a speculative execution timing side channel. On Tue, 02 Jan 2018 00:50:46 +0000, Adrian.Danis wrote:
Hi Corey,
It is definitely an interesting problem, although only occurs since Linux 'relies' on ASLR in the kernel for security due to running untrustworthy code in kernel mode. seL4 does not implement KASLR, as seL4 does not have the classes of bugs that ASLR attempts to mitigate the exploitability of. From that side, there is nothing for us to do.
Otherwise you are also correct, probing microarchitectural state to determine what another process is doing is a known and currently unsolvable[1] problem.
Adrian
[1] As far as is currently known and possible by the hardware ISA without truly prohibitive performance costs
On Mon 25-Dec-2017 10:37 AM, Corey Richardson wrote:
https://lwn.net/Articles/738975/
That's really painful, for Linux ;) I don't think seL4 is really impacted? I'm having a hard time thinking about what sensitive information could be disclosed by probing the kernel window. Maybe which memory regions caps being accessed by other concurrently running threads occupy? You could use that to make a covert channel, if the two threads trying to communicate are running in parallel. It seems really dubious that that could give you anything useful otherwise, and as the literature shows timing side channels are unavoidable on x86.
Thought it was interesting and worth sharing!