6 ms·

The second sentence of the article is: It arranges things such that this sensitive data is only ever in the clear in registers (never memory), and is s

The second sentence of the article is: It arranges things such that this sensitive data is only ever in the clear in registers (never memory), and is saved in an encrypted memory region called the secure stack on context switches

dmitrygr 7y ago
Not in their example. Data ends up in x0 and x1 and they don't talk about how they do this magic secure context switch. What stops the os from taking an irq just when they placed secret values into x0 and x1?? Where do they imagine x0 and x1's values will go when this irq is taken?
- CodeArtisan 7y ago
  > What stops the os from taking an irq From the article For data confidentiality, in addition to the call stack management described previously, Ginseng must also intercept all exceptions to save sensitive registers to the callstack before the exception can be handled by the OS. Ginseng intercepts exceptions using dynamic trapping. A NOP instruction is inserted at the beginning of the exception vector code in the kernel, and replaced by a call to the secure monitor at runtime when sensitive data enters registers. (Once the registers are clear of sensitive data, the NOP is restored). Once the OS serves the exception, control is handed back to the app. GService manages the return address to ensure we resume at the correct point in the sensitive function.
  - dmitrygr 7y ago
    Intercept every irq?!? Ouch, my performance! . Write to kernel code pages?!? Ouch, my cache! Oh, and my security!
    - nine_k 7y ago
      Interception only occurs when the sensitive data are in the registers. That is, rarely. And yes, you have to trust Ginseng more than you trust the OS, it's the whole point and an explicit initial premise.
  - olliej 7y ago
    The original commenters point is that the OS does not need to send an exception to the process before reading content — any interrupt (software or hardware) hits the kernel first. The kernel can then happily pull the content of any registers before switching the context back to the target app. Basically the threat model seems to be “malicious kernel”, but if the kernel is actually malicious then it can do whatever it wants before the target has an opportunity to “protect” itself
    - CodeArtisan 7y ago
      interrupt or exception, the handling mechanism remains the same: The CPU jumps to a handler routine by retrieving its address from a table. On Intel x86, Both interrupt and exception handlers are stored in the same table. From Intel x86 manual To aid in handling exceptions and interrupts, each architecturally defined exception and each interrupt condition requiring special handling by the processor is assigned a unique identification number, called a vector number. The processor uses the vector number assigned to an exception or interrupt as an index into the interrupt descriptor table (IDT). The table provides the entry point to an exception or interrupt handler (see Section 6.10, “Interrupt Descriptor Table (IDT)”). The allowable range for vector numbers is 0 to 255. Vector numbers in the range 0 through 31 are reserved by the Intel 64 and IA-32 architectures for architecture-defined exceptions and interrupts. Not all of the vector numbers in this range have a currently defined function. The unassigned vector numbers in this range are reserved. Do not use the reserved vector numbers. Vector numbers in the range 32 to 255 are designated as user-defined interrupts and are not reserved by the Intel 64 and IA-32 architecture. These interrupts are generally assigned to external I/O devices to enable those devices to send interrupts to the processor through one of the external hardware interrupt mechanisms (see Section 6.3, “Sources of Interrupts”). https://en.wikipedia.org/wiki/Interrupt_vector_table https://en.wikipedia.org/wiki/Interrupt_vector_table https://en.wikipedia.org/wiki/Interrupt_descriptor_table https://en.wikipedia.org/wiki/Interrupt_descriptor_table
      - olliej 7y ago
        The IVT is controlled by the OS, so a malicious kernel can force whatever IVT content it wants. 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. Again, if your attack model is a malicious kernel nothing you're doing in user mode is going to protect you. If you're using kernel APIs to install protections against that, you're still dealing with a malicious kernel that can ignore or wrap whatever you do. If you're trying to mitigate/protect against kernel bugs that's a different threat model, but the same general problems exist only by accident so are less likely to leak useful information.

dmitrygr 7y ago

Not in their example. Data ends up in x0 and x1 and they don't talk about how they do this magic secure context switch. What stops the os from taking an irq just when they placed secret values into x0 and x1?? Where do they imagine x0 and x1's values will go when this irq is taken?

CodeArtisan 7y ago
> What stops the os from taking an irq From the article For data confidentiality, in addition to the call stack management described previously, Ginseng must also intercept all exceptions to save sensitive registers to the callstack before the exception can be handled by the OS. Ginseng intercepts exceptions using dynamic trapping. A NOP instruction is inserted at the beginning of the exception vector code in the kernel, and replaced by a call to the secure monitor at runtime when sensitive data enters registers. (Once the registers are clear of sensitive data, the NOP is restored). Once the OS serves the exception, control is handed back to the app. GService manages the return address to ensure we resume at the correct point in the sensitive function.
- dmitrygr 7y ago
  Intercept every irq?!? Ouch, my performance! . Write to kernel code pages?!? Ouch, my cache! Oh, and my security!
  - nine_k 7y ago
    Interception only occurs when the sensitive data are in the registers. That is, rarely. And yes, you have to trust Ginseng more than you trust the OS, it's the whole point and an explicit initial premise.
- olliej 7y ago
  The original commenters point is that the OS does not need to send an exception to the process before reading content — any interrupt (software or hardware) hits the kernel first. The kernel can then happily pull the content of any registers before switching the context back to the target app. Basically the threat model seems to be “malicious kernel”, but if the kernel is actually malicious then it can do whatever it wants before the target has an opportunity to “protect” itself
  - CodeArtisan 7y ago
    interrupt or exception, the handling mechanism remains the same: The CPU jumps to a handler routine by retrieving its address from a table. On Intel x86, Both interrupt and exception handlers are stored in the same table. From Intel x86 manual To aid in handling exceptions and interrupts, each architecturally defined exception and each interrupt condition requiring special handling by the processor is assigned a unique identification number, called a vector number. The processor uses the vector number assigned to an exception or interrupt as an index into the interrupt descriptor table (IDT). The table provides the entry point to an exception or interrupt handler (see Section 6.10, “Interrupt Descriptor Table (IDT)”). The allowable range for vector numbers is 0 to 255. Vector numbers in the range 0 through 31 are reserved by the Intel 64 and IA-32 architectures for architecture-defined exceptions and interrupts. Not all of the vector numbers in this range have a currently defined function. The unassigned vector numbers in this range are reserved. Do not use the reserved vector numbers. Vector numbers in the range 32 to 255 are designated as user-defined interrupts and are not reserved by the Intel 64 and IA-32 architecture. These interrupts are generally assigned to external I/O devices to enable those devices to send interrupts to the processor through one of the external hardware interrupt mechanisms (see Section 6.3, “Sources of Interrupts”). https://en.wikipedia.org/wiki/Interrupt_vector_table https://en.wikipedia.org/wiki/Interrupt_vector_table https://en.wikipedia.org/wiki/Interrupt_descriptor_table https://en.wikipedia.org/wiki/Interrupt_descriptor_table
    - olliej 7y ago
      The IVT is controlled by the OS, so a malicious kernel can force whatever IVT content it wants. 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. Again, if your attack model is a malicious kernel nothing you're doing in user mode is going to protect you. If you're using kernel APIs to install protections against that, you're still dealing with a malicious kernel that can ignore or wrap whatever you do. If you're trying to mitigate/protect against kernel bugs that's a different threat model, but the same general problems exist only by accident so are less likely to leak useful information.