From mboxrd@z Thu Jan 1 00:00:00 1970 From: Marek Vasut Date: Thu, 5 Sep 2019 14:26:41 +0200 Subject: [U-Boot] What if ATF can be part of U-Boot source, like SPL? In-Reply-To: <3869de2e-691c-dfe9-ac19-696ca8c8ee67@arm.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> <3869de2e-691c-dfe9-ac19-696ca8c8ee67@arm.com> Message-ID: <21d64fc4-b0fc-a6c0-8618-ce9c8f91b476@gmail.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable To: u-boot@lists.denx.de On 9/5/19 2:54 AM, Andr=C3=A9 Przywara wrote: > On 04/09/2019 18:56, Marek Vasut wrote: >> On 9/4/19 7:32 PM, Andre Przywara wrote: >=20 > Hi Marek, Hi, >>>> 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 platfo= rms: >>> - 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 payloa= ds (OP-Tee). Typically we don't even use U-Boot primarily on those platform= s (but EDK II instead). >>> - There are platforms (low end SoCs like Allwinner, Rockchip, for insta= nce) 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? >=20 > 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. Then why is there so much init code in ATF plat/ and drivers/ ? I think that should rather be in the U-Boot SPL instead of being duplicated in ATF. > This BL31-only model is considered a perfectly fine way of using ATF. >=20 >>>> 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 somet= hing 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 t= his 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. >=20 > 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. There are quite a few GPL licensed bootloaders and they are doing quite fine I think, so it's not that clear cut. >> It seems like some platforms even went down this path already and only >> released blobs, hence, no security fixes etc. >=20 > 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. Every single time I asked a vendor for changes to BSD-licensed sources, I either got silent treatment or was told off. Hence, I am not a fan of BSD license at all. > 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. Considering how many various blobs recent ARM64 systems are growing (e.g. DDR4 init is usually a blob, some "secure" firmwares are blobs and so on), I don't think BSD licensed bootloader will help here. >>>> 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 a= spect alone. >>> >>> But on top of that, I see that ATF and U-Boot address two separate area= s: CPU initialisation and secure world management on one side, and a very v= ersatile bootloader running in the non-secure world on the other. Keeping t= hem separate allows a clean separation and lets each project focus on its c= ore functionality. >>> >>> I understand that this separation is not always as clear or as well imp= lemented on every platform, but at least we should aim at this. >=20 >> Shouldn't the "secure world" management be as open as possible then ? >=20 > "as open as possible", yes. As mentioned above, this might probably be > as good as it can get. I would very much prefer for those security components to have guaranteed source availability, but with BSD license, this is not gonna happen. --=20 Best regards, Marek Vasut