But they can only do that if I've had my phone on since 2003.
What? It will happen automatically when I turn it back on? *sigh*
Please create an account to participate in the Slashdot moderation system
But they can only do that if I've had my phone on since 2003.
What? It will happen automatically when I turn it back on? *sigh*
All drivers on OS X are already required to tell the operating system ahead of time that a device is about to DMA to memory. That's how that VT-d is able to configure the IOMMU hardware to allow those devices to access RAM without worrying about 64-bit address spaces. So the OS already knows precisely which pages of physical RAM should be accessible by PCIe devices using DMA. If other pages of RAM are accessible, that's a bug.
Similarly, making the Thunderbolt controller's IOMMU mappings be driven by that part of the kernel should not break any drivers at all, by definition, because PCIe devices shouldn't be issuing DMA requests except at driver-preapproved locations. So AFAIK, the only way such a fix could break any device would be if that device was trying to do something really dangerous, like reprogramming one of the PCI bus bridges, or reflashing the computer's EFI firmware....
I mean, I suppose that some drivers might be inadvertently configuring a mapping for a page of memory that also contains executable code or class instances (with function pointers), in which case fully fixing this would also require Apple to modify the IOMemoryDescriptor class to ensure that the DMA-enabled pages are whole pages owned by the descriptor, but that should still be pretty minor, and should result in only a modest amount of wired kernel memory bloat.
In the worst case, such a change might require a CPU-driven copy-on-prepare and/or copy-on-complete to work around drivers that provide their own virtual addresses for a memory descriptor that aren't page-aligned, which would cause a big performance hit for those few drivers, but I'd expect most driver developers to quickly fix those design mistakes to eliminate the performance hit. (And that's assuming this isn't done already—for some reason, I thought those buffers had to be page aligned or you'd get a panic, but I'm not seeing anything about it in the docs, so I might be remembering wrong.)
You can't be free without a cost. If lawyers are going to continue to ruin society, we need to curb them... but given how democracy is failing those issues are really sideshow to the real problems. Cutting down on misinformation and ignorance are one of the few things left that can be done to support democracy.
Heesa left een Jar Jar?
But for Kindle if it's supported in Kindle Previewer, then someone screwed up pretty carelessly.
I'd argue that if any WebKit-based reader doesn't support it, then someone screwed up pretty carelessly, but that's just me.
I am, of course, assuming that Thunderbolt controllers contain an IOMMU, but given that it has to function as a nontransparent PCI bridge when attached between two computers, that should be a safe assumption.
The whole point of requiring every driver to call the prepare method on an IOMemoryDescriptor object before telling a device to do DMA and calling the matching complete method when the I/O is done is so that the OS can create and tear down mappings in various IOMMU hardware to protect the system as a whole from buggy devices (and particularly those that don't understand 64-bit address spaces). If that isn't happening, I'd argue that it is a kernel bug, and given the security implications, a pretty serious one.
Thunderbolt is rather different, because the devices are basically PCI-E cards with a Thunderbolt transceiver bolted on. As such they can do anything that a PCI-E card can do, including accessing all RAM. PC Card devices have the same issue, and so does Firewire. It's a serious issue and tools that exploit it have been available for a while, both open source and commercial.
Here's what I don't get. Back when the G5 came out, Apple used a custom piece of hardware called DART to create a boundary between the I/O address space used by PCI devices and the physical address space used by RAM. It required device drivers to explicitly configure mappings before a PCI device could scribble on RAM, and limited those devices to scribbling over the ranges specified by the OS. That hardware went away with the Intel transition, of course, but most of the newer 64-bit Intel hardware has a feature called VT-d that does essentially the same thing. AFAIK, the 64-bit OS X kernel uses that functionality by default if the hardware supports it, so all of those tools should be completely non-functional on recent Macs running Mountain Lion and later. And I think I remember reading somewhere that Thunderbolt controllers contain an address translation table as well.
With that in mind, how is this Thunderbolt device somehow gaining the ability to tickle hardware that probably doesn't live on the PCI bus, on the opposite side of the Thunderbolt controller, at a location that wasn't explicitly configured for DMA by a device driver? Does it involve rebooting the machine and exploiting a driver bug in EFI?
Heh. I'll show you. I haven't updated my preferred roaming list since 2003. My ancient flip phone will never even see your tower!
On the other hand there is only so much wireless spectrum available that is set aside for 802.11x. Ever been to big even in a hotel where eveybody and their brother has the hot spot function enabled on their phones, is caring around those mobile hot spot things, folks are running classes in conference with their own wireless AP setup for their students, etc.
IIRC, cell phone hotspots deliberately limit their maximum gain to minimize interference. They typically have an indoor range of about 66 feet—essentially, your hotel room and one or two rooms on either side. Based on that, I suspect that those personal hotspots are more likely to be a symptom of the problem than its actual cause.
If you're seeing poor performance on a hotel's infrastructure Wi-Fi network, odds are good that either:
The first one is usually the main problem. Most hotels' networks were designed under the assumption that folks will have at most one Wi-Fi-capable device per room, and that most folks won't be using them at any given point in time. When you have a bunch of geeks with three or four devices, all talking at once, the spectrum can get clogged pretty badly.
There are two possible fixes for that problem. The first fix is to deploy 802.11ac more broadly. For clients that support it, this reduces congestion considerably, both by providing more channels and by reducing interference through beamforming. The second fix is to greatly increase the number of 802.11b/g APs (and, to a lesser degree, 802.11n APs) so that you can reduce their maximum receive and transmit gain settings, effectively creating a large number of very small clusters of nodes instead of a few big ones. Note that these solutions are not mutually exclusive.
Because they don't allow you to bring your own drinks and snacks...and you don't want to be "forced to purchase theirs at a dramatically inflated price". I'm just curious how strong your principles are.
That's not really a fair comparison, for several reasons:
So although they might be similar in principle, the differences in practice are so large so as to render one a meaningless annoyance that we can live with, while rendering the other a serious act of interference that cannot be tolerated.
There are legit reasons they would want to block all those random wifi hotspots. All those random hotspots are (or could) degrade the performance of the service they are offering. The air does not have unlimited bandwidth. If they knock out all the "rogue" hotspots, they *could* manage the airways within their building better.
Except the reality is that all of those random hotspots are almost by definition physically closer to the user than the ones provided by the hotel, which means the two Wi-Fi radios are likely to be using less power, and thus producing less interference than an extra guest on the hotel's network would produce, not more.
No, there's no legitimate reason for doing this. The only reason they do it is so they can charge as much for one day of service as most people pay for half a month. And yes, I often choose lesser hotels that offer free Wi-Fi over nicer hotels that charge for it. I consider Wi-Fi service to be a basic necessity, and hotels that don't build that into the cost of doing business are not effectively serving my needs.
If a hotel blocked my Wi-Fi hot spot, I would very likely leave their jamming range, go on Hotels.com, leave a negative review, book a different hotel, then go to the front desk and demand a complete refund of the cost of my room. If they refused, I would stand right in front of them while I called my credit card company and issued a charge-back, so that there could be absolutely no doubt in their minds why I did so. I don't care how nice your rooms are. If you're deliberately interfering with my ability to get things done solely so you can make a quick buck, you are not a hotel that is worth staying in.
So the guest is paying to offer Wi-Fi to people, and the hotel might require that the guest instead pay for the hotel Wi-Fi service.
That simply isn't a reasonable thing for a hotel to do. You would never accept a hotel requiring you to wear only hotel-provided clothing in a conference room. How is requiring you to use their Internet connection instead of a connection that you have already paid for any less absurd?
That search for the lowest place without rats in the toilet is why they do bs like this... they have to compete on "price" and then once you're in make up their money on crap like charging you for internets. Works the same way with airlines, and that's why airlines suck now.
See, that's the opposite of my experience. I've never seen a $50-per-night hotel that didn't offer free Wi-Fi. It's the $300-and-up-per-night hotels that charge $15 a day for Wi-Fi. These same hotels also charge five bucks for a tiny little can of Pringles, four bucks for a soda, etc. Basically, they assume that anybody with enough money to stay in those hotels also can't be bothered to walk downstairs and across the street to the gas station to buy a soda.
And the more expensive the hotel, the more likely they are to use a complex Wi-Fi system that requires you to sign in through a captive portal, breaks in fascinating ways, and is horribly unreliable. The cheaper the hotel, the more likely they are to just toss up a halfway decent trunk line connected to a handful of off-the-shelf Wi-Fi base stations, and be done with it. Guess which one actually works reliably? (Hint: It isn't the complex, expensive systems used at the high-priced hotels.)
As for when hotels should be allowed to block Wi-Fi, the correct answer is "never". It is never acceptable to deliberately cause interference with properly licensed hardware operating in a normal manner. It is illegal, unethical, and any hotel doing so should get buried in fines so high that nobody else ever even thinks of committing such an act in the future. Now if those Wi-Fi hotspots are operating incorrectly and causing interference, it is within their right to use passive mechanisms to track them down and ask the customers to stop using them. However, the burden of proof falls on the hotel chain to prove that those hotspots are, in fact, not operating correctly, and that the problem is not caused by the hotel's Wi-Fi network being set up incorrectly (which it almost certainly always is in any of the sorts of hotels that would attempt such jamming).
Let me clarify what I meant by that. Touchscreens built into the console of the car should be banned. Stand-alone GPS receivers are different, because you mount them in the corner of your windshield, so your peripheral vision is still on the road while you're looking at them.
In-dash GPS systems should be banned, both because they seem to universally suck and because using them to figure out where to turn is inherently less safe than using the ones mounted to your window, because you have to look down so far.
Of course, the absolute worst GPS systems are the in-car GPS systems that detect when you're moving and won't let you search or enter a destination location. That makes sense if the driver is operating it, but it basically makes them utterly useless if you have two people in the car and want to figure out where to stop for food (the single most common use of GPS devices, in my experience). Those should be banned because they encourage non-emergency stops on the side of the highway.
"Any excuse will serve a tyrant." -- Aesop