From mboxrd@z Thu Jan 1 00:00:00 1970 From: =?UTF-8?Q?Andr=c3=a9_Przywara?= Date: Fri, 6 Sep 2019 00:14:35 +0100 Subject: [U-Boot] What if ATF can be part of U-Boot source, like SPL? In-Reply-To: <21d64fc4-b0fc-a6c0-8618-ce9c8f91b476@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> <3869de2e-691c-dfe9-ac19-696ca8c8ee67@arm.com> <21d64fc4-b0fc-a6c0-8618-ce9c8f91b476@gmail.com> Message-ID: 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 Thu, 5 Sep 2019 14:26:41 +0200 Marek Vasut wrote: Hi, > On 9/5/19 2:54 AM, Andr=C3=A9 Przywara wrote: > > On 04/09/2019 18:56, Marek Vasut wrote: =20 > >> On 9/4/19 7:32 PM, Andre Przywara wrote: =20 > >>>> 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 op= en > >>>> 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...th= is > >>>> 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 =20 > >>> > >>> A bit like U-Boot, ATF can look quite differently on the various plat= forms: > >>> - There are platforms like Arm's Juno or the fastmodel, where ATF doe= s some loading. This is mostly for features like secure boot or secure payl= oads (OP-Tee). Typically we don't even use U-Boot primarily on those platfo= rms (but EDK II instead). > >>> - There are platforms (low end SoCs like Allwinner, Rockchip, for ins= tance) 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. =20 > >> > >> 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 > >=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. =20 >=20 > 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 AT= F. Anything in particular you are looking at? ATF handles more platforms that those just using the BL31 only approach. Also there are platforms that don't even support U-Boot. So those have more code in their plat/ directory, and bring their own drivers. > > 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 =20 > >>> > >>> I am not quite sure I follow how you come from 2. to 3. Was there som= ething in the presentation (I guess OSFC?) you are referring to? > >>> In contrast to the x86 world the firmware is actually Open Source bas= ed, 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. =20 > >> > >> 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 > >=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. =20 >=20 > There are quite a few GPL licensed bootloaders and they are doing quite > fine I think, so it's not that clear cut. For which platforms? Servers? High end network appliances? > >> It seems like some platforms even went down this path already and only > >> released blobs, hence, no security fixes etc. =20 > >=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. =20 >=20 > 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. Yes, I can see that from your response and the answers down here ;-) But as mentioned before: GPL was not an option for those components. Cheers, Andre. >=20 > > 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. =20 >=20 > 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. >=20 > >>>> 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 :-) =20 > >>> > >>> What are the relevant parts, exactly? Do you want to rip them out? Us= e 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 ar= eas: 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 i= mplemented on every platform, but at least we should aim at this. =20 > > =20 > >> Shouldn't the "secure world" management be as open as possible then ? = =20 > >=20 > > "as open as possible", yes. As mentioned above, this might probably be > > as good as it can get. =20 >=20 > I would very much prefer for those security components to have > guaranteed source availability, but with BSD license, this is not gonna > happen. >=20