Nothing. This is just a proof of concept that is ridiculously easy to detect. If your attackers can drop files in your /boot or /boot/efi directory, I think you have much worse things to worry about than this.
In fact, this bootkit would be about the least thing I would worry about. Because by the time an attack can write to /boot, they can also write to /etc/init.d . And the later is not protected by "secure boot".
How is an infection hidden somewhere in the friggin entire rootfs easier to detect and remove that one that literally replaces the one file for your kernel /boot ? What advantage could the latter possibly have ? Not to mention that something from a bootkit bootstrapping an infection in the root filesystem is the realm of useless tech demos like this one; while for something that can already write your rootfs, infecting the kernel is trivial.
The entire boot system has much, much fewer places for malware to hide compared to the entire "rootkit" OS attack surface which is astronomically larger. Secure Boot has always targeted the smaller and most useless of the swiss cheese holes.
No, I wasn't "asked" by the browser publisher to trust them unless you use the word "ask" in a very broad (almost to the point of meaninglessness) sense: when I installed my browser, it simply started using its pre-packaged bundle of CA certificates. Which it regularly updates, I imagine, although it also never asked me about what the update source I'd like to use either.
You can say that I implicitly trust the browser vendor's judgement in what CAs to trust, by the virtue of using the browser, and I'd agree with that. But saying that I was asked by the browser publisher to trust them? No, I disagree, I wasn't. It was a silent decision.
The FaCT DSL is used to define functions with predictable execution times to prevent timing leaks. In this notebook, functions have been created to simulate varying computational complexity (e.g., sorting, searching).
Abstract
Real-world cryptographic code is often written in a subset
of C intended to execute in constant-time, thereby avoiding
timing side channel vulnerabilities. This C subset eschews
structured programming as we know it: if-statements, looping constructs, and procedural abstractions can leak timing
information when handling sensitive data. The resulting
obfuscation has led to subtle bug
Since it appears you have chosen to incompletely quote the problem statement from the abstract as your submission statement, and since by accident or design the full title was not included in your submission:
This paper describes FaCT, a DSL for timing-sensitive computation. It is described as allowing readable, high-level cryptographic code, with efficient,
constant-time behavior.
At a very rough skim, the language seems to have interesting conveniences around implementing mitigations to timing channel attacks, like marking particular values 'secret' for the compiler.
