From mboxrd@z Thu Jan 1 00:00:00 1970 From: David Daney Subject: Re: [PATCH] efi: Add SHIM and image security database GUID definitions Date: Tue, 25 Oct 2016 12:59:18 -0700 Message-ID: <580FB996.9000302@caviumnetworks.com> References: <20161025174209.29073-1-jwboyer@fedoraproject.org> <580FA136.80006@caviumnetworks.com> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: Sender: linux-efi-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org To: Josh Boyer Cc: Ard Biesheuvel , Matt Fleming , "linux-efi-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" List-Id: linux-efi@vger.kernel.org On 10/25/2016 11:25 AM, Josh Boyer wrote: > On Tue, Oct 25, 2016 at 2:15 PM, David Daney wrote: >> On 10/25/2016 11:04 AM, Josh Boyer wrote: >>> >>> On Tue, Oct 25, 2016 at 1:44 PM, Ard Biesheuvel >>> wrote: >>>> >>>> Hi Josh, >>>> >>>> On 25 October 2016 at 18:42, Josh Boyer >>>> wrote: >>>>> >>>>> Add the definitions for shim and image security database, both of which >>>>> are used widely in various Linux distros. >>>>> >>>>> Signed-off-by: Josh Boyer >>>>> --- >>>>> include/linux/efi.h | 3 +++ >>>>> 1 file changed, 3 insertions(+) >>>>> >>>>> diff --git a/include/linux/efi.h b/include/linux/efi.h >>>>> index 2d089487d2da..ce943d5accfd 100644 >>>>> --- a/include/linux/efi.h >>>>> +++ b/include/linux/efi.h >>>>> @@ -592,6 +592,9 @@ void efi_native_runtime_setup(void); >>>>> #define EFI_MEMORY_ATTRIBUTES_TABLE_GUID EFI_GUID(0xdcfa911d, >>>>> 0x26eb, 0x469f, 0xa2, 0x20, 0x38, 0xb7, 0xdc, 0x46, 0x12, 0x20) >>>>> #define EFI_CONSOLE_OUT_DEVICE_GUID EFI_GUID(0xd3b36f2c, >>>>> 0xd551, 0x11d4, 0x9a, 0x46, 0x00, 0x90, 0x27, 0x3f, 0xc1, 0x4d) >>>>> >>>>> +#define EFI_IMAGE_SECURITY_DATABASE_GUID EFI_GUID(0xd719b2cb, >>>>> 0x3d3a, 0x4596, 0xa3, 0xbc, 0xda, 0xd0, 0x0e, 0x67, 0x65, 0x6f) >>>>> +#define EFI_SHIM_LOCK_GUID >>>>> EFI_GUID(0x605dab50, 0xe046, 0x4300, 0xab, 0xb6, 0x3d, 0xd8, 0x10, 0xdd, >>>>> 0x8b, 0x23) >>>>> + >>>> >>>> >>>> Given that this patch is not part of the series, could you explain >>>> what the point is of having these definitions in the kernel if they >>>> are never referenced? >>> >>> >>> Sure. >>> >>> The idea is to make sure a commonly used definition is both accessible >>> and reserved in the kernel. >> >> >> It is not in a uapi directory, so it cannot be used outside of the kernel. > > Fair point. Would there be value in creating an efi.h in uapi so that > it can serve as the canonical source? I doubt it. The kernel source tree is not meant to serve as an authoritative registry for assigned numbers used by external projects. > > josh >