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

Your description implies the existence of another mitigation. Namely: When you enter untrusted code you mprotect() all sensitive areas and remove PROT_READ. When exiting the untrusted code you add the permissions back.

Are you sure that works? As I understand it, the issue with Spectre is the branch predictor, not the memory mappings. The reason why process isolation works is that branch prediction gets reset on context switch (or that this will happen on newer generations of hardware in the future).

Mprotect should in fact work, but it is likely more expensive than actual process separation. Resurrecting segments or using virtualization hardware in userspace (see libdune) might be workable solutions.

The issue is that speculation allows bypassing software enforced bound checking, but, discounting meltdown, the hope is that hardware can still enforced them.

mprotect does not issue a memory barrier (mfence), so whilst theoretically protected it is practically delayed and can still be read from the cache via sidechannels. Same issue with the unsafe bzero call. A compiler barrier is not safe enough to delete secrets.

Mprotect should work because even under speculation the CPU shouldn't allow a read to an invalid address to be executed. Meltdown shows that some CPUs speculate even this sort of checks, but it seems that it is not inherently required for an high performance implementation.

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