7 ms·

Neither intel nor AMD supports core boot. Community efforts to add core boot focus entirely on intel because of market share (although intel is also plenty host

Neither intel nor AMD supports core boot. Community efforts to add core boot focus entirely on intel because of market share (although intel is also plenty hostile to floss in this regard).

bravo22 7y ago
Not sure about the support. Intel employees regularly submit to coreboot repo. I know at least for the Atom based designs that I've been involved in Intel provides reference designs using coreboot and supports it.
- wahern 7y ago
  AMD is a sponsor of coreboot according to https://www.coreboot.org/Sponsors https://www.coreboot.org/Sponsors Personally, I think the fundamental issue relates to IP. If the hardware design is made transparent by amazing and freely available documentation you invite infringement claims, particularly from IP trolls. (Threats from competitors are probably more existential, though, at least for large companies.) Often time companies will say that their products contain third-party IP that they cannot disclose, but that's just a roundabout way of saying neither the company nor its suppliers want the hassle. There are other reasons, too. For example, if you can't consistently provide such documentation it can make you look worse than if you had never bothered as it makes you appear unreliable. But I think the IP issue is what makes it a simple decision, notwithstanding whether the threats are actually substantial.
  - monocasa 7y ago
    I think it's that DRM doesn't work if they don't have a place that the user doesn't own, combined with that core is also used for system init because it's in the right place and you already want similar crypto you'd need for DRM for secure boot. There's not really any interesting IP in those cores from what we've seen.
    - wahern 7y ago
      But DRM only requires a secret key in the hardware. None of the implementing code needs to be secret, and indeed DRM that relies on opaque binary blobs or convoluted setup is useless. If the issue is why Intel, AMD, NXP, etc aren't more transparent with their references, DRM doesn't really explain any of that. The only reason that makes sense to me other than sheer neglect is fear of IP infringement claims, a fear that any developer contemplating releasing their source code has surely struggled with. The patent landscape is a fscking field of indiscriminate landmines. The "obviousness" test for patent eligibility is farcical. Just because the implementation of some driver seems obvious and straight-forward doesn't mean there doesn't exist a patent. Because of how technology develops--path dependency, foreseeable constraints--the vast majority of implementation details (including patented details) are obvious as understood by engineers, even if they've never encountered them before. But in practice obvious has effectively come to mean novel; were it any other way the vast majority of patents would never issue. And without omniscience you can never consistently know ahead of time whether something is novel or not; not if you're doing anything worthwhile. (Copyright is predicated on novelty, but copyright law permits independent development; patent law does not.) Patent claims usually turn on minute implementation details. (A result, no doubt, of the surfeit of patents. Were it otherwise patents would stop industry completely rather than slowly bleeding it.) I'm not a patent lawyer, but I know that in general (in the U.S.) any claim needs to make a prima facie showing, which over the past several decades SCOTUS has required provide increasingly direct evidence. In as much as you raise the costs of discovering the evidence necessary to make a prima facie case, you've reduced your exposure to lawsuits. If you're intent on targeting a particular company, and especially on targeting a particular company with a particular patent, opaque implementations are not much of a hurdle. But if you have a mountain of patents, the transactional costs of matching those patents to particular instances of [potential] infringement are quite significant. You not only need to expend effort to reverse engineer, but also effort to craft an argument to convince a court that your discoveries are legitimate. If an implementation is open it's much cheaper to accomplish both. Remember, labor is the single biggest expense in the Western world, and these types of activities are the epitome of labor intensive tasks. Reverse engineering a binary blob may be easy conceptually, but its absolutely costly in terms of labor, especially when it comes to pinning down the details in a way that matches particular claims in a patent. The reverse is also true: if you have a mountain of products and components with significant exposure to infringement liability, opaqueness can substantially reduce your risk and effective liability. Even if exposure merely scales linearly with market or company size it suffices to explain the behavior of large companies, but I doubt it scales linearly. For one thing, larger companies are juicier targets, all else being equal, from the perspective of an individual claimant.
- bubblethink 7y ago
  They support it to the extent it is required to support due to contractual obligations for chromebooks or other vendors who may have similar deals with Intel. I doubt if Intel actually sees coreboot as something worthwhile outside of a shim to load FSP. To that end, they have also create a BSD licensed project called slimboot (more like shimboot) which exemplifies that approach better.

Neither intel nor AMD supports core boot. Community efforts to add core boot focus entirely on intel because of market share (although intel is also plenty hostile to floss in this regard).

bravo22 7y ago

Not sure about the support. Intel employees regularly submit to coreboot repo. I know at least for the Atom based designs that I've been involved in Intel provides reference designs using coreboot and supports it.

wahern 7y ago
AMD is a sponsor of coreboot according to https://www.coreboot.org/Sponsors https://www.coreboot.org/Sponsors Personally, I think the fundamental issue relates to IP. If the hardware design is made transparent by amazing and freely available documentation you invite infringement claims, particularly from IP trolls. (Threats from competitors are probably more existential, though, at least for large companies.) Often time companies will say that their products contain third-party IP that they cannot disclose, but that's just a roundabout way of saying neither the company nor its suppliers want the hassle. There are other reasons, too. For example, if you can't consistently provide such documentation it can make you look worse than if you had never bothered as it makes you appear unreliable. But I think the IP issue is what makes it a simple decision, notwithstanding whether the threats are actually substantial.
- monocasa 7y ago
  I think it's that DRM doesn't work if they don't have a place that the user doesn't own, combined with that core is also used for system init because it's in the right place and you already want similar crypto you'd need for DRM for secure boot. There's not really any interesting IP in those cores from what we've seen.
  - wahern 7y ago
    But DRM only requires a secret key in the hardware. None of the implementing code needs to be secret, and indeed DRM that relies on opaque binary blobs or convoluted setup is useless. If the issue is why Intel, AMD, NXP, etc aren't more transparent with their references, DRM doesn't really explain any of that. The only reason that makes sense to me other than sheer neglect is fear of IP infringement claims, a fear that any developer contemplating releasing their source code has surely struggled with. The patent landscape is a fscking field of indiscriminate landmines. The "obviousness" test for patent eligibility is farcical. Just because the implementation of some driver seems obvious and straight-forward doesn't mean there doesn't exist a patent. Because of how technology develops--path dependency, foreseeable constraints--the vast majority of implementation details (including patented details) are obvious as understood by engineers, even if they've never encountered them before. But in practice obvious has effectively come to mean novel; were it any other way the vast majority of patents would never issue. And without omniscience you can never consistently know ahead of time whether something is novel or not; not if you're doing anything worthwhile. (Copyright is predicated on novelty, but copyright law permits independent development; patent law does not.) Patent claims usually turn on minute implementation details. (A result, no doubt, of the surfeit of patents. Were it otherwise patents would stop industry completely rather than slowly bleeding it.) I'm not a patent lawyer, but I know that in general (in the U.S.) any claim needs to make a prima facie showing, which over the past several decades SCOTUS has required provide increasingly direct evidence. In as much as you raise the costs of discovering the evidence necessary to make a prima facie case, you've reduced your exposure to lawsuits. If you're intent on targeting a particular company, and especially on targeting a particular company with a particular patent, opaque implementations are not much of a hurdle. But if you have a mountain of patents, the transactional costs of matching those patents to particular instances of [potential] infringement are quite significant. You not only need to expend effort to reverse engineer, but also effort to craft an argument to convince a court that your discoveries are legitimate. If an implementation is open it's much cheaper to accomplish both. Remember, labor is the single biggest expense in the Western world, and these types of activities are the epitome of labor intensive tasks. Reverse engineering a binary blob may be easy conceptually, but its absolutely costly in terms of labor, especially when it comes to pinning down the details in a way that matches particular claims in a patent. The reverse is also true: if you have a mountain of products and components with significant exposure to infringement liability, opaqueness can substantially reduce your risk and effective liability. Even if exposure merely scales linearly with market or company size it suffices to explain the behavior of large companies, but I doubt it scales linearly. For one thing, larger companies are juicier targets, all else being equal, from the perspective of an individual claimant.
bubblethink 7y ago
They support it to the extent it is required to support due to contractual obligations for chromebooks or other vendors who may have similar deals with Intel. I doubt if Intel actually sees coreboot as something worthwhile outside of a shim to load FSP. To that end, they have also create a BSD licensed project called slimboot (more like shimboot) which exemplifies that approach better.