| Computing desk | ||
|---|---|---|
| < August 28 | << Jul | August | Sep >> | August 30 > |
| Welcome to the Wikipedia Computing Reference Desk Archives |
|---|
| The page you are currently viewing is an archive page. While you can leave answers for any questions shown below, please ask new questions on one of the current reference desk pages. |
August 29 Information
I want to write a secure bootloader that will verify the digital signature of whatever it is goong to boot. I think it would need more than 512 bytes to fit all of the code, so I need to find a way that will make it possible to do this. Maybe a disk that does use sectors or is sectorless would work since the 512 byte limit is based on sector size? -- Melab±1 ☎ 02:37, 29 August 2011 (UTC)
- Advanced Format drives have 4096-byte sectors. A disk cannot be sectorless; as the sector is the basic unit in a data storage device in which data is stored. Rocketshiporion ♫ 04:45, 29 August 2011 (UTC)
- In the old days of floppy discs, it was possible to read a complete track into memory if one had direct access to the disc controller. (Of course, the data was not directly available from this read because it was spread in sectors, but a simple software routine could extract the data from all sectors in that track.) This facility has possibly been removed from the disc control firmware of hard drives because they are usually low-level formatted at manufacture. Dbfirs 08:42, 29 August 2011 (UTC)
- The boot process won't be secure unless the BIOS verifies your first-stage bootloader before running it. That means there's code in the BIOS to verify digital signatures and you should be able to use that to verify the next stage. -- BenRG ( talk) 06:11, 29 August 2011 (UTC)
- I'm assuming you mean a computer that is sufficiently like what we normally call "a PC", right? In that case you have two problems: loading and checking signatures. Firstly loading (neglecting the digital signature part for a second):
- The standard way to work given the BIOS 512 byte load is to load a tiny stub loader (and if we're talking Master boot record loading here, you only have 440 bytes for code there) which uses BIOS calls to load a fuller loader (which can be just about as many sectors as you want). That's what LILO and GRUB do.
- Use a system with Unified Extensible Firmware Interface rather than a BIOS boot, which doesn't have that limitation.
- (At a stretch) add whatever functionality you want to a custom flash image, and replace the BIOS image with that. People have wedged stuff into coreboot, for example.
- But, as BenRG says, this is all for naught if you can't verify the first thing you boot. Even with the coreboot solution, if you can change the boot flash image, so can anyone else. And where would you keep your key information - the BIOS flash part is just a memory device, readable by anyone. The industry-suggested solution to this is to use Trusted Platform Module, which stores keys in a relatively secure manner and which performs cryptography and validation. Some higher end desktop and server machines have TPM modules, and it seems many laptops do. But even then, this requires that the flash part be write protected and the boot code therein use an already initialised TPM to verify the bootloader it reads off the disk (see p12 onward in this presentation), which it seems isn't something that's practically available to an end user (cf TrouSerS FAQ). Even if it was, this is of very limited practical utility. TPM is mostly intended to provide a chain-of-trust so someone can trust the integrity of a loaded OS image, not to absolutely lock people out of otherwise generic hardware. Flashes can easily be physically swapped, non-integrated TPMs desoldered, and integrated ones removed by replacing the CPU. Even the original XBox, which went to extraordinary lengths to verify its boot chain (integrating that logic into its custom CPU and GPU dies) was still extensively modchipped. -- Finlay McWalter ☻ Talk 10:20, 29 August 2011 (UTC)
- EFI is a standard which is implemented by a bootrom, so an EFI compliant loader is almost always in directly addressable flash memory. Disks could be sectorless, and indeed SCSI has "read byte" commands (and so forth). But disks are sector addressed (really they're LBA addressed) because that's the standard that's evolved, mostly to cater for bulk sequential access of whole blocks. How a disk is sectored is an irrelevance for booting, as is the size of blocks. BIOS boots with a 512 byte block because it does, because it's compatible with programs that expect that. It would be trivial to code a bootloader that loaded more data, but that wouldn't be compatible with all the existing bootloaders that work the way they do. EFI throws that compatibility away. No smartphones don't use BIOS or EFI, in general. Some tablets do. --
Finlay McWalter ☻
Talk 13:36, 31 August 2011 (UTC)
- To be clear, BIOS is a specification for a type of boot ROM, right? --
Melab±1
☎ 14:21, 31 August 2011 (UTC)
- In part, yes. It's also a word that people use generically when they mean "bootrom" (luckily the common usage seems to be adapting to understand the difference, now that people care about how their iPhone or Android phone boots). It's also the standard set of real-mode APIs (implemented via interrupts) that CP/M and DOS programs expected to call to do hardware stuff (a basic set of built-in device drivers); boot loaders still use some of that. And it's a bunch of POST and hardware-discovery and hardware-enable code that's necessary when (unlike a fixed bill of materials device like a phone) the system doesn't know a priori what hardware is installed. The Google Talk the coreboot folks gave is very instructive with regard to all the stuff a PC BIOS has to do before it gets around to actually loading that boot block from the disk. -- Finlay McWalter ☻ Talk 14:38, 31 August 2011 (UTC)
- To be clear, BIOS is a specification for a type of boot ROM, right? --
Melab±1
☎ 14:21, 31 August 2011 (UTC)
- EFI is a standard which is implemented by a bootrom, so an EFI compliant loader is almost always in directly addressable flash memory. Disks could be sectorless, and indeed SCSI has "read byte" commands (and so forth). But disks are sector addressed (really they're LBA addressed) because that's the standard that's evolved, mostly to cater for bulk sequential access of whole blocks. How a disk is sectored is an irrelevance for booting, as is the size of blocks. BIOS boots with a 512 byte block because it does, because it's compatible with programs that expect that. It would be trivial to code a bootloader that loaded more data, but that wouldn't be compatible with all the existing bootloaders that work the way they do. EFI throws that compatibility away. No smartphones don't use BIOS or EFI, in general. Some tablets do. --
Finlay McWalter ☻
Talk 13:36, 31 August 2011 (UTC)
I'm trying to make a layout with three main components: a fixed-height horizontal banner on top, and two columns beneath it filling out the rest of the space. Now, I know that normally I can use a combination of height: 100%, overflow: hidden, and padding to create full-height columns without creating a scrollbar for the page. However, I want the two columns to be full-height and both have overflow-y: scroll, so that they can each be scrolled individually without the entire page having a scrollbar. Unfortunately, the usual column tricks don't seem to work here. If the columns have height: 100%, the scrollbars are able to go off the bottom of the window, even though the column content displays normally; if I try absolutely positioning the columns and force them down with padding, the scrollbars go through the top banner (while forcing them down with margins causing the scrollbars to go off the bottom again). This would of course be easy to fix if I, say, gave the banner a height of 10% and the columns 90%, but I need the banner to have a fixed height. I'm a little stumped as to how to do this without resorting to JavaScript. Obligatory lazy table diagram:
| Top Banner | |
| Vertical Column With Scrolling | Vertical Column With Scrolling |
71.179.14.98 ( talk) 18:04, 29 August 2011 (UTC)
- Use 3 divs. I'll call them header, col1, and col2. Make all 3 have position:absolute. Set header.top:0px, header.height:3em (or whatever height you want it to be), header.left:0px, header.width:100%. Set col1.top:3em (or whatever header.height is), col1.bottom:0px, col1.left:0px, col1.width:50%. Set col2.top:3em, col2.bottom:0px, col2.left:50%, col2.width:50%. -- kainaw ™ 18:18, 29 August 2011 (UTC)
Is there any way to hibernate a single program on a Windows 7 operating system; to save its current state from the RAM onto the disk and resume at a later date? I imagine this isn't a standard Windows feature, but perhaps some third-party software exists that can do this, maybe? 82.43.90.90 ( talk) 18:36, 29 August 2011 (UTC)
- I'm not very familiar with Windows, but I believe in general the ability to "freeze" a program requires internal support by the program itself. Suppose, for example, that the program has files open at the moment you want to freeze it -- there's nothing the operating system could possibly do to make that work without help from the program itself.
Looie496 (
talk) 01:23, 30 August 2011 (UTC)
- Well, you can just close and reopen the files. There are a lot of gotchas in process hibernation, but there are a lot of gotchas in full system hibernation too. (What if a process had a locked file open on a network drive? What if you hibernate an OS, boot into another, modify the first OS's system partition, then resume it?) The idea is reasonable enough, and similar to process migration, which is actually supported by some OSes.
- But I'm not aware of any way to do this in Windows. Microsoft could make it happen, but I'm not aware of any plans to do so. In theory Sandboxie might be able to do it, since the state that would need to be saved and restored is the same state that it has to track anyway. But in point of fact it doesn't support it. VMware and competitors support it, of course, if you think of the whole VM as an app (which is not so unreasonable). -- BenRG ( talk) 04:15, 30 August 2011 (UTC)
- I, too, reached for VMs when thinking of an answer to this query; I "hibernate" my VirtualBox virtual system all the time. Comet Tuttle ( talk) 17:34, 30 August 2011 (UTC)
| Computing desk | ||
|---|---|---|
| < August 28 | << Jul | August | Sep >> | August 30 > |
| Welcome to the Wikipedia Computing Reference Desk Archives |
|---|
| The page you are currently viewing is an archive page. While you can leave answers for any questions shown below, please ask new questions on one of the current reference desk pages. |
August 29 Information
I want to write a secure bootloader that will verify the digital signature of whatever it is goong to boot. I think it would need more than 512 bytes to fit all of the code, so I need to find a way that will make it possible to do this. Maybe a disk that does use sectors or is sectorless would work since the 512 byte limit is based on sector size? -- Melab±1 ☎ 02:37, 29 August 2011 (UTC)
- Advanced Format drives have 4096-byte sectors. A disk cannot be sectorless; as the sector is the basic unit in a data storage device in which data is stored. Rocketshiporion ♫ 04:45, 29 August 2011 (UTC)
- In the old days of floppy discs, it was possible to read a complete track into memory if one had direct access to the disc controller. (Of course, the data was not directly available from this read because it was spread in sectors, but a simple software routine could extract the data from all sectors in that track.) This facility has possibly been removed from the disc control firmware of hard drives because they are usually low-level formatted at manufacture. Dbfirs 08:42, 29 August 2011 (UTC)
- The boot process won't be secure unless the BIOS verifies your first-stage bootloader before running it. That means there's code in the BIOS to verify digital signatures and you should be able to use that to verify the next stage. -- BenRG ( talk) 06:11, 29 August 2011 (UTC)
- I'm assuming you mean a computer that is sufficiently like what we normally call "a PC", right? In that case you have two problems: loading and checking signatures. Firstly loading (neglecting the digital signature part for a second):
- The standard way to work given the BIOS 512 byte load is to load a tiny stub loader (and if we're talking Master boot record loading here, you only have 440 bytes for code there) which uses BIOS calls to load a fuller loader (which can be just about as many sectors as you want). That's what LILO and GRUB do.
- Use a system with Unified Extensible Firmware Interface rather than a BIOS boot, which doesn't have that limitation.
- (At a stretch) add whatever functionality you want to a custom flash image, and replace the BIOS image with that. People have wedged stuff into coreboot, for example.
- But, as BenRG says, this is all for naught if you can't verify the first thing you boot. Even with the coreboot solution, if you can change the boot flash image, so can anyone else. And where would you keep your key information - the BIOS flash part is just a memory device, readable by anyone. The industry-suggested solution to this is to use Trusted Platform Module, which stores keys in a relatively secure manner and which performs cryptography and validation. Some higher end desktop and server machines have TPM modules, and it seems many laptops do. But even then, this requires that the flash part be write protected and the boot code therein use an already initialised TPM to verify the bootloader it reads off the disk (see p12 onward in this presentation), which it seems isn't something that's practically available to an end user (cf TrouSerS FAQ). Even if it was, this is of very limited practical utility. TPM is mostly intended to provide a chain-of-trust so someone can trust the integrity of a loaded OS image, not to absolutely lock people out of otherwise generic hardware. Flashes can easily be physically swapped, non-integrated TPMs desoldered, and integrated ones removed by replacing the CPU. Even the original XBox, which went to extraordinary lengths to verify its boot chain (integrating that logic into its custom CPU and GPU dies) was still extensively modchipped. -- Finlay McWalter ☻ Talk 10:20, 29 August 2011 (UTC)
- EFI is a standard which is implemented by a bootrom, so an EFI compliant loader is almost always in directly addressable flash memory. Disks could be sectorless, and indeed SCSI has "read byte" commands (and so forth). But disks are sector addressed (really they're LBA addressed) because that's the standard that's evolved, mostly to cater for bulk sequential access of whole blocks. How a disk is sectored is an irrelevance for booting, as is the size of blocks. BIOS boots with a 512 byte block because it does, because it's compatible with programs that expect that. It would be trivial to code a bootloader that loaded more data, but that wouldn't be compatible with all the existing bootloaders that work the way they do. EFI throws that compatibility away. No smartphones don't use BIOS or EFI, in general. Some tablets do. --
Finlay McWalter ☻
Talk 13:36, 31 August 2011 (UTC)
- To be clear, BIOS is a specification for a type of boot ROM, right? --
Melab±1
☎ 14:21, 31 August 2011 (UTC)
- In part, yes. It's also a word that people use generically when they mean "bootrom" (luckily the common usage seems to be adapting to understand the difference, now that people care about how their iPhone or Android phone boots). It's also the standard set of real-mode APIs (implemented via interrupts) that CP/M and DOS programs expected to call to do hardware stuff (a basic set of built-in device drivers); boot loaders still use some of that. And it's a bunch of POST and hardware-discovery and hardware-enable code that's necessary when (unlike a fixed bill of materials device like a phone) the system doesn't know a priori what hardware is installed. The Google Talk the coreboot folks gave is very instructive with regard to all the stuff a PC BIOS has to do before it gets around to actually loading that boot block from the disk. -- Finlay McWalter ☻ Talk 14:38, 31 August 2011 (UTC)
- To be clear, BIOS is a specification for a type of boot ROM, right? --
Melab±1
☎ 14:21, 31 August 2011 (UTC)
- EFI is a standard which is implemented by a bootrom, so an EFI compliant loader is almost always in directly addressable flash memory. Disks could be sectorless, and indeed SCSI has "read byte" commands (and so forth). But disks are sector addressed (really they're LBA addressed) because that's the standard that's evolved, mostly to cater for bulk sequential access of whole blocks. How a disk is sectored is an irrelevance for booting, as is the size of blocks. BIOS boots with a 512 byte block because it does, because it's compatible with programs that expect that. It would be trivial to code a bootloader that loaded more data, but that wouldn't be compatible with all the existing bootloaders that work the way they do. EFI throws that compatibility away. No smartphones don't use BIOS or EFI, in general. Some tablets do. --
Finlay McWalter ☻
Talk 13:36, 31 August 2011 (UTC)
I'm trying to make a layout with three main components: a fixed-height horizontal banner on top, and two columns beneath it filling out the rest of the space. Now, I know that normally I can use a combination of height: 100%, overflow: hidden, and padding to create full-height columns without creating a scrollbar for the page. However, I want the two columns to be full-height and both have overflow-y: scroll, so that they can each be scrolled individually without the entire page having a scrollbar. Unfortunately, the usual column tricks don't seem to work here. If the columns have height: 100%, the scrollbars are able to go off the bottom of the window, even though the column content displays normally; if I try absolutely positioning the columns and force them down with padding, the scrollbars go through the top banner (while forcing them down with margins causing the scrollbars to go off the bottom again). This would of course be easy to fix if I, say, gave the banner a height of 10% and the columns 90%, but I need the banner to have a fixed height. I'm a little stumped as to how to do this without resorting to JavaScript. Obligatory lazy table diagram:
| Top Banner | |
| Vertical Column With Scrolling | Vertical Column With Scrolling |
71.179.14.98 ( talk) 18:04, 29 August 2011 (UTC)
- Use 3 divs. I'll call them header, col1, and col2. Make all 3 have position:absolute. Set header.top:0px, header.height:3em (or whatever height you want it to be), header.left:0px, header.width:100%. Set col1.top:3em (or whatever header.height is), col1.bottom:0px, col1.left:0px, col1.width:50%. Set col2.top:3em, col2.bottom:0px, col2.left:50%, col2.width:50%. -- kainaw ™ 18:18, 29 August 2011 (UTC)
Is there any way to hibernate a single program on a Windows 7 operating system; to save its current state from the RAM onto the disk and resume at a later date? I imagine this isn't a standard Windows feature, but perhaps some third-party software exists that can do this, maybe? 82.43.90.90 ( talk) 18:36, 29 August 2011 (UTC)
- I'm not very familiar with Windows, but I believe in general the ability to "freeze" a program requires internal support by the program itself. Suppose, for example, that the program has files open at the moment you want to freeze it -- there's nothing the operating system could possibly do to make that work without help from the program itself.
Looie496 (
talk) 01:23, 30 August 2011 (UTC)
- Well, you can just close and reopen the files. There are a lot of gotchas in process hibernation, but there are a lot of gotchas in full system hibernation too. (What if a process had a locked file open on a network drive? What if you hibernate an OS, boot into another, modify the first OS's system partition, then resume it?) The idea is reasonable enough, and similar to process migration, which is actually supported by some OSes.
- But I'm not aware of any way to do this in Windows. Microsoft could make it happen, but I'm not aware of any plans to do so. In theory Sandboxie might be able to do it, since the state that would need to be saved and restored is the same state that it has to track anyway. But in point of fact it doesn't support it. VMware and competitors support it, of course, if you think of the whole VM as an app (which is not so unreasonable). -- BenRG ( talk) 04:15, 30 August 2011 (UTC)
- I, too, reached for VMs when thinking of an answer to this query; I "hibernate" my VirtualBox virtual system all the time. Comet Tuttle ( talk) 17:34, 30 August 2011 (UTC)