You're right- I was wrong. I was thinking about QAM, where each QAM channel can support two HD channels (or 3, if you recompress the video like Comcast). I knew the bandwidth was essentially the same between QAM and ATSC channels, but I forgot that all the error correction drops the effective data rate from 36mbps to 19mbps. 19 would be enough to carry two H.264-compressed HD streams (which aren't widely used or supported for ATSC), but its not enough for 2 mpeg-2 streams.

Verizon's LTE coverage is actually pretty good. They cover lots of major cities, and since they're using a relatively low frequency, it penetrates walls and into buildings much, much, much better than Sprint/Clear's wimax coverage. Verizon claims to cover about 75% of the population with their current LTE deployment, which I believe based on the traveling I've done.

Of course, it seems sucks down the battery. That will be the case until LTE is everywhere, allowing Verizon to switch to Voice-over-LTE and turn off the CDMA radio in phones that have 4G coverage. Right now you always need the CDMA radio on if you want to be able to get calls.

Sure, but how many of those people are watching the major networks? You don't even need 25 digital channels to provide those.

He's probably counting the subchannels. For instance, a lot the major networks have 2-4 programs sharing the same channel. One digital TV channel is perfectly capable of handling 2 HD streams, or more if you use SD streams. So, a lot of networks will have one HD channel, and one or more SD channels airing stuff like weather, maybe a simulcast of the HD stream in SD, and possibly a third SD stream that just airs weird stuff.

25 channels seems like plenty to me. There's only 5-8 major networks (depending on what you consider 'major'), whose affiliates are collectively probably responsible for 98% of what is watched. A single digital channel can carry two HD channels, so 25 channels can carry up to 50 HD programs. That would push the smaller guys out, sure, but I think it is worth it to free up some spectrum for wireless Internet. There's only so much spectrum that is suitable for wireless Internet- it basically needs to be below 2600Mhz to have much of a chance at penetrating walls, and things around 700-1000Mhz do much, much better. Digital television is sitting on some of the most desirable spectrum out there, and quite frankly, a lot of it is being wasted right now.

First, the UEFI secure boot requirement is mainly for client systems. Microsoft is making it optional for servers, and many won't implement it for legacy support reasons. But perhaps even more relevant, the MS requirements definitely don't apply to the types of servers you have in mind, which rarely come with an OS installed.

Second, I suspect many, if not most, rackmount servers still undergo a provisioning process whereby each server is individually configured some minimal amount. Some probably already have to have their BIOSes configured for various reasons. So, for systems destined to run Linux, it can be disabled (if someone can't manage to sign GRUB). For systems that will run Windows, it can stay enabled. Actually, a third situation is probably even more likely- a server destined to run a hypervisor. Given how much VMWare and Citrix care about security, I'm sure they'll support signed bootloaders once servers start supporting UEFI secure boot.

Third, the types of servers that really aren't ever touched come with BMCs with nearly unfettered access to system settings, including BIOS. Even though its a bit of a security vulnerability, I'm sure BMCs will be able to disable UEFI secure boot on server systems.

Security features should always default to on- particularly ones suitable for 99% of users.

What are you needing to mass deploy? What situation do you have in mind where a corporation has deployed a bunch of Win8 machines with UEFI secure boot enabled, and then later needs to push out an update that will break the machines?

Windows boxes, which will make up the vast majority of clients being remotely managed, will definitely work with secure boot enabled. So, unless you put in a old add-in card (which require physical presence anyway), what system change will interfere with secure boot? You're not pushing out Linux installs and GRUB remotely, are you? Because it seems like that's the only thing that might not play well with secure boot.

You obviously have a strong background in this area. I don't do BIOS development myself, but I do know people that do, and they always corrected me when I said SMI was part of BIOS. I definitely see your argument, but I still think you shouldn't consider it part of BIOS because it executes in SMSM. SMM is very different from the other modes on an Intel CPU. Real and protected modes (and the numerous other modes) aren't logically separated in the same way that SMM is separated from every other mode.

I kind of assumed you were imagining using a timer or hijacking some other frequently-needed SMI. I can imagine how that could work, but it doesn't seem practical to regularly halt execution to enter SM, perform security checks on whatever is in memory, and then resume execution. Wouldn't you have to, at least, inspect everything in memory? That would be quite slow.

Sure, it seems like an interpreter would be required here, but I was more concerned about the logic surrounding the interpreter to create the secure sandbox, rather than the interpreter itself. If security wasn't a goal, it doesn't sound too hard. Maybe even if made people specifically write their option ROMs to run in this interpreter it wouldn't be so bad. But, without having any experience in this area at all, it seems like it would be difficult to set up a sandbox to run any old option ROMs that people wrote expecting to be executed directly. If you could do it, it seems like it would take a non-trivial amount of code. I doubt OEMs would want to spend system flash space on it, given this is a problem that goes away once people switch to signed UEFI device drivers.

Somewhat interestingly, UEFI BIOS already has an interpreter. The UEFI specs created something called EFI Byte Code to allow people to create architecture-independent UEFI device drivers. But, they were just trying to prevent add-in cards from having multiple copies of device drivers- they weren't trying to execute each driver in a sandbox.

Anyways, this is just a thought experiment (albeit a somewhat interesting one- I kind of like the sandbox idea, I just don't think it will happen). As I said, OEMs are explicitly forbidden from executing unsigned UEFI device drivers and/or legacy option ROMs when secure boot is enabled.

I think we're just having a terminology/interpretation difference. You're saying SMI handlers are "in" the BIOS, I'm saying SMI handlers are "set up" by the BIOS. I'm not quite sure what you mean by saying they're "in" the BIOS itself. As I said, SMI handlers are certainly loaded by the BIOS during boot. The BIOS is the only entity that can load SMI handlers, and its supposed to lock SMI code prior to executing untrusted option ROMs or bootloaders (otherwise you have a pretty nasty vulnerability on your hands).

But, I wouldn't call SMI handlers "part of" the BIOS, partly because they don't perform the same function as BIOS, but perhaps more importantly because they run in a logically separate execution environment from the BIOS (i.e., System Management Mode).

But, the distinction between "in" versus "set up by" the BIOS isn't particularly important. I'm still curious about your previous claim that you could use SMI to do code signing checks after you've passed control to untrusted code outside BIOS/boot firmware. As I said in my previous message, its not clear to me how that would work. What would trigger the SMI handler to perform the check?

I'm pretty sure it will be a problem for the tiny number of people that will attempt to do this on a new OEM-purchased Win8 box.

I have to admit, I have no idea what you're talking about when referring to some sort of sandboxed environment in BIOS. Nobody does that now, nor is it clear from me that it's even be possible to secure up a secure sandbox to execute opROMs in. Even if it is possible, it seems like it would be rather difficult to implement, so OEMs wouldn't be interested in wasting their precious system flash space on it.

While I'm skeptical of any sort of secure sandbox, you can have compatibility layers. In UEFI BIOS, you can load Compatibility Support Modules (CSM) to execute legacy option ROMs. But, this isn't a secure way to execute untrusted code- its just there for compatibility with legacy hardware/firmware. So, OEMs are explicitly prohibited from loading CSMs when secure boot is enabled.

My point is that your video card isn't going to work in the preboot environment if you don't have a signed UEFI device driver. Could an OS potentially work around that and get the video card working under the OS? Maybe, but even then you're still not going to be able to go into the BIOS settings in preboot to turn off UEFI secure boot, because video isn't going to work there. I don't know for sure, but I suspect Windows would have hard time using a video card if its option ROM wasn't executed during boot.

So, the moral of the story is just if you buy a Dell Windows 8 system, and want to toss in an old video card, make sure you turn off secure boot *before* you take out the video card the system came with (that is, if it has a discrete video card at all).

UEFI secure boot isn't incompatible with your idea. You'd still need some standardized interfaces for signing code and verifying that code at boot. The main differences would be trust anchor management and the signing process. But, the architecture of UEFI secure boot is absolutely compatible with the idea that the device owner can determine what code should run. Microsoft's requirement for x86 systems pretty much mandates it. It's Microsoft's requirements for ARM systems that are incompatible.

But, your proposed solution is awful for the vast majority of people. How are novice users going to sign the boot code on their systems? Your saying every single person is going to have to securely manage a private signing key for every device they have. To update code, that user is going to have to pull out that private signing key, sign the code they want to update their system to run, and then update the code. For home users, that sounds incredibly complicated. For corporations, it doesn't lend itself well to automation. It's only good for enthusiasts.

What's the alternative? For the vast majority of people, its much, much better to have a small set of trusted third parties that will sign boot code. I know I don't want to have to keep a signing key in a protected place, and have to take it out and use it to sign code whenever I want to update an option ROM or bootloader.

The compromise on x86 systems seems like a good approach. Microsoft will run a signing service, but if people want to swap out the trust anchors and stand up their own signing service, they can. That's not going to be easy for people to do, but I really don't see an alternative. What am I missing?

I fully intend to keep UEFI secure boot turned on whenever possible. It's a very useful security feature. We're already seeing some malware that modifies the Windows bootloader to get around 64-bit Windows code signing checks.