Announcement

Collapse
No announcement yet.

USB 4.0 "USB4" Specification Published

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • torsionbar28
    replied
    Originally posted by L_A_G View Post
    I suspect that the idea is to let device makers include both older and USB 4.0+ ports for devices and then eventually just let consumers use cheap "legacy USB hubs" to support their legacy devices. There's only so much legacy cruft that you can have in your standard before it becomes unwieldy and unmanageable.
    Makes sense, that probably is their intent. But it kind of takes the "universal" out of universal serial bus. These devices only work in these USB ports, but these other devices, you have to plug them into those other USB ports over there. Whatever, if there's one thing the USB people are good at, it's creating consumer confusion.

    Leave a comment:


  • xfcemint
    replied
    Originally posted by johannesburgel View Post
    By now you should have realized you suffer from a serious lack of information in regards to Thunderbolt.
    I do, that's why I asked the question.

    Originally posted by johannesburgel View Post
    Why don't you go and fix that, instead of bothering other people with your stupidity?
    Why do you bother to post your stupidities?

    Originally posted by johannesburgel View Post
    The default security mode for Thunderbolt is "secure". The controller in the host device does not automatically tunnel any PCIe lanes when you attach a PCIe-capable device to the bus. The user has to authorize the device to make that happen, and the operating system remembers the device so it can re-authorize it automatically in the future. This is also true for all current UEFI implementations I've worked with. All Thunderbolt-capable systems I've seen in the last four years had safe defaults both in the UEFI settings and the operating systems.
    That doesn't answer at least the following security concerns:

    1) Can an an attached device sucessfully fake another device ID?
    2) After you have authorized a device ID, is it possible for the device to access unauthorised areas in the memory?

    Originally posted by johannesburgel View Post
    Here's a blog post from someone who actually tried to hack a stock system via Thunderbolt back in 2016 and failed:
    http://blog.frizk.net/2016/10/dma-at...usb-c-and.html
    Thanks, that was an interesting read. However, the conclusion is far from "all OK". It says (quoted):

    "The default Thunderbolt security settings are secure - unless you approve a Thunderbolt to PCI Express adapter like the Sonnet Echo ExpressCard."

    Leave a comment:


  • jo-erlend
    replied
    Originally posted by Marc Driftmeyer View Post

    Yes it does and for those in the creative arts that deal with Soundtracks, Music creation, Film Production, Animation, etc etc., you bet your ass we want PCIe access. We want as much bandwidth as possible.

    See page 66 of the spec and read from there.

    Anyone incapable of securing their work environment is on them. Sorry, but knee capping for the sake of `security' by compromising bandwidth is absurd.
    Isn't that a false dilemma? I mean, nobody's saying external PCIe is necessarily a bad thing? Would it really be so horrible if you had USB not doing PCIe and things like OCuLink that did? Ideally, I think, we would have a few different types of connectors, a user-level connector, an OS-level connector and a hardware-level connector. I mean, PCIe is much more dangerous than USB and USB is much more dangerous than it ought to be for simple things like headphones or simple storage on your keyring.

    In my opinion, separating things by level of danger, is not a stupid idea.

    Leave a comment:


  • johannesburgel
    replied
    Originally posted by xfcemint View Post
    What "configurable thunderbolt policies" in UEFI are you takling about? If it consists of "1-enable, 2-disable, 3-fuck off", than it is obviously insufficient.
    By now you should have realized you suffer from a serious lack of information in regards to Thunderbolt. Why don't you go and fix that, instead of bothering other people with your stupidity?

    The default security mode for Thunderbolt is "secure". The controller in the host device does not automatically tunnel any PCIe lanes when you attach a PCIe-capable device to the bus. The user has to authorize the device to make that happen, and the operating system remembers the device so it can re-authorize it automatically in the future. This is also true for all current UEFI implementations I've worked with. All Thunderbolt-capable systems I've seen in the last four years had safe defaults both in the UEFI settings and the operating systems.

    Here's a blog post from someone who actually tried to hack a stock system via Thunderbolt back in 2016 and failed:

    http://blog.frizk.net/2016/10/dma-at...usb-c-and.html

    Leave a comment:


  • xfcemint
    replied
    Originally posted by brent View Post
    Security hasn't been an issue with Thunderbolt for many years now. I don't get it why uneducated people still bring this up all the time. UEFI system firmwares (those that I know) have configurable Thunderbolt policies and OS support with opt-in policies for new devices is easy to enable (or even default), too. Of course IOMMU with proper configuration is a plus, but if security policies keep unwanted Thunderbolt devices separated from the host on the PCIe level, you don't need it.
    Without proper IOMMU handling, thunderbolt can quickly turn into a real nightmare. I mean, if I tried to count how many external USB devices I have in my home, it would certainly be more than 30. Imagine what would happen if all those 30 devices were using USB 4.0. I would have to put each one of them separately on some kind of idiotic access list, and even that doesn't guarrantee me security since another device can fake the ID of an already connected device.

    Therefore, IOMMU is a must.

    Of course, you can say that I can just disable thunderbolt functionality, but then, why do I need USB 4.0 at all? What if I have a laptop dock/GPU which needs it? Does every UEFI have this setting? And, I am supposed to remember to toggle this setting in the UEFI every time I carry the laptop outside the house? That is rediculous.

    What "configurable thunderbolt policies" in UEFI are you takling about? If it consists of "1-enable, 2-disable, 3-fuck off", than it is obviously insufficient.


    Leave a comment:


  • tuxd3v
    replied
    Originally posted by anth View Post

    I've always thought the claims of extra bandwidth from TB compared with USB were a bit misleading. They are correct but with a caveat.

    PCIe over Thunderbolt 3 has the same maximum 20Gb/s bandwidth per direction as the USB 3.x protocol. The difference is USB (3.2 Gen 2x2) uses the two SuperSpeed+ lanes in one direction and the other two lanes in the other direction, but only does one direction at a time rather than both at once. TB also uses two lanes in each direction but can do both at once, though it is limited to a length of 0.5m or an active cable.
    orrect but with a caveat.

    PCIe over Thunderbolt 3 has the same maximum 20Gb/s bandwidth per direction as the USB 3.x protocol. The difference is USB (3.2 Gen 2x2) uses the two SuperSpeed+ lanes in one direction and the other two lanes in the other direction, but only does one direction at a time rather than both at once. TB also uses two lanes in each direction but can do both at once, though it is limited to a length of 0.5m or an active cable.

    DisplayPort 1.2 to 1.4 can use the HBR3 transmission mode from that standard as a USB-C alternate mode, with 1, 2, or all 4 SuperSpeed+ lanes, for a maximum bandwidth in one direction of 32.4Gb/s.

    I've not got to grips with USB 4 yet.
    DisplayPort 1.2 to 1.4 can use the HBR3 transmission mode from that standard as a USB-C alternate mode, with 1, 2, or all 4 SuperSpeed+ lanes, for a maximum bandwidth in one direction of 32.4Gb/s.

    I've not got to grips with USB 4 yet.
    At Physical Layer , Thunderbolt3 has the same speed Limitation as USB3.2 over USB-C..
    What turns it faster is the Paralel behavior in full duplex.. I agree
    Also,
    USB 3.2 on the 2 new modes SuperSpeed+, uses a 128b/132b encoding, which improves the transfers, but maybe give him a bit of latency, compared with the more conservative 8b/10b..

    Leave a comment:


  • L_A_G
    replied
    Originally posted by torsionbar28 View Post
    So it is NOT backwards compatible with USB 1.0/1.1? That's a pretty glaring omission. There are tons of older HID devices, printers, label printers, and other devices that don't need much bandwidth and typically have a long service life. People gonna be pissed when they find this out the hard way.
    I suspect that the idea is to let device makers include both older and USB 4.0+ ports for devices and then eventually just let consumers use cheap "legacy USB hubs" to support their legacy devices. There's only so much legacy cruft that you can have in your standard before it becomes unwieldy and unmanageable.

    Leave a comment:


  • brent
    replied
    Security hasn't been an issue with Thunderbolt for many years now. I don't get it why uneducated people still bring this up all the time. UEFI system firmwares (those that I know) have configurable Thunderbolt policies and OS support with opt-in policies for new devices is easy to enable (or even default), too. Of course IOMMU with proper configuration is a plus, but if security policies keep unwanted Thunderbolt devices separated from the host on the PCIe level, you don't need it.

    Leave a comment:


  • starshipeleven
    replied
    Originally posted by xfcemint View Post
    1) the IOMMU unit on the CPU must be properly programmed. This is the job of the Linux kernel. Of course, it must be sponsored by the CPU manufacturer (Intel / AMD / ARM). Did their developers do the job?
    IOMMU/VT-d needs to be enabled in UEFI settings, Linux supported it since a long time ago due to its usage in servers. This should block DMA attacks, assuming the IOMMU itself isn't vulnerable (which can and does happen, but still it's another layer of defence).

    Additional hardening is available through a daemon that controls access of devices connected to the port https://github.com/gicmo/bolt
    Similar daemons exist also for USB (usbauth).

    2) The BIOS / UEFI must be fixed so that it does not allow being intercepted by disallowed devices.
    ...
    Another option, the BIOS / UEFI must make use of IOMMU (never heard of it).
    This is possible as UEFI is capable of using IOMMU for itself, or disabling DMA alltogether on PCIe while in UEFI stage (and losing access to devices needing it). https://firmware.intel.com/blog/upda...-uefi-firmware

    From my limited understanding, Tianocore opensource UEFI implementation does support IOMMU https://github.com/tianocore/edk2/bl...e/IoMmuDxe.inf

    But as all things UEFI, good fucking luck with that on most commercial hardware (i.e. there is no guarantee that anyone will do more than the bare minimum to get things working at all, and test only on Windows). Afaik most hardware is vulnerable to these attacks when in the UEFI stage (i.e. during boot)

    Best candidates to get a device with a sane UEFI/firmware are companies that actually care and write their own device's UEFI (or try to use Coreboot), like System76 and Purism.

    Leave a comment:


  • xfcemint
    replied
    Originally posted by AndyChow View Post

    I second this. I don't want random hardware that has direct access to PCIe lanes. I'm pretty sure they showed external thunderbolt "harddrives" can take over your computer, aka "Thunderclap".

    I can also imagine a USB Killer type device that now fries your CPU directly.
    Thunderbolt is virtually useless with this shitty security hole. But is it still a hole? I mean, shouldn't the stuff be patched already? It been how many years since?

    Two things need to be done:

    1) the IOMMU unit on the CPU must be properly programmed. This is the job of the Linux kernel. Of course, it must be sponsored by the CPU manufacturer (Intel / AMD / ARM). Did their developers do the job?

    2) The BIOS / UEFI must be fixed so that it does not allow being intercepted by disallowed devices. A user can create a list in the BIOS of devices that need to access the PCI bus (no BIOS does this). Another option, the BIOS / UEFI must make use of IOMMU (never heard of it).

    So it's still thoroughly fucked up, as per my undestanding.

    Somebody please prove me wrong.


    Leave a comment:

Working...
X