Typo... adming == admit

Were. Moving on.

Not nearly to the levels you claimed. I have not disputed that there is a performance impact; in fact, I discussed that in one of my posts.

It cannot. You need to actually read up on BadUSB. I've pointed you to a few references, and you've pointed out a few, yourself, that you've clearly not read, or at least not understood. It's either willful ignorance, you not being willing to adming you might be wrong and go back and actually read, or you simply are incapable of understanding the subject matter. In either case, there is no point arguing with you about it.

each of which I have acknowledged and addressed, repeatedly.

Yes, by way of disabling DMA for the Firewire bus. In short, any device that relies on it does not work on a Mac never than 2012, or works with reduced performance. For example, the LaCie Firewire drive that's been around my workplace for a few years now, consistently sees read speeds of 90MB/s and write speeds of 60MB/s on the 2010 and 2011 Macs in the office, because it is able to make use of DMA during transfers. On the 2013 Mac used by our designer, it struggles to keep up 40MB/s in either direction. Our designer ended up switching to a USB3 drive that's capable of sustaining over 100MB/s reads and 90MB/s writes.

Notice how I'm now only pointing out flaws in your arguments, and no longer arguing the points. That is because I have said what I needed to say and provided references where applicable, and you have shown that you are not capable of following the conversation, as you think I've gone off topic when I most certainly have not.

Forgot to log in... yes, that post was mine.

Then you've not read up on the issue as much as your stong opinions on it would seem to imply.

I've been trying...

You know what else I mentioned?

Indeed, I've been trying in vain, as you clearly don't read. Mind you, these are drive I use every day for high-speed media transfer. I'm sure I don't know WTF I'm talking about, though, and the world is just bending to my will. Right?

As you've shown a complete unwillingness to actually consider that you may be wrong, or to even read the posts you're replying to, let alone the linked information (because you're likely sure it'll prove you wrong), I think we're done here. I'm sure anyone reading this will have read everything, leaving you the only one who still thinks you're right.

You got my point, though...

Well, as USB itself does not provide DMA (again, this is requested and handled at the driver level), a USB device can do absolutely nothing until the system recognizes it and starts talking to it (e.g. via a driver). You clearly didn't follow what you've read, or you'd understand that the nature of this vulnerability is that many devices don't have firmware programming disabled and can be reprogrammed to behave as other devices (in fact, you do seem to understand this, as you said "The problem lies in that USB trusts the device to be what it says it is, even if that is more than one thing", which is correct; it's equally correct that a USB device can be more than one thing, e.g. an audio device and a video device, so that's not a flaw, the flaw is in the devices being reprogrammable in the first place). Which, of course, means the devices have to be identified by the system and a driver has to exist for whatever they identify as.

Further proof that it is a device issue here, and evidence that USB devices must be "accepted" by the host before they can to anything at all, here. Not that this should be necessary, given a basic understanding of what you're talking about and a bit of logic.

Meanwhile, devices utilizing any of the DMA-enabled buses*[1] can just power up and happily start reading and writing your RAM, with the system being unable to stop them. If a cheap Firewire device was shipped with its firmware still writable, well, just imagine the possibilities. In fact, it's been done and the sky hasn't fallen yet, so I think we're okay.

That's you; Firewire is still fairly widely used in media production, and the devices using it include cameras, control boards, and DAT decks, which do get passed around. And without USB, where do you think you'd plug that thumb drive?

Okay, so you're doing two copy operations and are surprised when seek times slow them by more than 50%? You don't copy files on spinning disks much, do you? I do it all the time, albeit with SSDs, and have not once seen the slowdown you are talking about, so either you're full of shit, your equipment is full of shit, or you don't really know where the slowdown is coming from, but none of that is the fault of USB.

Which is it, 10 or 2? One, two, or three transfers? All this goalpost moging makes me think you're just full of shit.

You state that your drives can handle 100MB/s; USB3 is 5gbps (that's 640MBps), while SATA is 1.5, 3., or 6gbps (187.5, 375, or 750MB/s) depending on whether you've got SATA I, II, or III ports. On a high-end mobo like you claim to own, it's probably SATA-III, so 6gbps. That includes a fair bit of overhead, so the best you can expect on SATA-II is about 225MB/s, and 515MB/s on SATA-III. Figure the same math for your USB3 port, (515/750 = .686667 ; 640*686667 = ~440) you can expect 440MB/sec from USB3. Divide that by 2 and you're seeing just a hair, nothing you'd notice, under SATA-II speeds, and a damn sight better than USB2 transfer speeds.

Of course, USB is a serial bus, so the more devices you add to it, the longer the path and the more times each bit waits in a buffer before being passed on, which adds to latency, which affects transfer speed. So, if you've got 10 disks plugged in, there's your problem; interestingly, one you'd have with Firewire, as well, given that it is also serial. Of course you don't have that issue with eSATA connectors, each one is a full-on SATA port. And your idea of a port multiplier isn't as interesting as you might think, those introduce something like a 10% overhead, so with a single drive you're losing 10% of your speed right off the bat. From there, divide by the number of drives actively being accessed, and that's what you'll see.


*[1] Of which I'd like to point out, we're really only discussing two, Firewire and PCI, though I suppose ISA and the rest of the legacy buses would be equally affected. I say this because PCI-Express is an evolution of PCI; ExpressCard, mini-PCIExpress, and, well, pretty much any bus with Express in its name, all simply expose one or more PCI-Express lanes. In fact, that's all Thunderbolt does, too, and mini-PCIExpress exposes a USB port, as well.

Now I almost feel bad for tearing you apart so bad in that other post. Almost.

Everybody had USB, I never said everybody used it. That said, I refer you to this post, with actual references, so you can see just how wrong you are. Firewire came out on 1994, by the way, on Macs, 4 years before they added USB to the iMac.

Or I just didn't pay attention to Apple in the '90s and was too lazy to look it up. As a 2000 grad, I'd say I lived through the 90's. I also tend to get my history right when it related to something I actually care about. That being said:

1) You're thinking of Windows 95, which didn't see USB support until OSR2.1.Windows 98 did, in fact, ship with USB support.
2) USB 1.0 debuted in 1995, USB 1.1 in 1998. The iMac G3 did drop legacy ports as you claim, but is that a pair of Firewire ports I see? Yes, because Firewire was Apple's darling at the time and not a legacy port
3) I won't argue this, as it's factually correct as far as I am aware; however: the first 2 iPod models did not support USB at all, and the 3 after it only supported sync, no charging via USB for them.
4) Yes, you do.

If they hang it in their front lawn... are you telling me it's illegal to look at it? Of course it's not legal to take,; but, then. nobody claimed it was fine to take someone's security camera because they didn't change the default password, either. Legal to view it? Well, yes, until such time that you could reasonably realize that they, perhaps, hadn't intended to make it public.

But, of course, you knew what I meant and were simply being obtuse for the sake of argument. Bravo.

You mean that drivers can determine whether they, themselves, require DMA? That's no worse than the device having DMA itself; in fact, it's damn sight better, given that Firewire device doesn't even have to identify itself, let alone have that identity accepted by the system, to gain that level of access, meanwhile a USB device must identify itself as a device whose driver required DMA, that driver must be present, and it must emulate that device well enough to fool the driver into actually talking to it; the bar is a fair bit higher with USB than DMA.

That's all fine and dandy, the device still has to fool the driver, as well, whereas the OHCI 1394 specification (aka Firewire) allows for devices for performance reasons to bypass the operating system and access physical memory directly without any security restrictions.. In case Wikipedia isn't a strong enough source for you, here is the actual specification. A Firewire or Thunderbolt device or, as you correctly point out, ecpressCard, PCI, PCI-express (though you're really repeating yourself with that list) device doesn't even need OS or driver cooperation to be rejected by your system, it just pops on the bus and says "Let me see this RAM" and gets what it wants. Hell, it can do that repeatedly until it finds the bit of vulnerable code it's after and immediately turn around and overwrite it with an exploit. Actually, there's nothing stopping it from using that method to exploit your OS' I/O stack to allow itself to write arbitrary files on disk. All with no drivers, or authentication.

If you're worried about USB, you need to be terrified about the other busses in your system.

"Hook 2 devices up to a USB 3 hub, watch yourself get lower than USB 2 speeds"?

I'd figure there'd be no reason to mention a hub if you didn't use one.

Did you just get caught debating dirty? Yes, yes you did. Bad Gr8Apes! No soup for you!

Firewire is a bigger security threat than USB in many ways, namely that it is a bus with direct memory access, meaning it can read and write anything in RAM at any time. The USB attack vector has nothing to do with USB itself; it's a flaw in a poor quality devices that allow their firmwares to be reprogrammed, enabling them to act as a different class of device. There is no reason Firewire would not be vulnerable in the same way, were a Firewire device's firmware made writable in the same way as the vulnerable subset of USB devices; only the exposure would be worse, given Firewire's DMA. Likewise with Thunderbolt, as it also has DMA.

Citation? Maybe there's something I missed, but I think you're thinking of this, in which case: Nope. Well, no more than a device with direct memory access. In fact, a little less.

Also, maybe try getting a USB3 hub that isn't a piece of shit. I don't have the speed problems you describe at all.

Your first paragraph refers to Canadian law, which may apply to you but does not apply to me, or to the majority of Slashdot readers. I can't argue with it as, from your position, you are perfectly correct. Your second paragraph is what's interesting to me, as that's exactly the point I was trying to make.

Actually, the first paragraph is interesting to me, as well, as I did not know that bit of Canadian law. Knowing that this is legally (and likely socially) enforced in Canada, I'd be willing to wager that it we compared the ratio of netcams with default passwords to netcams with non-default passwords in Canada and compared it with the same in the US, Canada would fare considerably better.

We need something like that here in the states, so people start taking a bit of fucking responsibility for themselves and their own actions. Though, if we had it, it would probably be applied to rape victims who wore short skirts and no panties, while being ignored in cases where someone leaves their door wide open and hangs a flashing neon "murder me" sign in the window. And people I know say Canada is backwards...

I'll refer you to my response to the first reply to that post. I have a feeling you know exactly what I was getting at, but, in case you don't, that should clarify.

Supporting documentation?