From: Jan Beulich <jbeulich@suse.com>
To: Trammell Hudson <hudson@trmm.net>
Cc: "Roger Pau Monné" <roger.pau@citrix.com>,
"xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
Subject: Re: [PATCH v3 4/4] efi: Do not use command line if secure boot is enabled.
Date: Mon, 14 Sep 2020 14:16:22 +0200 [thread overview]
Message-ID: <deab1428-c329-b1e5-aa92-866887836f8e@suse.com> (raw)
In-Reply-To: <fbcs49Ps8wnxc2ZwN9e7ptr8gwGxRSVEg6J58A8W84wo2RYwkSUS0bhHeocFpGVXsd4YWDL72FkYOHeye8VzWmy_EUyHKMNeBnAzspklDls=@trmm.net>
On 14.09.2020 13:36, Trammell Hudson wrote:
> On Monday, September 14, 2020 6:24 AM, Roger Pau Monné <roger.pau@citrix.com> wrote:
>> On Mon, Sep 07, 2020 at 03:00:27PM -0400, Trammell Hudson wrote:
>> [...]
>>> - static const __initconst EFI_GUID global_guid = EFI_GLOBAL_VARIABLE;
>>> - uint8_t secboot, setupmode;
>>> - UINTN secboot_size = sizeof(secboot);
>>> - UINTN setupmode_size = sizeof(setupmode);
>>> -
>>> - if ( efi_rs->GetVariable(L"SecureBoot", (EFI_GUID *)&global_guid, NULL, &secboot_size, &secboot) != EFI_SUCCESS )
>>
>> I'm slightly worried about the dropping of the const here, and the
>> fact that the variable is placed in initconst section. Isn't it
>> dangerous that the EFI services will try to write to it?
>
> The EFI services do not try to write to it; the API doesn't
> even bother with const-correctness. The prototype has IN
> and OUT, but they are not used for constness:
>
> typedef EFI_STATUS(EFIAPI * EFI_GET_VARIABLE) (
> IN CHAR16 *VariableName,
> IN EFI_GUID *VendorGuid,
> OUT UINT32 *Attributes,
> OPTIONAL IN OUT UINTN *DataSize,
> OUT VOID *Data OPTIONAL)
And I think this underlying aspect if the reason for a lot of apparently
missing const in our EFI interfacing code.
Jan
next prev parent reply other threads:[~2020-09-14 12:16 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-09-07 19:00 [PATCH v3 0/4] efi: Unified Xen hypervisor/kernel/initrd images Trammell Hudson
2020-09-07 19:00 ` [PATCH v3 1/4] x86/xen.lds.S: Work around binutils build id alignment bug Trammell Hudson
2020-09-08 9:04 ` Jan Beulich
2020-09-08 9:30 ` Trammell Hudson
2020-09-08 12:29 ` Jan Beulich
2020-09-14 9:14 ` Trammell Hudson
2020-09-14 9:15 ` Jan Beulich
2020-09-07 19:00 ` [PATCH v3 2/4] efi/boot.c: add file.need_to_free and split display_file_info() Trammell Hudson
2020-09-14 9:05 ` Roger Pau Monné
2020-09-14 10:45 ` Trammell Hudson
2020-09-07 19:00 ` [PATCH v3 3/4] efi: Enable booting unified hypervisor/kernel/initrd images Trammell Hudson
2020-09-14 10:06 ` Roger Pau Monné
2020-09-14 11:19 ` Trammell Hudson
2020-09-14 12:14 ` Jan Beulich
2020-09-07 19:00 ` [PATCH v3 4/4] efi: Do not use command line if secure boot is enabled Trammell Hudson
2020-09-14 10:24 ` Roger Pau Monné
2020-09-14 11:36 ` Trammell Hudson
2020-09-14 12:16 ` Jan Beulich [this message]
-- strict thread matches above, loose matches on Subject: below --
2020-09-07 17:49 Trammell Hudson
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=deab1428-c329-b1e5-aa92-866887836f8e@suse.com \
--to=jbeulich@suse.com \
--cc=hudson@trmm.net \
--cc=roger.pau@citrix.com \
--cc=xen-devel@lists.xenproject.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.