Hacker News new | past | comments | ask | show | jobs | submit login

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.

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.


> 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?

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.

What prevents the data being read before the memset is executed?

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.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact