23 Mar, 2020

1 commit


17 Mar, 2020

1 commit


29 Feb, 2020

1 commit

  • Following kernel's proposal for an arch-agnostic initrd loading
    mechanism [1] let's implement the U-boot counterpart.
    This new approach has a number of advantages compared to what we did up
    to now. The file is loaded into memory only when requested limiting the
    area of TOCTOU attacks. Users will be allowed to place the initramfs
    file on any u-boot accessible partition instead of just the ESP one.
    Finally this is an attempt of a generic interface across architectures
    in the linux kernel so it makes sense to support that.

    The file location is intentionally only supported as a config option
    argument(CONFIG_EFI_INITRD_FILESPEC), in an effort to enhance security.
    Although U-boot is not responsible for verifying the integrity of the
    initramfs, we can enhance the offered security by only accepting a
    built-in option, which will be naturally verified by UEFI Secure Boot.
    This can easily change in the future if needed and configure that via ENV
    or UEFI variable.

    [1] https://lore.kernel.org/linux-efi/20200207202637.GA3464906@rani.riverdale.lan/T/#m4a25eb33112fab7a22faa0fd65d4d663209af32f

    Signed-off-by: Ilias Apalodimas
    Signed-off-by: Heinrich Schuchardt

    Ilias Apalodimas
     

08 Jan, 2020

5 commits


19 Nov, 2019

1 commit


08 Oct, 2019

1 commit

  • At present these two functions are defined in efi_loader.h but only if
    CONFIG_EFI_LOADER is enabled. But these are functions that are useful to
    other code, such as that which deals with Intel Handoff Blocks (HOBs).

    Move these to the top of the function.

    Possibly ascii2unicode() should not be an inline function, since this
    might impact code size.

    Signed-off-by: Simon Glass
    Reviewed-by: Bin Meng

    Simon Glass
     

21 Sep, 2019

1 commit

  • Sandbox's "host" devices are currently described as UCLASS_ROOT udevice
    with DEV_IF_HOST block device. As the current implementation of
    efi_device_path doesn't support such a type, any "host" device
    on sandbox cannot be seen as a distinct object.

    For example,
    => host bind 0 /foo/disk.img

    => efi devices
    Scanning disk host0...
    Found 1 disks
    Device Device Path
    ================ ====================
    0000000015c19970 /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)
    0000000015c19d70 /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)

    => efi dh
    Handle Protocols
    ================ ====================
    0000000015c19970 Device Path, Device Path To Text, Device Path Utilities, Unicode Collation 2, HII String, HII Database, HII Config Routing
    0000000015c19ba0 Driver Binding
    0000000015c19c10 Simple Text Output
    0000000015c19c80 Simple Text Input, Simple Text Input Ex
    0000000015c19d70 Block IO, Device Path, Simple File System

    As you can see here, efi_root (0x0000000015c19970) and host0 device
    (0x0000000015c19d70) have the same representation of device path.

    This is not only inconvenient, but also confusing since two different
    efi objects are associated with the same device path and
    efi_dp_find_obj() will possibly return a wrong result.

    Solution:
    Each "host" device should be given an additional device path node
    of "vendor device path" to make it distinguishable.

    Signed-off-by: AKASHI Takahiro
    Reviewed-by: Heinrich Schuchardt
    Signed-off-by: Heinrich Schuchardt

    AKASHI Takahiro
     

09 Sep, 2019

1 commit


06 Sep, 2019

1 commit


17 Jul, 2019

2 commits

  • In packed structures GUIDs are not aligned. Avoid a build error with
    GCC 9.1 by using const void * as argument for guidcmp().

    Reported-by: Ramon Fried
    Signed-off-by: Heinrich Schuchardt

    Heinrich Schuchardt
     
  • We currently have some inconsistent use of efi_add_memory_map()
    throughout the code. In particular the return value of efi_add_memory_map()
    is not interpreted the same way by various users in the codebase.

    This patch does the following:

    - Changes efi_add_memory_map() to return efi_status_t.
    - Adds a method description to efi_add_memory_map().
    - Changes efi_add_memory_map() to return EFI_SUCCESS
    - Returns non-zero for error in efi_add_memory_map()
    - Updates efi_allocate_pages() to new efi_add_memory_map()
    - Updates efi_free_pages() to new efi_add_memory_map()
    - Updates efi_carve_out_dt_rsv() to new efi_add_memory_map()
    - Updates efi_add_runtime_mmio() to new efi_add_memory_map()

    Fixes: 5d00995c361c ("efi_loader: Implement memory allocation and map")
    Fixes: 74c16acce30b ("efi_loader: Don't allocate from memory holes")
    Suggested-by: Heinrich Schuchardt
    Cc: Alexander Graf
    Signed-off-by: Bryan O'Donoghue
    Reviewed-by: Heinrich Schuchardt

    Bryan O'Donoghue
     

07 Jul, 2019

4 commits


15 Jun, 2019

1 commit

  • This variable is defined in UEFI specification 2.8, section 8.1.
    Its value should be updated whenever we add any usable runtime services
    function.

    Currently we only support SetVirtualAddress() for all systems and
    ResetSystem() for some.

    Signed-off-by: AKASHI Takahiro
    Reviewed-by: Heinrich Schuchardt

    AKASHI Takahiro
     

11 Jun, 2019

2 commits

  • Up to now we have only been using a flag queued for events. But this does
    not satisfy the requirements of the UEFI spec. Events must be notified in
    the sequence of decreasing TPL level and within a TPL level in the sequence
    of signaling.

    Implement a queue for signaled events.

    Signed-off-by: Heinrich Schuchardt

    Heinrich Schuchardt
     
  • ExitBootServices() has to stop timer related activity before calling the
    events of the EFI_EVENT_GROUP_EXIT_BOOT_SERVICES event group. But our
    current implementation was stopping all other events.

    All events have to observe the task priority level.

    Signed-off-by: Heinrich Schuchardt

    Heinrich Schuchardt
     

01 Jun, 2019

2 commits


25 May, 2019

1 commit


19 May, 2019

2 commits

  • In EFI 1.10 a version of the Unicode collation protocol using ISO 639-2
    language codes existed. This protocol is not part of the UEFI specification
    any longer. Unfortunately it is required to run the UEFI Self Certification
    Test (SCT) II, version 2.6, 2017. So we implement it here for the sole
    purpose of running the SCT. It can be removed once a compliant SCT is
    available.

    The configuration option defaults to no.

    Signed-off-by: Rob Clark

    Most of Rob's original patch is already merged. Only the deprecated
    protocol is missing. Rebase it and make it configurable.

    Signed-off-by: Heinrich Schuchardt

    Heinrich Schuchardt
     
  • Rename variables to make it clear they refer to the Unicode collation
    protocol identified by the EFI_UNICODE_PROTOCOL2_GUID.

    Signed-off-by: Heinrich Schuchardt

    Heinrich Schuchardt
     

08 May, 2019

4 commits


03 May, 2019

2 commits

  • In case of a failure exit data may be passed to Exit() which in turn is
    returned by StartImage().

    Let the `bootefi` command print the exit data string in case of an error.

    Signed-off-by: Heinrich Schuchardt

    Heinrich Schuchardt
     
  • The field boot OptionalData in structure _EFI_LOAD_OPTIONS is for binary
    data.

    When we use `efidebug boot add` we should convert the 5th argument from
    UTF-8 to UTF-16 before putting it into the BootXXXX variable.

    When printing boot variables with `efidebug boot dump` we should support
    the OptionalData being arbitrary binary data. So let's dump the data as
    hexadecimal values.

    Here is an example session protocol:

    => efidebug boot add 00a1 label1 scsi 0:1 doit1 'my option'
    => efidebug boot add 00a2 label2 scsi 0:1 doit2
    => efidebug boot dump
    Boot00A0:
    attributes: A-- (0x00000001)
    label: label1
    file_path: .../HD(1,MBR,0xeac4e18b,0x800,0x3fffe)/doit1
    data:
    00000000: 6d 00 79 00 20 00 6f 00 70 00 74 00 69 00 6f 00 m.y. .o.p.t.i.o.
    00000010: 6e 00 00 00 n...
    Boot00A1:
    attributes: A-- (0x00000001)
    label: label2
    file_path: .../HD(1,MBR,0xeac4e18b,0x800,0x3fffe)/doit2
    data:

    Signed-off-by: Heinrich Schuchardt

    Heinrich Schuchardt
     

23 Apr, 2019

2 commits

  • In the current implementation, bootefi command and EFI boot manager
    don't use load_image API, instead, use more primitive and internal
    functions. This will introduce duplicated code and potentially
    unknown bugs as well as inconsistent behaviours.

    With this patch, do_efibootmgr() and do_boot_efi() are completely
    overhauled and re-implemented using load_image API.

    Signed-off-by: AKASHI Takahiro

    Use efi_root as parent handle for the loaded image.
    LoadImage() should be called with BootPolicy = true by the boot manager.
    Avoid duplicate free_pool().
    Eliminate variable memdp which is not needed after anymore due to
    "efi_loader: correctly split device path of loaded image".

    Reviewed-by: Heinrich Schuchardt
    Signed-off-by: Heinrich Schuchardt

    AKASHI Takahiro
     
  • This is a preparatory patch.
    The root node handle will be used as a dummy parent handle when invoking
    an EFI image from bootefi/bootmgr command.

    Signed-off-by: AKASHI Takahiro

    Rebased.

    Signed-off-by: Heinrich Schuchardt

    AKASHI Takahiro
     

13 Apr, 2019

1 commit


07 Apr, 2019

3 commits

  • Those two functions will be used later to re-implement do_bootefi_exec().

    Signed-off-by: AKASHI Takahiro
    Reviewed-by: Heinrich Schuchardt
    Signed-off-by: Heinrich Schuchardt

    AKASHI Takahiro
     
  • To meet UEFI spec v2.7a section 9.2, we should add
    EFI_LOADED_IMAGE_DEVICE_PATH_PROTOCOL to image handle,
    instead of EFI_DEVICE_PATH_PROTOCOL.

    Signed-off-by: AKASHI Takahiro
    Reviewed-by: Heinrich Schuchardt

    AKASHI Takahiro
     
  • Currently, image's image_base points to an address where the image was
    temporarily uploaded for further loading. Since efi_loader relocates
    the image to final destination, image_base and image_size should reflect
    that.

    This bug was detected in UEFI SCT, "Loaded Image Protocol Test - test 2,"
    which shows that 'Unload' function doesn't fit into a range suggested by
    image_base and image_size.

    TestCase/UEFI/EFI/Protocol/LoadedImage/BlackBoxTest/
    LoadedImageBBTestMain.c:1002

    Changes in this patch also includes:
    * reverts a patch, "efi_loader: save image relocation address
    and size" since newly added fields are no longer needed.
    * copy PE headers as well since those information will be needed
    for module loading, in particular, at gurb.
    (This bug was reported by Heinrich.)

    Reported-by: Heinrich Schuchardt
    Signed-off-by: AKASHI Takahiro

    Rebase patch.
    Remove unused fields from struct efi_loaded_image_obj.

    Reviewed-by: Heinrich Schuchardt

    AKASHI Takahiro
     

16 Feb, 2019

1 commit