[edk2] A possible bug in iSCSI driver implementation

[Ying Guo]

I'm using VMWare EFI firmware to test one project, since the UEFI firmware
currently implemented by VMWware doesn't have a iSCSI driver, so I built
the iSCSI driver from EDK2, and load / connect to VMWare driver
stack. After driver was loaded, I found the firmware stopped responding
while I tried to execute "connect -r" in shell . It looks like very much a
dead loop happend somewhere since I observed that the CPU usage by VMWare
is abnormally hight when it happens.

Afrer few days of investigating (I'm a newbee to UEFI), I noticed that in
the implementation of iSCSI driver, in the file IScsiMisc.c
function IScsiGetTcpConnDevicePath, it copies the gateway and subnetmask to
device path in the code like below:

IP4_COPY_ADDRESS (
&DPathNode->Ipv4.GatewayIpAddress,
&Session->ConfigData.NvData.Gateway
);

IP4_COPY_ADDRESS (
&DPathNode->Ipv4.SubnetMask,
&Session->ConfigData.NvData.SubnetMask
);

However, in the case of underlying IP4 was implemented with older UEFI
spcecification like the VMWare firmware, the IPv4_DEVICE_PATH have neighter
GatewayIpAddress nor SubnetMask, and the Length is 19, rather that 27
defined in latest UEFI specification. Copying the gateway and subnetmask
will break the device path array. Thus in a upper layer driver, namly
SCSIBus driver, it will get into a infinite loop when the driver tries to
iterate through the nodes of device path, which is broken.

So I suggest to check the length of IP4 node before copying gateway and
subnetmask into the node, in this way the iSCSI driver can be used in older
implemenation of UEFI firmwares. This may apply to files in both NetworkPkg
and MdeModulePkg.





Regards,

Ying Guo

[Ye, Ting]

Hi Ying Guo,

Thanks for capturing this. I agree this is a bug and need be fixed. I will follow up to fix this soon.

Best Regards,
Ting

From: Ying Guo [mailto:***@gmail.com]
Sent: Wednesday, July 15, 2015 4:11 PM
To: edk2-***@lists.sourceforge.net
Subject: [edk2] A possible bug in iSCSI driver implementation

I'm using VMWare EFI firmware to test one project, since the UEFI firmware currently implemented by VMWware doesn't have a iSCSI driver, so I built the iSCSI driver from EDK2, and load / connect to VMWare driver stack. After driver was loaded, I found the firmware stopped responding while I tried to execute "connect -r" in shell . It looks like very much a dead loop happend somewhere since I observed that the CPU usage by VMWare is abnormally hight when it happens.

Afrer few days of investigating (I'm a newbee to UEFI), I noticed that in the implementation of iSCSI driver, in the file IScsiMisc.c function IScsiGetTcpConnDevicePath, it copies the gateway and subnetmask to device path in the code like below:

IP4_COPY_ADDRESS (
&DPathNode->Ipv4.GatewayIpAddress,
&Session->ConfigData.NvData.Gateway
);

IP4_COPY_ADDRESS (
&DPathNode->Ipv4.SubnetMask,
&Session->ConfigData.NvData.SubnetMask
);

However, in the case of underlying IP4 was implemented with older UEFI spcecification like the VMWare firmware, the IPv4_DEVICE_PATH have neighter GatewayIpAddress nor SubnetMask, and the Length is 19, rather that 27 defined in latest UEFI specification. Copying the gateway and subnetmask will break the device path array. Thus in a upper layer driver, namly SCSIBus driver, it will get into a infinite loop when the driver tries to iterate through the nodes of device path, which is broken.

So I suggest to check the length of IP4 node before copying gateway and subnetmask into the node, in this way the iSCSI driver can be used in older implemenation of UEFI firmwares. This may apply to files in both NetworkPkg and MdeModulePkg.





Regards,

Ying Guo