From: Matt Fleming <matt@codeblueprint.co.uk>
To: Colin King <colin.king@canonical.com>
Cc: "H . Peter Anvin" <hpa@zytor.com>,
Thomas Gleixner <tglx@linutronix.de>,
Ingo Molnar <mingo@redhat.com>,
x86@kernel.org, linux-efi@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] x86/efi: initialize status to ensure garbage is not returned on small size
Date: Wed, 27 Jul 2016 15:38:13 +0100 [thread overview]
Message-ID: <20160727143813.GG31759@codeblueprint.co.uk> (raw)
In-Reply-To: <1469009466-19980-1-git-send-email-colin.king@canonical.com>
On Wed, 20 Jul, at 11:11:06AM, Colin Ian King wrote:
> From: Colin Ian King <colin.king@canonical.com>
>
> Although very unlikey, if size is too small or zero, then we end up with
> status not being set and returning garbage. Instead, initializing status to
> EFI_INVALID_PARAMETER to indicate that size is invalid in the calls to
> setup_uga32 and setup_uga64.
>
> Signed-off-by: Colin Ian King <colin.king@canonical.com>
> ---
> arch/x86/boot/compressed/eboot.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/arch/x86/boot/compressed/eboot.c b/arch/x86/boot/compressed/eboot.c
> index ff574da..ec6d2ef 100644
> --- a/arch/x86/boot/compressed/eboot.c
> +++ b/arch/x86/boot/compressed/eboot.c
> @@ -578,7 +578,7 @@ setup_uga32(void **uga_handle, unsigned long size, u32 *width, u32 *height)
> efi_guid_t uga_proto = EFI_UGA_PROTOCOL_GUID;
> unsigned long nr_ugas;
> u32 *handles = (u32 *)uga_handle;;
> - efi_status_t status;
> + efi_status_t status = EFI_INVALID_PARAMETER;
> int i;
>
> first_uga = NULL;
> @@ -623,7 +623,7 @@ setup_uga64(void **uga_handle, unsigned long size, u32 *width, u32 *height)
> efi_guid_t uga_proto = EFI_UGA_PROTOCOL_GUID;
> unsigned long nr_ugas;
> u64 *handles = (u64 *)uga_handle;;
> - efi_status_t status;
> + efi_status_t status = EFI_INVALID_PARAMETER;
> int i;
>
> first_uga = NULL;
Can this ever happen in practice? This would imply that
locate_protocol() found EFI_UGA_PROTOCOL_GUID but that the size
returned is utterly bogus?
If so, I have no problem applying the patch but want to make sure
we're not tricking ourselves into thinking we're being protected from
something when we're not.
next prev parent reply other threads:[~2016-07-27 14:38 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-07-20 10:11 [PATCH] x86/efi: initialize status to ensure garbage is not returned on small size Colin King
2016-07-27 14:38 ` Matt Fleming [this message]
[not found] ` <20160727143813.GG31759-mF/unelCI9GS6iBeEJttW/XRex20P6io@public.gmane.org>
2016-07-27 14:50 ` Colin Ian King
[not found] ` <ada10a97-f3d3-91af-51b8-6d2f973c95a1-Z7WLFzj8eWMS+FvcfC7Uqw@public.gmane.org>
2016-08-01 11:50 ` Matt Fleming
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=20160727143813.GG31759@codeblueprint.co.uk \
--to=matt@codeblueprint.co.uk \
--cc=colin.king@canonical.com \
--cc=hpa@zytor.com \
--cc=linux-efi@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=tglx@linutronix.de \
--cc=x86@kernel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).