5 ms·

> But it's still not relevant, as the kernel can arbitrarily halt execution of any process at any point, and therefore can read the content of all registers whe

> But it's still not relevant, as the kernel can arbitrarily halt execution of any process at any point, and therefore can read the content of all registers whenever it wants them. Not if the kernel can't handle interruptions? The only way for the kernel to "steal control" from the process is through an interruption (software or hardware). If all interrupts are first handled by the secure monitor, which handles saving the registers securely, then it's OK.

dmitrygr 8y ago
that is also complete nonsense. I could have a whole other core in the system (nowadays computers have more than one), which can replace the vectors back with the original ones and not the "secured" ones. In fact, if I was a malicious kernel, I would do precisely that This whole idea will not work unless your hypervisor is a real complete hypervisor. This attempt at a halfway-hypervisor-lite is doomed to failure for this and many other reasons.
- CodeArtisan 8y ago
  Ginseng modifies the kernel and protects sensitive parts by using the CPU's trusted execution environment[1] which has a higher privilege level than the kernel. From the paper We now describe Ginseng’s runtime protection against such accesses. The runtime protection heavily relies on GService, a passive, app-independent piece of software in the Secure world. GService ensures the code integrity, data confidentiality and control-flow integrity (CFI). It does so only for sensitive functions to minimize overhead. It also modifies the kernel at three points, when booting, when modifying the kernel page table, and when handling an exception. Since we do not trust the OS, the kernel may overwrite the modifications. However, when any of these modifications is disabled, the kernel will infinitely trigger data aborts trying to modify readonly memory, thus ensuring sensitive data are always safe. I would have look at the source code to find more but the github repository has been deleted. [1] https://en.wikipedia.org/wiki/Trusted_execution_environment https://en.wikipedia.org/wiki/Trusted_execution_environment https://en.wikipedia.org/wiki/ARM_architecture#Security_extensions https://en.wikipedia.org/wiki/ARM_architecture#Security_exte... https://en.wikipedia.org/wiki/Software_Guard_Extensions https://en.wikipedia.org/wiki/Software_Guard_Extensions
  - dmitrygr 8y ago
    No amount of modifications in the kernel will make this safe. What if I load a module that fixes my IRQ handlers? Or do they forbid modules? What if I find an exploit in the kernel? Or did they somehow make a 100% exploit-free kernel? This sort of thing is exactly why TEE exists. It cannot be done half in userspace half in TEE
    - CodeArtisan 8y ago
      From what i have understood, Ginseng sets sensitive memory regions to only be accessed by the TEE then unmap these regions from the kernel memory space. If your kernel module try to read/write/map these regions, a memory violation exception is raised and then handled by the TEE.
      - dmitrygr 8y ago
        That literally means that every time you take an interrupt, you also take an extra fault into the hypervisor (since your CPU cannot read the vector, because it has been protected). In that case, forget any ideas of speed. The whole point of hardware assisted virtualization was to prevent that situation. These guys suggest going decades back in terms of performance. No thanks.
olliej 8y ago
Userspace obviously isn't directly impact the "secure monitor", e.g. hypervisor, so instead what you're saying is that we have two operating systems: 1. the os in charge of the hypervisor 2. the os in charge of the virtualised system. We're saying that we don't trust 2. so we're going to get the kernel from 1. to intercept interrupts. But that means we already have a trustworthy kernel. The one running the hypervisor, so why aren't we just using that?
- vertex-four 8y ago
  Because one might be small and formally proveable and the other might be Linux.

dmitrygr 8y ago

that is also complete nonsense. I could have a whole other core in the system (nowadays computers have more than one), which can replace the vectors back with the original ones and not the "secured" ones. In fact, if I was a malicious kernel, I would do precisely that This whole idea will not work unless your hypervisor is a real complete hypervisor. This attempt at a halfway-hypervisor-lite is doomed to failure for this and many other reasons.

CodeArtisan 8y ago
Ginseng modifies the kernel and protects sensitive parts by using the CPU's trusted execution environment[1] which has a higher privilege level than the kernel. From the paper We now describe Ginseng’s runtime protection against such accesses. The runtime protection heavily relies on GService, a passive, app-independent piece of software in the Secure world. GService ensures the code integrity, data confidentiality and control-flow integrity (CFI). It does so only for sensitive functions to minimize overhead. It also modifies the kernel at three points, when booting, when modifying the kernel page table, and when handling an exception. Since we do not trust the OS, the kernel may overwrite the modifications. However, when any of these modifications is disabled, the kernel will infinitely trigger data aborts trying to modify readonly memory, thus ensuring sensitive data are always safe. I would have look at the source code to find more but the github repository has been deleted. [1] https://en.wikipedia.org/wiki/Trusted_execution_environment https://en.wikipedia.org/wiki/Trusted_execution_environment https://en.wikipedia.org/wiki/ARM_architecture#Security_extensions https://en.wikipedia.org/wiki/ARM_architecture#Security_exte... https://en.wikipedia.org/wiki/Software_Guard_Extensions https://en.wikipedia.org/wiki/Software_Guard_Extensions
- dmitrygr 8y ago
  No amount of modifications in the kernel will make this safe. What if I load a module that fixes my IRQ handlers? Or do they forbid modules? What if I find an exploit in the kernel? Or did they somehow make a 100% exploit-free kernel? This sort of thing is exactly why TEE exists. It cannot be done half in userspace half in TEE
  - CodeArtisan 8y ago
    From what i have understood, Ginseng sets sensitive memory regions to only be accessed by the TEE then unmap these regions from the kernel memory space. If your kernel module try to read/write/map these regions, a memory violation exception is raised and then handled by the TEE.
    - dmitrygr 8y ago
      That literally means that every time you take an interrupt, you also take an extra fault into the hypervisor (since your CPU cannot read the vector, because it has been protected). In that case, forget any ideas of speed. The whole point of hardware assisted virtualization was to prevent that situation. These guys suggest going decades back in terms of performance. No thanks.

olliej 8y ago

Userspace obviously isn't directly impact the "secure monitor", e.g. hypervisor, so instead what you're saying is that we have two operating systems: 1. the os in charge of the hypervisor 2. the os in charge of the virtualised system. We're saying that we don't trust 2. so we're going to get the kernel from 1. to intercept interrupts. But that means we already have a trustworthy kernel. The one running the hypervisor, so why aren't we just using that?

vertex-four 8y ago
Because one might be small and formally proveable and the other might be Linux.