christina_b

Unless you have build servers capable of rebuilding all Qt, WebKit etc. and performing an LTO link (which pulls in all build artifacts in form of bitcode archives/objects) in a reasonable amount of time (big reason buildlabs exist - it takes a long time), LTO is not likely to be suitable, it's an extremely expensive optimization that essentially defers all real compilation until the link step at which the linker calls back into libLLVM/libLTO and have them do all the heavy lifting.

At the very least you need a workstation grade machine to be able to do that kind of stuff on regular basis, you really can't expect everyone to have that. And there's a reason libLLVM.so is usually dynamically linked, it cuts a massive amount of time spent on builds, which is especially useful while developing and it's a middle ground between building all LLVM and Clang libraries as shared objects and having to wait for static linking of various LLVM modules into every LLVM toolchain binary (which tends to result in the toolchain being much much bigger). The build cache with shared libLLVM.so for Clang/LLVM/LLD builds is around 6-7GB (Asserts/Test builds). Statically linking LLVM modules blows that up to 20GB. God forbid you actually do a full debug build with full debug information with that.

That's a terrible argument against dynamic linking. That's not to say static linking is bad, in fact, recently it's been making a comeback for exactly that reason - LTO and next-generation optimizers. But saying LTO makes static linking viable for everyone including consumers is somewhat far fetched.

If he's who I think he is, I doubt his early background is that clean, despite him being a whitehat now. It is very much possible he is being held because of something related to that and not because of anything related to WannaCry. This was all before he even started running the MalwareTech blog, it's very much possible the FBI decided to look into his background or were already familiar with it prior to him arriving in or leaving the US.

That being said, it's possible that I'm mistaking him for someone else in which case I do apologize. I edited the post a bit, to clarify, the first paragraph to the best of my knowledge is certainly true, second one is based on my own speculation so take it with a grain of salt.

1). The first stage bootloader doesn't require signing.

2). The first stage bootloader starts in EL3 mode (ie. BootROM doesn't exit it like it did on some OMAP dev boards)

Most ARM cores start in secure supervisor mode, which can transition to secure monitor mode at will (secure monitor being a special version of secure supervisor). Most bootloaders including Allwinner's will exit secure mode by setting the NS bit in SCR and therefore enter user provided code in non-secure supervisor (or hypervisor mode) which would be called EL1 (or EL2 for hypervisor) on AArch64.

EL3 has nothing to do with ROM or Allwinner or anything else, it's an execution mode defined by ARM themselves, the core is reset in that mode.

(Secure mode is also known as TrustZone, if that term seems more familiar though TrustZone is usually "the whole package" including support from the CPU and the corresponding peripherals)

My favourite is probably NVIDIA Jetson TX1 where development boards do not have a key fused in them and have documented TrustZone peripherals, so you're free to run your own secure monitor.

Sadly while ARM on rPi does start in secure mode, it lacks any secure peripherals (AxPROT[1] is forced to high so even if ARM is in secure mode, it cannot make secure bus transactions) but it's mostly a matter of principle of being able to have ARM code run in EL3 for me.

The entire point of a development board is to be able to mess around with it, I'm not wasting my time on boards with locked down features.

Support from Broadcom is unlikely to fix it, the BCM283x family of SoCs are just a huge mess and in my opinion are either suited for really specific applications (TV boxes) or as "toys".

The ARM core itself is integrated very poorly almost as an afterthought, since it wasn't in the original design, the BCM283x family is just BCM27xx family VideoCore4 VPU+QPU combinations with an ARM core hacked (and I really do mean hacked) on top.

Actually that's open and mainlined now, there are DRM drivers for BCM285x family but they rely on mailbox interfaces for power and clock management.

Yes precisely, so we offer an alternative to those blobs that allows you to boot ARM without needing a closed-source firmware.

We actually have documented most vector instructions of VC4 and Julian's toolchain supports pretty much all documented ones, so the toolchain we have is pretty close to what Broadcom would have with their MetaWare compiler for VC4.

>The RPI3 is rated for 24GFLOPS

You mean the VPU, we also have QPU and ARM on the side.

>so many really weird abnormal subsystems

True that, lack of TZPCs, ARM AxPROT[1] being forced to high causing all ARM accesses to be insecure on AXI even in secure monitor mode (sadness), lack of a GIC. I could go on and on about what's wrong with BCM283x family but hey at least it's interesting.

>But I am sincerely impressed and it has been amazing work slowly wrangling this abomination into order.

Thank you ^^