On 6/3/20 5:47 PM, Andrew Fish wrote:
On Jun 2, 2020, at 11:32 PM, Ard Biesheuvel <ard.biesheu...@arm.com
<mailto:ard.biesheu...@arm.com>> wrote:
On 6/3/20 12:28 AM, Andrew Fish wrote:
On Jun 2, 2020, at 6:38 AM, Ard Biesheuvel
<ard.biesheu...@linaro.org <mailto:ard.biesheu...@linaro.org>> wrote:
From: Ard Biesheuvel <ard.biesheu...@arm.com
<mailto:ard.biesheu...@arm.com>>
The ChaosKey driver implements the UEFI driver model, and so it is
not guaranteed that any controllers will be attached to this driver
unless it is connected explicitly. On many platforms today, this is
taken care of by the ConnectAll() call that occurs in the BDS, but
this is not something we should rely on.
So add a protocol notification event that will attempt to connect
the ChaosKey on each USB I/O protocol instance that carries the
expected vendor and product IDs. This still relies on the USB host
controllers to be connected by the platform, which is typically the
case (given that a USB keyboard is required to interrupt the boot)
On platforms where USB is not connected at all by default, it is really
not up to a third party driver to meddle with this, and so relying on
the USB host controllers to have been connected non-reursively is the
best we can do. Note that third party drivers registered via Driver####
can set a 'reconnect all' flag if needed to mitigate this.
Signed-off-by: Ard Biesheuvel <ard.biesheu...@arm.com
<mailto:ard.biesheu...@arm.com>>
---
Unfortunately, the previous approach of connecting a short-form USB
device
path containing the ChaosKey's VID/PID turned out not to be reliable in
practice (it doesn't work at all on ThunderX2 with AMI firmware)
So instead, we have to rely on USB I/O protocols having been
instantiated
by the DXE core. This is what typically happens, given that USB
keyboards
are also exposed via USB I/O protocol instances. The only difference
with
a non-fast [ConnectAll()] boot is that those USB I/O protocol instances
are not connected further automatically, but it is reasonable to expect
that the handles themselves have been instantiated.
Platforms that do not produce those USB I/O handles would not be able to
offer the ability to interrupt the boot or enter the menu using a USB
keyboard, so this is rather rare in practice. Also, if such platforms do
exist, it is not up to this 3rd party driver to override this policy and
enumerate the entire USB hierarchy.
So this means we need to call UsbHwrngDriverBindingSupported() directly
to check whether the USB I/O protocol in question has the right VID/PID.
If that succeeds, there is really no point in using ConnectController(),
so just call UsbHwrngDriverBindingStart() directly to connect the driver
to the controller.
Actually there is a point in using gBS->ConnectController().
1) You make it impossible for the platform to override the drivers
choice. The philosophy of EFI has alway been that the drivers should
not cary policy and the platforms should cary policy. This inverts that.
2) I’m not sure it is well defined behavior by UEFI to NOT call
gBS->ConnectController(). I took a quick look at the DXE Core and the
gBS->ConnectController() is not doing any book keeping, other than
managing the precedence rules, but it seems like it would be legal to
add something in the future. + Mike in case I’m off on this one.
The idea is really that by loading this driver, you are indicating
that you want it to connect to any supporting controller and produce
the RNG protocol, despite the platform policy. The UEFI driver model
simply isn't a great fit here, since the RNG is never a boot target
and you just want it to connect all the time.
I understand the issue. On the fast boot path only things in the NVRAM
variables, or hard coded as BDS policy get connected. For example in our
custom BDS we have code that connects devices related to the T2 and we
have custom code that only connects them at the known location. These
devices produce services that other EFI Driver Model drivers use when
they connect.
Sure. If the controller is known to live at a particular location on a
particular platform, you can just connect it. The idea of this driver is
that you can install it on any platform, plug in the USB stick and off
you go, which is substantially more complicated.
It is a shame my first approach did not work: it attempted to connect
the short form USB class device path carrying the VID and PID of this
controller as the remaining device path on each detected USB host
controller, similar to how USB keyboards are connected in the upstream
BDS code.
Is there a BZ for that? I’ve gotten feedback over the years that our BDS
implementation is hard to understand. Maybe we should invest some time
in documentation on how to use it?
I'm not sure that would help. I was hoping we could rely on spec'ed
behavior here, rather than how some BDSes might behave.
Note that the AMI BDS behaved differently here than the EDK2 one.
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#60679): https://edk2.groups.io/g/devel/message/60679
Mute This Topic: https://groups.io/mt/74627343/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
