skiboot
skiboot copied to clipboard
open-power
Option to disable USB ports
Disable USB ports on the machine to help with physical security. This would mean that people walking up to the machine could not insert USB keyboards or storage devices and gain any control over the system.
Threat Model
When the internals of the machine are somewhat secured, an attacker could plug in USB keyboards or storage devices to alter the boot process. Since these devices can be small and inconspicuous, it's possible to insert them quite quickly while casually walking through a data center.
We assume that the administrator of the machine is trusted to enable/disable this as needed.
Solution
NVRAM configuration option to disable certain PCI devices (e.g. USB controllers). This could have a graphical interface in Petitboot to be more user friendly.
We currently have no way to set these options from the BMC, so if we wanted this in the future we'd have to work out a IPMI sensor or similar.
If this is just an admin-level thing, couldn't it be easily done in the OS as an init script?
The thought is that then we're covered in petitboot as well, so it prevents boot options being changed.
https://en.m.wikipedia.org/?title=Hot_glue_gun
But more seriously, the GUI part could be covered by this recent series: https://lists.ozlabs.org/pipermail/petitboot/2018-December/001251.html
If this is just an admin-level thing, couldn't it be easily done in the OS as an init script?
Does that leave us open to a gap while Petitboot is coming up?
Ah, good point.
We could do this in petitboot userspace (to cover the petiboot environment too), but would need to ensure that the implementation doesn't allow for a hotplug race. udev rules should be fine. However, then we'd need to duplicate the behaviour in the distro OS, which would be a bit of a hassle for the user.
So, perhaps something that sets status = "disabled" properties on the DT notes within skiboot, matching a particular PCI class and/or (vendor,device) types?
Jeremy Kerr [email protected] writes:
So, perhaps something that sets
status = "disabled"properties on the DT notes within skiboot, matching a particular PCI class and/or (vendor,device) types?
That was my thought.
-- Stewart Smith OPAL Architect, IBM.
On Mon, Jan 14, 2019 at 1:18 PM Stewart Smith [email protected] wrote:
Jeremy Kerr [email protected] writes:
So, perhaps something that sets
status = "disabled"properties on the DT notes within skiboot, matching a particular PCI class and/or (vendor,device) types?That was my thought.
I just tried this out and it looks like linux doesn't even look at the status property of pci devices. I hacked status="disabled" into the DT node for the xhci on romulus and it looks like the device was probed and a driver loaded anyway:
/sys/firmware/devicetree/base/pciex@600c3c0300000/pci@0/usb-xhci@0 # lsprop ibm,pci-config-space-type 00000001 interrupts 00000001 class-code 000c0330 (787248) revision-id 00000002 status "disabled" vendor-id 0000104c (4172) reg 00010000 00000000 00000000 00000000 00000000 phandle 000006d6 (1750) ibm,loc-code "Builtin USB" name "usb-xhci" device-id 00008241 (33345)
lspci -s 3:1:0 -k
0003:01:00.0 USB controller: Texas Instruments TUSB73x0 SuperSpeed USB 3.0 xHCI Host Controller (rev 02) Subsystem: IBM S824 (8286-42A) Kernel driver in use: xhci_hcd
Just to make sure it was working I plugged a USB hub that was lying around into one of the backplane ports and it seems to be working:
Before # lsusb Bus 001 Device 001: ID 1d6b:0002 Bus 002 Device 001: ID 1d6b:0003 Bus 001 Device 002: ID 046d:c014
After # lsusb Bus 002 Device 002: ID 0bda:0401 Bus 001 Device 001: ID 1d6b:0002 Bus 001 Device 003: ID 0bda:5401 Bus 002 Device 001: ID 1d6b:0003 Bus 001 Device 002: ID 046d:c014 Bus 002 Device 003: ID 0bda:8153
So, maybe look at a different approach.
-- Stewart Smith OPAL Architect, IBM.
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/open-power/skiboot/issues/211#issuecomment-453888341, or mute the thread https://github.com/notifications/unsubscribe-auth/AABn-tTajHDE3aJI85n7-LuNPaz2cE7Sks5vC-kKgaJpZM4Z9duC .
I took a look at the discussion around PR #2790 and looks like we have some consensus that the solution presented there is ready to be merged, but it also must be explicitly enabled in a _defconfig for the desired platform to show this characteristic (disable USB by default). Any objections to merging it?
In an e-mail discussion with Kevin Kehne and Chet Mehta, they confirmed that the request is to allow a runtime-configurable policy to completely disable USB support - that includes Host OS as well.
I don't think that Pull Request #2790 is able to achieve this.
@oohal, you commented some other way in which this could be achieved, can you clarify?
@jk-ozlabs Sam mentioned this RFC patch as a possible mechanism to configure this, although I didn't see a clear way in which this could be protected under a password or similar. Thoughts?