On Sat, 22 Jun 2019 at 11:21, David Edmundson <da...@davidedmundson.co.uk> wrote: > > Benchmarks of dolphin on a low end ARM laptop: > Dolphin via QProcess: 1233ms > Dolphin via Kinit: 1144ms > > again a consistent saving in the order of ~7% > > Initially I had wanted to scrap it, I'm now very conflicted. > > I'll try to port all of plasma services to use it properly again and > see what difference that makes across a broad context over a wider > range of services. > > David
Hi David, There is also one more thing we might want to take into account: Kinit mostly breaks ASLR since all libraries will have libc, QtBase, etc mapped at the same address if we do fork() without execve(). This makes code reuse attacks a bit easier since the attacker can reuse the guessed addresses for all base libraries. Only the executable and any libraries loaded by the executable will have randomized addressed. However, in my opinion all probabilistic vulnerability mitigation schemes such as ASLR are not particularly useful since they just make it more difficult for an attacker rather than actually preventing the attack. Moreover, it has been shown that ASLR can be broken due to MMU side-channels (even from JavaScript running in a browser sandbox!) [1] or if you have a fork()ing server (which is similar to the kinit case)[2]. Upcoming CPUs will have more useful features to partially enforce control flow integrity (Intel Control-flow Enforcement Technology (CET) or ARM Branch Target Indicators (BTI)) which should be more effective than ASLR. Personally, I think it makes sense to keep kinit if it speeds up start-up by 7% even if it (mostly) breaks ASLR since ASLR is already pretty much broken. Also we have been doing this for years and I don't think there has been a CVE because of kinit not randomizing some library locations. I am currently working on CHERI [3], an ISA extension that adds 128-bit capabilities (essentially pointers with bounds and permissions) to the MIPS (and RISC-V) ISAs. We currently run everything on a 100Mhz FPGA so I'm sure the start-up time would be quite noticeable there. I have not yet managed to get kinit to compile but we do have QtBase and QtWebkit working. It shouldn't be too hard to compile kinit and run the measurements but I doubt I will have time to do that in the next month or two. In the past few years I've done quite a lot of work with the FreeBSD runtime linker. Based on my current measurements of relocation processing in the runtime linker, it can take a lot of time to resolve all symbols (especially if lazy binding is disabled by linking with -z now) and to process all relocations. I believe LD_BIND_NOW/-z now is becoming the default in some distributions since it allows mapping the GOT read-only after relocation processing and therefore slightly reduces the attack surface. Kinit allows us to skip those steps for some of the libraries so it should always be a noticeable performance win. Alex [1] https://www.vusec.net/projects/anc/ [2] www.scs.stanford.edu/brop/bittau-brop.pdf [3] http://chericpu.com