"It allows a rogue application or user to read and write physical memory, and execute arbitrary code with kernel (supervisor) and machine-mode privileges, allowing them to take over the device entirely.[…]
The vulnerability lies in faulty instructions in the C910’s vector extension implementation […]. The problem is that some of these instructions operate on physical memory […].
And as the instructions are baked into the silicon, they cannot be fixed with a microcode or software update. To mitigate the issue, the vector extension must be disabled. […]
Yeah, so I’ve been looking at this. If I want to ensure a Meles is not vulnerable, the only thing I do is configure my kernel with CONFIG_RISCV_ISA_V=n or equivalent?
Can anyone help me understand why this works? Looking at the kernel’s documentation on that option, it seems that it configures the kernel itself not to use those instructions, but why does that stop programs in userspace from doing so? Does it normally involve a syscall to use those instructions?
Luckily, the vulnerable instructions lie in the vector extension, which can be disabled by the operating system. This fully mitigates GhostWrite, but also fully disables vector instructions on the CPU. Linux can be compiled with CONFIG_VECTOR=n or CONFIG_RISCV_ISA_V=n depending on the source tree, which disables all vector-related code paths and thereby keeps the vector extension disabled.
Right, which is what I said… but my question is how/why that mitigates the vulnerability. It keeps the kernel from using those instructions, but why can’t userspace use them once booted?
I suppose there must be some kind of initialization or enablement step the kernel takes to make those instructions available later to userspace, but I would like to know whether that’s true and in more detail.