4 ms·

According to their blog post[1], there is little you can do against this. Running different applications on different cpus help against them reading each other’

by spockz 7y ago

According to their blog post[1], there is little you can do against this. Running different applications on different cpus help against them reading each other’s data but an rogue process can still read data from the “super ordinated kernel” or hypervisor.

rurban 7y ago
Of course you can fix it. I fixed it in Dec 2018 for most such attacks in my safelibc memset_s implementation, but nobody wanted to use it, because securely purging the buffers with secrets via mfence was deemed to slow. So everybody can read your secrets via sidechannel attacks. These tiny MDS buffers need to be purged with verw or l1d_flush followed by an lfence. This needs to be added to memset and memset_s variants. This is much faster. But it will not happen, libc maintainers notoriously don't care, even crypto maintainers not. Only Linux does. https://software.intel.com/security-software-guidance/software-guidance/microarchitectural-data-sampling https://software.intel.com/security-software-guidance/softwa...
- tux1968 7y ago
  > This is much faster. Hi. Am trying to understand what you meant here. That both "verw" or "l1d_flush followed by an lfence" are faster than "mfence" which you implemented in safelibc? If so, why didn't you use these faster options yourself? My understanding was that these faster options needed to be handled at the hypervisor/kernel level, rather than in libc. If so, how is the attitude of glibc maintainers relevant?
  - rurban 7y ago
    verw and l1d_fence have no costs. lfence is a bit costly, mfence is basically an lfence + sfence. it flushes both caches, load and store. safe libs need to do the right thing, not the fast thing. esp. crypto. The attitude of libc and crypto maintainers is that you cannot trust them with security. all the memzero's are insecure. besides being overly complicated and slow. Linux is a bit better, but there are still estimated 20.000 security relevant bugs.
- gpderetta 7y ago
  What prevents the data being read before the memset is executed?
  - rurban 7y ago
    Nothing but the window of opportunity. A secure lib will zero secrets as soon as they are not needed anymore. On the fly attacks are always possible. But when you securely cleanup, the attackers has less time to extract it. the usual sidechannel attacks leak the secrets only bit by bit and need some time.
    - gpderetta 7y ago
      but mfence itself also only close a small window of opportunity on the same thread between the zeros being written and the store buffer being flushed.

by spockz 7y ago

rurban 7y ago

Of course you can fix it. I fixed it in Dec 2018 for most such attacks in my safelibc memset_s implementation, but nobody wanted to use it, because securely purging the buffers with secrets via mfence was deemed to slow. So everybody can read your secrets via sidechannel attacks. These tiny MDS buffers need to be purged with verw or l1d_flush followed by an lfence. This needs to be added to memset and memset_s variants. This is much faster. But it will not happen, libc maintainers notoriously don't care, even crypto maintainers not. Only Linux does. https://software.intel.com/security-software-guidance/software-guidance/microarchitectural-data-sampling https://software.intel.com/security-software-guidance/softwa...

tux1968 7y ago
> This is much faster. Hi. Am trying to understand what you meant here. That both "verw" or "l1d_flush followed by an lfence" are faster than "mfence" which you implemented in safelibc? If so, why didn't you use these faster options yourself? My understanding was that these faster options needed to be handled at the hypervisor/kernel level, rather than in libc. If so, how is the attitude of glibc maintainers relevant?
- rurban 7y ago
  verw and l1d_fence have no costs. lfence is a bit costly, mfence is basically an lfence + sfence. it flushes both caches, load and store. safe libs need to do the right thing, not the fast thing. esp. crypto. The attitude of libc and crypto maintainers is that you cannot trust them with security. all the memzero's are insecure. besides being overly complicated and slow. Linux is a bit better, but there are still estimated 20.000 security relevant bugs.
gpderetta 7y ago
What prevents the data being read before the memset is executed?
- rurban 7y ago
  Nothing but the window of opportunity. A secure lib will zero secrets as soon as they are not needed anymore. On the fly attacks are always possible. But when you securely cleanup, the attackers has less time to extract it. the usual sidechannel attacks leak the secrets only bit by bit and need some time.
  - gpderetta 7y ago
    but mfence itself also only close a small window of opportunity on the same thread between the zeros being written and the store buffer being flushed.