Apple designed the iOS platform with security at its core. When we set out to create the best possible mobile platform, we drew from decades of experience to build an entirely new architecture. We thought about the security hazards of the desktop environment, and established a new approach to security in the design of iOS. We developed and incorporated innovative features that tighten mobile security and protect the entire system by default. As a result, iOS is a major leap forward in security for mobile devices.
This document provides details about how security technology and features areimplemented within the iOS platform. It will also help organizations combine iOSplatform security technology and features with their own policies and procedures to meet their specific security needs.
Some light reading over the weekend.
But not sure how well publicized. It seems the secure enclave runs a “customized version of the L4 microkernel”.
Microkernel may represent an interesting approach to lessening the impact of Spectre and Meltdown: https://sourceforge.net/p/genode/mailman/message/36178974/
Edited 2018-01-14 13:45 UTC
Depends on what you mean by impact. The performance impact will be greater as there are more context switches having to use the (hack) Spectre mitigation and communication overheads will increase as some mapping tricks can’t be used.
Don’t see how Spectre would be helped by microkernels as they are optimized to keep out of the way – the attacker is more likely to be able to influence the victim and the reduced kernel cache activity would reduce timing noise making the hidden channel easier to construct.
Example:
My current design maps all memory kernel visible in a shared address space where every user process have a slice of memory. This means that currently Meltdown can read any memory in the system.
The current design uses a copying IPC model where the kernel copies data between two processes without needing to do any type of context switch and then switches to the receiving process: 1 context switch in total.
To reduce the risks from Meltdown there will have to be two context switches: the sending process calls the kernel that switches to a private view, copies the data and then switches to the receiver. The private view is essentially what is now mapped as kernel-only memory in each process space so it’s an easy change.
At the moment I’m thinking about adding a piece of memory that is mapped into each process space as kernel only and allowing small messages to be copied from the sender into that small buffer and then copied from that kernel buffer to the receiver after switching to that process context. That would mean an extra copy and more complex code but remove one context switch for simple, small messages.
Megol,
Why not just allocate a slice of memory for those processes to share between themselves? If no one else has those pages mapped (including your kernel), then in addition to being “zero copy”, it’s also not vulnerable to meltdown.
That is my theoretical approach to add memory protection to an AmigaOS-like system (microkernel/exokernel) without compromising speed too much.
IPC via sending pointers to the relevant data. This data needs to be in a shared space.
After such a space is established between two (or more) processes the message passing can also take place in this space without involvement of the kernel-message-queue – if it makes sense (eg. a library-call, where the library is just another process).
In that case there would be no need for Meltdown, since the all kernel memory is already visible? Am I wrong?
cybergorf,
With x86 memory paging, pages can be mapped, yet have a privilege bit to deny access to userspace processes. This means simply having the memory in the page mapping doesn’t imply access to those pages.
In case it’s not already clear, the reason not to unmap pages is because it simplifies kernel syscalls and reduces the overhead of kernel context switching, the permission bits are supposed to be honored by the CPU to block unauthorized access. The problem stems from intel’s implementation, even when the page table declares page protected, the speculative code execution engine is extremely aggressive and completely ignores the privilege bit while speculating. The meltdown attack attacks this flaw of intel processors, while AMD’s implementation doesn’t have this problem.
It seems pretty obvious now, but future intel processors will have to strictly abide by the memory permission bits in the speculative code paths. Until then the workaround for meltdown is obviously to unmap the kernel from userspace, albeit at a great performance cost for every syscall.
Spectre is a different kind of attack, which doesn’t depend on bugs per say, but rather exploiting the nature of speculative execution in general. The vendors have been focusing on the worst form of the vulnerability right now that let attackers read an entire byte/word at a time, but I’m convinced there’s another form of the attack, one that hasn’t yet been published, that will extract bits using much more common branch instructions. It’s not really restricted to kernels either, but any code executing speculatively under the right circumstances could cause a leak, even through javascript.
IMHO it’s going to be extremely difficult for us to confidently solve this one in the long term short of abandoning long speculation code paths all together (or designing the CPU to follow all branches so it doesn’t leak information about which branch it took, however the energy/transistor costs of doing this are exponential).
Edited 2018-01-16 18:30 UTC
Thank you Alfman for this more detailed insight.
This fits my rough understanding of the Meltdown attack on Windows and Linux.
here I was referring to Megols implementation:
“My current design maps all memory kernel visible in a shared address space”
so I am not sure what he exactly means by “visible” in this case.
cybergorf,
Oh, I can’t speak for Megol’s OS naturally. His post suggests that full physical memory is mapped into his kernel. So presumably the page table protection bits are used to keep processes isolated. But with a meltdown style attack the full memory is compromised including user processes, which was Megol’s observation.
Ahh – this makes more sense.
I was misreading it as “kernel-memory visible” iinstead of “(all) memory (is) kernel-visible” 🙂
someone,
So, assuming it’s true that nothing of secret importance is held in kernel memory space (this would need to be justified to be sure), then there’s very little risk from the meltdown attack.
In practice, I’d feel uncomfortable giving all processes readonly access to the kernel, but for the sake of argument, if we could give all processes readonly access to the kernel (which is what the meltdown attack achieves indirectly) without compromising security, then arguably the meltdown attack is irrelevant.
This logic could never apply to a monolithic-kernel, due to everything being handled in kernel spaces, things like disk caches and network buffers would be vulnerable. But assuming 100% of secure information gets passed directly from one userspace program to another, then meltdown is effectively mitigated.
Edited 2018-01-14 20:27 UTC