Hacker News Reader

Comment by e12e | Hacker News Reader

Differently is right. Every buffer over/underrun can now potentially overwrite your "persisted" data - now we're all writing file/storage/db systems .... ;-)

It'll be wonderful if we actually can get some simplifications in our byzantine architectures, although - I wonder if it doesn't all boil down to our "RAM" (fastest storage) becoming "smarter" - as CPUs manage the three levels of cache - and we "only" loose the "slow disk/ssd" on the far end. CPU cache becomes the new RAM, and cache management microcode becomes our new memory allocators....?

View on HN

A buffer overrun can't overwrite random memory that isn't mapped into your process. We solved this issue with virtual memory like 35 years ago.

So you're saying there will be a web assembly version in a few years that will claim to be a huge advancement?

Yeah, just like that time microsoft invented lambda functions

Correct, but in practice memory has permissions on a page level and most pages today are 4K. So a page containing a buffer is also likely to contain other data as well. Unless you are going to isolate each buffer by placing it in its own page.

That doesn't make sense to me. So an OS will assign a 4K page of memory to multiple processes, with some granularity that each process "should" only be able to write/read some of it?

Kind of... We solved this issue like 35 years ago and then broke it again in the last decade. First CPU timing attacks allowed peeking at secret key generation in shared environments. Then we got rowhammer which ignores your mapping. Now we got memory access timing attacks which allow probing kernel memory mapping and bypassing ASLR.

While you can't easily write into other processes anymore, the barrier is more of a suggestion again.

"ignores your mapping" is pretty generous considering rowhammer doesn't work on ECC RAM.

From https://en.m.wikipedia.org/wiki/Row_hammer

> Tests show that simple ECC solutions, providing single-error correction and double-error detection (SECDED) capabilities, are not able to correct or detect all observed disturbance errors because some of them include more than two flipped bits per memory word

But anyway - even if ECC was perfect at preventing the issue, lots of hosts do not use ECC. That includes practically every desktop.

So your 1tb linked-list/hashtable that holds all the mail servers email, and is conveniently persisted because ram is the disk, and everything on the heap is magically permanent - isn't at risk?

> Differently is right. Every buffer over/underrun can now potentially overwrite your "persisted" data - now we're all writing file/storage/db systems .... ;-)

Sounds like a great use-case for lmdb :)

Reply on news.ycombinator.com