we should be able to eat and digest things like all grasses, and branches, etc. We can't do that.
While I agree that veganism is not human nature (it is likely we would not have developed as far mentally without the proteins and Omega-3 fatty acids from meat, for example), I'm not sure I understand the quoted argument. Are you saying that if it is human nature to be vegan, that we should be able to eat any plant matter? All herbivorous animals are not capable of eating the same things. For example, a cow can eat grass, but an herbivorous bird might not be capable of eating grass and can only eat seeds. Are you saying that makes them not vegan?
Good point. The only fix I can see for your problem would be for both BIOS chips to be flashable. After updating and testing the new BIOS revision, then flip a jumper to switch to the backup chip and update that one as well. As long as they are physically separate and only accessable when the jumper is flipped, the backup BIOS should not be affected by this attack.
So what happens when they learn to write over the "unwritable" one?
I meant a ROM chip that, once manufactured, is literally not able to be written to physically, just like the old BIOS chips in the days before they were flashable. Or, failing that, use 2 writable flash chips that are physically separate and switched between with a hardware jumper. If someone can move a jumper on your PC with no physical access, then you are fucked because you are dealing with a hacker with telekinesis. If they have physical access to your PC, then you are fucked no matter what failsafes are in play.
What if the unwritable one gets legitimately corrupted?
Then you are fucked, sorry. There are diminishing returns. The chance of both your flashable BIOS chip and your backup chip getting hacked or corrupted are pretty small.
AC has a point when it comes to average users, who are normally very afraid of even looking inside the computer in case some of the magic smoke that makes it work leaks out. Then again, those users are unlikely to be flashing their BIOS and are probably paying the Geek Squad hundreds of dollars to do it for them. A replaceable chip makes it easy and reversible for those that will actually be performing the work.
I see, thanks. I had thought prior art was just used to invalidate a patent by demonstrating that it has been implemented before by you and therefore they had no right to patent that design(and you could thus possibly claim ownership of the patent?). Am I understanding correctly that a claim of prior art is to demonstrate obviousness of the design and therefore it should not be patentable? Not trying to spark debate or flame or anything, just curious.
I was referring to the BIOS settings, which is where the BIOS password is normally stored. I probably should have specified the word "settings", but alas, I lack an edit button.
I'm pretty sure to claim prior art you have to have actually implemented your idea and not just thought of it and documented it. I could very well be mistaken.
Is the backup BIOS writable? If not, then perfect! If yes, then it would help protect against BIOS update failures, but might not against an attack like this.
Really? They show shit like that on the news and in the newspapers where you live? The pictures are of late-stage abortions or miscarriages and show bloody, deformed, dead babies. All the while claiming to be photographs of early-term abortions. No news network or newspaper I've ever seen shows shit like that.
I still can't see how blocking pornography is any different. It is blocked because they claim both are offensive material. If it were naughty pictures with some sort of political agenda would you say it should not be blocked? I agree that anti-abortion sites should not be blocked. Neither should pro-abortion sites. And, frankly, neither should pornography. If you are afraid of dirty pictures on the internet shattering your poor child's mind, then stop being lazy and use the FREE filtering software the government provided you beforehand. Or just do your job as a parent yourself and stop making the government do it for you.
Every motherboard I've ever worked with either had a BIOS reset jumper or the CMOS battery was removable. The settings entered into the BIOS configuration screen are not normally saved to the Flash ROM, but are stored in CMOS and kept alive by the battery. If you remove the battery or use the reset jumper procedure, it kills power to the CMOS and the settings are cleared, this normally includes the BIOS password.
Also, I just reread my post and realized that you might have misunderstood. I was referring to resetting the BIOS password and settings, not the contents of the flash rom.
From what I get from the summary, what is new is that it only replaces part of the BIOS instead of installing a whole new one. If it can somehow tell which part it needs to replace on different model motherboards, then it may be able to spread further than older BIOS malware which is normally motherboard-specific.
If it replaces anything it would probably be the hardware controls that a modern OS normally controls directly. So you could keep a copy of DOS handy and if it stops working with some bit of hardware then you may be infected.
The virus could check if the motherboard is compatible with coreboot or something similar before flashing a modified version. If coreboot can boot a linux kernel directly without any other bootloader, it is likely possible that the average BIOS has enough room for self-replicating code.
I do agree that it is not revolutionary, I've heard of BIOS viruses for a while, but the general consensus was that they are too motherboard-specific to be of any real threat. However, coreboot claims it is supported on over 200 mainboard models, so perhaps they have become less specialized.
This is why there should always be 2 copies of the BIOS. One that is physically read-only and contains the BIOS as shipped. And another writable one that can be disabled with a jumper. If your BIOS is corrupted or hijacked, you could always go back to the backup BIOS and restore.
An alternative would be replaceable BIOS chips like the ones from the days before writable BIOS. If a customer gets a BIOS corruption or virus, they could call and order a replacement and not have to buy a whole new mobo. That would also be a good way to distribute BIOS updates to people afraid of bricking their system.
if your BIOS password were changed, you'd be out of luck
Or you could reset the BIOS with the jumper or by unplugging and removing the CMOS battery. Unless said hijack somehow creates a permanent BIOS password, in which case you'd be totally screwed.
IIRC, there was never a porn-only optional filter. Originally they were going to have 2 filters: the default, which blocks porn and "illegal files", and the on-request one that only blocks "illegal files". If this was just about porn, then they should have stuck with the original plan of providing filtering software to people who wanted it. These people were too lazy to do it themselves, or just wanted to censor everybody, so now we have the filter.
Also, the anti-abortion website they blocked was because it was shock photos, kind of like goatse but with dead cut-up babies. If you don't want them to censor that, but you're okay with them censoring other things, than you are just a fucking hypocrite.
I had misunderstood the previous story due to seeing an overwhelming number of posts stating that you shouldn't expect data to be written successfully unless you explicitly fsync(). Now I understand that a crash between rename() and whenever the filesystem forces a write will leave 2 zero sized files. As far as browser cache goes, I'm surprised the browser would not ignore cache files with a size of zero, but this is still bad filesystem behavior and not application behavior.
If your write rate is low and you are worried about this, use nodelalloc when mounting. On a high-volume server with battery-backed cache and a solid UPS, go for the delayed allocation.
Well, I looked into this a bit more and understand now. The problem is not that data that hasn't been fsync()'ed isn't guaranteed. It is that rename() operations replaces the old file before writing the new file to disc. My bad, that is bad behavior.
From what I understand, the only data lost is when the application calls sync() instead of fsync(). The POSIX spec in question has long been that a sync() does not guarantee that the data is written until the next scheduled write. The problem exists in other file systems, but the write-ahead time is so short as to be less likely to cause a problem. EXT4 has such a long write-ahead time that now it can cause a problem.
Slashdot Mirror
So he wants prominent display of licensing for the client-side code on websites, and something like Greasemonkey built into OSS browsers?.
Isn't he the guy that claims he browses the web by invoking some daemon to download an html page and email it to him? If so, why would he even care?
we should be able to eat and digest things like all grasses, and branches, etc. We can't do that.
While I agree that veganism is not human nature (it is likely we would not have developed as far mentally without the proteins and Omega-3 fatty acids from meat, for example), I'm not sure I understand the quoted argument. Are you saying that if it is human nature to be vegan, that we should be able to eat any plant matter? All herbivorous animals are not capable of eating the same things. For example, a cow can eat grass, but an herbivorous bird might not be capable of eating grass and can only eat seeds. Are you saying that makes them not vegan?
Good point. The only fix I can see for your problem would be for both BIOS chips to be flashable. After updating and testing the new BIOS revision, then flip a jumper to switch to the backup chip and update that one as well. As long as they are physically separate and only accessable when the jumper is flipped, the backup BIOS should not be affected by this attack.
So what happens when they learn to write over the "unwritable" one?
I meant a ROM chip that, once manufactured, is literally not able to be written to physically, just like the old BIOS chips in the days before they were flashable. Or, failing that, use 2 writable flash chips that are physically separate and switched between with a hardware jumper. If someone can move a jumper on your PC with no physical access, then you are fucked because you are dealing with a hacker with telekinesis. If they have physical access to your PC, then you are fucked no matter what failsafes are in play.
What if the unwritable one gets legitimately corrupted?
Then you are fucked, sorry. There are diminishing returns. The chance of both your flashable BIOS chip and your backup chip getting hacked or corrupted are pretty small.
AC has a point when it comes to average users, who are normally very afraid of even looking inside the computer in case some of the magic smoke that makes it work leaks out. Then again, those users are unlikely to be flashing their BIOS and are probably paying the Geek Squad hundreds of dollars to do it for them. A replaceable chip makes it easy and reversible for those that will actually be performing the work.
Add another layer to your tinfoil hat?
I see, thanks. I had thought prior art was just used to invalidate a patent by demonstrating that it has been implemented before by you and therefore they had no right to patent that design(and you could thus possibly claim ownership of the patent?). Am I understanding correctly that a claim of prior art is to demonstrate obviousness of the design and therefore it should not be patentable? Not trying to spark debate or flame or anything, just curious.
I was referring to the BIOS settings, which is where the BIOS password is normally stored. I probably should have specified the word "settings", but alas, I lack an edit button.
I'm pretty sure to claim prior art you have to have actually implemented your idea and not just thought of it and documented it. I could very well be mistaken.
Is the backup BIOS writable? If not, then perfect! If yes, then it would help protect against BIOS update failures, but might not against an attack like this.
Really? They show shit like that on the news and in the newspapers where you live? The pictures are of late-stage abortions or miscarriages and show bloody, deformed, dead babies. All the while claiming to be photographs of early-term abortions. No news network or newspaper I've ever seen shows shit like that.
I still can't see how blocking pornography is any different. It is blocked because they claim both are offensive material. If it were naughty pictures with some sort of political agenda would you say it should not be blocked? I agree that anti-abortion sites should not be blocked. Neither should pro-abortion sites. And, frankly, neither should pornography. If you are afraid of dirty pictures on the internet shattering your poor child's mind, then stop being lazy and use the FREE filtering software the government provided you beforehand. Or just do your job as a parent yourself and stop making the government do it for you.
Probably most customers didn't care about the feature compared to what it cost to implement. I do wish this was standard though.
Every motherboard I've ever worked with either had a BIOS reset jumper or the CMOS battery was removable. The settings entered into the BIOS configuration screen are not normally saved to the Flash ROM, but are stored in CMOS and kept alive by the battery. If you remove the battery or use the reset jumper procedure, it kills power to the CMOS and the settings are cleared, this normally includes the BIOS password.
Also, I just reread my post and realized that you might have misunderstood. I was referring to resetting the BIOS password and settings, not the contents of the flash rom.
From what I get from the summary, what is new is that it only replaces part of the BIOS instead of installing a whole new one. If it can somehow tell which part it needs to replace on different model motherboards, then it may be able to spread further than older BIOS malware which is normally motherboard-specific.
If it replaces anything it would probably be the hardware controls that a modern OS normally controls directly. So you could keep a copy of DOS handy and if it stops working with some bit of hardware then you may be infected.
The virus could check if the motherboard is compatible with coreboot or something similar before flashing a modified version. If coreboot can boot a linux kernel directly without any other bootloader, it is likely possible that the average BIOS has enough room for self-replicating code.
I do agree that it is not revolutionary, I've heard of BIOS viruses for a while, but the general consensus was that they are too motherboard-specific to be of any real threat. However, coreboot claims it is supported on over 200 mainboard models, so perhaps they have become less specialized.
This is why there should always be 2 copies of the BIOS. One that is physically read-only and contains the BIOS as shipped. And another writable one that can be disabled with a jumper. If your BIOS is corrupted or hijacked, you could always go back to the backup BIOS and restore.
An alternative would be replaceable BIOS chips like the ones from the days before writable BIOS. If a customer gets a BIOS corruption or virus, they could call and order a replacement and not have to buy a whole new mobo. That would also be a good way to distribute BIOS updates to people afraid of bricking their system.
if your BIOS password were changed, you'd be out of luck
Or you could reset the BIOS with the jumper or by unplugging and removing the CMOS battery. Unless said hijack somehow creates a permanent BIOS password, in which case you'd be totally screwed.
IIRC, there was never a porn-only optional filter. Originally they were going to have 2 filters: the default, which blocks porn and "illegal files", and the on-request one that only blocks "illegal files". If this was just about porn, then they should have stuck with the original plan of providing filtering software to people who wanted it. These people were too lazy to do it themselves, or just wanted to censor everybody, so now we have the filter.
Also, the anti-abortion website they blocked was because it was shock photos, kind of like goatse but with dead cut-up babies. If you don't want them to censor that, but you're okay with them censoring other things, than you are just a fucking hypocrite.
I had misunderstood the previous story due to seeing an overwhelming number of posts stating that you shouldn't expect data to be written successfully unless you explicitly fsync(). Now I understand that a crash between rename() and whenever the filesystem forces a write will leave 2 zero sized files. As far as browser cache goes, I'm surprised the browser would not ignore cache files with a size of zero, but this is still bad filesystem behavior and not application behavior.
If your write rate is low and you are worried about this, use nodelalloc when mounting. On a high-volume server with battery-backed cache and a solid UPS, go for the delayed allocation.
(such as browser cache)
Is there a better example? Browser cache should be volatile.
Well, I looked into this a bit more and understand now. The problem is not that data that hasn't been fsync()'ed isn't guaranteed. It is that rename() operations replaces the old file before writing the new file to disc. My bad, that is bad behavior.
From what I understand, the only data lost is when the application calls sync() instead of fsync(). The POSIX spec in question has long been that a sync() does not guarantee that the data is written until the next scheduled write. The problem exists in other file systems, but the write-ahead time is so short as to be less likely to cause a problem. EXT4 has such a long write-ahead time that now it can cause a problem.