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?