On 4 August 2015 at 11:21, Sharma Bhupesh <bhupesh.sha...@freescale.com> wrote:
>> -----Original Message-----
>> From: Laszlo Ersek [mailto:ler...@redhat.com]
>> Sent: Tuesday, August 04, 2015 2:36 PM
>> On 08/04/15 10:38, Sharma Bhupesh wrote:
>> >> -----Original Message-----
>> >> From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]
>> >> Sent: Tuesday, August 04, 2015 2:01 PM
>> >>
>> >> On 4 August 2015 at 10:07, Sharma Bhupesh
>> >> <bhupesh.sha...@freescale.com>
>> >> wrote:
>>
>> >>> With the EFI_STUB becoming more or less mandatory and the leagacy
>> >>> ARM Bds Linux Loader being deprecated, are there any plans to
>> >>> provide means
>> >> to pass FIT format images via EFI_STUB to the ARM64 Linux kernel?
>> >>>
>> >>
>> >> No. FIT images are a U-Boot construct. The recommended way under UEFI
>> >> is to install the device tree as a FDT configuration table in the
>> firmware.
>> >> Look at FdtPlatformDxe for more info. The initrd can be loaded by the
>> >> EFI stub, by passing the initrd= option.
>> >>
>> >> The recommended way of doing authentication of bootable images is to
>> >> use UEFI Secure Boot. DTB authentication is implicit if it is part of
>> >> the UEFI image itself. How to do initrd authentication is undefined.
>>
>> (I'd say "unspecified" rather than "undefined", but that's a side point.)
>>
>> > initrd (Rootfs) is probably the easiest place to introduce a malicious
>> > application in, which can easily overwrite the text area, thus causing
>> the core to run a Trojan.
>>
>> How is this different from overwriting applications on a normal file
>> system? As far as I understand, applications are not part of the chain
>> being verified.
>
> Cryptographically verifying the entire Root filesystem being provided with
> a software development kit, allows a OEM/customer to ensure that
> the platform only boots a application-set which is authenticated using
> their Public-Private key pairs.
>

Putting DTB, kernel and initrd in the same signed archive is a design
driven by convenience, not by security.

It is the firmware's responsibility to authenticate and boot the
kernel image, and provide it with a description of the hardware. The
kernel's trust of the firmware is implicit, that is why, under UEFI
Secure Boot, the only way of obtaining a DTB is from the configuration
table (the dtb= kernel command line parameter is disabled in this
case)

It is the kernel's responsibility to authenticate the file system,
regardless of whether it is a initrd or a filesystem hosted on block
storage. To the firmware, the initrd is just an opaque blob, whereas,
from the kernel pov, the initrd is a readable archive with kernel
modules and executables, each of which may have their own
authentication requirements.

> So, if the system tries to launch a rootfs which is not authenticated
> via the OEM/customer's public key, the boot process stalls and a preventive
> tamper-proofing action like zero'ing the DDR contents and reseting the SoC 
> can be taken.
>

A chain of trust implies discrete links. Signing everything with the
OEM/customer's public key and verifying all at the same time may be
appropriate in some cases, but you should not present it as the common
design. In general, it is much more convenient to allow the kernel to
be in charge of the public keys that authenticate subsequent boot
stages rather than mandating that DTB, kernel *and* initrd are all
signed with a public key known to the firmware.

-- 
Ard.



>>
>> Kernel modules are (and they do reside in the initrd), but they should
>> already be covered by module signing.
>>
>> http://mjg59.dreamwidth.org/12368.html
>>
>> https://access.redhat.com/documentation/en-
>> US/Red_Hat_Enterprise_Linux/7/html/System_Administrators_Guide/sect-
>> signing-kernel-modules-for-secure-boot.html
>> https://www.suse.com/documentation/sles11/book_sle_admin/data/sec_uefi_se
>> cboot.html
>>
>> https://www.suse.com/documentation/sles-
>> 12/book_sle_admin/data/sec_uefi_secboot.html
>>
>> Thanks
>> Laszlo
>>
>> >
>> > The normal secure chain of boot, requires that each component verifies
>> > the next component it launches. FIT format seems to plug this gap.
>> >
>> > Can you point me to some documentation on UEFI secure boot and how it
>> > works on the
>> > ARM64 platforms - does it internally use and program the ARM TrustZone
>> > components like the TZASC and TZPC to partition the System RAM, etc
>> > into appropriate secure and non-secure partitions and the images
>> cryptographically verify the next stage image.
>> > A typical flow most OEMs use is:
>> >
>> > BootROM -> Arm Trusted Firmware -> UEFI -> Linux -> Initrd
>> >
>> > The current SEC stage code for ARM64 platforms supported in EDK2 seem
>> > to be programming the TZASC and TZPC entities, but I cannot see any
>> > secure chain-of-trust being established for the next stage images
>> there.
>> >
>> > Regards,
>> > Bhupesh
>> >
>> >>
>> >> Regards,
>> >> Ard.
>> >>
>> >>>> -----Original Message-----
>> >>>> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf
>> >>>> Of Ard Biesheuvel
>> >>>> Sent: Tuesday, August 04, 2015 1:27 PM
>> >>>> To: edk2-devel@lists.01.org; leif.lindh...@linaro.org;
>> >>>> ler...@redhat.com
>> >>>> Cc: ryan.har...@linaro.org; Ard Biesheuvel
>> >>>> Subject: [edk2] [PATCH] ArmVirtPkg: align ARM BDS build with
>> >>>> LinuxLoader changes
>> >>>>
>> >>>> LinuxLoader has been split off from the ARM BDS into a separate EFI
>> >>>> application. Because we never included this application into the
>> >>>> ArmVirtPkg platforms, its ARM BDS builds have effectively been
>> >>>> broken ever since that change was merged.
>> >>>>
>> >>>> Let's fix the situation by:
>> >>>> - Disabling LinuxLoader support for AARCH64 builds: arm64 Linux
>> >> kernels
>> >>>>   have UEFI stub support enabled by default, and the LinuxLoader
>> >>>> code
>> >> for
>> >>>>   booting arm64 Linux kernels is buggy. Note that this does not
>> >> disable
>> >>>>   the ARM BDS text menu, it just removes the ability to boot bare
>> >> Linux
>> >>>>   kernels.
>> >>>> - Adding the LinuxLoader EFI application to the ARM builds.
>> >>>>
>> >>>> Contributed-under: TianoCore Contribution Agreement 1.0
>> >>>> Signed-off-by: Ard Biesheuvel <ard.biesheu...@linaro.org>
>> >>>> ---
>> >>>>  ArmVirtPkg/ArmVirt.dsc.inc | 9 ++++++---
>> >>>> ArmVirtPkg/ArmVirtQemu.dsc
>> >>>> | 5
>> >>>> +++++  ArmVirtPkg/ArmVirtQemu.fdf | 3 +++
>> >>>>  3 files changed, 14 insertions(+), 3 deletions(-)
>> >>>>
>> >>>> diff --git a/ArmVirtPkg/ArmVirt.dsc.inc
>> >>>> b/ArmVirtPkg/ArmVirt.dsc.inc index
>> >>>> 2e2708d1c281..735f9edc58d6 100644
>> >>>> --- a/ArmVirtPkg/ArmVirt.dsc.inc
>> >>>> +++ b/ArmVirtPkg/ArmVirt.dsc.inc
>> >>>> @@ -206,6 +206,9 @@ [LibraryClasses.common.UEFI_APPLICATION]
>> >>>>
>> >>>> PerformanceLib|MdeModulePkg/Library/DxePerformanceLib/DxePerformanc
>> >>>> PerformanceLib|eL
>> >>>> PerformanceLib|ib.in
>> >>>> f
>> >>>>
>> >>>> MemoryAllocationLib|MdePkg/Library/UefiMemoryAllocationLib/UefiMemo
>> >>>> MemoryAllocationLib|ry
>> >>>> MemoryAllocationLib|Alloc
>> >>>> ationLib.inf
>> >>>>    HiiLib|MdeModulePkg/Library/UefiHiiLib/UefiHiiLib.inf
>> >>>> +  ShellLib|ShellPkg/Library/UefiShellLib/UefiShellLib.inf
>> >>>> +
>> >>>> + FileHandleLib|MdePkg/Library/UefiFileHandleLib/UefiFileHandleLib.
>> >>>> + FileHandleLib|in
>> >>>> + f  SortLib|MdeModulePkg/Library/UefiSortLib/UefiSortLib.inf
>> >>>>
>> >>>>  [LibraryClasses.common.UEFI_DRIVER]
>> >>>>
>> >>>> ReportStatusCodeLib|IntelFrameworkModulePkg/Library/DxeReportStatus
>> >>>> ReportStatusCodeLib|Co
>> >>>> ReportStatusCodeLib|deLib
>> >>>> Framework/DxeReportStatusCodeLib.inf
>> >>>> @@ -277,6 +280,9 @@ [PcdsFeatureFlag.common]
>> >>>>
>> >>>>    gEfiMdeModulePkgTokenSpaceGuid.PcdTurnOffUsbLegacySupport|TRUE
>> >>>>
>> >>>> +[PcdsFeatureFlag.AARCH64]
>> >>>> +  gArmPlatformTokenSpaceGuid.PcdBdsLinuxSupport|FALSE
>> >>>> +
>> >>>>  [PcdsFixedAtBuild.common]
>> >>>>    gArmPlatformTokenSpaceGuid.PcdFirmwareVendor|"ARM Virtualization
>> >>>> Platform"
>> >>>>
>> >>>> @@ -398,9 +404,6 @@ [Components.common]
>> >>>>
>> >>>> NULL|ShellPkg/Library/UefiShellInstall1CommandsLib/UefiShellInstall
>> >>>> NULL|1C
>> >>>> NULL|omman
>> >>>> dsLib.inf
>> >>>>
>> >>>> NULL|ShellPkg/Library/UefiShellNetwork1CommandsLib/UefiShellNetwork
>> >>>> NULL|1C
>> >>>> NULL|omman
>> >>>> dsLib.inf
>> >>>>
>> >>>> HandleParsingLib|ShellPkg/Library/UefiHandleParsingLib/UefiHandlePa
>> >>>> HandleParsingLib|rs
>> >>>> HandleParsingLib|ingLi
>> >>>> b.inf
>> >>>> -      ShellLib|ShellPkg/Library/UefiShellLib/UefiShellLib.inf
>> >>>> -
>> >>>> FileHandleLib|MdePkg/Library/UefiFileHandleLib/UefiFileHandleLib.in
>> >>>> FileHandleLib|f
>> >>>> -      SortLib|MdeModulePkg/Library/UefiSortLib/UefiSortLib.inf
>> >>>>        PrintLib|MdePkg/Library/BasePrintLib/BasePrintLib.inf
>> >>>>
>> >>>> BcfgCommandLib|ShellPkg/Library/UefiShellBcfgCommandLib/UefiShellBc
>> >>>> BcfgCommandLib|fg
>> >>>> BcfgCommandLib|Comma
>> >>>> ndLib.inf
>> >>>>
>> >>>> diff --git a/ArmVirtPkg/ArmVirtQemu.dsc
>> >>>> b/ArmVirtPkg/ArmVirtQemu.dsc index
>> >>>> a2a82a4dba8c..92d55c770f55 100644
>> >>>> --- a/ArmVirtPkg/ArmVirtQemu.dsc
>> >>>> +++ b/ArmVirtPkg/ArmVirtQemu.dsc
>> >>>> @@ -381,3 +381,8 @@ [Components.common]
>> >>>>    MdeModulePkg/Bus/Pci/XhciDxe/XhciDxe.inf
>> >>>>    MdeModulePkg/Bus/Usb/UsbBusDxe/UsbBusDxe.inf
>> >>>>    MdeModulePkg/Bus/Usb/UsbKbDxe/UsbKbDxe.inf
>> >>>> +
>> >>>> +[Components.ARM]
>> >>>> +!if $(INTEL_BDS) == FALSE
>> >>>> +  ArmPkg/Application/LinuxLoader/LinuxLoader.inf
>> >>>> +!endif
>> >>>> diff --git a/ArmVirtPkg/ArmVirtQemu.fdf
>> >>>> b/ArmVirtPkg/ArmVirtQemu.fdf index 3c0487cd95b6..47f9b095b3af
>> >>>> 100644
>> >>>> --- a/ArmVirtPkg/ArmVirtQemu.fdf
>> >>>> +++ b/ArmVirtPkg/ArmVirtQemu.fdf
>> >>>> @@ -177,6 +177,9 @@ [FV.FvMain]
>> >>>>    INF IntelFrameworkModulePkg/Universal/BdsDxe/BdsDxe.inf
>> >>>>  !else
>> >>>>    INF ArmPlatformPkg/Bds/Bds.inf
>> >>>> +!if $(ARCH) == ARM
>> >>>> +  INF ArmPkg/Application/LinuxLoader/LinuxLoader.inf
>> >>>> +!endif
>> >>>>  !endif
>> >>>>
>> >>>>    #
>> >>>> --
>> >>>> 1.9.1
>> >>>>
>> >>>> _______________________________________________
>> >>>> edk2-devel mailing list
>> >>>> edk2-devel@lists.01.org
>> >>>> https://lists.01.org/mailman/listinfo/edk2-devel
>
_______________________________________________
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Reply via email to