Re: Discuss support for the linux kernel's EFI Handover Protocol on x86 and ARM
On 11.01.19 20:32, Matthew Garrett wrote: > On Thu, Jan 10, 2019 at 12:59 AM Alexander Graf wrote: >> So really dumb question here: What if we didn't use the MS key? What if >> instead, we just provide a SUSE/openSUSE key and give customers the ability >> to sign their own grub+Linux binaries? > > Then you end up blocking install of any Linux distribution that isn't > big enough to have every ARM server vendor include their keys. This is > the exact reason we chose not to explore this approach on x86 - we > didn't want Red Hat to have privileges that, say, Gentoo didn't. The > problem is somewhat mitigated if systems are guaranteed to be shipped > with Secure Boot disabled, but you then still end up encouraging > vendor lock-in - it becomes difficult to migrate systems from one > distribution to another without manual re-keying. But on the other hand (given we gave people the right tools), wouldn't that also enable end users to secure things down to *their* stack? I you are big-customer and you only want your own big-customer branded Linux to run on your servers, not a stock SUSE or Red Hat or whatever OS, then you would have the ability to easily add your key to the key store. Isn't that a much more preferable approach? I personally would advise OEMs to simply not enable secure boot by default and then have everyone give instructions how to either a) install the distro key and/or b) provide easy means to resign binaries themselves and install those keys At the end of the day, as a customer I care much more about integrity of *my* stack, rather than whether the boot chain is MS approved, no? Alex ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: Discuss support for the linux kernel's EFI Handover Protocol on x86 and ARM
On Thu, Jan 10, 2019 at 12:59 AM Alexander Graf wrote: > So really dumb question here: What if we didn't use the MS key? What if > instead, we just provide a SUSE/openSUSE key and give customers the ability > to sign their own grub+Linux binaries? Then you end up blocking install of any Linux distribution that isn't big enough to have every ARM server vendor include their keys. This is the exact reason we chose not to explore this approach on x86 - we didn't want Red Hat to have privileges that, say, Gentoo didn't. The problem is somewhat mitigated if systems are guaranteed to be shipped with Secure Boot disabled, but you then still end up encouraging vendor lock-in - it becomes difficult to migrate systems from one distribution to another without manual re-keying. ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
[PATCH] bootp: add native DHCPv4 support
From: Andrei Borzenkov
This patch adds support for native DHCPv4 and removes requirement for
BOOTP compatibility support in DHCP server.
There is no provision for selecting preferred server. We take the first
OFFER and try to REQUEST configuration from it. If NAK was received,
transaction is restarted, but if we hit timeout, configuration fails.
It also handles pure BOOTP reply (detected by lack of DHCP message type
option) and proceeds with configuration immedately. I could not test it
because I do not have pure BOOTP server.
Because we need access to DHCP options in multiple places now, it also
factors out DHCP option processing, adding support for option overload.
Timeout handling is now per-interface, with independent timeouts for
both DISCOVER and REQUEST. It should make it more responsive if answer
was delayed initially. Total timeout remains the same as originally, as
well as backoff algorithm, but we poll in fixed 200ms ticks so notice
(successful) reply earlier.
Failure to send packet to interface now does not terminate command (and
leaks memory) but rather simply ignores this interface and continues with
remaining ones if present.
Finally it adds net_dhcp alias with intention to deprecate net_bootp
completely (it would be possible to make net_bootp to actually send BOOTP
packet if someone thinks it is required).
Features not implements:
- DHCP server selection. We take first DHCPOFFER or BOOTPREPLY. No plans
to implement.
- DHCP option concatenation (RFC3396). I do not expect to hit it in real
life and it rather complicates implementation, so let's wait for actual
use case.
- client identifier (RFC6842). So far we expect valid MAC address, which
should be enough to uniquely identify client. It is also not clear how to
generate unique client identifier if we ever need one.
v2: change find_dhcp_option to use subscripts to avoid signed/unsigned
comparison warning.
Should fix "may be used uninitialized" warning (although I could not
reproduce it).
Signed-off-by: Andre Przywara
---
Hi,
this patch is a rebased version of Andrei's work from 2016 [1][2][3].
We have still this issue here where our company DHCP server does not
support the BOOTP protocol, so grub doesn't get a valid IP address.
I took v2 from Andrei of the list, and fixed the minor conflicts during the
rebase. I can confirm that this patch makes the difference between DHCP
working and not:
grub-master> net_bootp
error: couldn't autoconfigure efinet0.
...
grub-patched> net_bootp
grub-patched> net_ls_addr
efinet0:dhcp 00:11:22:33:44:55 10.1.23.42
Also back in the days there were concerns about regressing BOOTP-only
servers. So I took the CMU bootpd[4], disabled the DHCP extensions at
compile time and still got IP addresses in both cases (patched/unpatched).
dhclient on Linux on the other hand was not happy with that server and
ignored the reply. I guess this is as close to a "BOOTP only server" as
we can get in 2019.
I would be very happy if we can get this merged now.
Please let me know if you need more information or any help on this.
Thanks!
Andre.
P.S. The original patch didn't have a Signed-off-by:, so I kept it that
way. Added mine for legal reason, feel free to drop it.
[1] http://lists.gnu.org/archive/html/grub-devel/2016-01/msg00035.html
[2] http://lists.gnu.org/archive/html/grub-devel/2016-03/msg00276.html
[3] http://lists.gnu.org/archive/html/grub-devel/2016-04/msg00066.html
[4] https://packages.debian.org/jessie/bootp
grub-core/net/bootp.c | 759 --
grub-core/net/ip.c| 2 +-
include/grub/net.h| 14 +-
3 files changed, 528 insertions(+), 247 deletions(-)
diff --git a/grub-core/net/bootp.c b/grub-core/net/bootp.c
index 9e2fdb795..890df715b 100644
--- a/grub-core/net/bootp.c
+++ b/grub-core/net/bootp.c
@@ -25,25 +25,107 @@
#include
#include
-static void
-parse_dhcp_vendor (const char *name, const void *vend, int limit, int *mask)
+struct grub_dhcp_discover_options
+ {
+ grub_uint8_t magic[4];
+ struct
+{
+ grub_uint8_t code;
+ grub_uint8_t len;
+ grub_uint8_t data;
+} GRUB_PACKED message_type;
+grub_uint8_t end;
+ } GRUB_PACKED;
+
+struct grub_dhcp_request_options
+ {
+grub_uint8_t magic[4];
+struct
+ {
+ grub_uint8_t code;
+ grub_uint8_t len;
+ grub_uint8_t data;
+ } GRUB_PACKED message_type;
+struct
+ {
+ grub_uint8_t type;
+ grub_uint8_t len;
+ grub_uint32_t data;
+ } GRUB_PACKEDserver_identifier;
+struct
+ {
+ grub_uint8_t type;
+ grub_uint8_t len;
+ grub_uint32_t data;
+ } GRUB_PACKEDrequested_ip;
+struct
+ {
+ grub_uint8_t type;
+ grub_uint8_t len;
+ grub_uint8_t data[7];
+ } GRUB_PACKEDparameter_request;
+grub_uint8_t end;
+ } GRUB_PACKED;
+
+enum
+ {
+GRUB_DHCP_MESSAGE_UNKNOWN,
+GRUB_DHCP_MESSAGE_DISCOVER,
+GRUB_DHCP_MESSAGE_OFFER,
+
Re: Discuss support for the linux kernel's EFI Handover Protocol on x86 and ARM
On Fri, 11 Jan 2019 at 11:58, Leif Lindholm wrote: > > On Thu, Jan 10, 2019 at 09:59:38AM +0100, Alexander Graf wrote: > > > Am 10.01.2019 um 09:12 schrieb Michael Chang : > > > > > > Hi, > > > > > > With the advent of new verifier framework and shim lock protocol support > > > to the grub's community, we are driving to the world of UEFI Secure > > > Boot, well, almost .. > > > > > > There is a missing piece in the puzzle remaining, that is booting linux > > > kernel via it's own EFI Handover Protocol's entry. I don't understand what this means. > Strictly speaking, > > > the interface is not part of the UEFI Secure Boot, but we have to use it > > > to avoid problem of using UEFI LoadImage Protocol, which will not work > > > with shim and it's Machine Owner Key (MOK) as they are not part of > > > firmware's KEK and db. > > The 'problem' of using the UEFI LoadImage protocol is the whole point of secure boot. Shim and GRUB essentially bypasses UEFI secure boot entirely, but in a controlled way. > > So really dumb question here: What if we didn't use the MS key? What > > if instead, we just provide a SUSE/openSUSE key and give customers > > the ability to sign their own grub+Linux binaries? > > > > Then we would only need to lobby with platform vendors to include > > our public key in the delivered Keystore in parallel and everything > > would "just work". > > > > The only reason shim needs to provide its own key management is that > > on most x86 systems, we (and customers) don't have control over the > > keystore, right? We can just push to not have that problem on ARM. > > Sure. That's a valid (and I think Ard would say preferable) decision, > and should "just work" with upstream GRUB. But that's for each distro > to decide. > > > Am I missing anything? > > As I understand it, there was a concern with the wording in UEFI > 2.(3?, 4?) that made it possible to interpret it such that only one key > had to be supported. > > It all comes down to who wants to make sure the key is already in > shipped systems.. > I will repeat the same thing I have been saying since 2013: carrying over Shim to other architectures is a mistake. We could have a simple and clean secure boot architecture on arm64, where the firmware authenticates GRUB, and GRUB calls LoadImage() which authenticates the kernel against the firmware keys. All we need for that is to ensure that the distros get their act together, and work with the industry to get Redhat, Canonical and Suse keys into the KEK and/or db databases by default. Instead, we are having this discussion again, how we can circumvent authentication checks so that GRUB can load what are essentially unverified binaries (from the POV of the firmware), authenticated against certificates that are kept in unauthenticated UEFI variables. Canonical is even shipping a GRUB with cosmic and disco now that is signed with their master key, and happily boots anything if shim is not loaded, which makes it impossible to ever move to a model where the canonical key is in the UEFI db rather than in the MOK database. So I strongly suggest that you make things work without shim, relying on a monolithic distro signed GRUB which authenticates against the UEFI database only. Should the need ever arise, we can always introduce shim at a later date. In fact, if I were running a shrink wrapped distro and did not have to rely on MS signed option ROMs, I wouldn't even want the MS key in my UEFI db if all I want to run is SUSE. ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] grub: add grub variable update functionality
Just re-pinging on this ...
P.
On 1/4/19 7:53 AM, Prarit Bhargava wrote:
> Please be aware I am NOT subscribed to grub-devel.
>
> P.
>
> ---8<---
>
> Customers and users of the kernel are commenting that there is no way to
> update
> a grub variable without copy and pasting the existing data.
>
> For example,
>
> [10:57 AM root@intel-wildcatpass-07 grub-2.02]# ./grub-editenv list
> saved_entry=0
> next_entry=
> kernelopts=root=/dev/mapper/rhel_intel--wildcatpass--07-root ro
> crashkernel=auto resume=/dev/mapper/rhel_intel--wildcatpass--07-swap
> rd.lvm.lv=rhel_intel-wildcatpass-07/root
> rd.lvm.lv=rhel_intel-wildcatpass-07/swap console=ttyS0,115200n81
> ignore_loglevel
> [10:57 AM root@intel-wildcatpass-07 grub-2.02]# ./grub-editenv - set
> kernelopts="root=/dev/mapper/rhel_intel--wildcatpass--07-root ro
> crashkernel=auto resume=/dev/mapper/rhel_intel--wildcatpass--07-swap
> rd.lvm.lv=rhel_intel-wildcatpass-07/root
> rd.lvm.lv=rhel_intel-wildcatpass-07/swap console=ttyS0,115200n81
> ignore_loglevel newarg"
> [10:57 AM root@intel-wildcatpass-07 grub-2.02]# ./grub-editenv list
> saved_entry=0
> next_entry=
> kernelopts=root=/dev/mapper/rhel_intel--wildcatpass--07-root ro
> crashkernel=auto resume=/dev/mapper/rhel_intel--wildcatpass--07-swap
> rd.lvm.lv=rhel_intel-wildcatpass-07/root
> rd.lvm.lv=rhel_intel-wildcatpass-07/swap console=ttyS0,115200n81
> ignore_loglevel newarg
>
> which is cumbersome.
>
> Add functionality to add to an existing variable. For example,
>
> [10:58 AM root@intel-wildcatpass-07 grub-2.02]# ./grub-editenv list
> saved_entry=0
> next_entry=
> kernelopts=root=/dev/mapper/rhel_intel--wildcatpass--07-root ro
> crashkernel=auto resume=/dev/mapper/rhel_intel--wildcatpass--07-swap
> rd.lvm.lv=rhel_intel-wildcatpass-07/root
> rd.lvm.lv=rhel_intel-wildcatpass-07/swap console=ttyS0,115200n81
> ignore_loglevel
> [10:58 AM root@intel-wildcatpass-07 grub-2.02]# ./grub-editenv - set
> kernelopts+="newarg"
> [10:59 AM root@intel-wildcatpass-07 grub-2.02]# ./grub-editenv list
> saved_entry=0
> next_entry=
> kernelopts=root=/dev/mapper/rhel_intel--wildcatpass--07-root ro
> crashkernel=auto resume=/dev/mapper/rhel_intel--wildcatpass--07-swap
> rd.lvm.lv=rhel_intel-wildcatpass-07/root
> rd.lvm.lv=rhel_intel-wildcatpass-07/swap console=ttyS0,115200n81
> ignore_loglevel newarg
>
> Signed-off-by: Prarit Bhargava
> Cc: mleit...@redhat.com
> Cc: pjo...@redhat.com
> Cc: javi...@redhat.com
> Cc: ar...@redhat.com
> ---
> grub-core/lib/envblk.c| 61 +++
> include/grub/lib/envblk.h | 1 +
> util/grub-editenv.c | 25 +++-
> 3 files changed, 86 insertions(+), 1 deletion(-)
>
> diff --git a/grub-core/lib/envblk.c b/grub-core/lib/envblk.c
> index 230e0e9d9abe..8ddbe2e8267e 100644
> --- a/grub-core/lib/envblk.c
> +++ b/grub-core/lib/envblk.c
> @@ -295,3 +295,64 @@ grub_envblk_iterate (grub_envblk_t envblk,
>p = find_next_line (p, pend);
> }
> }
> +
> +int
> +grub_envblk_add (grub_envblk_t envblk, const char *name, const char *add)
> +{
> + char *current, *new, *ostart, *pstart, *pend;
> + int newsize, ret = 1;
> +
> + /* get a copy of the existing entry */
> + pstart = envblk->buf + sizeof (GRUB_ENVBLK_SIGNATURE) - 1;
> + pstart = grub_strstr (pstart, name);
> + if (!pstart)
> + {
> + ret = -1; /* existing entry not found */
> + goto out;
> + }
> + pend = grub_strchr (pstart, '\n');
> + if (!pend || pend > (envblk->buf + envblk->size))
> + {
> + ret = -1; /* existing entry not found */
> + goto out;
> + }
> +
> + current = grub_zalloc (pend - pstart + 1);
> + if (!current)
> + {
> + ret = -2; /* out of memory */
> + goto out;
> + }
> + grub_strncpy (current, pstart, (int)(pend - pstart));
> +
> + ostart = grub_strchr (current, '=');
> + ostart++;
> +
> + /* create a buffer for the updated entry. */
> + newsize = grub_strlen (ostart) + grub_strlen (add) + 2;
> + new = grub_zalloc (newsize);
> + if (!new)
> +{
> + return -2; /* out of memory */
> + goto out;
> +}
> +
> + grub_strcpy (new, ostart);
> + grub_memcpy (new + grub_strlen (new), " ", 1);
> + grub_strcpy (new + grub_strlen (new), add);
> +
> + /* erase the current entry */
> + grub_envblk_delete (envblk, name);
> + /* add the updated entry */
> + if (!grub_envblk_set (envblk, name, new))
> +{
> + /* restore the original entry. This should always work */
> + grub_envblk_set (envblk, name, ostart);
> + ret = 0;
> +}
> +
> +out:
> + grub_free(new);
> + grub_free(current);
> + return ret;
> +}
> diff --git a/include/grub/lib/envblk.h b/include/grub/lib/envblk.h
> index c3e655921709..2a0f09e3435b 100644
> --- a/include/grub/lib/envblk.h
> +++ b/include/grub/lib/envblk.h
> @@ -37,6 +37,7 @@ void grub_envblk_delete (grub_envblk_t envblk, const char
> *name);
> void grub_envblk_iterate (grub_envblk_t envblk,
>void
