Bitlocker can be "paused", which really means the key is written unprotected to disk. This can be done by the user, but also happens temporarily during updates that would change bootchain measurements, because those measurements are used by the TPM to decrypt the key (hence changing them would make the key undecipherable).
Thank you! This is a very useful one-pager, answers many questions I had I couldn't find in their documentation (being on mobile I couldn't test with SSH).
Not sure if it was DARPA, but the web server used Tame, a custom event-driven framework at a time where the thread vs. events debate was all the rage in the academic community. (I did a PhD on the topic and that's how I learned about Ok Cupid!)
Trivia time: Laeticia (née Laetitia) was married to Johnny, the famous French rock singer; Estelle was married to David, son of Johnny. Note that Johnny is dead now, Laeticia has been remaried twice but kept Johnny's last name, Estelle is divorced, and David is not the son of Laeticia as Johnny got married several times (David's mother is the French actress Sylvie Vartan).
OK, that makes a lot of sense. Thanks for taking the time to clarify!
> But as joatmon-snoo correctly said, the more important point is demonstrating how bad backend churn is with this algorithm.
Yes, again the overall point came across clearly, but faced with specific examples I like to dive into the details to check my understanding of how things work. Otherwise, it's easy to overlook key but subtle details.
There are several points in the article where the examples didn't make sense at all to me. Overall an interesting article, but I'm either a bit dense this morning, or it's sloppy in the details and explanations
For instance, in table 3, it looks like they excluded backend tasks {0,1} (for frontend tasks {0, 1}) then {2,3} (for frontend tasks {2,3}) in the N=10 case, but backend tasks {1,2} then {3,4} in the N=11. Why the discrepancy? I get that it helps them make the point about task 3 changing subset, but it's inconsistent with excluding left-overs in a round-robin fashion presented in the previous paragraph.
Another sentence that I couldn't make sense of is: "If these [tasks 2 and 4] carry over to the subset of the next frontend task, you might get the shuffled backend tasks [7, 2, 0, 8, 9, 1, 4, 5, 3, 6], but you can't assign backend task 2 to the same frontend task. " The "same frontend task" as what? Obviously note the one task 2 was already assigned to (the most intuitive reading to me), since precisely task 2 was not assigned and is a left-over. But then again, what does this mean?
I found the blog post slightly confusing because it never explicitly spells out that endorsing a new node is a manual operation that the administrator has to perform from one of the trusted nodes. Of course this is what you'd want, anything automatic would ruin the purpose of tailnet lock. But still not seeing it mentioned, neither in the text nor in the pictures, made me wonder what I had missed, until I watched the video which features that very step as part of the demo.
Also from the start they introduce a bug in the kernel (in the TimerDispatcher implementation), and this is the very bug they focus on and eventually write an exploit for.
They explain why they do so, and the article is extremely valuable as a first step and tutorial to get started in Zircon kernel hacking. They also find some actual issues, including one CVE. But I disagree the article shows how "unsecure Fuchsia is as a result of being unfinished".