lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Mon, 17 Feb 2020 13:09:06 +0200 From: Ilias Apalodimas <ilias.apalodimas@...aro.org> To: Ard Biesheuvel <ardb@...nel.org> Cc: Laszlo Ersek <lersek@...hat.com>, linux-efi <linux-efi@...r.kernel.org>, Linux Kernel Mailing List <linux-kernel@...r.kernel.org>, Leif Lindholm <leif@...iainc.com>, Peter Jones <pjones@...hat.com>, Matthew Garrett <mjg59@...gle.com>, Alexander Graf <agraf@...raf.de>, Heinrich Schuchardt <xypron.glpk@....de>, Daniel Kiper <daniel.kiper@...cle.com>, Arvind Sankar <nivedita@...m.mit.edu>, James Bottomley <James.Bottomley@...senpartnership.com>, Lukas Wunner <lukas@...ner.de> Subject: Re: [PATCH v2 2/3] efi/libstub: Add support for loading the initrd from a device path Hi Ard, [...] > > > > + return EFI_INVALID_PARAMETER; > > > > > > Doesn't return EFI_LOAD_ERROR. > > > > > > > + > > > > + dp = (efi_device_path_protocol_t *)&initrd_dev_path; > > > > + status = efi_bs_call(locate_device_path, &lf2_proto_guid, &dp, &handle); > > > > + if (status != EFI_SUCCESS) > > > > + return status; > > > > > > Seems safe (the only plausible error could be EFI_NOT_FOUND). > > > > > > > + > > > > + status = efi_bs_call(handle_protocol, handle, &lf2_proto_guid, > > > > + (void **)&lf2); > > > > + if (status != EFI_SUCCESS) > > > > + return status; > > > > > > Interesting case; this should never fail... but note, if it does, it > > > returns EFI_UNSUPPORTED, not EFI_NOT_FOUND (if the protocol is missing > > > from the handle). > > > > > > > + > > > > + status = efi_call_proto(lf2, load_file, dp, false, &initrd_size, NULL); > > > > + if (status != EFI_BUFFER_TOO_SMALL) > > > > + return EFI_LOAD_ERROR; > > > > + > > > > + status = efi_allocate_pages(initrd_size, &initrd_addr, max); > > > > + if (status != EFI_SUCCESS) > > > > + return status; > > > > > > Not sure about the efi_allocate_pages() wrapper (?); the UEFI service > > > could return EFI_OUT_OF_RESOURCES. > > > > > > > Hmm, guess I was a bit sloppy with the return codes. The important > > thing is that EFI_NOT_FOUND is only returned in the one specifically > > defined case. > > > > For the record [in case no respin+resend is needed for other reasons], > I intend to update the comment block as below, and keep the code as > is: > Yes i think this makes more sense the return codes are already correct and the fallback is properly triggered. For what it's worth Tested-by: Ilias Apalodimas <ilias.apalodimas@...aro.org> Acked-by: Ilias Apalodimas <ilias.apalodimas@...aro.org> > > * @load_addr: pointer to store the address where the initrd was loaded > * @load_size: pointer to store the size of the loaded initrd > * @max: upper limit for the initrd memory allocation > - * @return: %EFI_SUCCESS if the initrd was loaded successfully, in > which case > - * @load_addr and @load_size are assigned accordingly > - * %EFI_NOT_FOUND if no LoadFile2 protocol exists on the initrd > - * device path > + * @return: %EFI_SUCCESS if the initrd was loaded successfully, in which > + * case @load_addr and @load_size are assigned accordingly > + * %EFI_NOT_FOUND if no LoadFile2 protocol exists on the initrd > + * device path > + * %EFI_INVALID_PARAMETER if load_addr == NULL or load_size == NULL > + * %EFI_OUT_OF_RESOURCES if memory allocation failed > * %EFI_LOAD_ERROR in all other cases Regards /Ilias
Powered by blists - more mailing lists