From mboxrd@z Thu Jan 1 00:00:00 1970 From: =?UTF-8?Q?Andr=c3=a9_Przywara?= Date: Thu, 5 Sep 2019 01:54:48 +0100 Subject: [U-Boot] What if ATF can be part of U-Boot source, like SPL? In-Reply-To: <7c017abf-75af-e573-b6e6-48106d402ed2@gmail.com> References: <0aa82db6-be91-2775-41de-e936b6344da0@gmail.com> <09cd7b54-47f5-6af1-7edf-46d12214857e@arm.com> <20190904183237.7bc77826@donnerap.cambridge.arm.com> <7c017abf-75af-e573-b6e6-48106d402ed2@gmail.com> Message-ID: <3869de2e-691c-dfe9-ac19-696ca8c8ee67@arm.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de On 04/09/2019 18:56, Marek Vasut wrote: > On 9/4/19 7:32 PM, Andre Przywara wrote: Hi Marek, >>> I have been avoiding this thread but today I attended a talk on ATF >>> and ARM's approach in general. ARM seems to be moving towards an >>> approach of providing increasingly complex source code to add more >>> layers of security software to fully round out two mostly separate >>> worlds (secure and normal). >>> >>> Oddly enough Intel was also there talking about how they are breaking >>> things down into pieces and slowly releasing more things into the open >>> source world. >>> >>> I came away with the impression that the two companies are going in >>> different directions. ARM seems to be heading where Intel was and >>> Intel is heading back. This is a gross simplification of course. >>> >>> To me it seems that the following scenario might play out: >>> >>> 1. ARM releases new ATF versions as source drops that firmware >>> projects like U-Boot expected to take. In fact, not even U-Boot...this >>> is just users picking up whatever they find >>> >>> 2. ATF keeps getting more complex, adding its own drivers for serial, >>> storage, etc., duplicating and perhaps conflicting with those in >>> U-Boot >> >> A bit like U-Boot, ATF can look quite differently on the various platforms: >> - There are platforms like Arm's Juno or the fastmodel, where ATF does some loading. This is mostly for features like secure boot or secure payloads (OP-Tee). Typically we don't even use U-Boot primarily on those platforms (but EDK II instead). >> - There are platforms (low end SoCs like Allwinner, Rockchip, for instance) which don't do any loading at all, actually rely on other code (SPL?) to load ATF itself. >> >> So I don't see how this would duplicate effort or even conflict. > > So why don't we put all the platform init code into U-Boot SPL, which > already has all the loading code and only load this ATF BL31 with SPL? But this is what we actually do on those platforms: SPL is loaded by the BootROM, PLLs and bus clocks are set up in SPL, then DRAM and MMC are initialised, then we load U-Boot proper and ATF BL31. BL31 does SMP init and errata workaround, and stays resident in EL3 to provide PSCI services. This BL31-only model is considered a perfectly fine way of using ATF. >>> 3. Over time we end up with binary blobs on ARM that are every bit as >>> impenetrable as what Intel used to have >> >> I am not quite sure I follow how you come from 2. to 3. Was there something in the presentation (I guess OSFC?) you are referring to? >> In contrast to the x86 world the firmware is actually Open Source based, so you actually have a realistic chance to rebuild and/or verify it. If this is not true in a particular case, poke your vendor. > > I thought ATF was designed to be BSD-licensed to allow vendors to take > all the open source contributions, benefit from it, but also allow the > vendors to never release their changes if they so desire. BSD was simply chosen because basically every vendor said they would not (be able to) use GPL licensed code for their firmware. So it was BSD license or no (Open Source) firmware at all. You might find that sad (I do), but that's what it is. > It seems like some platforms even went down this path already and only > released blobs, hence, no security fixes etc. If you don't control the platform (servers), then you still have some power as a customer to ask for releasing the firmware source. AFAIK this is well understood by the vendors, as it is a good selling point against x86. And what I meant above is that this is in contrast to x86, where most of the firmware ("BIOS") is proprietary and consists of many third-party parts. So even when your system vendor wanted, it couldn't possibly publish the code. With the core firmware being Open Source, you have a much better chance of getting the source. If the vendor doesn't want to give code away, it would just use proprietary code anyway, probably of much worse quality. >>> 4. Firmware security and open-sourceness suffers, overall. >>> >>> One approach might be for ATF to split into a library which can be >>> linked into a new U-Boot phase and a driver/init bit that could be >>> used for other bootloaders, whatever they might be. >>> >>> But in the meantime, I think it makes more sense to incorporate the >>> relevant parts of ATF into U-Boot and maintain them there, only for >>> the platforms that U-Boot supports. If ATF starts using GUIDs and the >>> like, we at least have somewhere to hide :-) >> >> What are the relevant parts, exactly? Do you want to rip them out? Use git submodules? >> For reasons I detailed before, I doubt the viability of the practical aspect alone. >> >> But on top of that, I see that ATF and U-Boot address two separate areas: CPU initialisation and secure world management on one side, and a very versatile bootloader running in the non-secure world on the other. Keeping them separate allows a clean separation and lets each project focus on its core functionality. >> >> I understand that this separation is not always as clear or as well implemented on every platform, but at least we should aim at this. > Shouldn't the "secure world" management be as open as possible then ? "as open as possible", yes. As mentioned above, this might probably be as good as it can get. Cheers, Andre.