1. 21 Jun, 2021 1 commit
  2. 07 Apr, 2021 1 commit
    • Yongbo Yao's avatar
      Loader: support booting OS from memory disk (MD) · 5984246f
      Yongbo Yao authored
      Until now, the boot image can be embedded into the loader with
      /sys/tools/embed_mfs.sh, and memory disk (MD) is already supported
      in loader source. But due to memory disk (MD) driver isn't registered
      to the loader yet, the boot image can't be boot from embedded memory
      disk.
      
      Reviewed by:	dab, tsoome
      MFC after:	1 week
      Sponsored by:	Dell EMC Isilon
      Differential Revision:	https://reviews.freebsd.org/D29512
      5984246f
  3. 04 Feb, 2021 1 commit
  4. 02 Jan, 2021 1 commit
    • Toomas Soome's avatar
      loader: implement framebuffer console · 3630506b
      Toomas Soome authored
      Draw console on efi.
      Add vbe framebuffer for BIOS loader (vbe off, vbe on, vbe list,
      vbe set xxx).
      autoload font (/boot/fonts) based on resolution and font size.
      Add command loadfont (set font by file) and
      variable screen.font (set font by size). Pass loaded font to kernel.
      
      Export variables:
      screen.height
      screen.width
      screen.depth
      
      Add gfx primitives to draw the screen and put png image on the screen.
      Rework menu draw to iterate list of consoles to enamble device specific
      output.
      
      Probably something else I forgot...
      
      Relnotes: yes
      Differential Revision: https://reviews.freebsd.org/D27420
      3630506b
  5. 01 Jan, 2021 1 commit
  6. 14 Oct, 2020 1 commit
  7. 28 Sep, 2020 1 commit
    • Warner Losh's avatar
      Fix video on PCI heuristic · d53ed735
      Warner Losh authored
      The video on PCI heuristic was broken. It was supposed to infer a
      video device when the last element of the path was a PCI DEVICE PATH
      node. However, the last node in the device path is an END node, so
      this heuristic never fired.
      
      This leads, among other things, to bhyve only producing output in the
      serial connection once we leave the boot loader. This restores the
      dual headed boot on bhyve + UEFI (as we did in 11.2), but will favor
      serial in the absence of other config which may be a change from 11.2.
      
      MFC After: 3 days
      Differential Revision: https://reviews.freebsd.org/D26572
      d53ed735
  8. 23 Sep, 2020 1 commit
  9. 21 Sep, 2020 1 commit
    • Toomas Soome's avatar
      loader: zfs should support bootonce an nextboot · e307eb94
      Toomas Soome authored
      bootonce feature is temporary, one time boot, activated by
      "bectl activate -t BE", "bectl activate -T BE" will reset the bootonce flag.
      
      By default, the bootonce setting is reset on attempt to boot and the next
      boot will use previously active BE.
      
      By setting zfs_bootonce_activate="YES" in rc.conf, the bootonce BE will
      be set permanently active.
      
      bootonce dataset name is recorded in boot pool labels, bootenv area.
      
      in case of nextboot, the nextboot_enable boolean variable is recorded in
      freebsd:nvstore nvlist, also stored in boot pool label bootenv area.
      On boot, the loader will process /boot/nextboot.conf if nextboot_enable
      is "YES", and will set nextboot_enable to "NO", preventing /boot/nextboot.conf
      processing on next boot.
      
      bootonce and nextboot features are usable in both UEFI and BIOS boot.
      
      To use bootonce/nextboot features, the boot loader needs to be updated on disk;
      if loader.efi is stored on ESP, then ESP needs to be updated and
      for BIOS boot, stage2 (zfsboot or gptzfsboot) needs to be updated
      (gpart or other tools).
      
      At this time, only lua loader is updated.
      
      Sponsored by:	Netflix, Klara Inc.
      Differential Revision:	https://reviews.freebsd.org/D25512
      e307eb94
  10. 18 Aug, 2020 1 commit
    • Mariusz Zaborski's avatar
      zfs: add an option to the bootloader to rewind the ZFS checkpoint · 277f38ab
      Mariusz Zaborski authored
      The checkpoints are another way of keeping the state of ZFS.
      During the rewind, the pool has to be exported.
      This makes checkpoints unusable when using ZFS as root.
      Add the option to rewind the ZFS checkpoint at the boot time.
      If checkpoint exists, a new option for rewinding a checkpoint will appear in
      the bootloader menu.
      We fully support boot environments.
      If the rewind option is selected, the boot loader will show a list of
      boot environments that existed before the checkpoint.
      
      Reviewed by:	tsoome, allanjude, kevans (ok with high-level overview)
      Differential Revision:	https://reviews.freebsd.org/D24920
      277f38ab
  11. 06 Jul, 2020 1 commit
    • Mitchell Horne's avatar
      RISC-V boot1.efi and loader.efi support · 2192efc0
      Mitchell Horne authored
      This implementation doesn't have any major deviations from the other EFI
      ports. I've copied the boilerplate from arm and arm64.
      
      I've tested this with the following boot flows:
      OpenSBI (M-mode) -> u-boot (S-mode) -> loader.efi -> FreeBSD
      OpenSBI (M-mode) -> u-boot (S-mode) -> boot1.efi -> loader.efi -> FreeBSD
      
      Due to the way that u-boot handles secondary CPUs, OpenSBI >= v0.7 is required,
      as the HSM extension is needed to bring them up explicitly. Because of this,
      using BBL as the SBI implementation will not be possible. Additionally, there
      are a few recent u-boot changes that are required as well, all of which will be
      present in the upcoming v2020.07 release.
      
      Looks good:	emaste
      Differential Revision:	https://reviews.freebsd.org/D25135
      2192efc0
  12. 20 Jun, 2020 1 commit
    • Toomas Soome's avatar
      loader: create single zfs nextboot implementation · 3830659e
      Toomas Soome authored
      We should have nextboot feature implemented in libsa zfs code.
      To get there, I have created zfs_nextboot() implementation based on
      two sources, our current simple textual string based approach with added
      structured boot label PAD structure from OpenZFS.
      
      Secondly, all nvlist details are moved to separate source file and
      restructured a bit. This is done to provide base support to add nvlist
      add/update feature in followup updates.
      
      And finally, the zfsboot/gptzfsboot disk access functions are swapped to use
      libi386 and libsa.
      
      Sponsored by:	Netflix, Klara Inc.
      Differential Revision:	https://reviews.freebsd.org/D25324
      3830659e
  13. 14 Mar, 2020 1 commit
  14. 08 Mar, 2020 1 commit
    • Simon J. Gerraty's avatar
      veloader use vectx API for kernel and modules · afc571b1
      Simon J. Gerraty authored
      The vectx API, computes the hash for verifying a file as it is read.
      This avoids the overhead of reading files twice - once to verify, then
      again to load.
      
      For doing an install via loader, avoiding the need to rewind
      large files is critical.
      
      This API is only used for modules, kernel and mdimage as these are the
      biggest files read by the loader.
      The reduction in boot time depends on how expensive the I/O is
      on any given platform.  On a fast VM we see 6% improvement.
      
      For install via loader the first file to be verified is likely to be the
      kernel, so some of the prep work (finding manifest etc) done by
      verify_file() needs to be factored so it can be reused for
      vectx_open().
      
      For missing or unrecognized fingerprint entries, we fail
      in vectx_open() unless verifying is disabled.
      
      Otherwise fingerprint check happens in vectx_close() and
      since this API is only used for files which must be verified
      (VE_MUST) we panic if we get an incorrect hash.
      
      Reviewed by:	imp,tsoome
      MFC after:	1 week
      Sponsored by:	Juniper Networks
      Differential Revision:	https://reviews.freebsd.org//D23827
      afc571b1
  15. 20 Feb, 2020 1 commit
    • Warner Losh's avatar
      Create ptov() function. · ed2a6576
      Warner Losh authored
      Create a ptov() function. It's basically the same as the btx PTOV
      macro, but works everywhere. smbios needs this to translate addresses,
      but the translation differs between BIOS booting and EFI booting. Make
      it a function so one smbios.o can be used everywhere. Provide
      definitions for it in the two loaders affected.
      
      Differential Revision: https://reviews.freebsd.org/D23660
      ed2a6576
  16. 12 Feb, 2020 1 commit
    • Kyle Evans's avatar
      efiloader: don't execute hooks when setting currdev/loaddev · 6b197e58
      Kyle Evans authored
      We still need to set the hooks to prevent improper manipulations thereafter
      at the loader prompt, but as it is we're actively preventing loaddev from
      being set correctly in some circumstances (ZFS in particular) and doing more
      work than needed with currdev -- that hook in particular validates it as a
      correct device, which we can assume isn't needed in this context.
      
      Reviewed by:	imp, sigsys@gmail.com
      Submitted/Diagnosed by:	sigsys@gmail.com
      Differential Revision:	https://reviews.freebsd.org/D23390
      6b197e58
  17. 06 Dec, 2019 1 commit
  18. 28 Nov, 2019 1 commit
  19. 08 Nov, 2019 1 commit
    • Emmanuel Vadot's avatar
      loader.efi: Default to serial if we don't have a ConOut variable · 14fb9485
      Emmanuel Vadot authored
      In the EFI implementation in U-Boot no ConOut efi variable is created,
      this cause loader to fallback to TERM_EMU implementation which is very
      very very slow (and uses the ConOut device in the system table anyway).
      The UEFI spec aren't clear as if this variable needs to exists or not.
      
      Reviewed by:	imp, kevans
      14fb9485
  20. 02 Nov, 2019 1 commit
    • Toomas Soome's avatar
      loader: fall back to term_emu on efi console with serial backend · b9f745fd
      Toomas Soome authored
      In case of efi console having serial backend (video + serial or only serial),
      we need to stick with old emulator till we can draw console.
      
      Eventually we would need to get console terminal emulator to be removed
      from serial console because the serial link already has the terminal.
      
      However, we need to implement comconsole on all efi platforms first, then
      we need the ability to draw console, so we do not have to use SimpleTextOutput
      protocol (which will write both on video and serial in case of multiplexed
      ComOut).
      
      Differential Revision:	https://reviews.freebsd.org/D22161
      b9f745fd
  21. 24 Oct, 2019 2 commits
  22. 17 Oct, 2019 1 commit
  23. 05 Sep, 2019 1 commit
    • Toomas Soome's avatar
      loader: use teken teminal emulator for x86 and uefi · 56758831
      Toomas Soome authored
      Replace mini cons25 emulator with teken, this does enable us proper console
      terminal for loader and will make it possible to implement different
      back end callbacks to draw to screen.
      
      At this time we still only "draw" in text mode.
      56758831
  24. 08 Aug, 2019 1 commit
    • Marcin Wojtas's avatar
      Verify files loaded in chain command. · 435672e3
      Marcin Wojtas authored
      The chain command can be used to chain load another binary.
      If veriexec is enabled we should verify it first.
      Note that on EFI systems the verification was already done
      through firmware, assuming that Secure Boot was enabled there.
      
      Submitted by: Kornel Duleba <mindal@semihalf.com>
      Reviewed by: sjg
      MFC after: 1 week
      Obtained from: Semihalf
      Differential Revision: https://reviews.freebsd.org/D20952
      435672e3
  25. 06 Aug, 2019 1 commit
    • Toomas Soome's avatar
      loader.efi: replace HandleProtocol() with OpenProtocol() · 110d56cb
      Toomas Soome authored
      The HandleProtocol() is deprecated interface and we should use OpenProtocol()
      instead. Moreover, in some firmware implementation(s), the HandleProtocol()
      does return device path using static storage, so we can not keep the value
      returned there. With same firmware, the OpenProtocol() does return data we
      do not need to clone.
      
      Reviewed by:	imp
      Differential Revision:	https://reviews.freebsd.org/D21162
      110d56cb
  26. 24 Jun, 2019 1 commit
  27. 02 May, 2019 1 commit
    • Kyle Evans's avatar
      stand: correct mis-merge from r346879 · 83475ff1
      Kyle Evans authored
      Small mis-merge from multiple WIP resulted in block io media handles getting
      double-initialized. This resulted in some installations oddly landing at the
      mountroot prompt.
      
      Reported by:	ler
      Reviewed by:	imp
      83475ff1
  28. 29 Apr, 2019 3 commits
    • Warner Losh's avatar
      Implement uefi_ignore_boot_mgr env variable. · 4ecd512f
      Warner Losh authored
      When set, we ignore all the hints that the UEFI boot manager has set
      for us. We also always fail back to the OK prompt when we can't find
      the right thing to boot rather than failing back to the UEFI boot
      manager. This has the side effect of also expanding the cases where we
      fail back to the OK prompt to include when we're booted under UEFI,
      but UEFI::BootCurrent isn't set in the environment and we can't find a
      proper place to boot from.
      
      Reviewed by: bcran
      Differential Revision: https://reviews.freebsd.org/D20016
      4ecd512f
    • Warner Losh's avatar
      Implement uefi_rootdev · bc6053b3
      Warner Losh authored
      If uefi_rootdev is set in the environment, then treat it like a device
      path. Convert the string to a device path and see if we can find a
      device that matches. If so, use that device at our root dev no matter
      what. If it's bad in any way, the boot will fail.
      
      Reviewed by: bcran
      Differential Revision: https://reviews.freebsd.org/D20016
      bc6053b3
    • Warner Losh's avatar
      Read in and parse /efi/freebsd/loader.env from the boot device's · 8ac2d6f5
      Warner Losh authored
      partition as if it were on the command line.
      
      Fetch FreeBSD-LoaderEnv UEFI enviornment variable. If set, read in
      loader environment variables from it. Otherwise read in
      /efi/freebsd/loader.env. Both are read relative to the device
      loader.efi loaded from (they aren't full UEFI device paths)
      
      Next fetch FreeBSD-NextLoaderEnv UEFI environment variable. If
      present, read the file it points to in as above and delete the UEFI
      environment variable so it only happens once.
      
      This lets one set environment variables in the bootloader.
      Unfortunately, we don't have all the mechanisms in place to parse the
      file, nor do we have the magic pattern matching in place that
      loader.conf has. Variables are of the form foo=bar. No quotes are
      supported, so spaces aren't allowed, for example. Also, variables like
      foo_load=yes are intercepted when we parse the loader.conf file and
      things are done based on that. Since those aren't done here, variables
      that cause an action to happen won't work.
      
      Reviewed by: bcran
      Differential Revision: https://reviews.freebsd.org/D20016
      8ac2d6f5
  29. 25 Apr, 2019 2 commits
  30. 22 Apr, 2019 2 commits
    • Warner Losh's avatar
      Create boot_img as a global variable · 59a05bdf
      Warner Losh authored
      Get the information from the image that we're booting and store it in
      a global variable. Prefer using this to passing it around. Remove the
      special case for zfs that set the preferred boot handle by having it
      uses this global variable diretly.
      
      Reviewed by: kevans@
      Differential Revision: https://reviews.freebsd.org/D20015
      59a05bdf
    • Warner Losh's avatar
      Move setting of console earlier in boot. · 36d37160
      Warner Losh authored
      There's no reason we can't setup the console first thing after the
      arch flags are setup. We set it undconditionally to efi. This is a
      good default, and will get us error messages to at least the efi
      console no matter what. This will also prime the pump so that as other
      variables are set, they will take effect and the console will be
      correct as soon as those env vars are set. Also remove the redundant
      setting of the console to efi when we know the console is efi.
      
      Differential Revision: https://reviews.freebsd.org/D20014
      36d37160
  31. 20 Apr, 2019 1 commit
    • Warner Losh's avatar
      Start to reduce the number of #ifdef EFI_ZFS_BOOT · 3d384d51
      Warner Losh authored
      There's a number of EFI_ZFS_BOOT #ifdefs that aren't needed, or can be
      eliminated with some trivial #defines. Remove the EFI_ZFS_BOOT ifdefs
      that aren't needed. Replace libzfs.h include which is not safe to
      include without EFI_ZFS_BOOT with efizfs.h which is and now
      conditionally included libzfs.h. Define efizfs_set_preferred away
      and define efi_zfs_probe to NULL when ZFS is compiled out.
      3d384d51
  32. 07 Apr, 2019 1 commit
  33. 24 Mar, 2019 1 commit
    • Ian Lepore's avatar
      Distinguish between "no partition" and "choose best partition" with a constant. · 14243f8d
      Ian Lepore authored
      The values of the d_slice and d_partition fields of a disk_devdesc have a
      few values with special meanings in the disk_open() routine. Through various
      evolutions of the loader code over time, a d_partition value of -1 has
      meant both "use the first ufs partition found in the bsd label" and "don't
      open a bsd partition at all, open the raw slice."
      
      This defines a new special value of -2 to mean open the raw slice, and it
      gives symbolic names to all the special values used in d_slice and
      d_partition, and adjusts all existing uses of those fields to use the new
      constants.
      
      The phab review for this timed out without being accepted, but I'm still
      citing it below because there is useful commentary there.
      
      Differential Revision:	https://reviews.freebsd.org/D19262
      14243f8d
  34. 06 Mar, 2019 1 commit
    • Marcin Wojtas's avatar
      Extend libsecureboot(old libve) to obtain trusted certificates from UEFI and implement revocation · 13ea0450
      Marcin Wojtas authored
      UEFI related headers were copied from edk2.
      
      A new build option "MK_LOADER_EFI_SECUREBOOT" was added to allow
      loading of trusted anchors from UEFI.
      
      Certificate revocation support is also introduced.
      The forbidden certificates are loaded from dbx variable.
      Verification fails in two cases:
      
      There is a direct match between cert in dbx and the one in the chain.
      The CA used to sign the chain is found in dbx.
      One can also insert a hash of TBS section of a certificate into dbx.
      In this case verifications fails only if a direct match with a
      certificate in chain is found.
      
      Submitted by: Kornel Duleba <mindal@semihalf.com>
      Reviewed by: sjg
      Obtained from: Semihalf
      Sponsored by: Stormshield
      Differential Revision:	https://reviews.freebsd.org/D19093
      13ea0450
  35. 04 Feb, 2019 1 commit
    • Warner Losh's avatar
      Regularize the Netflix copyright · 52467047
      Warner Losh authored
      Use recent best practices for Copyright form at the top of
      the license:
      1. Remove all the All Rights Reserved clauses on our stuff. Where we
         piggybacked others, use a separate line to make things clear.
      2. Use "Netflix, Inc." everywhere.
      3. Use a single line for the copyright for grep friendliness.
      4. Use date ranges in all places for our stuff.
      
      Approved by: Netflix Legal (who gave me the form), adrian@ (pmc files)
      52467047