**** BEGIN LOGGING AT Thu Oct 13 02:59:59 2016 Oct 14 00:20:04 DocScrutinizer05: on the Neo900, what is the interface between the modem and the SoC? Oct 14 00:47:51 USB Oct 14 00:49:59 alas even full-spec USB, not inter-chip USB. Means we need a PHY, for 3V3/5V and VBUS Oct 14 00:51:33 ooh, and we also exploit/employ the alternative UART interface, just in case user wants a "low bandwidth" low-power low-overhead (ENUM) interface Oct 14 00:55:23 pabs3: ^^^ Oct 14 00:56:23 pabs3: you know http://neo900.org/stuff/block-diagrams/neo900/neo900.html ? Oct 14 00:59:42 primary interface on SoC: ULPI (to PHY, to modem USB). Then UART#1. PCM for audio, form SoC McBSP#4. Half a dozen signal lines like RING, POWER-BUTTON, IGNITION etc (not shown). And power supply lines which we monitor and also can cut with a switch Oct 14 01:00:25 hmm. so the modem could theoretically simulate a USB keyboard if it wanted? Oct 14 01:00:53 and type `curl ... | sudo bash` :) Oct 14 01:01:23 it could, but the system on SoC would be very poorly configured if it accepted such a completly unexpected change of hw config Oct 14 01:01:32 thanks, couldn't find that URL from the front page Oct 14 01:01:52 check "resources", it has lots of good URLs Oct 14 01:02:06 https://neo900.org/resources Oct 14 01:03:01 hmm, looking at that, there are 3 connections from the CPU to modem Oct 14 01:03:08 (simulate) note that this isn't a plug&play USB, it's hardwired and not supposed to need any hw detection Oct 14 01:03:24 yes, USB, UART, PCM Oct 14 01:06:12 to be utterly clear on that: if we don't load the driver during bootup, configured to that particular USB port hw addr, then at least udev should not probe for any other devices on that USB, and only load that particular modem usb kernel driver when the vebdor, product, and devicetype is as expected. This rules out any e.g. kbd USB driver ever gets loaded for the modem USB port Oct 14 01:08:29 btw you have exactly same issue for e.g. the mouse on every standard indistry workstation, and usually you define a particular USB jack where the mouse needs to get connected and this USB jack will only accpet mice and nothing else Oct 14 01:08:39 accept* Oct 14 01:10:45 also not uncommon in industry that all other USB jacks are either completely disabled (just a variant of above udev config, or whatever the equivalent on windows), or your system admin configures your workstation in such a way that company's security gets informed when anything gets plugged to any USB jack that's not expected and approved to get connected there Oct 14 01:12:00 bottom note: system admins / distro maintainers should not blame hw manufactueres for not fixinf poor system config the admins themselves are responsible for ;-) Oct 14 01:12:08 :) Oct 14 01:13:22 where will the config for locking down the allowed USB types on that USB interface? I would recommend putting it in Linux, perhaps in the devicetree, so that distros don't have to know about this Oct 14 01:17:35 I don't know. Note the *we* don't do software Oct 14 01:18:05 on my devioce I will patch the udeb rules accordingly Oct 14 01:18:12 udev Oct 14 01:18:33 (*we* == Neo900 UG) Oct 14 01:24:34 the udev rules test for a wide set of parameters for each hotplug event, usually that's something like "bus==USB && vendor==Logitech && product==MxRevo" or "bus==USB && deviceclass==mouse". But in this case we shall test for "bus==USB && interfaceaddr=bus1.jack1" or somesuch, so *any* device "plugges in" to that USB interface triggers that rule and thus can't trigger another rule Oct 14 01:25:47 makes sense? Oct 14 01:29:04 pabs3: https://www.freedesktop.org/software/systemd/man/udev.html Oct 14 01:34:30 of course in above the "bus", "product", "deviceclass" and "interfaceaddr" etc were just made up placeholders for the correct properties to check against Oct 14 01:34:54 to convey the principle Oct 14 01:38:35 useful: udevinfo -a -p /sys/block/mmcblk0 Oct 14 01:38:45 et al Oct 14 01:42:52 http://termbin.com/myyz Oct 14 01:45:08 so IF this was the right USB interface for modem, the udev rule would be SUBSYSTEM=="usb", KERNEL=="1-0:1.0" Oct 14 01:46:45 so whenever something starts ENUM (= gets plugged) to USB 1-0:1.1 "jack", udev will load the modem driver and initiate the modem device, and never any other device Oct 14 01:48:43 problem solved, in my book Oct 14 01:50:36 the only theoretical attack vector then would be the classical buffer overruns exploits etc in the generic USB controller kernel driver, but that's something totally out of scope of this particular case, since you always have that risk and it's the main focus of all security audits done to any system to avoid such vulns Oct 14 01:54:38 also the modem interface is very low attack surface here, since you first need to "root" the modem before you even can *start* to try attacking/penetrating the linux system via a buffer overrun bug in modem kernel driver. Other kernel drivers like e.g. TCP/IP stack / NIC are way more exposed to such attacks than the modem driver Oct 14 01:58:52 hmm Oct 14 02:06:46 hmm? Oct 14 02:14:37 anyway Neo900 is supposed to ship with a BSP. Such BSP will contain the modem driver and the according udev rule to solve this issue, in devuan Oct 14 02:15:23 (maybe s/udev/vdev/, we'll see) **** ENDING LOGGING AT Fri Oct 14 02:59:58 2016