From bd93c5e229b02b8db600c5a92233ca4e1d01cdff Mon Sep 17 00:00:00 2001 From: jaseg Date: Wed, 21 Nov 2018 22:18:37 +0900 Subject: Initial PCB draft --- old/architecture/architecture.tex | 9 ++------- 1 file changed, 2 insertions(+), 7 deletions(-) (limited to 'old') diff --git a/old/architecture/architecture.tex b/old/architecture/architecture.tex index 12373d3..3e5b302 100644 --- a/old/architecture/architecture.tex +++ b/old/architecture/architecture.tex @@ -91,13 +91,8 @@ programmers do not recognize the USB interface as a potential target for attack one USB device can potentially compromise this USB device as part of a larger attack. Issues like these can in part be mitigated with host-based filtering, such as explicit whitelisting of physical USB -ports for HID devices. In this case, however, the USB driver stack of the linux kernel running the USB VM remains as a -very large attack surface. The USB device drivers in Linux in general are not a paragon of code quality, and since the -device can choose which driver the kernel will load a flaw in any one of them suffices. Approaches such as whitelisting -or explicit approval of driver loads interfere too much with a computer's day-to-day operation and thus are not -generally implemented. Also, like any kind of application firewall the user would quickly be desensitized to the -frequent but harmless warning message popping up decreasing the probability of the protection working in case of an -actual attack by a large margin. +ports for HID devices. In this case, however, the USB driver stack of the linux kernel running the USB VM remains as an +attack surface. A possible secure solution for this problem would be to completely separate security-critical USB devices such as keyboard and mouse from everything else. A practical implementation of this would require two separate USB host -- cgit