Post 1307561 by dizzy@mastodon.social
 (DIR) More posts by dizzy@mastodon.social
 (DIR) Post #1306421 by kurisu@iscute.moe
       2018-11-18T21:34:59.196035Z
       
       0 likes, 0 repeats
       
       lol i finally got around to reading what L1TF actually was and... lmao u fucked up intel
       
 (DIR) Post #1307450 by dizzy@mastodon.social
       2018-11-18T22:14:26Z
       
       1 likes, 0 repeats
       
       @kurisu twice as fun with SGX
       
 (DIR) Post #1307456 by kurisu@iscute.moe
       2018-11-18T22:14:45.721699Z
       
       0 likes, 0 repeats
       
       @dizzy >using sgx
       
 (DIR) Post #1307506 by dizzy@mastodon.social
       2018-11-18T22:17:28Z
       
       0 likes, 0 repeats
       
       @kurisu enjoy your flushing everything, lmao
       
 (DIR) Post #1307507 by kurisu@iscute.moe
       2018-11-18T22:17:55.648904Z
       
       0 likes, 0 repeats
       
       @dizzy hmm?
       
 (DIR) Post #1307535 by dizzy@mastodon.social
       2018-11-18T22:17:59Z
       
       0 likes, 0 repeats
       
       @kurisu tfw no enclaveID tags uwu
       
 (DIR) Post #1307536 by kurisu@iscute.moe
       2018-11-18T22:19:42.255778Z
       
       0 likes, 0 repeats
       
       @dizzy i think i'm missing the point of this thread. I realise L1TF lets you target SGX but does some obscure usage of SGX somehow provide mitigations as well?
       
 (DIR) Post #1307561 by dizzy@mastodon.social
       2018-11-18T22:20:46Z
       
       1 likes, 0 repeats
       
       @kurisu they mitigate by flushing the entire L1$ for each enclave transition
       
 (DIR) Post #1307596 by kurisu@iscute.moe
       2018-11-18T22:22:42.263840Z
       
       0 likes, 0 repeats
       
       @dizzy still need to disable SMT for that to work though right, since it can't flush the whole other core's pipeline and registers
       
 (DIR) Post #1307609 by dizzy@mastodon.social
       2018-11-18T22:22:20Z
       
       1 likes, 0 repeats
       
       @kurisu sgx amplifies L1TF by forwarding actual cache line data, without sgx you don’t see the data, instead you can infer something by side channel
       
 (DIR) Post #1307613 by kurisu@iscute.moe
       2018-11-18T22:23:22.348072Z
       
       0 likes, 0 repeats
       
       @dizzy oh, damn wtf
       
 (DIR) Post #1307629 by dizzy@mastodon.social
       2018-11-18T22:23:57Z
       
       1 likes, 0 repeats
       
       @kurisu presumably it’s because cache lines aren’t tagged with enclaveID
       
 (DIR) Post #1307714 by dizzy@mastodon.social
       2018-11-18T22:28:20Z
       
       0 likes, 0 repeats
       
       @kurisu basically all spectre, meltdown and l1tf are about leaking micro architectural state of one context into another because micro architecture is sharing everything. ContextID tag on branch predictor and maybe on every piece of caches could fix it? Idk
       
 (DIR) Post #1307715 by kurisu@iscute.moe
       2018-11-18T22:29:21.853755Z
       
       0 likes, 0 repeats
       
       @dizzy ideally mill would usher in an age of simpler yet high IPC architectures which were naturally immune
       
 (DIR) Post #1307730 by dizzy@mastodon.social
       2018-11-18T22:30:17Z
       
       0 likes, 0 repeats
       
       @kurisu >millarrrgh ^^;
       
 (DIR) Post #1307731 by kurisu@iscute.moe
       2018-11-18T22:30:29.995350Z
       
       0 likes, 0 repeats
       
       @dizzy hmm?
       
 (DIR) Post #1307772 by dizzy@mastodon.social
       2018-11-18T22:31:14Z
       
       0 likes, 0 repeats
       
       @kurisu whenever someone mentions Mill I enter the troll alert mode ^^
       
 (DIR) Post #1307773 by kurisu@iscute.moe
       2018-11-18T22:33:06.784984Z
       
       0 likes, 0 repeats
       
       @dizzy dunno why, it's a nice microarchitecture. Obviously it's yet to be proven and getting it to market is a whole other story but I like to believe.
       
 (DIR) Post #1307821 by dizzy@mastodon.social
       2018-11-18T22:32:11Z
       
       0 likes, 0 repeats
       
       @kurisu but honestly I know nothing about the Mill ;;
       
 (DIR) Post #1307822 by kurisu@iscute.moe
       2018-11-18T22:36:07.719056Z
       
       0 likes, 0 repeats
       
       @dizzy basically there's a large series of long lectures on the mill's microarchitecture and it's very novel and makes grand claims - and the architecture seems to be novel enough to follow through.It's very interesting if you have the time, but it's difficult to really get a sense of the mill in a short period of time. https://millcomputing.com/docs/
       
 (DIR) Post #1307850 by dizzy@mastodon.social
       2018-11-18T22:37:00Z
       
       0 likes, 0 repeats
       
       @kurisu unlikely it’s going into any production soon, tho. uwuArch designers will likely employ a bunch of tags, add hardware compartment and cache partitioning and will get away with it, tbh
       
 (DIR) Post #1307851 by kurisu@iscute.moe
       2018-11-18T22:38:23.345559Z
       
       0 likes, 0 repeats
       
       @dizzy oh yeah, the mill is a long long way off going into production and needs probably a decade's more investment.It's not a short-term fix but it seems like an interesting long-term root-cause fix.
       
 (DIR) Post #1307874 by dizzy@mastodon.social
       2018-11-18T22:38:25Z
       
       0 likes, 0 repeats
       
       @kurisu yeah, I saw a couple of second of Ivan’s talks, but to busy to properly research. Have to roll square wheels, no time to make them round ;;
       
 (DIR) Post #1307875 by kurisu@iscute.moe
       2018-11-18T22:39:35.411081Z
       
       0 likes, 0 repeats
       
       @dizzy yeah... unfortunately. As much as I wish we could redesign everything to not suck it's a pointless task without credible migration paths. (and doing that with the whole UNIX api for example is impossible)
       
 (DIR) Post #1308037 by dizzy@mastodon.social
       2018-11-18T22:45:18Z
       
       0 likes, 0 repeats
       
       @kurisu I guess software gonna need a total redesign and rewrite for the Mill (but again I am not familiar with it) and adding anything more involved than memory tagging into existing code is quite a hard sell currently TT  Software devs generally hate everything that is not just wait for OS(+firmware) devs to add more exception handlers into $arch/entry.S so OS magically does everything for you ;;
       
 (DIR) Post #1308038 by kurisu@iscute.moe
       2018-11-18T22:51:34.172179Z
       
       0 likes, 0 repeats
       
       @dizzy the mill wouldn't be nearly as interesting as it was if it couldn't run linux with small modifications - or if it required modifications to C code. The mill's author knows that it's going to be an impossible sell if it's not backwards compatible.Basically the mill is immune simply because it doesn't do any speculation at all. Yet it employs a bunch of novel micro-architectural techniques to increase massively the IPC of non-speculative processors.So both memory tagging and the mill are "silent" solutions to the problem, although the mill is obviously a lot harder to implement because despite that you still need to do a standard linux, compiler, etc architecture port even if the CPUs were on silicon right now.
       
 (DIR) Post #1308129 by kurisu@iscute.moe
       2018-11-18T22:56:12.181650Z
       
       0 likes, 0 repeats
       
       @dizzy that being said, the mill does have a bunch of awesome features which essentially enable microkernels to run at the same performance level as traditional kernels. (the feature is called portal calls and it enables any normal function call to change the security context of the CPU with only 1-2 cycles overhead. Also security contexts are byte-granularity not page-granularity so you can literally share one data structure in your stack with the OS and not allow the OS to touch any of the rest of your stack - though that requires software support as imagined)
       
 (DIR) Post #1308148 by dizzy@mastodon.social
       2018-11-18T22:54:20Z
       
       0 likes, 0 repeats
       
       @kurisu I definitely should read about the Mill, otherwise picture of VLIW/EPIC popping up in my head ;; I recon that it’s something completely different
       
 (DIR) Post #1308149 by kurisu@iscute.moe
       2018-11-18T22:56:55.239966Z
       
       0 likes, 0 repeats
       
       @dizzy it is VLIW, but actually fast.
       
 (DIR) Post #1308212 by kurisu@iscute.moe
       2018-11-18T23:00:33.517815Z
       
       0 likes, 0 repeats
       
       @dizzy what makes it easier to believe for me is that there's like 20 novel things about the mill, it's not a "one trick pony". Maybe one or two of those things don't work out but that can still happen and it'd be a huge innovation.
       
 (DIR) Post #1308220 by kurisu@iscute.moe
       2018-11-18T23:01:00.672825Z
       
       0 likes, 0 repeats
       
       @dizzy now i'm just fanboying oops :P
       
 (DIR) Post #1308562 by dizzy@mastodon.social
       2018-11-18T23:16:59Z
       
       0 likes, 0 repeats
       
       @kurisu obligatory pic related 🤣
       
 (DIR) Post #1308563 by kurisu@iscute.moe
       2018-11-18T23:19:39.255428Z
       
       0 likes, 0 repeats
       
       @dizzy yeah itanium is a well-documented failure :)There are enough reasons to believe that the mill can bring a serious competitive advantage, but even if it does it'll be a hard sell. We'll see, I'm definitely not counting on it but I have hope.