On Mon, 2013-03-18 at 16:02 +0000, Matthew Garrett wrote: > On Mon, 2013-03-18 at 11:36 +0000, Matt Fleming wrote: > > On Fri, 2013-03-15 at 08:57 +0000, David Woodhouse wrote: > > > True. It probably doesn't *matter* because the size is zero so the > > > firmware is just going to ignore the pointer anyway. Although in that > > > case I wonder why we couldn't have just passed NULL. Perhaps we expected > > > that some firmware might do some validation on the pointer before > > > getting to the size check? > > > > I doubt that the firmware checks the validity of pci_handle when size is > > zero, and I agree it's worth passing NULL to silence the warning (which > > is also more explicit that just initialising pci_handle), unless Matthew > > knows of a reason we shouldn't do that? > > No reason I can think of, and any failure will be pretty immediately > obvious. I agree with Matthew that I can think of no reason why a sane implementation of EFI would ever actually dereference the pointer in that case¹. But there's an important difference in the way I phrased it... I can't see why a *sane* implementation of EFI would do a lot of things. Many of which have actually been seen in the field, much to our distress. So I'm starting to to think "hm, maybe we should give it a valid pointer anyway, just in case". Remember: Any sufficiently advanced incompetence is indistinguishable from malice. Assuming malice on the part of firmware authors is a fairly good way to model their potential behaviour. So I'm perfectly prepared that someone would ship an implementation which does *no* input checking, ever. Except for gratuitously checking that particular pointer for NULL and bailing out with an 'invalid parameters' error, even if the length was zero. -- dwmw2 ¹ Although I haven't actually checked the spec to see if the pointer is required to be valid even when length is zero.
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
