efi_loader: Ensure efi_dp_find_obj() finds exact matches
authorAlexander Graf <agraf@suse.de>
Mon, 11 Dec 2017 13:29:46 +0000 (14:29 +0100)
committerAlexander Graf <agraf@suse.de>
Sat, 16 Dec 2017 21:51:19 +0000 (22:51 +0100)
commit905cb9e1720294d244bc9273c45dc76c33f6034e
tree78b292746edcc51ff54aeb0302e63d632abaf16d
parent52a250afa53215190e1714ee2c858ab0bbfa0953
efi_loader: Ensure efi_dp_find_obj() finds exact matches

When calling efi_dp_find_obj(), we usually want to find the *exact* match
of an object for a given device path. However, I ran into a nasty corner case
where I had the following objects with paths available:

Handle 0x9feffa70
  /HardwareVendor(e61d73b9-a384-4acc-aeab-82e828f3628b)[0: ]/USB(6,0)/EndEntire
Handle 0x9feffb58
  /HardwareVendor(e61d73b9-a384-4acc-aeab-82e828f3628b)[0: ]/USB(6,0)/HD(1,800,32000,2de808cb00000000,1,1)/EndEntire

and was searching for

  /HardwareVendor(e61d73b9-a384-4acc-aeab-82e828f3628b)[0: ]/USB(6,0)/HD(1,800,32000,2de808cb00000000,1,1)/EndEntire

But because our device path search looked for any substring match, it would
return

  /HardwareVendor(e61d73b9-a384-4acc-aeab-82e828f3628b)[0: ]/USB(6,0)/EndEntire

because that path is a full substring of the path we were searching for.

So this patch adapts the device path search logic to always look for exact
matches first. The way we distinguish between those cases is by looking at
whether our caller actually deals with remainders.

As a side effect, the code as is from all I can tell now never does a
substring match anymore, because it always gets called with rem=NULL, so
we always only do exact matches now.

Reported-by: Jonathan Gray <jsg@jsg.id.au>
Signed-off-by: Alexander Graf <agraf@suse.de>
lib/efi_loader/efi_device_path.c