Technology
This is the official technology community of Lemmy.ml for all news related to creation and use of technology, and to facilitate civil, meaningful discussion around it.
Ask in DM before posting product reviews or ads. All such posts otherwise are subject to removal.
Rules:
1: All Lemmy rules apply
2: Do not post low effort posts
3: NEVER post naziped*gore stuff
4: Always post article URLs or their archived version URLs as sources, NOT screenshots. Help the blind users.
5: personal rants of Big Tech CEOs like Elon Musk are unwelcome (does not include posts about their companies affecting wide range of people)
6: no advertisement posts unless verified as legitimate and non-exploitative/non-consumerist
7: crypto related posts, unless essential, are disallowed
view the rest of the comments
I wish it were that easy, there's a lot of shared architecture in CPU design. So maybe there's cache lines that are shared, those have to be disabled.
Architecturally, maybe memory tagging for cash lines that in addition to looking at the TLB and physical addresses also looks at memory spaces. So if you're addressing something that's in the cache Even for another complete processor, you have to take the full hit going out to main memory.
But even then it's not perfect, because if you're invalidating the cache of another core there is going to be some memory penalty, probably infotesimal compared to going to main memory, but it might be measurable. I'm almost certain it would be measurable. So still a side channel attack
One mitigation that does come to mind, is running each program in a virtual machine, that way it's guaranteed to have completely different physical address space. This is really heavy-handed, and I have seen some papers about the side channel attacks getting leaked information from co guest VMs in AWS. But it certainly reduces the risk surface