Copyrights and licenses

2020-04-12 Thread Eric McCorkle
As part of my work on FreeBSD (re)-integration, I would like to pull in
some code from the FreeBSD loader for GELI volumes.  Specifically, there
were some changes a while back that did things like store keys and check
new volumes against the cached keys.  I also noticed when I looked at
the current GELI code in grub that it doesn't seem to be zeroing out
keys properly when done with them.

This of course introduces a licensing question.  The FreeBSD loader code
is under the 2-clause BSD license.  I noticed that the current GELI code
seems to incorporate a 2-clause BSD banner; is it therefore acceptable
to simply update the banner?



signature.asc
Description: OpenPGP digital signature
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel


Re: [PATCH] Add functionality for passing information to FreeBSD kernel

2020-04-05 Thread Eric McCorkle
A couple of things...

First, these calls are in grub_cmd_freebsd, not grub_freebsd_boot.  They
seem to get dropped on the floor when placed in the latter, and I'm not
sure why.  This is going to cause some problems, because the EFI memory
map (which is produced by exit_boot_services) needs to get written out
as another metadata item, or else FreeBSD won't be able to use EFI
runtime services.  From the looks of things, this is a larger
restructuring than what I've done here.

Also, the GELI keys need to get passed into the kernel via keybuf
metadata.  I think I want to pull GELI code in from the FreeBSD loader,
as it's structured to do that (the current implementation has some
issues as well: it leaves key material on the stack).


On 4/5/20 5:10 PM, e...@metricspace.net wrote:
> From: Eric McCorkle 
> 
> Fixes GRUB with FreeBSD to pass EFI frame buffer info into the kernel at boot.
> 
> ---
>  grub-core/loader/i386/bsd.c| 81 ++
>  include/grub/i386/freebsd_linker.h |  9 
>  2 files changed, 90 insertions(+)
> 
> diff --git a/grub-core/loader/i386/bsd.c b/grub-core/loader/i386/bsd.c
> index eb82391db..d3dc1d27f 100644
> --- a/grub-core/loader/i386/bsd.c
> +++ b/grub-core/loader/i386/bsd.c
> @@ -76,6 +76,21 @@ static grub_uint32_t openbsd_root;
>  static struct grub_relocator *relocator = NULL;
>  static struct grub_openbsd_ramdisk_descriptor openbsd_ramdisk;
>  
> +#ifdef GRUB_MACHINE_EFI
> +struct freebsd_efi_fb
> +{
> +  grub_uint64_t fb_addr;
> +  grub_uint64_t fb_size;
> +  grub_uint32_t fb_height;
> +  grub_uint32_t fb_width;
> +  grub_uint32_t fb_stride;
> +  grub_uint32_t fb_mask_red;
> +  grub_uint32_t fb_mask_green;
> +  grub_uint32_t fb_mask_blue;
> +  grub_uint32_t fb_mask_reserved;
> +};
> +#endif
> +
>  struct bsd_tag
>  {
>struct bsd_tag *next;
> @@ -591,6 +606,63 @@ freebsd_get_zfs (void)
>grub_free (uuid);
>  }
>  
> +static grub_err_t
> +grub_freebsd_setup_fw_handle (void)
> +{
> +  grub_err_t err = GRUB_ERR_NONE;
> +#ifdef GRUB_MACHINE_EFI
> +
> +  /* Add EFI firmware handle */
> +  err = grub_bsd_add_meta (FREEBSD_MODINFO_METADATA |
> +   FREEBSD_MODINFOMD_FW_HANDLE,
> +   _efi_system_table,
> +   sizeof (grub_efi_system_table));
> +#endif
> +  return err;
> +}
> +
> +static grub_err_t
> +grub_freebsd_setup_video (void)
> +{
> +  grub_err_t err = GRUB_ERR_NONE;
> +
> +#ifdef GRUB_MACHINE_EFI
> +
> +  /* Add EFI frame buffer info */
> +  struct freebsd_efi_fb efifb;
> +  struct grub_video_mode_info mode_info;
> +  void *framebuffer;
> +
> +  err = grub_video_get_info_and_fini (_info, );
> +
> +  if (err)
> +return err;
> +
> +  efifb.fb_addr = (grub_addr_t) framebuffer;
> +  efifb.fb_height = mode_info.height;
> +  efifb.fb_width = mode_info.width;
> +  efifb.fb_stride = mode_info.pitch / mode_info.bytes_per_pixel;
> +  efifb.fb_size = mode_info.height * mode_info.pitch;
> +  efifb.fb_mask_red =
> +((1 << mode_info.red_mask_size) - 1) <<
> +mode_info.red_field_pos;
> +  efifb.fb_mask_green =
> +((1 << mode_info.green_mask_size) - 1) <<
> +mode_info.green_field_pos;
> +  efifb.fb_mask_blue =
> +((1 << mode_info.blue_mask_size) - 1) <<
> +mode_info.blue_field_pos;
> +  efifb.fb_mask_reserved =
> +((1 << mode_info.reserved_mask_size) - 1) <<
> +mode_info.reserved_field_pos;
> +  err = grub_bsd_add_meta (FREEBSD_MODINFO_METADATA |
> +   FREEBSD_MODINFOMD_EFI_FB,
> +   , sizeof (efifb));
> +#endif
> +
> +  return err;
> +}
> +
>  static grub_err_t
>  grub_freebsd_boot (void)
>  {
> @@ -1563,11 +1635,20 @@ grub_cmd_freebsd (grub_extcmd_context_t ctxt, int 
> argc, char *argv[])
> if (err)
>   return err;
>  
> +  err = grub_freebsd_setup_fw_handle ();
> +  if (err)
> +return err;
> +
> +  err = grub_freebsd_setup_video ();
> +  if (err)
> +return err;
> +
> err = grub_bsd_add_meta (FREEBSD_MODINFO_METADATA |
>  FREEBSD_MODINFOMD_KERNEND, , len);
> if (err)
>   return err;
>   }
> +
>grub_bsd_get_device (_biosdev, , , );
>freebsd_zfsguid = 0;
>if (!is_64bit)
> diff --git a/include/grub/i386/freebsd_linker.h 
> b/include/grub/i386/freebsd_linker.h
> index 3c1eb64b6..2dab21678 100644
> --- a/include/grub/i386/freebsd_linker.h
> +++ b/include/grub/i386/freebsd_linker.h
> @@ -65,9 +65,18 @@
>  #define FREEBSD_MODINFOMD_HO

Re: Patch to add newer i386 modinfo types

2020-04-05 Thread Eric McCorkle
Will do.  I want to try and get the TODOs in the code taken care of
first, though.

Also, FYI, I just tested the FreeBSD port with clang, and it worked.

I'm boot-testing on a Librem 15 (amd64) with the original AMI BIOS (not
coreboot).  I'd have to look up the exact version.

On 4/5/20 4:42 AM, Paul Menzel wrote:
> Dear Eric,
> 
> 
> Am 05.04.20 um 03:54 schrieb Eric McCorkle:
>> Here's a first attempt at a patch that adds the code necessary to pass
>> the EFI framebuffer info into the FreeBSD kernel.  I have tested this
>> successfully on real hardware.
> 
> Nice. Great work. What hardware (also firmware version) did you test with?
> 
> Could you please send the changes as git formatted patches. That way
> they can be easily applied, and there is a commit message. `git
> format-patch` and `git send-email` should do that for you.
> 
> 
> Kind regards,
> 
> Paul



signature.asc
Description: OpenPGP digital signature
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel


Re: Patch to add newer i386 modinfo types

2020-04-04 Thread Eric McCorkle
Here's a first attempt at a patch that adds the code necessary to pass
the EFI framebuffer info into the FreeBSD kernel.  I have tested this
successfully on real hardware.

On 4/4/20 6:57 PM, Eric McCorkle wrote:
> I'm working on trying to get GRUB to properly set up the EFI framebuffer
> info for the freebsd kernel.
> 
> This is a patch to one of the includes that adds updates the modinfo
> types to match the FreeBSD kernel sources.  Hopefully the EFI
> framebuffer patch will come shortly.
> 
> 
> ___
> Grub-devel mailing list
> Grub-devel@gnu.org
> https://lists.gnu.org/mailman/listinfo/grub-devel
> 
--- grub-core/loader/i386/bsd.c.orig	2019-04-23 04:54:47.0 -0400
+++ grub-core/loader/i386/bsd.c	2020-04-04 21:47:56.073361000 -0400
@@ -76,6 +76,29 @@
 static struct grub_relocator *relocator = NULL;
 static struct grub_openbsd_ramdisk_descriptor openbsd_ramdisk;
 
+#ifdef GRUB_MACHINE_EFI
+struct freebsd_efi_fb
+{
+  grub_uint64_t fb_addr;
+  grub_uint64_t fb_size;
+  grub_uint32_t fb_height;
+  grub_uint32_t fb_width;
+  grub_uint32_t fb_stride;
+  grub_uint32_t fb_mask_red;
+  grub_uint32_t fb_mask_green;
+  grub_uint32_t fb_mask_blue;
+  grub_uint32_t fb_mask_reserved;
+};
+
+struct freebsd_efi_map_header
+{
+  grub_uint64_t memory_size;
+  grub_uint64_t descriptor_size;
+  grub_uint32_t descriptor_version;
+  grub_uint8_t data[];
+};
+#endif
+
 struct bsd_tag
 {
   struct bsd_tag *next;
@@ -1567,7 +1590,56 @@
    FREEBSD_MODINFOMD_KERNEND, , len);
 	  if (err)
 	return err;
+
+  /* TODO: add keys to keybuf */
+#ifdef GRUB_MACHINE_EFI
+  /* Add EFI firmware handle */
+  err = grub_bsd_add_meta (FREEBSD_MODINFO_METADATA |
+   FREEBSD_MODINFOMD_FW_HANDLE,
+   _efi_system_table,
+   sizeof (grub_efi_system_table));
+
+  if (err)
+return err;
+
+  /* Add EFI frame buffer info */
+  struct freebsd_efi_fb efifb;
+  struct grub_video_mode_info mode_info;
+  void *framebuffer;
+
+  err = grub_video_get_info_and_fini (_info, );
+
+  if (err)
+return err;
+
+  efifb.fb_addr = (grub_addr_t) framebuffer;
+  efifb.fb_height = mode_info.height;
+  efifb.fb_width = mode_info.width;
+  efifb.fb_stride = mode_info.pitch / mode_info.bytes_per_pixel;
+  efifb.fb_size = mode_info.height * mode_info.pitch;
+  efifb.fb_mask_red =
+((1 << mode_info.red_mask_size) - 1) <<
+mode_info.red_field_pos;
+  efifb.fb_mask_green =
+((1 << mode_info.green_mask_size) - 1) <<
+mode_info.green_field_pos;
+  efifb.fb_mask_blue =
+((1 << mode_info.blue_mask_size) - 1) <<
+mode_info.blue_field_pos;
+  efifb.fb_mask_reserved =
+((1 << mode_info.reserved_mask_size) - 1) <<
+mode_info.reserved_field_pos;
+  err = grub_bsd_add_meta (FREEBSD_MODINFO_METADATA |
+   FREEBSD_MODINFOMD_EFI_FB,
+   , sizeof (efifb));
+
+  if (err)
+return err;
+
+  /* TODO: add EFI map */
+#endif
 	}
+
   grub_bsd_get_device (_biosdev, , , );
   freebsd_zfsguid = 0;
   if (!is_64bit)



signature.asc
Description: OpenPGP digital signature
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel


Patch to add newer i386 modinfo types

2020-04-04 Thread Eric McCorkle
I'm working on trying to get GRUB to properly set up the EFI framebuffer
info for the freebsd kernel.

This is a patch to one of the includes that adds updates the modinfo
types to match the FreeBSD kernel sources.  Hopefully the EFI
framebuffer patch will come shortly.
--- include/grub/i386/freebsd_linker.h.orig	2020-04-04 18:30:09.528583000 -0400
+++ include/grub/i386/freebsd_linker.h	2020-04-04 18:33:16.300613000 -0400
@@ -65,9 +65,18 @@
 #define FREEBSD_MODINFOMD_HOWTO		0x0007	/* boothowto */
 #define FREEBSD_MODINFOMD_KERNEND	0x0008	/* kernend */
 #define FREEBSD_MODINFOMD_SHDR		0x0009	/* section header table */
+#define FREEBSD_MODINFOMD_CTORS_ADDR0x000a  /* address of .ctors */
+#define FREEBSD_MODINFOMD_CTORS_SIZE0x000b  /* size of .ctors */
+#define FREEBSD_MODINFOMD_FW_HANDLE 0x000c  /* firmware dependent handle */
+#define FREEBSD_MODINFOMD_KEYBUF0x000d  /* crypto key intake buffer */
 #define FREEBSD_MODINFOMD_NOCOPY	0x8000	/* don't copy this metadata to the kernel */
 
 #define FREEBSD_MODINFOMD_SMAP		0x1001
+#define FREEBSD_MODINFOMD_SMAP_XATTR0x1002
+#define FREEBSD_MODINFOMD_DTBP  0x1003
+#define FREEBSD_MODINFOMD_EFI_MAP   0x1004
+#define FREEBSD_MODINFOMD_EFI_FB0x1005
+#define FREEBSD_MODINFOMD_EFI_MODULEP   0x1006
 
 #define FREEBSD_MODINFOMD_DEPLIST	(0x4001 | FREEBSD_MODINFOMD_NOCOPY)  /* depends on */
 


signature.asc
Description: OpenPGP digital signature
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel


FreeBSD support

2019-10-12 Thread Eric McCorkle
Hi all,

I finally got a chance to resume work on FreeBSD support recently.
Here's where things are:

* I can boot on an EFI platform, however, the efifb driver never turns
the screen on, so the screen is blank until the X11 DRM driver takes
over (I know why this is, see below)

* grub_install doesn't properly detect what modules to link into the
image, so you have to manually tell it to load whatever you need to
detect the filesystem (ex: zfs, ufs, bsd, etc)


Other than that, everything is fine as far as I can tell.

As for the screen issue, it comes down to a change that I'm looking into
making.  The FreeBSD kernel has the ability to send data into the kernel
using what amounts to synthetic loadable modules.  It creates ELF images
containing the data synthetically in memory.

This capacity is used in two ways with an EFI boot: to send EFI terminal
data to the efifb driver, and to pass keys from the loader to the
kernel.  The latter is only used for GELI for now, with the older
environment variable method being supported but deprecated.  The EFI
terminal data used to be send in via environment variables, but that was
replaced with the synthetic modules method.

So basically, I need to implement the synthetic modules functionality in
GRUB, assuming it already doesn't exist.

As for the grub_install problem, I suspect that's just a matter of
debugging it on FreeBSD.



signature.asc
Description: OpenPGP digital signature
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel


Re: FreeBSD port work

2019-06-08 Thread Eric McCorkle
On 6/8/19 8:53 AM, Eric McCorkle wrote:

> Basically, you have to treat R_X86_64_PLT32 linker symbols as R_X86_64_32.

I'm sorry, I meant R_X86_64_PC32.



signature.asc
Description: OpenPGP digital signature
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel


Re: FreeBSD port work

2019-06-08 Thread Eric McCorkle
On 6/3/19 6:05 AM, Leif Lindholm wrote:
> Hi Eric,
> 
> Well, feels a bit silly to deal with the other main BSDs and not
> FreeBSD... (especially as it looks like it was supported at some point
> in the past).

A bit of info here: the way the FreeBSD ports system works, we have a
bunch of patch files which get applied to a standard distribution to fix
up any issues.  The port system unpacks the distribution archive,
applies the patches, and builds.  We actually have scripts to create
these patches as part of a porting effort.  That's what these files are.

I also had to do a bit more work to get GRUB to a point where
grub-install works.  Basically, you have to treat R_X86_64_PLT32 linker
symbols as R_X86_64_32.  The reason for this is that binutils is
creating a single R_X86_64_PLT32 symbol for the main, which gets
referenced from _start.  I'll repost that, plus any other work I end up
doing once I get it booting.

Unfortunately, I'm getting a boot hang when it boots the FreeBSD kernel.
 This might be a regression of some kind, so I'm going back to the
FreeBSD port to see if the same behavior happens.  If that fails, I'll
try log messages to figure out what's going on.

> Most of the below is out of my area of knowledge, but the patch seems
> to have some whitespace-only changes (pointed out individually below)
> that should probably be filtered out separately, or dropped.

That's an artifact of my emacs setup, I think.  It auto-deletes trailing
whitespace.  I can undo it.

>> +#include 
>> +
>> +typedef unsigned int uint_t;
>> +typedef uint64_t hrtime_t;
>> +typedef unsigned char uchar_t;
>> +typedef int boolean_t;
> 
> I see these four lines repeated a couple of times below as well, but I
> don't see any code in the tree making use of them. What are they
> needed for? Is there some common header (i.e. grub/cpu/freebsd.h)
> where they could go?
> 

I think this is an artifact of OS differences, so it would make sense
for it to go there.

I will apply these to the git repo and send them as a git-generated
patch once I get a boot working on 2.02.  Not sure how long that'll be;
I don't have a great deal of time to work on this at present.



signature.asc
Description: OpenPGP digital signature
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel


FreeBSD port work

2019-05-31 Thread Eric McCorkle
Hi folks,

I've been doing some work to refurbish the FreeBSD port, and I may take
over maintaining it.  I also want to modify GRUB to pass GELI keys into
the kernel using the newer keybuf mechanism, but that's later (I posted
about this a while back).

Attached are some quick-and-dirty patches I created for getting the
updated port to build in the FreeBSD ports tree.  Note: there's a
"force-label" flag in the grub-install utility which is currently
unimplemented; the old version used a kind of script, but the newer one
is a C file, and I need to do more investigation to figure out how to
implement it in the C file.

If people think any of these patches should go into the main tree, let
me know what I need to do, or how I need to polish them up first and
I'll get it done
--- build-aux/test-driver.o 2013-07-29 08:36:33.775875020 -0400
+++ build-aux/test-driver   2013-07-29 08:35:04.085870311 -0400
@@ -0,0 +1,127 @@
+#! /bin/sh
+# test-driver - basic testsuite driver script.
+
+scriptversion=2012-06-27.10; # UTC
+
+# Copyright (C) 2011-2013 Free Software Foundation, Inc.
+#
+# This program is free software; you can redistribute it and/or modify
+# it under the terms of the GNU General Public License as published by
+# the Free Software Foundation; either version 2, or (at your option)
+# any later version.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with this program.  If not, see .
+
+# As a special exception to the GNU General Public License, if you
+# distribute this file as part of a program that contains a
+# configuration script generated by Autoconf, you may include it under
+# the same distribution terms that you use for the rest of that program.
+
+# This file is maintained in Automake, please report
+# bugs to  or send patches to
+# .
+
+# Make unconditional expansion of undefined variables an error.  This
+# helps a lot in preventing typo-related bugs.
+set -u
+
+usage_error ()
+{
+  echo "$0: $*" >&2
+  print_usage >&2
+  exit 2
+}
+
+print_usage ()
+{
+  cat <$log_file 2>&1
+estatus=$?
+if test $enable_hard_errors = no && test $estatus -eq 99; then
+  estatus=1
+fi
+
+case $estatus:$expect_failure in
+  0:yes) col=$red res=XPASS recheck=yes gcopy=yes;;
+  0:*)   col=$grn res=PASS  recheck=no  gcopy=no;;
+  77:*)  col=$blu res=SKIP  recheck=no  gcopy=yes;;
+  99:*)  col=$mgn res=ERROR recheck=yes gcopy=yes;;
+  *:yes) col=$lgn res=XFAIL recheck=no  gcopy=yes;;
+  *:*)   col=$red res=FAIL  recheck=yes gcopy=yes;;
+esac
+
+# Report outcome to console.
+echo "${col}${res}${std}: $test_name"
+
+# Register the test result, and other relevant metadata.
+echo ":test-result: $res" > $trs_file
+echo ":global-test-result: $res" >> $trs_file
+echo ":recheck: $recheck" >> $trs_file
+echo ":copy-in-global-log: $gcopy" >> $trs_file
+
+# Local Variables:
+# mode: shell-script
+# sh-indentation: 2
+# eval: (add-hook 'write-file-hooks 'time-stamp)
+# time-stamp-start: "scriptversion="
+# time-stamp-format: "%:y-%02m-%02d.%02H"
+# time-stamp-time-zone: "UTC"
+# time-stamp-end: "; # UTC"
+# End:
--- configure.ac.orig   2017-04-24 07:30:15.0 -0400
+++ configure.ac2019-05-27 13:03:39.615962000 -0400
@@ -1787,19 +1787,26 @@
 
 if test x"$libzfs_excuse" = x ; then
   # Only check for system headers if libzfs support has not been disabled.
-  AC_CHECK_HEADERS(libzfs.h libnvpair.h)
+  AC_CHECK_HEADERS(libzfs.h libnvpair.h, [], [], [
+#include 
+
+typedef unsigned int uint_t;
+typedef uint64_t hrtime_t;
+typedef unsigned char uchar_t;
+typedef int boolean_t;
+])
 fi
 
 if test x"$libzfs_excuse" = x ; then
   AC_CHECK_LIB([zfs], [libzfs_init],
[],
-   [libzfs_excuse="need zfs library"])
+   [libzfs_excuse="need zfs library"], [-lavl -lnvpair -luutil 
-lm])
 fi
 
 if test x"$libzfs_excuse" = x ; then
   AC_CHECK_LIB([nvpair], [nvlist_lookup_string],
[],
-   [libzfs_excuse="need nvpair library"])
+   [libzfs_excuse="need nvpair library"], [-lavl -lnvpair -luutil 
-lm])
 fi
 
 if test x"$enable_libzfs" = xyes && test x"$libzfs_excuse" != x ; then
@@ -1812,6 +1819,9 @@
   AC_DEFINE([HAVE_LIBZFS], [1],
 [Define to 1 if you have the ZFS library.])
   LIBNVPAIR="-lnvpair"
+  if test x$host_kernel = xkfreebsd; then
+LIBNVPAIR="$LIBNVPAIR -lavl -luutil -lm"
+  fi
   AC_DEFINE([HAVE_LIBNVPAIR], [1],
 [Define to 1 if you have the NVPAIR library.])
 fi
--- grub-core/gnulib/argp-fmtstream.c.orig
+++ grub-core/gnulib/argp-fmtstream.c
@@ -47,7 +47,11 @@
 #endif
 
 #define INIT_BUF_SIZE 200
+#ifdef __FreeBSD__
+#define PRINTF_SIZE_GUESS 32767
+#else
 #define PRINTF_SIZE_GUESS 150
+#endif
 
 /* 

Re: Integrating a FreeBSD/GELI change

2017-04-01 Thread Eric McCorkle
On 04/01/2017 09:57, Andrei Borzenkov wrote:

> 
> There was proposed patch that stored secret in environment variable that
> was later used by loader (I think; I am not sure whether loader part was
> actually implemented). Search this list for subject
> 
> Patch to support GELI passphrase passthrough​
> 
> from Kris Moore (October 2014)

That was the old method, which was replaced by the new key intake
metadata.  The old way is still supported for the time being, but may be
phased out eventually.



signature.asc
Description: OpenPGP digital signature
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel


Integrating a FreeBSD/GELI change

2017-04-01 Thread Eric McCorkle
Hello,

I've been working on a series of changes designed to expand FreeBSD's
full-disk encryption support via GELI (its preferred disk encryption
mechanism).  One of the important parts of this landed in HEAD last night:

https://github.com/freebsd/freebsd/commit/6a205a32527153697eb4df4114ff0cd3c7cd6fd8

This adds a general mechanism for passing keys into the FreeBSD kernel
at boot.  At present, this is used exclusively by the GELI subsystem.

FreeBSD currently supports full-disk encryption for i386 BIOS.  I am
actively working on EFI support and would like to make sure that GRUB
also supports full-disk encryption as well (as GRUB is our best option
for a coreboot setup).


Basically, to add support for this, I'd need to do two things:

1) Ensure that GRUB can handle an entirely GELI-encrypted disk hosting a
FreeBSD system (I suspect it can, but I've never done a GRUB/GELI setup
before)

2) An additional metadata item needs to get generated when booting the
FreeBSD kernel that contains all the GELI keys.  (For those who don't
know, FreeBSD has a kernel metadata mechanism that is used to pass some
information into the kernel: for example, the EFI console on EFI, some
BIOS information on i386 BIOS, and so on)


I've never submitted a patch to GRUB before, so I'm interested in 1) how
hard would this be, 2) where should I look in the source code, and 3)
what is the procedure for submitting patches like this?


Best,
Eric



signature.asc
Description: OpenPGP digital signature
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel