Prohibition of seed saving, copyright/patent suits against others when the trait hybridizes with other varieties, fooling courts into finding in their favor only to have their assertions disproved after it's too late, Harassment of farmers who choose not to grow their modified varieties.
Don't pawn all that off on liberals. I'm fine with irradiation and sterile packaging for food and medical supplies.
I don't believe that GM techniques are somehow intrinsically bad, I just don't believe that the corporations developing them are at all angelic or infallible. That is, if there is a corner to cut, they will cut it and externalize the risks.
For example, will the work in TFA result in food with less anti-oxidants or more things toxic to humans (but not necessarily the plants). Perhaps, perhaps not. Will the seed producers scrupulously test for that? Hell no, that costs money. If we find out later that it is a problem, will they have carefully contained the new varieties such that they can be removed from the food supply without a huge public expenditure? I doubt it. See this.
Highly targeted spraying isn't the same as light use.
Fully agreed, seeds should not be subject to patent or copyright. That has already been abused and the plaintiffs have already gotten away with too many lies in court to the detriment of everyone else.
I have actually disassembled BIOS before. I'm not against a massive clean-up of some of the nasty proprietary code. For example, CoreBoot + SeaBIOS is good.
The goalpost didn't even quiver. If the BIOS is read only in hardware, nobody's going to implant an APT in it by any means other than physically setting the write enable jumper PERIOD. Exploiting the SMM or even the ME can't change that.
Keep in mind, we're talking about the value add for writable firmware here, so the face that the OS might be corrupted after being booted (for example, through an obscure TCP stack vuln) is irrelevant since that can happen no matter what booted it.
An ME vuln CAN disable checking firmware signatures. That has actually been demonstrated. But if writing is disabled in hardware, no remote attack can change that.
TL;DR my point is that we would be better off tossing out ME, EFI, SMM and all the other complexities and just use a simple old school firmware that you have to be physically present to make writable. None of that stuff adds to YOUR security, but it can certainly provide aid and comfort to your enemies (known and unknown).
I am well aware that that isn't the direction industry is choosing. Whaty does that sau about the industry and your relationship to it?
A funny thing with secure boot in UEFI. Why can't the bad guy just turn it off or replace your key with his own and then sign a new corrupted bootloader?
You can check what key is installed once the system boots, but if you're unknowingly running the bad guy's patched kernel, you can't trust the results of the check.
If the firmware can be changed, that includes the trust DB or the code that checks the signatures.
If someone prefers convenience over security, they can set the jumper when they set up the machine. If they want a middle way, they can replace the jumper with a switch on the front panel.
You're right that most people don't care. They just turn secure boot off too since that may also be inconvenient later.
Essentially, you are advocating to open a REMOTE vulnerability just in case you want to apply a patch to close a vulnerability that requires physical presence to exploit. In reality, there are a lot more people halfway across the world who might like to take advantage of a remote vulnerability from the safety of their basement then there are people willing to actually enter my server room (where they might actually face arrest) to carry out an exploit.
There is also a matter of scale and target value. Nobody is going to fly halfway across the world to attack my server. But plenty of bad people might put significant effort into a hack where they could compromise thousands of servers in a single night with a bad update.
Member the days when you used to drop your phone n the battery would fall out. Now if you drop your phone your heart falls out ur arsehole Megan Macleod
And what exact protection does Coreboot provide that UEFI Secure Boot does not provide in this regard?
If I may interject, the concept of secure boot only works as a security measure if the owner of the hardware is the sole owner of the key trusted to sign the bootloader and the OS. My machine, *I* sign the code I trust. MS's opinion doesn't matter. Intel's opinion doesn't matter.
That is absolutely false. If you can compromise the firmware then it does not matter what is loaded afterward, you can modify it as it is loaded or before it is loaded.
I think you missed my point. The BIOS is out of the picture by the time the network is up. It is also read only. So that's a really big IF. You'll need to be physically present to set that jumper if you want to implant an APT into the firmware..
Note that IOMMU and VT-d are not the same thing. VT-d is a way to give a real PCI device over to a VM.IOMMU includes preventing PCI cards from overflowing a memory/address space assignment at the hardware level. Likewise, the USB controller itself will enforce buffer limits. Since USB data transfer is host driven, the device doesn't have much opportunity to make trouble.
Unless you implement a very simple PHY and depend on polling and bit banging to implement soft USB, that's not going to be a problem. (And if you DO implement that, you already have a problem or five).
Note with all of this, it *IS* possible to update the firmware if you're physically present to set the jumper (or do the chromebook secret handshake as you pointed out). But again, if the firmware is read-only, you won't be installing an APT there.
But in all of those scenarios, if it can work against a PC with an old BIOS, it will also work against a PC with EFI. However, since EFI doesn't play nice with read-only flash, you get a bonus that the evil USB or PCI device can implant an APT in the EFI such that removing the offending device and re-installing the OS won't help. You'd need tools that most repair shops and IT departments don't have.
If you disable CSM then...
Yes. Likewise, for similar reasons, I fully expect all that API in UEFI to be considered avoid at all cost in the future.
I am assuming you would have the choice to trust a cert from a non -apple- manufacturer or bypass the warning to check for certs like we do with browsers today.
You should, so you don't end up locked in. Which is exactly why I assume that ability will quietly disappear one fine day. Possibly after a "totally accidental" time delay to make sure everyone's installed the new shiny before the other shoe drops.
I don't NEED EFI. Initing the video card has been happening since before the first PC.
I will concede that some sort of byte code could be a useful thing (divorced from EFI). For example, some other firmware systems used to support a FORTH interpreter. I even experimentally added one to LinuxBIOS at one time, but I ran out of time to work on it.
Those opportunities will be hard to come by if the BIOS is a distant memory by the time networking is up. The on-disk bootloader would be a much "better" target for the bad guy and offers some chance at persistence.
A USB device could be a problem if you boot from it, if the BIOS is configured to boot from USB, but EFI and/or firmware updates won't change that. PCI devices could certainly be a problem, though less so now that chipsets have an IOMMU. If the option ROM contains an exploit, again neither EFI or the ability to update firmware will make it go away.
I am aware of how many things have firmware in them. I write some of it. Ignoring the KISS principle is the problem. Ignoring it harder isn't the solution to that problem.
Note that in many of those things, the case for updatability is better since the firmware is the only ware on the thing and it provides all of the functionality including the user interface. That is a bit contrast to something that provides (or should provide) no user functionality other than loading the OS and going away.
As a side note, don't forget that BIOS provides int 20 functions left over from the original IBM PC. Beyond the boot sector, it gets ignored completely, for good reason. I suspect the past will repeat itself.
If the firmware isn't writable, it won't get corrupted by an attacker in the first place. Making it updatable without physical intervention actually PROVIDES the attack vector that you then have to create security updates to protect.
As for a hacked USB device, it is widely believed that physical access == game over in any event.
The idea of the OS update channel being able to apply updates to the firmware is a big screaming NO! It's bad enough that the OS is changing out from under the user.
As for vendor lock-in, it is still being accomplished through NDA's, undocumented but necessary information and blobs. EFI did nothing to fix that.
If the BIOS contains any code that creates a security problem for a server, you've already screwed up. By the time the OS comes up, the BIOS should be a distant memory. If you need to upgrade it to support new hardware, you've already opened it up to change the hardware. If the user isn't sophisticated enough to know firmware exists, how would they ever come to the conclusion they need to update it?
You would be surprised how modular BIOS can actually be without a complex API. It starts with the CPU specific code, moves on to the platform specific code, then the more generic code. All without a filesystem, memory allocator, or stored variables beyond a few bytes in CMOS.
Slashdot Mirror
The rational thing to do then is for the lower classes to compost the rich.
Prohibition of seed saving, copyright/patent suits against others when the trait hybridizes with other varieties, fooling courts into finding in their favor only to have their assertions disproved after it's too late, Harassment of farmers who choose not to grow their modified varieties.
Don't pawn all that off on liberals. I'm fine with irradiation and sterile packaging for food and medical supplies.
I don't believe that GM techniques are somehow intrinsically bad, I just don't believe that the corporations developing them are at all angelic or infallible. That is, if there is a corner to cut, they will cut it and externalize the risks.
For example, will the work in TFA result in food with less anti-oxidants or more things toxic to humans (but not necessarily the plants). Perhaps, perhaps not. Will the seed producers scrupulously test for that? Hell no, that costs money. If we find out later that it is a problem, will they have carefully contained the new varieties such that they can be removed from the food supply without a huge public expenditure? I doubt it. See this.
Highly targeted spraying isn't the same as light use.
Fully agreed, seeds should not be subject to patent or copyright. That has already been abused and the plaintiffs have already gotten away with too many lies in court to the detriment of everyone else.
I have actually disassembled BIOS before. I'm not against a massive clean-up of some of the nasty proprietary code. For example, CoreBoot + SeaBIOS is good.
I must have missed a memo, which one is that that doesn't harm the environment?
I'm saying Google and most corporations play accounting games that are on the ragged edge of legality and provability.
Except when they play accounting games to shift those revenues to overseas offices.
Yes, the employees pay their taxes, so they should enjoy the best efforts of the fire department should their property be threatened.
The goalpost didn't even quiver. If the BIOS is read only in hardware, nobody's going to implant an APT in it by any means other than physically setting the write enable jumper PERIOD. Exploiting the SMM or even the ME can't change that.
Keep in mind, we're talking about the value add for writable firmware here, so the face that the OS might be corrupted after being booted (for example, through an obscure TCP stack vuln) is irrelevant since that can happen no matter what booted it.
An ME vuln CAN disable checking firmware signatures. That has actually been demonstrated. But if writing is disabled in hardware, no remote attack can change that.
TL;DR my point is that we would be better off tossing out ME, EFI, SMM and all the other complexities and just use a simple old school firmware that you have to be physically present to make writable. None of that stuff adds to YOUR security, but it can certainly provide aid and comfort to your enemies (known and unknown).
I am well aware that that isn't the direction industry is choosing. Whaty does that sau about the industry and your relationship to it?
A funny thing with secure boot in UEFI. Why can't the bad guy just turn it off or replace your key with his own and then sign a new corrupted bootloader?
You can check what key is installed once the system boots, but if you're unknowingly running the bad guy's patched kernel, you can't trust the results of the check.
It's turtles all the way down.
So what magic is it that EFI is somehow able to fit, but a BIOS supporting the old ABI just can't manage?
BIOS has been going into flat-32 mode for some time. Are you saying a 4GB address space just isn't big enough?
If the firmware can be changed, that includes the trust DB or the code that checks the signatures.
If someone prefers convenience over security, they can set the jumper when they set up the machine. If they want a middle way, they can replace the jumper with a switch on the front panel.
You're right that most people don't care. They just turn secure boot off too since that may also be inconvenient later.
Essentially, you are advocating to open a REMOTE vulnerability just in case you want to apply a patch to close a vulnerability that requires physical presence to exploit. In reality, there are a lot more people halfway across the world who might like to take advantage of a remote vulnerability from the safety of their basement then there are people willing to actually enter my server room (where they might actually face arrest) to carry out an exploit.
There is also a matter of scale and target value. Nobody is going to fly halfway across the world to attack my server. But plenty of bad people might put significant effort into a hack where they could compromise thousands of servers in a single night with a bad update.
Relevant Scottish tweet:
Member the days when you used to drop your phone n the battery would fall out. Now if you drop your phone your heart falls out ur arsehole
Megan Macleod
And what exact protection does Coreboot provide that UEFI Secure Boot does not provide in this regard?
If I may interject, the concept of secure boot only works as a security measure if the owner of the hardware is the sole owner of the key trusted to sign the bootloader and the OS. My machine, *I* sign the code I trust. MS's opinion doesn't matter. Intel's opinion doesn't matter.
That is absolutely false. If you can compromise the firmware then it does not matter what is loaded afterward, you can modify it as it is loaded or before it is loaded.
I think you missed my point. The BIOS is out of the picture by the time the network is up. It is also read only. So that's a really big IF. You'll need to be physically present to set that jumper if you want to implant an APT into the firmware..
Note that IOMMU and VT-d are not the same thing. VT-d is a way to give a real PCI device over to a VM.IOMMU includes preventing PCI cards from overflowing a memory/address space assignment at the hardware level. Likewise, the USB controller itself will enforce buffer limits. Since USB data transfer is host driven, the device doesn't have much opportunity to make trouble.
Unless you implement a very simple PHY and depend on polling and bit banging to implement soft USB, that's not going to be a problem. (And if you DO implement that, you already have a problem or five).
Note with all of this, it *IS* possible to update the firmware if you're physically present to set the jumper (or do the chromebook secret handshake as you pointed out). But again, if the firmware is read-only, you won't be installing an APT there.
But in all of those scenarios, if it can work against a PC with an old BIOS, it will also work against a PC with EFI. However, since EFI doesn't play nice with read-only flash, you get a bonus that the evil USB or PCI device can implant an APT in the EFI such that removing the offending device and re-installing the OS won't help. You'd need tools that most repair shops and IT departments don't have.
If you disable CSM then...
Yes. Likewise, for similar reasons, I fully expect all that API in UEFI to be considered avoid at all cost in the future.
The judge likely wanted to be a bit more comprehensive since he could see that the board was quite willing to abuse any hint of a technicality.
Or the dreaded non-OEM ink and toner which will like totally make your printer explode and mutate your cat's DNA.
I am assuming you would have the choice to trust a cert from a non -apple- manufacturer or bypass the warning to check for certs like we do with browsers today.
You should, so you don't end up locked in. Which is exactly why I assume that ability will quietly disappear one fine day. Possibly after a "totally accidental" time delay to make sure everyone's installed the new shiny before the other shoe drops.
https://slashdot.org/comments.pl?sid=19/01/02/2025207&cid=57894076&sbsrc=topcom#
I don't NEED EFI. Initing the video card has been happening since before the first PC.
I will concede that some sort of byte code could be a useful thing (divorced from EFI). For example, some other firmware systems used to support a FORTH interpreter. I even experimentally added one to LinuxBIOS at one time, but I ran out of time to work on it.
Those opportunities will be hard to come by if the BIOS is a distant memory by the time networking is up. The on-disk bootloader would be a much "better" target for the bad guy and offers some chance at persistence.
A USB device could be a problem if you boot from it, if the BIOS is configured to boot from USB, but EFI and/or firmware updates won't change that. PCI devices could certainly be a problem, though less so now that chipsets have an IOMMU. If the option ROM contains an exploit, again neither EFI or the ability to update firmware will make it go away.
I am aware of how many things have firmware in them. I write some of it. Ignoring the KISS principle is the problem. Ignoring it harder isn't the solution to that problem.
Note that in many of those things, the case for updatability is better since the firmware is the only ware on the thing and it provides all of the functionality including the user interface. That is a bit contrast to something that provides (or should provide) no user functionality other than loading the OS and going away.
As a side note, don't forget that BIOS provides int 20 functions left over from the original IBM PC. Beyond the boot sector, it gets ignored completely, for good reason. I suspect the past will repeat itself.
If the firmware isn't writable, it won't get corrupted by an attacker in the first place. Making it updatable without physical intervention actually PROVIDES the attack vector that you then have to create security updates to protect.
As for a hacked USB device, it is widely believed that physical access == game over in any event.
The idea of the OS update channel being able to apply updates to the firmware is a big screaming NO! It's bad enough that the OS is changing out from under the user.
As for vendor lock-in, it is still being accomplished through NDA's, undocumented but necessary information and blobs. EFI did nothing to fix that.
So they tooked it down?
We can all rest easily in our hice knowing that.
If the BIOS contains any code that creates a security problem for a server, you've already screwed up. By the time the OS comes up, the BIOS should be a distant memory. If you need to upgrade it to support new hardware, you've already opened it up to change the hardware. If the user isn't sophisticated enough to know firmware exists, how would they ever come to the conclusion they need to update it?
You would be surprised how modular BIOS can actually be without a complex API. It starts with the CPU specific code, moves on to the platform specific code, then the more generic code. All without a filesystem, memory allocator, or stored variables beyond a few bytes in CMOS.
That would be best, yes.
So why not throw the excess plumbing away and just have the BIOS call the secure boot module?
EFI isn't needed for that, it just happens to be where it was implemented.