Re: [PATCH] Add fwupdate and Mok GUID's to the EFI variable immutable whitelist
On Tue, 22 Mar, at 09:36:25PM, Mario Limonciello wrote: > > Actually, I think this patch should be discarded unless there is a > desire to make the kernel work with older userspace tools. > > I later realized that efivar 0.22 will actually handle working with > immutable variables properly. This means that mokutil 0.2 won't work > with this kernel commit, but mokutil 0.3 which uses efivar > (https://github.com/lcp/mokutil/commit/7b49e834284659527c9f7cf554f223748c00564b) > should work properly. > > fwupdate works properly in most instances except for an install time > cleanup script that removes stale variables. This is fixed with a > trivial change: > https://github.com/rhinstaller/fwupdate/pull/50/commits/535d3a0f9c096d452cc7e2b5be79cf964e2d6d5b Indeed. Given that the kernel patch works around such a serious problem, I'm inclined to encourage distributions to upgrade mokutil and fwupdate.
Re: [PATCH] Add fwupdate and Mok GUID's to the EFI variable immutable whitelist
On Tue, 22 Mar, at 09:36:25PM, Mario Limonciello wrote: > > Actually, I think this patch should be discarded unless there is a > desire to make the kernel work with older userspace tools. > > I later realized that efivar 0.22 will actually handle working with > immutable variables properly. This means that mokutil 0.2 won't work > with this kernel commit, but mokutil 0.3 which uses efivar > (https://github.com/lcp/mokutil/commit/7b49e834284659527c9f7cf554f223748c00564b) > should work properly. > > fwupdate works properly in most instances except for an install time > cleanup script that removes stale variables. This is fixed with a > trivial change: > https://github.com/rhinstaller/fwupdate/pull/50/commits/535d3a0f9c096d452cc7e2b5be79cf964e2d6d5b Indeed. Given that the kernel patch works around such a serious problem, I'm inclined to encourage distributions to upgrade mokutil and fwupdate.
Re: [PATCH] Add fwupdate and Mok GUID's to the EFI variable immutable whitelist
On 03/22/2016 04:37 PM, Limonciello, Mario wrote:
> ed8b0de5a33d2a2557dce7f9429dca8cb5bc5879 caused all variables to be
> immutable by default. This causes problems with userspace applications
> mokutil and fwupdate.
> ---
> drivers/firmware/efi/vars.c | 2 ++
> include/linux/efi.h | 8
> 2 files changed, 10 insertions(+)
>
> diff --git a/drivers/firmware/efi/vars.c b/drivers/firmware/efi/vars.c
> index 0ac594c..16bd2a9 100644
> --- a/drivers/firmware/efi/vars.c
> +++ b/drivers/firmware/efi/vars.c
> @@ -199,6 +199,8 @@ static const struct variable_validate variable_validate[]
> = {
> { EFI_GLOBAL_VARIABLE_GUID, "PlatformLang", validate_ascii_string },
> { EFI_GLOBAL_VARIABLE_GUID, "Timeout", validate_uint16 },
> { LINUX_EFI_CRASH_GUID, "*", NULL },
> + { FWUPDATE_GUID, "fwupdate*", NULL },
> + { MOK_GUID, "Mok*", NULL },
> { NULL_GUID, "", NULL },
> };
>
> diff --git a/include/linux/efi.h b/include/linux/efi.h
> index 1626474..c882cb0 100644
> --- a/include/linux/efi.h
> +++ b/include/linux/efi.h
> @@ -575,6 +575,14 @@ void efi_native_runtime_setup(void);
> EFI_GUID(0x8be4df61, 0x93ca, 0x11d2, \
>0xaa, 0x0d, 0x00, 0xe0, 0x98, 0x03, 0x2b, 0x8c)
>
> +#define FWUPDATE_GUID \
> + EFI_GUID(0x0abba7dc, 0xe516, 0x4167, \
> + 0xbb, 0xf5, 0x4d, 0x9d, 0x1c, 0x73, 0x94, 0x16)
> +
> +#define MOK_GUID \
> + EFI_GUID(0x605dab50, 0xe046, 0x4300, \
> + 0xab, 0xb6, 0x3d, 0xd8, 0x10, 0xdd, 0x8b, 0x23)
> +
> #define UV_SYSTEM_TABLE_GUID \
> EFI_GUID(0x3b13a7d4, 0x633e, 0x11dd, \
>0x93, 0xec, 0xda, 0x25, 0x56, 0xd8, 0x95, 0x93)
Actually, I think this patch should be discarded unless there is a
desire to make the kernel work with older userspace tools.
I later realized that efivar 0.22 will actually handle working with
immutable variables properly. This means that mokutil 0.2 won't work
with this kernel commit, but mokutil 0.3 which uses efivar
(https://github.com/lcp/mokutil/commit/7b49e834284659527c9f7cf554f223748c00564b)
should work properly.
fwupdate works properly in most instances except for an install time
cleanup script that removes stale variables. This is fixed with a
trivial change:
https://github.com/rhinstaller/fwupdate/pull/50/commits/535d3a0f9c096d452cc7e2b5be79cf964e2d6d5b
Re: [PATCH] Add fwupdate and Mok GUID's to the EFI variable immutable whitelist
On 03/22/2016 04:37 PM, Limonciello, Mario wrote:
> ed8b0de5a33d2a2557dce7f9429dca8cb5bc5879 caused all variables to be
> immutable by default. This causes problems with userspace applications
> mokutil and fwupdate.
> ---
> drivers/firmware/efi/vars.c | 2 ++
> include/linux/efi.h | 8
> 2 files changed, 10 insertions(+)
>
> diff --git a/drivers/firmware/efi/vars.c b/drivers/firmware/efi/vars.c
> index 0ac594c..16bd2a9 100644
> --- a/drivers/firmware/efi/vars.c
> +++ b/drivers/firmware/efi/vars.c
> @@ -199,6 +199,8 @@ static const struct variable_validate variable_validate[]
> = {
> { EFI_GLOBAL_VARIABLE_GUID, "PlatformLang", validate_ascii_string },
> { EFI_GLOBAL_VARIABLE_GUID, "Timeout", validate_uint16 },
> { LINUX_EFI_CRASH_GUID, "*", NULL },
> + { FWUPDATE_GUID, "fwupdate*", NULL },
> + { MOK_GUID, "Mok*", NULL },
> { NULL_GUID, "", NULL },
> };
>
> diff --git a/include/linux/efi.h b/include/linux/efi.h
> index 1626474..c882cb0 100644
> --- a/include/linux/efi.h
> +++ b/include/linux/efi.h
> @@ -575,6 +575,14 @@ void efi_native_runtime_setup(void);
> EFI_GUID(0x8be4df61, 0x93ca, 0x11d2, \
>0xaa, 0x0d, 0x00, 0xe0, 0x98, 0x03, 0x2b, 0x8c)
>
> +#define FWUPDATE_GUID \
> + EFI_GUID(0x0abba7dc, 0xe516, 0x4167, \
> + 0xbb, 0xf5, 0x4d, 0x9d, 0x1c, 0x73, 0x94, 0x16)
> +
> +#define MOK_GUID \
> + EFI_GUID(0x605dab50, 0xe046, 0x4300, \
> + 0xab, 0xb6, 0x3d, 0xd8, 0x10, 0xdd, 0x8b, 0x23)
> +
> #define UV_SYSTEM_TABLE_GUID \
> EFI_GUID(0x3b13a7d4, 0x633e, 0x11dd, \
>0x93, 0xec, 0xda, 0x25, 0x56, 0xd8, 0x95, 0x93)
Actually, I think this patch should be discarded unless there is a
desire to make the kernel work with older userspace tools.
I later realized that efivar 0.22 will actually handle working with
immutable variables properly. This means that mokutil 0.2 won't work
with this kernel commit, but mokutil 0.3 which uses efivar
(https://github.com/lcp/mokutil/commit/7b49e834284659527c9f7cf554f223748c00564b)
should work properly.
fwupdate works properly in most instances except for an install time
cleanup script that removes stale variables. This is fixed with a
trivial change:
https://github.com/rhinstaller/fwupdate/pull/50/commits/535d3a0f9c096d452cc7e2b5be79cf964e2d6d5b
[PATCH] Add fwupdate and Mok GUID's to the EFI variable immutable whitelist
ed8b0de5a33d2a2557dce7f9429dca8cb5bc5879 caused all variables to be
immutable by default. This causes problems with userspace applications
mokutil and fwupdate.
---
drivers/firmware/efi/vars.c | 2 ++
include/linux/efi.h | 8
2 files changed, 10 insertions(+)
diff --git a/drivers/firmware/efi/vars.c b/drivers/firmware/efi/vars.c
index 0ac594c..16bd2a9 100644
--- a/drivers/firmware/efi/vars.c
+++ b/drivers/firmware/efi/vars.c
@@ -199,6 +199,8 @@ static const struct variable_validate variable_validate[] =
{
{ EFI_GLOBAL_VARIABLE_GUID, "PlatformLang", validate_ascii_string },
{ EFI_GLOBAL_VARIABLE_GUID, "Timeout", validate_uint16 },
{ LINUX_EFI_CRASH_GUID, "*", NULL },
+ { FWUPDATE_GUID, "fwupdate*", NULL },
+ { MOK_GUID, "Mok*", NULL },
{ NULL_GUID, "", NULL },
};
diff --git a/include/linux/efi.h b/include/linux/efi.h
index 1626474..c882cb0 100644
--- a/include/linux/efi.h
+++ b/include/linux/efi.h
@@ -575,6 +575,14 @@ void efi_native_runtime_setup(void);
EFI_GUID(0x8be4df61, 0x93ca, 0x11d2, \
0xaa, 0x0d, 0x00, 0xe0, 0x98, 0x03, 0x2b, 0x8c)
+#define FWUPDATE_GUID \
+ EFI_GUID(0x0abba7dc, 0xe516, 0x4167, \
+0xbb, 0xf5, 0x4d, 0x9d, 0x1c, 0x73, 0x94, 0x16)
+
+#define MOK_GUID \
+ EFI_GUID(0x605dab50, 0xe046, 0x4300, \
+0xab, 0xb6, 0x3d, 0xd8, 0x10, 0xdd, 0x8b, 0x23)
+
#define UV_SYSTEM_TABLE_GUID \
EFI_GUID(0x3b13a7d4, 0x633e, 0x11dd, \
0x93, 0xec, 0xda, 0x25, 0x56, 0xd8, 0x95, 0x93)
--
2.7.3
[PATCH] Add fwupdate and Mok GUID's to the EFI variable immutable whitelist
ed8b0de5a33d2a2557dce7f9429dca8cb5bc5879 caused all variables to be
immutable by default. This causes problems with userspace applications
mokutil and fwupdate.
---
drivers/firmware/efi/vars.c | 2 ++
include/linux/efi.h | 8
2 files changed, 10 insertions(+)
diff --git a/drivers/firmware/efi/vars.c b/drivers/firmware/efi/vars.c
index 0ac594c..16bd2a9 100644
--- a/drivers/firmware/efi/vars.c
+++ b/drivers/firmware/efi/vars.c
@@ -199,6 +199,8 @@ static const struct variable_validate variable_validate[] =
{
{ EFI_GLOBAL_VARIABLE_GUID, "PlatformLang", validate_ascii_string },
{ EFI_GLOBAL_VARIABLE_GUID, "Timeout", validate_uint16 },
{ LINUX_EFI_CRASH_GUID, "*", NULL },
+ { FWUPDATE_GUID, "fwupdate*", NULL },
+ { MOK_GUID, "Mok*", NULL },
{ NULL_GUID, "", NULL },
};
diff --git a/include/linux/efi.h b/include/linux/efi.h
index 1626474..c882cb0 100644
--- a/include/linux/efi.h
+++ b/include/linux/efi.h
@@ -575,6 +575,14 @@ void efi_native_runtime_setup(void);
EFI_GUID(0x8be4df61, 0x93ca, 0x11d2, \
0xaa, 0x0d, 0x00, 0xe0, 0x98, 0x03, 0x2b, 0x8c)
+#define FWUPDATE_GUID \
+ EFI_GUID(0x0abba7dc, 0xe516, 0x4167, \
+0xbb, 0xf5, 0x4d, 0x9d, 0x1c, 0x73, 0x94, 0x16)
+
+#define MOK_GUID \
+ EFI_GUID(0x605dab50, 0xe046, 0x4300, \
+0xab, 0xb6, 0x3d, 0xd8, 0x10, 0xdd, 0x8b, 0x23)
+
#define UV_SYSTEM_TABLE_GUID \
EFI_GUID(0x3b13a7d4, 0x633e, 0x11dd, \
0x93, 0xec, 0xda, 0x25, 0x56, 0xd8, 0x95, 0x93)
--
2.7.3
Re: fwupdate
On Tue, Mar 10, 2015 at 10:56:32AM -0400, Peter Jones wrote: > That said, I haven't sent my patch to add the capsule headers to gnu-efi > yet, so you won't get very far - I'll make sure and send those this > week, hopefully today. Slight correction, I did actually do that - it's in the current upstream repo. -- Peter -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: fwupdate
On Mon, Mar 09, 2015 at 06:54:12PM -0700, Roy Franz wrote: > On Mon, Mar 9, 2015 at 2:23 PM, Borislav Petkov wrote: > > + pjones. > > > > So reportedly, there is already a capsule-loading thing which doesn't > > need the kernel at all: > > > > https://github.com/rhinstaller/fwupdate > > > > So why are we even wasting energy with this discussion here? > > > > -- > > Regards/Gruss, > > Boris. > > The network boot case can be taken care of as Peter described (ie > taking network device paths, instead of just file paths), so > this should work for those cases as well. There would be some extra > setup, as for this to work the EFI firmware update program > would need to be run at boot (via the BootNext variable), but I don't > think this is unreasonable. > It looks like GnuEFI now supports Aarch64, so building the firmware > update utility shouldn't be a problem. Peter - have you you tried > building > this on Aarch64 yet? If not I'll give it a try. I tried a very early version of the code on an Aarch64 machine where I also wrote the firmware feature, and it basically seemed to work, modulo my buggy firmware ;) I haven't tried it recently, but I do have all the right makefile goo in there to build it reasonably, and I don't know of any reason it wouldn't work. That said, I haven't sent my patch to add the capsule headers to gnu-efi yet, so you won't get very far - I'll make sure and send those this week, hopefully today. Also note that fwupdate is still a very active work in progress; it's not /quite/ ready for general purpose deployment even in a "trying it out" phase, but I'm hoping to get to that point this week or next - in particular the code on github right now assumes an HD() device path with a specific partition guid. That is, it has literally worked on two machines ever. Yes, it's a thing we intend on supporting, but it's not /there/ yet. > I think there is some value in using runtime update capsule calls, as > that will help make sure the feature works in the firmware. I think > with arm64 servers in an early stage of development, we can influence > the firmware support of various features by using them. I don't know > that this is a sufficient reason, but if runtime capsules are never > used then there is a good chance that there will be many broken > implementations. That's certainly potentially valid, but it doesn't necessarily yield something we (the OS vendor deploying features to customers) can actually depend on. Usually firmware features like this become generally usable when there's some market maker causing hardware vendors to have a large interest in making sure the feature works. That means most often the carrot being dangled is MS Logo certification marketing dollars, and the testing all follows from the situations they require to work. So far, it appears MS has been using this only from Boot Services, so that's what works. It looks to me like that's probably likely to remain true. One reason is peripheral cards. My expectation (though possibly unfounded) is that MS will require peripheral cards to use this same update mechanism for option ROMs, and even if they don't I know some vendors are working on it. To do so, the card's UEFI driver (supplied on the option ROM) will be using EFI's Firmware Management Protocol (FMP) to participate in the capsule update system. The 2.5 spec drafts that include FMP and UpdateCapsule() support for FMP state that capsule updates for FMP aren't required to be available during runtime - it expressly calls out the case where CAPSULE_FLAGS_PERSIST_ACROSS_RESET is used. (I don't think I'm allowed to quote language from drafts in public, but if you have a copy, I'm talking about the last paragraph of 22.2.1) In my mind this means most implementations are going to always try to do updates from before ExitBootServices() for those option types - anything else and you're just in an error case where you have to do that anyway. So again, I'm not dead-set against having a kernel implementation, but I think its use cases are severely constrained, and most of the time most implementations will want to do this before the kernel loads. The best case for doing it in the kernel is embedded devices where a) there's no persistent storage except the flash part you're updating anyway, and b) the vendor nominally controls both the firmware and the deployed OS. -- Peter, heading back to the code. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: fwupdate
On Mon, Mar 09, 2015 at 06:54:12PM -0700, Roy Franz wrote: On Mon, Mar 9, 2015 at 2:23 PM, Borislav Petkov b...@alien8.de wrote: + pjones. So reportedly, there is already a capsule-loading thing which doesn't need the kernel at all: https://github.com/rhinstaller/fwupdate So why are we even wasting energy with this discussion here? -- Regards/Gruss, Boris. The network boot case can be taken care of as Peter described (ie taking network device paths, instead of just file paths), so this should work for those cases as well. There would be some extra setup, as for this to work the EFI firmware update program would need to be run at boot (via the BootNext variable), but I don't think this is unreasonable. It looks like GnuEFI now supports Aarch64, so building the firmware update utility shouldn't be a problem. Peter - have you you tried building this on Aarch64 yet? If not I'll give it a try. I tried a very early version of the code on an Aarch64 machine where I also wrote the firmware feature, and it basically seemed to work, modulo my buggy firmware ;) I haven't tried it recently, but I do have all the right makefile goo in there to build it reasonably, and I don't know of any reason it wouldn't work. That said, I haven't sent my patch to add the capsule headers to gnu-efi yet, so you won't get very far - I'll make sure and send those this week, hopefully today. Also note that fwupdate is still a very active work in progress; it's not /quite/ ready for general purpose deployment even in a trying it out phase, but I'm hoping to get to that point this week or next - in particular the code on github right now assumes an HD() device path with a specific partition guid. That is, it has literally worked on two machines ever. Yes, it's a thing we intend on supporting, but it's not /there/ yet. I think there is some value in using runtime update capsule calls, as that will help make sure the feature works in the firmware. I think with arm64 servers in an early stage of development, we can influence the firmware support of various features by using them. I don't know that this is a sufficient reason, but if runtime capsules are never used then there is a good chance that there will be many broken implementations. That's certainly potentially valid, but it doesn't necessarily yield something we (the OS vendor deploying features to customers) can actually depend on. Usually firmware features like this become generally usable when there's some market maker causing hardware vendors to have a large interest in making sure the feature works. That means most often the carrot being dangled is MS Logo certification marketing dollars, and the testing all follows from the situations they require to work. So far, it appears MS has been using this only from Boot Services, so that's what works. It looks to me like that's probably likely to remain true. One reason is peripheral cards. My expectation (though possibly unfounded) is that MS will require peripheral cards to use this same update mechanism for option ROMs, and even if they don't I know some vendors are working on it. To do so, the card's UEFI driver (supplied on the option ROM) will be using EFI's Firmware Management Protocol (FMP) to participate in the capsule update system. The 2.5 spec drafts that include FMP and UpdateCapsule() support for FMP state that capsule updates for FMP aren't required to be available during runtime - it expressly calls out the case where CAPSULE_FLAGS_PERSIST_ACROSS_RESET is used. (I don't think I'm allowed to quote language from drafts in public, but if you have a copy, I'm talking about the last paragraph of 22.2.1) In my mind this means most implementations are going to always try to do updates from before ExitBootServices() for those option types - anything else and you're just in an error case where you have to do that anyway. So again, I'm not dead-set against having a kernel implementation, but I think its use cases are severely constrained, and most of the time most implementations will want to do this before the kernel loads. The best case for doing it in the kernel is embedded devices where a) there's no persistent storage except the flash part you're updating anyway, and b) the vendor nominally controls both the firmware and the deployed OS. -- Peter, heading back to the code. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: fwupdate
On Tue, Mar 10, 2015 at 10:56:32AM -0400, Peter Jones wrote: That said, I haven't sent my patch to add the capsule headers to gnu-efi yet, so you won't get very far - I'll make sure and send those this week, hopefully today. Slight correction, I did actually do that - it's in the current upstream repo. -- Peter -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: fwupdate
On Mon, Mar 9, 2015 at 2:23 PM, Borislav Petkov wrote: > + pjones. > > So reportedly, there is already a capsule-loading thing which doesn't > need the kernel at all: > > https://github.com/rhinstaller/fwupdate > > So why are we even wasting energy with this discussion here? > > -- > Regards/Gruss, > Boris. The network boot case can be taken care of as Peter described (ie taking network device paths, instead of just file paths), so this should work for those cases as well. There would be some extra setup, as for this to work the EFI firmware update program would need to be run at boot (via the BootNext variable), but I don't think this is unreasonable. It looks like GnuEFI now supports Aarch64, so building the firmware update utility shouldn't be a problem. Peter - have you you tried building this on Aarch64 yet? If not I'll give it a try. I think there is some value in using runtime update capsule calls, as that will help make sure the feature works in the firmware. I think with arm64 servers in an early stage of development, we can influence the firmware support of various features by using them. I don't know that this is a sufficient reason, but if runtime capsules are never used then there is a good chance that there will be many broken implementations. Roy -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
fwupdate
+ pjones. So reportedly, there is already a capsule-loading thing which doesn't need the kernel at all: https://github.com/rhinstaller/fwupdate So why are we even wasting energy with this discussion here? -- Regards/Gruss, Boris. ECO tip #101: Trim your mails when you reply. -- -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
fwupdate
+ pjones. So reportedly, there is already a capsule-loading thing which doesn't need the kernel at all: https://github.com/rhinstaller/fwupdate So why are we even wasting energy with this discussion here? -- Regards/Gruss, Boris. ECO tip #101: Trim your mails when you reply. -- -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: fwupdate
On Mon, Mar 9, 2015 at 2:23 PM, Borislav Petkov b...@alien8.de wrote: + pjones. So reportedly, there is already a capsule-loading thing which doesn't need the kernel at all: https://github.com/rhinstaller/fwupdate So why are we even wasting energy with this discussion here? -- Regards/Gruss, Boris. The network boot case can be taken care of as Peter described (ie taking network device paths, instead of just file paths), so this should work for those cases as well. There would be some extra setup, as for this to work the EFI firmware update program would need to be run at boot (via the BootNext variable), but I don't think this is unreasonable. It looks like GnuEFI now supports Aarch64, so building the firmware update utility shouldn't be a problem. Peter - have you you tried building this on Aarch64 yet? If not I'll give it a try. I think there is some value in using runtime update capsule calls, as that will help make sure the feature works in the firmware. I think with arm64 servers in an early stage of development, we can influence the firmware support of various features by using them. I don't know that this is a sufficient reason, but if runtime capsules are never used then there is a good chance that there will be many broken implementations. Roy -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
