ZombieLoad: Cross Privilege-Boundary Data Leakage on Intel CPUs • Hacker News Board

Re: ZombieLoad: Cross Privilege-Boundary Data Leakage on Intel CPUs

#331

Post by rurban » Fri, May 17, 2019, 11:50 AM UTC

tux1968 wrote: post #217

rurban wrote: post #71

Earlier quoted context omitted.

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 varian…

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

Re: ZombieLoad: Cross Privilege-Boundary Data Leakage on Intel CPUs

#332

Post by rurban » Fri, May 17, 2019, 11:53 AM UTC

gpderetta wrote: post #222

rurban wrote: post #71

Earlier quoted context omitted.

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 varian…

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.

Re: ZombieLoad: Cross Privilege-Boundary Data Leakage on Intel CPUs

#333

Post by pas » Fri, May 17, 2019, 10:10 PM UTC

effie wrote: post #316

rini17 wrote: post #134

Earlier quoted context omitted.

The industry will probably get dragged, kicking and screaming, into using tagged pointers. CPU could then use the information to put safe lid on speculative execution. And it will be tough as no compiler supports it, moreover C/C++ are architected from the beginnign to not bother with runtime information about object types/sizes.

That sounds interesting. Is there some analysis out there which shows tagged pointers to be superior to the status quo?

Ultimately, if we do transparent per process memory encryption, then we can let the CPU do all the speculation it wants, but the result will be gibberish. And it's a lot easier to do a simple key switch than doing a full TLB flush. Of course, it probably doesn't do much against/for the timing attacks (side channels).

Re: ZombieLoad: Cross Privilege-Boundary Data Leakage on Intel CPUs

#334

Post by gpderetta » Tue, May 21, 2019, 12:34 PM UTC

rurban wrote: post #332

gpderetta wrote: post #222

Earlier quoted context omitted.

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.

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.

Re: ZombieLoad: Cross Privilege-Boundary Data Leakage on Intel CPUs

#335

Post by ct520 » Wed, May 22, 2019, 5:59 AM UTC

cfallin wrote: post #268

ct520 wrote: post #265

Earlier quoted context omitted.

Your not, but the gentlemen your replying to is. Bet you can’t guess where and what he worked on?

Yup, I worked for a bit at Intel, but I don't speak for them, I wasn't involved in any of the designs under discussion, and everything I'm saying here is public knowledge in the computer architecture community. I figured that the perspective from the academic comparch world might be interesting.

Hehehehe I love it! Thank you much. I was being a bit rousing/ambiguous as your commentary caught my attention and was a bit excited when I checked out your background.

Re: ZombieLoad: Cross Privilege-Boundary Data Leakage on Intel CPUs

#336

Post by ct520 » Wed, May 22, 2019, 6:05 AM UTC

dang wrote: post #276

ct520 wrote: post #265

Earlier quoted context omitted.

Your not, but the gentlemen your replying to is. Bet you can’t guess where and what he worked on?

Not sure how to read this, but if you meant it as a personal attack that's totally not ok here. https://news.ycombinator.com/newsguidelines.html

Not sure how to read this either, but as a moderator if you strive to warn people on ambiguity you can’t discern I can assure you no harm intended per the rules cited

Re: ZombieLoad: Cross Privilege-Boundary Data Leakage on Intel CPUs

#337

Post by fluffything » Mon, May 27, 2019, 9:32 AM UTC

fdfdde3 wrote: post #306

OpenBSD was right and disabled HT for Intel CPUs in June 2018 ago due to concerns of more such CPU bugs coming up. There we go ... https://news.ycombinator.com/item?id=17350278

This. I remember people laughing at this decision back then, and flaming on OpenBSD policies to handling security vulnerabilities, to the point where they aren't informed anymore. Yet OpenBSD is the only major OS taking these issues seriously instead of believing whatever Intel marketing department yells every other day.