December 2017 - coreboot - mail.coreboot.org

G505s with Coreboot unable to run any version of Qubes
by Emil Novik Dec. 27, 2017

Dec. 27, 2017

Hey, I'm having some heavy trouble getting my laptop to run Qubes and I first thought I was having issues with the OS. But after digging into the logs I managed to get(crashes too early during boot to get any persistent logs, had to write most by hand) it feels more like an issue with my Coreboot built. So there are the details : - G505s with integrated HD 8650G + discrete R5 M230 graphics. - Coreboot 4.6-2477-g6ab3edac3c-dirty with processor microcode patch (change-ID: Ibbfee47ce1d5081640d6924e2b12f5213a7fcadb). - Runs Debian Stretch fine. - Fails to start Qubes 3.2 / 4.0 rc3 / Live 3.1. - I added the vgabios.rom for the integrated card with menuconfig and the one for the discrete card with cbfstool. - Coreboot.rom, .config and full make output as attachment. Some more error data I gathered from coreinfo's Bootlog : Failed to enable LTR for dev = PCI: 01:00.0 Failed to enable LTR for dev = PCI: 02:00.0 ... I2C: 01:50 missing read_resources I2C: 01:51 missing read_resources PNP: 00ff.1 missing read_resources ... Warning: Can't write PCI_INTR 0xC00/0xC01 registers because 'mainboard_picr_data' or 'mainboard_intr_data' tables are NULL Warning: Can't write PCI IRQ assignments because 'mainboard_pirq_data' structure does not exist ... ASSERTION ERROR: file 'src/vendorcode/amd/agesa/f15tn/Proc/Common/CommonReturns.c', line 187 ASSERTION ERROR: file 'src/vendorcode/amd/agesa/f15tn/Proc/CPU/cpuGeneralServices.c', line 776 ASSERTION ERROR: file 'src/vendorcode/amd/agesa/f15tn/Proc/Common/CommonReturns.c', line 187 ASSERTION ERROR: file 'src/vendorcode/amd/agesa/f15tn/Proc/CPU/cpuGeneralServices.c', line 776 ASSERTION ERROR: file 'src/vendorcode/amd/agesa/f15tn/Proc/Common/CommonReturns.c', line 187 ASSERTION ERROR: file 'src/vendorcode/amd/agesa/f15tn/Proc/CPU/cpuGeneralServices.c', line 776 ASSERTION ERROR: file 'src/vendorcode/amd/agesa/f15tn/Proc/Common/CommonReturns.c', line 187 ASSERTION ERROR: file 'src/vendorcode/amd/agesa/f15tn/Proc/CPU/cpuGeneralServices.c', line 776 ASSERTION ERROR: file 'src/vendorcode/amd/agesa/f15tn/Proc/Common/CommonReturns.c', line 187 ASSERTION ERROR: file 'src/vendorcode/amd/agesa/f15tn/Proc/CPU/cpuGeneralServices.c', line 776 ASSERTION ERROR: file 'src/vendorcode/amd/agesa/f15tn/Proc/Common/CommonReturns.c', line 187 ASSERTION ERROR: file 'src/vendorcode/amd/agesa/f15tn/Proc/CPU/cpuGeneralServices.c', line 776 ASSERTION ERROR: file 'src/vendorcode/amd/agesa/f15tn/Proc/Common/CommonReturns.c', line 187 ASSERTION ERROR: file 'src/vendorcode/amd/agesa/f15tn/Proc/CPU/cpuGeneralServices.c', line 776 ASSERTION ERROR: file 'src/vendorcode/amd/agesa/f15tn/Proc/Common/CommonReturns.c', line 187 ASSERTION ERROR: file 'src/vendorcode/amd/agesa/f15tn/Proc/CPU/cpuGeneralServices.c', line 776 ASSERTION ERROR: file 'src/vendorcode/amd/agesa/f15tn/Proc/Common/CommonReturns.c', line 187 ASSERTION ERROR: file 'src/vendorcode/amd/agesa/f15tn/Proc/CPU/cpuGeneralServices.c', line 776 ... Manufacturer: ef SF: Detected W25Q32 with sector size 0x1000, total 0x400000 ASSERTION ERROR: file 'src/drivers/spi/spi_flash.c', line 425 ASSERTION ERROR: file 'src/drivers/spi/spi_flash.c', line 425 ASSERTION ERROR: file 'src/drivers/spi/spi_flash.c', line 425 ASSERTION ERROR: file 'src/drivers/spi/spi_flash.c', line 425 Manufacturer: ef SF: Detected W25Q32 with sector size 0x1000, total 0x400000 ASSERTION ERROR: file 'src/drivers/spi/spi_flash.c', line 425 ASSERTION ERROR: file 'src/drivers/spi/spi_flash.c', line 425 ASSERTION ERROR: file 'src/drivers/spi/spi_flash.c', line 425 ASSERTION ERROR: file 'src/drivers/spi/spi_flash.c', line 425 ASSERTION ERROR: file 'src/drivers/amd/agesa/state_machine.c', line 309 ... EEPROM not found EEPROM not found EEPROM not found EEPROM not found EEPROM not found EEPROM not found EEPROM not found ... I2C: 01:50 (unknown) I2C: 01:51 (unknown) ... APIC: 11 (unknown) APIC: 12 (unknown) APIC: 13 (unknown) PCI: 01:00.0 (unknown) PCI: 02:00.0 (unknown) PNP: 00ff.0 (unknown) "..." are parts I didn't write down as they didn't show any obvious errors(but I'm bad at seeing them) and it would take me a loooong time to write down the full log as I can't export it as far as I know, if you need any more information from it, I can write down any part missing. Output of "cbfstool coreboot.rom print" after I added the optionrom for the R5 M230 discrete graphic card : Name Offset Type Size Comp cbfs master header 0x0 cbfs header 32 none fallback/ramstage 0x80 stage 129247 none config 0x1f9c0 raw 263 none revision 0x1fb00 raw 582 none payload_revision 0x1fd80 raw 239 none apu/amdfw 0x1fec0 raw 131072 none fallback/romstage 0x3ff00 stage 320556 none cmos_layout.bin 0x8e3c0 cmos_layout 1164 none pci1002,990b.rom 0x8e8c0 optionrom 61952 none fallback/postcar 0x9db40 stage 13268 none fallback/dsdt.aml 0xa0f80 raw 9435 none img/coreinfo 0xa34c0 payload 102712 none img/nvramcui 0xbc640 payload 141628 none fallback/payload 0xdefc0 payload 67370 none payload_config 0xef740 raw 1611 none pci1002,6665.rom 0xefe00 optionrom 32768 none (empty) 0xf7e80 null 3112984 none s3nv 0x3efec0 raw 32768 none (empty) 0x3f7f00 null 31192 none bootblock 0x3ff900 bootblock 1424 none What happened when I tried to boot each version of Qubes : Live 3.1 : mce: Unable to init device /dev/mcelog (rc: -16) radeon 000:04:00:0: Invalid ROM contents radeon 000:04:00:0: Invalid ROM contents [drm:radeon_get_bios] *ERROR* Unable to locate a BIOS ROM radeon 000:04:00:0: Fatal error during GPU init [TTM] Memory type 3 has not been initialized SQUASHFS error: squashfs_read_data failed to read block 0x5cb75d68 SQUASHFS error: Unable to read data cache entry [0x5cb75d68] SQUASHFS error: Unable to read page, block 0x5cb75d68, size af0 SQUASHFS error: Unable to read data cache entry [0x5cb75d68] SQUASHFS error: Unable to read page, block 0x5cb75d68, size af0 EXT4-fs error (device dm-0): ext4_find_entry:1289: inode #41642: comm plymouthd: reading directory lblock 0 (Hangs at the Qubes graphical loading screen, with loading bar full.) 3.2 (Install looked fine) : Hangs at "Booting from Hard Disk..." in SeaBIOS on every try 4.0 rc3 : [ FAILED ] Failed to start Load Kernel Modules. ... [ OK ] Reached target Basic System. (Hangs for about 10secs, followed by 5s of black screen) BUG: Unable to handle NULL pointer dereference at (null) (followed by a lot of output likely concerning the error and quickly back to boot) Sadly too much output and disappearing too fast for me to get anything out of it if all I can do is read and type to export it. Tried Ctrl+S/Ctrl+Q to "pause" it but nope, also checked that the laptop should not reboot in case of kernel panic but it still does... Thanks to anyone that could help me find what's wrong and how to fix it :) --- Emil Novik

1 0

Public Notepad for coreboot 4.7 release
by Ivan Ivanov Dec. 27, 2017

Dec. 27, 2017

Hi Paul, only now I noticed this public notepad for 4.7 coreboot release notes: [1] https://pads.ccc.de/s7c2eXetAu Last revision - 8 days ago, hope more people will notice this notepad now. I will be contributing to it Best regards, Ivan 2017-12-21 11:23 GMT+03:00 Paul Menzel <paulepanter(a)users.sourceforge.net>: > Dear coreboot folks, > > > Martin said, that the missing/unwritten release notes are the reason > holding up the coreboot 4.7 release. > > Could the maintainers, developers, and users please jump in and help > write them. Please use the pad [1]. Some coreboot folks already > contributed. Big thank you to them. > > Also, thanks to the now mostly great and elaborate commit messages, the > release notes should really just give a broad overview. The detail can > then be looked up. > > Additionally, can you think of the something that has to be adapted by > someone switching from coreboot 4.6 to coreboot 4.7? > > > Thanks, > > Paul > > > [1] https://pads.ccc.de/s7c2eXetAu > -- > coreboot mailing list: coreboot(a)coreboot.org > https://mail.coreboot.org/mailman/listinfo/coreboot<div id="DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2"><br /> <table style="border-top: 1px solid #D3D4DE;"> <tr> <td style="width: 55px; padding-top: 18px;"><a href="https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campai…" target="_blank"><img src="https://ipmcdn.avast.com/images/icons/icon-envelope-tick-round-orange-anima…" alt="" width="46" height="29" style="width: 46px; height: 29px;" /></a></td> <td style="width: 470px; padding-top: 17px; color: #41424e; font-size: 13px; font-family: Arial, Helvetica, sans-serif; line-height: 18px;">Без вирусов. <a href="https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campai…" target="_blank" style="color: #4453ea;">www.avast.ru</a> </td> </tr> </table> <a href="#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2" width="1" height="1"></a></div>

1 0

BDX-DE PCI init fail
by Hilbert Tu(杜睿哲_Pegatron) Dec. 27, 2017

Dec. 27, 2017

Hi, I am porting coreboot on Intel BDX-DE platform and it gets stuck when init PCI 00:1f.3. This device should be SMBus, serial management bus. But I don’t know why this happened. Does anyone can give me some hint? Attached is my boot up log. Thanks in advance. -Hilbert This e-mail and its attachment may contain information that is confidential or privileged, and are solely for the use of the individual to whom this e-mail is addressed. If you are not the intended recipient or have received it accidentally, please immediately notify the sender by reply e-mail and destroy all copies of this email and its attachment. Please be advised that any unauthorized use, disclosure, distribution or copying of this email or its attachment is strictly prohibited. 本電子郵件及其附件可能含有機密或依法受特殊管制之資訊，僅供本電子郵件之受文者使用。台端如非本電子郵件之受文者或誤收本電子郵件，請立即回覆郵件通知寄件人，並銷毀本電子郵件之所有複本及附件。任何未經授權而使用、揭露、散佈或複製本電子郵件或其附件之行為，皆嚴格禁止。

1 0

History question: which LLNL clusters used LinuxBIOS?
by Trammell Hudson Dec. 26, 2017

Dec. 26, 2017

Which of the LLNL clusters used LinuxBIOS? This page doesn't mention it: https://computing.llnl.gov/tutorials/linux_clusters/ Based on the LinuxNetworx slides, I know that MCR did and reached #3 on the top500. Did any of the others? -- Trammell

1 0

Re: [coreboot] How to properly conform with GPLv2 for Coreboot and SeaBIOS on an embedded system
by Ian Lewis Dec. 25, 2017

Dec. 25, 2017

Hello Peter, Thank you for your detailed reply. Of course, I understand that you cannot provide legal advice. But, for now, I need to understand the practicalities of how to comply, more than I need to understand the law of compliance. And, in any case, that will probably be someone else's problem if we reach that point. Since I wrote to this group, I found another page from SFLC https://www.softwarefreedom.org/resources/2014/SFLC-Guide_to_GPL_Compliance…. I know that Sam said that SFLC may have issues, but their write up still seems useful. On the issue of notice, I am referring to section 1. of the license. 1. You may copy and distribute verbatim copies of the Program's source code as you receive it, in any medium, provided that you conspicuously and appropriately publish on each copy an appropriate copyright notice and disclaimer of warranty; keep intact all the notices that refer to this License and to the absence of any warranty; and give any other recipients of the Program a copy of this License along with the Program. This seems to me to require some kind of clear notice to the recipient of their GPL rights. A microSD attached to our product may provide the necessary source and license agreements. But, it sure does not satisfy "conspicuously ", at least in my opinion. You say that it is not possible to absolve our customer from GPL responsibility. But, I had the impression that they would have met their obligations if we can keep the source with our product (that is, physically attached to it) and provide each recipient with the notice (as I called it - see above) somehow. Do you read this as incorrect? That is, even if we could get our notice in front of each recipient and our product always included the full license and source on microSD, that would not be good enough to cover the obligations of our distributor/customer? Thank you for the additional references. I will review them, though probably not until next week. Happy Holidays to you as well. Ian PS. I did not get a direct copy of your message. So, I constructed the history below by hand. Peter Stuge wrote: ------------------------ Hi Ian, Thank you for reaching out to the community with your very valid concerns! You are asking exactly the right questions. In the end, the community can't provide you with legal advice, but what we can do is help with pointers to successful uses of GPL code, and we can of course discuss personal understanding of the license text. I'm a developer, not legal counsel. :) Lewis, Ian (Microstar Laboratories) wrote: > We have never used GPL licensed code in our products before. And, I > am having a hard time seeing how we can do so and comply with GPLv2, > or GPLv3 for that matter. In the end it may be that you actually can't, if you have non-technical requirements which are incompatible with the GPL. But several companies have done it, so it is in no way impossible per se! > I have read this page > https://www.softwarefreedom.org/resources/2008/compliance-guide.html > several times, a number of other sites, as well as reading the GPLv2 > itself. Thanks for the link, I hadn't seen that, and I think it's a good commentary to read along the license text itself. > I do not want to impose a GPLv2 requirement on our customers if they use > our product. I want GPLv2 compliance to be fully our responsibility. The license applies to the software wherever the software ends up, whoever the distributors and recipients are. This is very different from a proprietary license, where conditions usually end with the first recipient, and usually amount to "do not ever distribute" or "you paid us once, so distribute as much as you like", or anything in between. Think about what the GPL strives to achieve. The conditions in the license want to ensure that every single recipient of the software has the same possibilities that you, the initial recipient, have. This in turn means that GPL compliance is per definition required from every single distributor, not only from you. > If we do have to impose a GPLv2 requirement on our customers to use a > Coreboot/SeaBIOS initialized platform, we probably cannot use such a > platform in any product, which would be quite unfortunate from my point > of view. That's your decision to make. It is certainly possible, many companies do so very successfully already, and I would argue that some of their success can actually be attributed to the very fact that they have decided to reuse (and perhaps contribute to!) existing GPL projects, at the very small compliance cost. > A large fraction of our customers are OEMs or VARs and they make > products of their own that use our products as a part. Unless they pull > the system apart, the end-use customer often does not even know one of > our products is part of the system they buy, though our licensing to our > customer (OEM) does require that the reseller maintain our copyright > notice in their system documentation or software copyright notice or > they do not have a right to distribute our software. The copyright for > the hardware is printed on the hardware itself, as is customary. The OEM > who uses our product configures our product before it ships to the > end-use customer, and they often build additional hardware of their own > as part of the system. The OEM (our customer) almost always includes a > PC and custom software of their own as part of the end-use system. The > end use customer may later re-sell their system to yet another end-use > customer or even pull our product out of the system and resell that > separately (on eBay, say). Cool. None of that is per se incompatible with the GPL, IMHO. > If I have understood correctly, all of these owners of our product must > have access to exactly the Coreboot/SeaBIOS source used to produce the > binary in the copy of our product they own. Yes, that is my understanding too. > Based on my understanding so far (highly limited), the only way that > looks like it might be possible to avoid propagating a GPLv2 requirement > to our customers - and thus making the compliance fully our responsibility No, absolving someone else of GPL requirements is simply not possible, unless you are the sole copyright holder and you use a dual-licensing scheme. (Enabling that is one purpose of copyright assignment.) Every single distributor of GPL code must comply with the license, as is the case with every other license. The conditions of the GPL mean that distributors do have to spend some effort on compliance. Instead, quite some NRE effort can be saved! In the case of coreboot, I think the monetary advantage to GPL is super obvious, but of course that doesn't help if you have strict requirements to not require your customers to understand and implement GPL compliance. So far that may sound quite scary, but: GPLv2 compliance is not really difficult, just different from engineering, but maybe more importantly it is very different from the adversarial compliance that lawyers have trained for decades to deal with. It's common for legal departments to need some time to climb the learning curve for free and open source. > - would be if we distribute a copy of the exact source > code used to build the module's Coreboot/SeaBIOS configuration as an > integral part of our product. This is one way to comply; the "Source Alongside Binary" option. > If there is any way to do it, we would actually rather not develop > the expertise to set up such a build, but I see no way around being > able to build our own version of the system image if we are to > comply with GPLv2. GPL requirements aside, being able to build yourself what you deliver to customers is never a bad thing. It takes some R&D yes, but nothing comparable to full R&D for an inhouse replacement, and in my experience quite many open source and free software projects are far simpler to use than proprietary products. > My understanding is that we have to know exactly how to build the > exact binary we distribute I don't think the GPL requires this explicitly, but I think you should do this regardless, if you distribute anything at all. Let's look at my layman understanding of the GPLv2 sections: 1. You may copy and distribute verbatim copies of the Program's source code as you receive it, in any medium, provided that you conspicuously and appropriately publish on each copy an appropriate copyright notice and disclaimer of warranty; keep intact all the notices that refer to this License and to the absence of any warranty; and give any other recipients of the Program a copy of this License along with the Program. This section gives you the freedom to distribute the source code, and sets out the conditions for compliance should you want or need to do so. 2. You may modify your copy or copies of the Program or any portion of it, thus forming a work based on the Program ... This section gives you the freedom to modify the code. It doesn't seem that you want to do so. Your case is a typical one where you would benefit the most from getting your shipped configuration included into the upstream repository, and as long as you take ownership of that configuration (in the end probably just a few files) then that is also very much welcomed and desired by the project! 3. You may copy and distribute the Program (or a work based on it, under Section 2) in object code or executable form under the terms of Sections 1 and 2 above provided that you also do one of the following: So this is an important section, becase you want to distribute object code. Let's look at a) and b). (c) we'll ignore, because it's only for noncommercial distribution. a) Accompany it with the complete corresponding machine-readable source code, which must be distributed under the terms of Sections 1 and 2 above on a medium customarily used for software interchange; or, Something like the memory card you described could be used to achieve compliance with the above section. It is important to note, that every downstream distributor must also comply with the license. But you can make it easy for them. If all they need to do is ship that memory card along to their customers, then that's not a high cost for compliance, and on the flip side they of course save cost through your competitive pricing that was enabled by you reusing coreboot and SeaBIOS. b) Accompany it with a written offer, valid for at least three years, to give any third party, for a charge no more than your cost of physically performing source distribution, a complete machine-readable copy of the corresponding source code, to be distributed under the terms of Sections 1 and 2 above on a medium customarily used for software interchange; or, Because paper costs less than storage medium this mini-book or booklet method is used by many consumer electronics vendors. I've personally received such a "compliance booklet" from Philips with a TV set, from Samsung with a TV set and with a phone, and from several wireless router vendors. Personally I am less fond of this method. Yes, the cost at time of shipment is less per unit, but on the other hand you must set up a process to fulfill the offer, and you must keep it running for a minimum of three years after your distribute the very last unit! This is fairly risky; because this process will not be exercised very frequently it is also much more prone to fail, and fail silently, and then you are suddenly no longer compliant without being aware, so if a request then comes in but the offer is not fulfilled then the (usually simple) operational issue immediately becomes a legal liability. Most importantly, if the process breaks you are unable to satisfy your customer's request for the source code. > and we have to be able to tell a technically competent recipient of > the binary how to do that build themselves, as well as how to > incorporate the new build into our product. Neither of those are in GPLv2, but indeed in GPLv3. Certainly the GPLv3 has more requirements, and that may be a reason to use coreboot, but not SeaBIOS. Other bootloaders exist, such as FILO. Since you are booting your own OS anyway, that may even be preferable over hanging on to obsolete BIOS services and data structures. > We do not have to support any changes whatsoever, but we do have to > support the initial process of re-configuring our product with a > newly built binary that came from the sources we supply as long as > there are no changes made to those sources. For GPLv3, yes. > One idea I had is to put the source on a microSD drive .. > So, an owner of our product (and so a recipient of > the binary distribution of Coreboot/SeaBIOS) would have the code on the > microSD, but we have no easy way to provide them access to its content. > But, they could remove the microSD from the product and read it from any > machine that can read a microSD. That means almost any machine. It could be argued that a memory card qualifies as "a medium customarily used for software interchange". > That seems to me like it might cover the source distribution requirement > of GPLv2, though I am not quite certain it is good enough. I think it is one feasible way for *you* to comply. But as part of your product, maybe in some documentation or training, you should probably also make sure that your customers understand why they must *also* ensure that *they* comply, and that part of the value of your particular product is that you have already prepared this medium to assist them with that. For GPLv2 I think the rest is a matter of documentation that they supply with their products. (Like a booklet.) > However, so far, it looks impossible to me to meet the GPLv2 > notification requirements. Sorry, what are you refering to here? Neither "notification", "Notification", "notify" nor "Notify" appears in my copy of the GPLv2 license text. > And, I do not understand at all how the likes of network routers > that use GPL licensed code can possibly comply either. Many ship a compliance booklet which refers to a distribution service where recipients of a binary copy can obtain the source code in compliance with the license requirements. Once set up, and firmly established within a company, that is probably by far the most cost-effective. It's a longer commitment than shipping a physical storage medium - that's a one-time thing for you. GPLv3 is explicit about who can operate network servers, but: "Regardless of what server hosts the Corresponding Source, you remain obligated to ensure that it is available for as long as needed to satisfy these requirements." > I can imagine fitting a URL, such as www.mstarlabs.com/GPL (not a real > URL) on to the product to point any owner of the product to an > explanation of where to find the license text and source for > Coreboot/SeaBIOS. The microSD would have everything needed to > comply on it, but I do not think that comes close to meeting the > notice requirements of GPL. Maybe you refer to the 3b) "written offer" option for Section 3 of GPLv2? Whether a mere URL constitues "a written offer ..." I don't know. Personally I find that a very weak offer. A booklet or even a single sheet of peper is significantly more obvious. Note that Section 3 requires only "one of the following" options, not all. > Do you have any written guidelines that explain how to properly - > and legally - distribute a commercial hardware product that incorporates > Coreboot/SeaBIOS? In particular, how can we meet the notification > requirements when the user never even physically handles the product, > sees any output from the device, or installs any software on it? I am > having a hard time figuring out how to do this, if it is possible at > all. I personally find GPLv2 Section 3a) and 3b) to be pretty clear and comprehensible. 3a) says accompanying object code with complete corresponding machine-readable source code on a medium. 3b) says accompanying object code with a written offer. Note that however source code is distributed, Sections 1 and 2 must also be complied with. > If this is the wrong forum for this kind of question, I apologies. And, > I would appreciate if someone could point me to an appropriate forum. I think SFLC is a good point of contact, and FSF Europe also have a strong focus on applied use of free software code. http://fsfe.org/activities/ftf/documentation.en.html http://fsfe.org/activities/ftf/services.html http://gpl-violations.org/faq/vendor-faq/ And if you are interested to connect your legal counsel with experts on the field of free software licensing, then this may be relevant: http://fsfe.org/activities/ftf/ln.en.html Hope this helps, and happy holidays to everyone! :) //Peter

2 2

Re: [coreboot] How to properly conform with GPLv2 for Coreboot and SeaBIOS on an embedded system
by Ian Lewis Dec. 24, 2017

Dec. 24, 2017

Hello Sam, Thank you for the information on the SFC. I had not yet found their materials. I will look at them, though probably not until next week. Ian -----Original Message----- From: Sam Kuper Sent: Sunday, December 24, 2017 10:06 AM To: Lewis, Ian (Microstar Laboratories) Cc: coreboot(a)coreboot.org ; Peter Stuge Subject: Re: [coreboot] How to properly conform with GPLv2 for Coreboot and SeaBIOS on an embedded system Hi Ian, On 24/12/2017, Lewis, Ian (Microstar Laboratories) <ilewis(a)mstarlabs.com> wrote: > I have read this page > https://www.softwarefreedom.org/resources/2008/compliance-guide.html > several times, a number of other sites, as well as reading the GPLv2 > itself. I want to echo Peter Stuge on these points... On 24/12/2017, Peter Stuge <peter(a)stuge.se> wrote: > Thank you for reaching out to the community with your very valid concerns! > > You are asking exactly the right questions. > > In the end, the community can't provide you with legal advice .. and to add a caveat to these points from Peter: >> If this is the wrong forum for this kind of question, I apologies. And, >> I would appreciate if someone could point me to an appropriate forum. > > I think SFLC is a good point of contact, and FSF Europe also have a > strong focus on applied use of free software code. > > http://fsfe.org/activities/ftf/documentation.en.html > http://fsfe.org/activities/ftf/services.html > http://gpl-violations.org/faq/vendor-faq/ > > And if you are interested to connect your legal counsel with experts on > the field of free software licensing, then this may be relevant: > > http://fsfe.org/activities/ftf/ln.en.html The caveat is that this is all good advice *except* that instead of contacting the SFLC (i.e. the Software Freedom Law Centre, run by Eben Moglen et al), it might be better for you to contact the SFC (the Software Freedom Conservancy, run by Bradley Kuhn, Karen Sandler, et al). In my opinion, the SFLC was still giving decent advice in 2008, which is when it published the post you linked to. But it has, sadly, behaved rather confusingly of late. By contrast, the SFC has always, as far as I know, taken a reasonable and consistent stance in its work. For more about the SFLC's recent, unfortunate behaviour, see: - https://mjg59.dreamwidth.org/49370.html - http://www.rants.org/2017/11/conservancy_sflc_dispute/ - https://lwn.net/Articles/738046/ Wishing you a successful and GPL-compliant product! Sam

1 0

Re: [coreboot] How to properly conform with GPLv2 for Coreboot and SeaBIOS on an embedded system
by Ian Lewis Dec. 24, 2017

Dec. 24, 2017

Thank you for your rapid reply, Ivan. We certainly can, and probably will, ship a mini-book with our product. But, as you say, that is likely to get lost long before the end user has the system, let alone any reselling of the product by the end-user. Your ideas about displaying the booklet and notice about where to find the source at boot time are interesting. Unfortunately, we have no access to a screen of any type at boot time. Our product - a measurement system with built-in processing, largely used for control or signal processing - has no user I/O. It communicates with another computer (usually a PC) over a communication link that is - at root - either PCI, PCIe, or USB (2 or 3). Our PC-side driver can get to the Windows Event log, but it cannot interact directly with the user (well, actually, it could, but our customers would not appreciate that). Still, if we ever do use Coreboot on a device that has a screen these seem like useful approaches to presenting the GPL license and information on where to find the source code. Best Regards, Ian Lewis www.mstarlabs.com -----Original Message----- From: Ivan Ivanov Sent: Sunday, December 24, 2017 5:11 AM To: Lewis, Ian (Microstar Laboratories) ; coreboot(a)coreboot.org Subject: Re: [coreboot] How to properly conform with GPLv2 for Coreboot and SeaBIOS on an embedded system Good day, Ian! Perhaps it is a good idea to look what another responsible company did at the same situation The TP-Link company is using the GPLv2-licensed source code for the firmware of their routers, and they include a small paper printed mini-book ---> which contains two major things: 1) the complete text of GNU GPLv2 license 2) an explanation that the complete firmware source code could be obtained from TP-Link website: http://www.tp-link.com/us/support/gpl-code-center But it seems that in your situation you could not include such a mini-book, because it could be lost before it reaches the eventual user of your device and also - these are additional expenses to print such mini-books However there are two excellent alternative solutions : 1ST SOLUTION : 1) Modify the SeaBIOS source code, so that - while booting - it will print a two-line message at the bottom of screen, something like "The source code of this BIOS is GNU GPLv2 licensed, for more info - press "ESC" and then a letter corresponding to "FreeDOS with GNU GPLv2 texts" boot entry 2) Download a FreeDOS floppy, remove an installer from it (not needed!) and add two text files to this image: *) your "mini-book" in txt format with GNU GPLv2 license text and a link to your sources *) similar "mini-book" but for FreeDOS - with a license for FreeDOS and a link to its sources 3) Add this virtual floppy to the completed coreboot+SeaBIOS build while using the LZMA compression using a simple command like this: ./coreboot/build/cbfstool ./coreboot/build/coreboot.rom add -f ./FreeDOS.img -n floppyimg/FreeDOS_with_GNU_GPLv2_texts.lzma -t raw -c lzma and then it will be shown as "FreeDOS with GNU GPLv2 texts" boot entry at SeaBIOS boot menu. Good thing is that even if the user makes some edits to license using a text editor - these changes will be temporary and will disappear after a user reboots your device When LZMA compression is used, FreeDOS floppy takes about 714 KB - twice less than its original 1440 KB size However, if thats still too large for you, instead of FreeDOS you could use any other floppy based OS which meets these two requirements: *) Contains a text editor / text displayer as the means to show the license texts to the user. *) That OS is licensed by GNU GPLv2 or less restrictive license So, if you don't like FreeDOS you could use something like MikeOS: *) this floppy MikeOS is licensed by BSD-like license *) it compresses significantly better than FreeDOS: to just 54 KB, and even better if you remove some games/demos from it 2ND SOLUTION: Similar to 1ST, but - instead of using a floppy based OS - you could directly modify the SeaBIOS source code to include a fake boot entry - which, when selected, instead of booting any device will start showing your mini-book page by page and its possible to scroll pages or move back/forward between them I wrote a patch to SeaBIOS which sadly didn't got accepted, you could obtain it here: https://mail.coreboot.org/pipermail/seabios/2017-June/011416.html [SeaBIOS] [PATCH] boot: boot menu up to 35 devices with letters and possible pages Without this patch the SeaBIOS supports just 9 or 10 boot entries, but with this patch - 35 boot entries, and its possible to switch the pages between the first 18 entries and last 17 entries You can borrow this paging code and modify it to display the pages of your mini-book with license texts and explanation that sources are easily available from your website Actually it would be much better if you will be able to contribute the sources for your device to the official coreboot repositories: 1) it will be more convenient both for you and your users to have the latest coreboot updates 2) other coreboot users will clearly see that your device is supported and would want to get it Please ask if any questions, we could come up with a lot of good ideas of how it could be done. Also it will be great to learn about your product once its released, maybe some of coreboot developers would want to get your device - and this could probably give some additional support from community Best regards, Ivan Ivanov<div id="DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2"><br /> <table style="border-top: 1px solid #D3D4DE;"> <tr> <td style="width: 55px; padding-top: 18px;"><a href="https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campai…" target="_blank"><img src="https://ipmcdn.avast.com/images/icons/icon-envelope-tick-round-orange-anima…" alt="" width="46" height="29" style="width: 46px; height: 29px;" /></a></td> <td style="width: 470px; padding-top: 17px; color: #41424e; font-size: 13px; font-family: Arial, Helvetica, sans-serif; line-height: 18px;">Без вирусов. <a href="https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campai…" target="_blank" style="color: #4453ea;">www.avast.ru</a> </td> </tr> </table> <a href="#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2" width="1" height="1"></a></div> 2017-12-24 9:46 GMT+03:00 Lewis, Ian (Microstar Laboratories) <ilewis(a)mstarlabs.com>: > I am looking at using a processor module that initializes using Coreboot and > SeaBIOS to make an embedded hardware product. Assuming we move forward, > Coreboot/SeaBIOS will load our (proprietary) OS. Our OS contains no GPL > licensed code. > > > > We have never used GPL licensed code in our products before. And, I am > having a hard time seeing how we can do so and comply with GPLv2, or GPLv3 > for that matter. > > > > I have read this page > https://www.softwarefreedom.org/resources/2008/compliance-guide.html several > times, a number of other sites, as well as reading the GPLv2 itself. > > > > I do not want to impose a GPLv2 requirement on our customers if they use our > product. I want GPLv2 compliance to be fully our responsibility. If we do > have to impose a GPLv2 requirement on our customers to use a > Coreboot/SeaBIOS initialized platform, we probably cannot use such a > platform in any product, which would be quite unfortunate from my point of > view. > > > > A large fraction of our customers are OEMs or VARs and they make products of > their own that use our products as a part. Unless they pull the system > apart, the end-use customer often does not even know one of our products is > part of the system they buy, though our licensing to our customer (OEM) does > require that the reseller maintain our copyright notice in their system > documentation or software copyright notice or they do not have a right to > distribute our software. The copyright for the hardware is printed on the > hardware itself, as is customary. The OEM who uses our product configures > our product before it ships to the end-use customer, and they often build > additional hardware of their own as part of the system. The OEM (our > customer) almost always includes a PC and custom software of their own as > part of the end-use system. The end use customer may later re-sell their > system to yet another end-use customer or even pull our product out of the > system and resell that separately (on eBay, say). > > > > If I have understood correctly, all of these owners of our product must have > access to exactly the Coreboot/SeaBIOS source used to produce the binary in > the copy of our product they own. > > > > Based on my understanding so far (highly limited), the only way that looks > like it might be possible to avoid propagating a GPLv2 requirement to our > customers – and thus making the compliance fully our responsibility - would > be if we distribute a copy of the exact source code used to build the > module’s Coreboot/SeaBIOS configuration as an integral part of our product. > If there is any way to do it, we would actually rather not develop the > expertise to set up such a build, but I see no way around being able to > build our own version of the system image if we are to comply with GPLv2. My > understanding is that we have to know exactly how to build the exact binary > we distribute and we have to be able to tell a technically competent > recipient of the binary how to do that build themselves, as well as how to > incorporate the new build into our product. We do not have to support any > changes whatsoever, but we do have to support the initial process of > re-configuring our product with a newly built binary that came from the > sources we supply as long as there are no changes made to those sources. > > > > One idea I had is to put the source on a microSD drive and semi-permanently > attach that drive to the product. That way the Coreboot/SeaBIOS code would > go along for the ride any time our product changed hands (as long as no one > lost it). The microSD would not be part of our product. So, an owner of our > product (and so a recipient of the binary distribution of Coreboot/SeaBIOS) > would have the code on the microSD, but we have no easy way to provide them > access to its content. But, they could remove the microSD from the product > and read it from any machine that can read a microSD. That means almost any > machine. > > > > That seems to me like it might cover the source distribution requirement of > GPLv2, though I am not quite certain it is good enough. > > > > However, so far, it looks impossible to me to meet the GPLv2 notification > requirements. And, I do not understand at all how the likes of network > routers that use GPL licensed code can possibly comply either. > > > > I can imagine fitting a URL, such as www.mstarlabs.com/GPL (not a real URL) > on to the product to point any owner of the product to an explanation of > where to find the license text and source for Coreboot/SeaBIOS. The microSD > would have everything needed to comply on it, but I do not think that comes > close to meeting the notice requirements of GPL. > > > > Under Windows, where we sell the vast majority of our systems, we do have a > control panel application that every user could potentially get to. And, it > could include a screen that explains the owner’s GPL rights and where to > find the source microSD on the product. But, we have no means to force the > user to look at the control panel application, and most users would never > have any reason to do so. > > > > Do you have any written guidelines that explain how to properly – and > legally - distribute a commercial hardware product that incorporates > Coreboot/SeaBIOS? In particular, how can we meet the notification > requirements when the user never even physically handles the product, sees > any output from the device, or installs any software on it? I am having a > hard time figuring out how to do this, if it is possible at all. > > > > If this is the wrong forum for this kind of question, I apologies. And, I > would appreciate if someone could point me to an appropriate forum. > > > > Ian Lewis > > www.mstarlabs.com > > > -- > coreboot mailing list: coreboot(a)coreboot.org > https://mail.coreboot.org/mailman/listinfo/coreboot

1 0

Re: [coreboot] Re : Re: Coreboot Purism BIOS is free? open?
by echelon＠free.fr Dec. 24, 2017

Dec. 24, 2017

This is incredible!!!!! When I bought my PC, I bought my PC, NOT a service!!.. W!T!F! (sorry for being rude...) ----- Mail d'origine ----- De: Alberto Bursi <alberto.bursi(a)outlook.it> À: echelon(a)free.fr Cc: coreboot(a)coreboot.org Envoyé: Mon, 25 Dec 2017 00:52:22 +0100 (CET) Objet: Re: Re : Re: [coreboot] Coreboot Purism BIOS is free? open? "TrustZone is only an operational mode of the CPU, not a whole computing subsystem like ME with its own CPU running its OS" Both do the same job, allowing a customer to run its applications in a "safe" environment. I don't know why Intel could not just do something similar to TrustZone, maybe Intel CPUs have too much legacy modes so trying to make another mode is too hard, or Intel went for the more secret and "safe" way it could do, as a dedicated processor is much more secret and "safer". "the physical and .. legal owner for me.." Many embedded devices are just tools to provide a service. You did not buy the hardware, you bought the service. Like for example the smartphones provided by mobile carriers. You bought a phone contract where the phone was included (for cheap), but the phone is not really yours. They keep pushing this mindset into PCs where it does not belong (yet), but in embedded it's very common. "If ARM SoCs can live without this kind of ... companion for the main CPU, what remains the argument of Intel to convince us of the fact the their CPUs cannot live without their beloved ME running side-by-side" Because they used their ME also for themselves, to keep their own proprietary components "safe". As I said, the ME is responsible of initialization and of running some advanced hardware features (like fan control or power management). It's called "eating their own dog food". https://en.wikipedia.org/wiki/Eating_your_own_dog_food They genuinely think ME is so great and safe that they are the first using it to hide their own secrets. -Alberto On 12/25/2017 12:07 AM, echelon(a)free.fr wrote: > Thank you Alberto for the answers, but I was not questioning the ME "per-se". > Anyway, if ME is required for platform initialization, why not stopping it after said "platform initialization"? > Also you said "ARM provides TrustZone, which is something like Intel ME". Permit me to disagree : TrustZone is only an operational mode of the CPU, not a whole computing subsystem like ME with its own CPU running its OS.. > Also as you said ARM ltd doesn't strongarm (pun unintented..) its customers to make ALWAYS Trustzone uncontrolable by the "end user" (the physical and .. legal owner for me..) > If ARM SoCs can live without this kind of ... companion for the main CPU, what remains the argument of Intel to convince us of the fact the their CPUs cannot live without their beloved ME running side-by-side (I know, I know, Intel doesn't have to speak to us miserable microbes, their real customers are more noble entities...) > > But anyway (and I will stop here with my trolls..), back to the main topic of this thread: > - Purism guys : I for one, I think that you are doing a really great job (my previous mail was a troll/sarcasm, take it with a tongue in cheek :-P) and I wish you great successes, but as other senders said in this thread, I think that we, the Libre community cannot put big hopes in the promises of entities like Intel or AMD anymore, and should actively explore alternatives to the x86 world (and encourage initiative like Talos..) > > That being said have a nice and happy Christmas! > Florentin Demetrescu > > ----- Mail d'origine ----- > De: Alberto Bursi <alberto.bursi(a)outlook.it> > À: coreboot(a)coreboot.org, echelon(a)free.fr > Envoyé: Sun, 24 Dec 2017 22:27:28 +0100 (CET) > Objet: Re: [coreboot] Coreboot Purism BIOS is free? open? > > Meh, Intel ME is necessary for x86 platform initalization. Without ME > the PC does not start at all. > > Anyway, the ME is used to provide third parties control and "security" > over the user's system by cutting out the middleman (board firmware). > Due to technical reasons they added all this functionality in a single > place, because it would be silly to have 3 different hardware backdoors > when you can just have one doing 3 different things. > > On consumer PCs it provides DRM, and on office PCs it provides limited > (but quite useful) remote management, plus more (it can execute a > customer's dedicated java applications on its own integrated JVM, for > example). > > For example I've seen some Dell PCs that had integrated some kind of > third party anti-theft functionality inside their UEFI firmware, where > you would license a third party software and then connect your PC's UEFI > firmware to their servers or something, so when it is stolen it can > still be tracked whenever it connects to the internet again. > Don't know if this feature is using the Intel ME, but it is an example > of feature the OEM might want to add to their products. > > Intel themselves also added random stuff to the ME (like advanced fan > speed control), just because they had a relatively powerful processor in > there, so why not add more features to it. see here > https://en.wikipedia.org/wiki/Intel_Management_Engine#Modules > > Does the industry ask for this? Maybe. What is sure is that Intel thinks > that this backdoor thingy offers features their customers want or might > find interesting to add features to their products. These features > should be the ones sought after by end users. > > And "Customers" in this case is companies designing PCs and embedded > systems with Intel products. Not people, end users. End users buy > motherboards or PCs from Intel's customers. > > Note that ARM provides TrustZone, which is something like Intel ME, but > is a generic feature, the OEM can do whatever it wants with it, even > disable and not use it at all. > AMD mindlessly followed Intel's footsteps by integrating ARM cores > running the TrustZone feature, and calling this Platform Security Processor. > > So it's not just Intel that thinks his customers might want more control > over the products they sell to the end user. Maybe they are all > misguided. Maybe not. > > Remember, it does not matter what is actually real, but what company > managers think is real. > > There is many people that still thinks that "secret" is "safe", and that > does not understand that software will have bugs, that it's only a > matter of time before it becomes vulnerable. > > For example, HDCP (HDMI cable antipiracy feature) is still in use even > if it was (and is) regularly busted by 30$ devices. Not even for > pirating, usually it is busted because it is causing compatibility > issues in devices. > > The people in charge of government agencies in the US know better, at > least. They asked for a ME feature to disable it in the hardware with > High Assurance Platform certification. > And due to Intel being cheap, this switch is available in all MEs after > version 11, Intel didn't make a custom ME only for the US government. > Currently it requires using external tools to edit the setting on the > motherboard's flash chip (or being an OEM), same as the older method of > nuking modules manually. > > > I hope I helped you understand the most likely reasons why ME exists. > > -Alberto > > On 12/24/2017 08:46 PM, echelon(a)free.fr wrote: >> By the way you said : "ODMs/OEMs are the real customers of Intel/AMD" and "Intel/AMD serve them law" (which law???) >> I have a scoop : a friend of mine happened to work in the marketing department of a (very large) OEM, and speaking about ME he told me that Intel OBLIGED them to adopt and integrate the ME! (in the beging the OEM guys were reluctant..) >> Of course this is only "street whispering" (and I will not force you to buy this..) but, but, as we say in Romanian "there is no smoke without fire..." ;-) >> Just my 2 satoshis.. >> Florentin >> >> ----- Mail d'origine ----- >> De: echelon(a)free.fr >> À: coreboot(a)coreboot.org >> Envoyé: Sun, 24 Dec 2017 20:31:53 +0100 (CET) >> Objet: Re : Re: [coreboot] Coreboot Purism BIOS is free? open? >> >> No you didn't answer my question Peter, sorry!.. >> I am NOT questioning the "legitimacy" of ME/PSP (be it from a purely corporate/financial point of view..). (By the way I have no "legitimacy" myself to put this question of "legitimacy" to begin with..) >> I simply don't understand (and this is why I pollute the coreboot ML with this blah-blah..) why ALL (I insist on capital letters _ALL_) the systems (consumer/office even .. industrial..) have to have this kind of .. "technology" activated ALL the time (at least from the Intel/AMD point of view)?? >> For me this is simply irrational!.. Period!.. >> (And for the fact that consumer devices outnumber office/industrial/governmental devices, I will belive you when I see REAL statistics, sorry!..) >> Florentin >> >> ----- Mail d'origine ----- >> De: Peter Stuge <peter(a)stuge.se> >> À: coreboot(a)coreboot.org >> Envoyé: Sun, 24 Dec 2017 18:29:48 +0100 (CET) >> Objet: Re: [coreboot] Coreboot Purism BIOS is free? open? >> >> echelon(a)free.fr wrote: >>> (can we anymore speak about "owner"?..) >> We can and we must, if we want to own anything at all. >> >> Don't get tricked into merely consuming services and products; >> take ownership and shape your reality. >> >> >> echelon(a)free.fr wrote: >>> But what has Netflix (or Sony, or the entertainment industry in >>> general...) to LEGALLY gain by strongarming Intel/AMD to keep >>> ME/PSP activated on all x86 platforms (not only consumer ones!..)? >> Philipp Stanner wrote: >>> I don't get it, too. ME has nothing to do with what you can do >>> with your machine and what it can perform. >>> >>> Even if 90% of users use their machine for multimedia purposes... >> Follow the money. What drives Intel sales? We can't know. Who are the >> strongest partners officially? That would be Microsoft (with Windows) >> and ODMs/OEMs. Intel serves them, by law. >> >> I guess that consumer devices significantly outnumber office devices. >> That's where the content industry comes into play. >> >> >> MSFT wants UEFI Secure Boot, so that OEMs are not required to deliver >> security. >> >> Content industry wants PAVP, so that hardware owners can not legally >> access unecrypted versions of the content. >> >> ME is Intel's answer to both those requirements and a few more, as >> described pretty clearly in the PSTR[1] book. >> >> And the DMCA and EUCD legal foundations align (un?)surprisingly well >> with the technical implementation details. >> >> >> //Peter >> >> [1] http://www.apress.com/9781430265719 >> >

1 0

Re : Re: Coreboot Purism BIOS is free? open?
by echelon＠free.fr Dec. 24, 2017

Dec. 24, 2017

Thank you Alberto for the answers, but I was not questioning the ME "per-se". Anyway, if ME is required for platform initialization, why not stopping it after said "platform initialization"? Also you said "ARM provides TrustZone, which is something like Intel ME". Permit me to disagree : TrustZone is only an operational mode of the CPU, not a whole computing subsystem like ME with its own CPU running its OS.. Also as you said ARM ltd doesn't strongarm (pun unintented..) its customers to make ALWAYS Trustzone uncontrolable by the "end user" (the physical and .. legal owner for me..) If ARM SoCs can live without this kind of ... companion for the main CPU, what remains the argument of Intel to convince us of the fact the their CPUs cannot live without their beloved ME running side-by-side (I know, I know, Intel doesn't have to speak to us miserable microbes, their real customers are more noble entities...) But anyway (and I will stop here with my trolls..), back to the main topic of this thread: - Purism guys : I for one, I think that you are doing a really great job (my previous mail was a troll/sarcasm, take it with a tongue in cheek :-P) and I wish you great successes, but as other senders said in this thread, I think that we, the Libre community cannot put big hopes in the promises of entities like Intel or AMD anymore, and should actively explore alternatives to the x86 world (and encourage initiative like Talos..) That being said have a nice and happy Christmas! Florentin Demetrescu ----- Mail d'origine ----- De: Alberto Bursi <alberto.bursi(a)outlook.it> À: coreboot(a)coreboot.org, echelon(a)free.fr Envoyé: Sun, 24 Dec 2017 22:27:28 +0100 (CET) Objet: Re: [coreboot] Coreboot Purism BIOS is free? open? Meh, Intel ME is necessary for x86 platform initalization. Without ME the PC does not start at all. Anyway, the ME is used to provide third parties control and "security" over the user's system by cutting out the middleman (board firmware). Due to technical reasons they added all this functionality in a single place, because it would be silly to have 3 different hardware backdoors when you can just have one doing 3 different things. On consumer PCs it provides DRM, and on office PCs it provides limited (but quite useful) remote management, plus more (it can execute a customer's dedicated java applications on its own integrated JVM, for example). For example I've seen some Dell PCs that had integrated some kind of third party anti-theft functionality inside their UEFI firmware, where you would license a third party software and then connect your PC's UEFI firmware to their servers or something, so when it is stolen it can still be tracked whenever it connects to the internet again. Don't know if this feature is using the Intel ME, but it is an example of feature the OEM might want to add to their products. Intel themselves also added random stuff to the ME (like advanced fan speed control), just because they had a relatively powerful processor in there, so why not add more features to it. see here https://en.wikipedia.org/wiki/Intel_Management_Engine#Modules Does the industry ask for this? Maybe. What is sure is that Intel thinks that this backdoor thingy offers features their customers want or might find interesting to add features to their products. These features should be the ones sought after by end users. And "Customers" in this case is companies designing PCs and embedded systems with Intel products. Not people, end users. End users buy motherboards or PCs from Intel's customers. Note that ARM provides TrustZone, which is something like Intel ME, but is a generic feature, the OEM can do whatever it wants with it, even disable and not use it at all. AMD mindlessly followed Intel's footsteps by integrating ARM cores running the TrustZone feature, and calling this Platform Security Processor. So it's not just Intel that thinks his customers might want more control over the products they sell to the end user. Maybe they are all misguided. Maybe not. Remember, it does not matter what is actually real, but what company managers think is real. There is many people that still thinks that "secret" is "safe", and that does not understand that software will have bugs, that it's only a matter of time before it becomes vulnerable. For example, HDCP (HDMI cable antipiracy feature) is still in use even if it was (and is) regularly busted by 30$ devices. Not even for pirating, usually it is busted because it is causing compatibility issues in devices. The people in charge of government agencies in the US know better, at least. They asked for a ME feature to disable it in the hardware with High Assurance Platform certification. And due to Intel being cheap, this switch is available in all MEs after version 11, Intel didn't make a custom ME only for the US government. Currently it requires using external tools to edit the setting on the motherboard's flash chip (or being an OEM), same as the older method of nuking modules manually. I hope I helped you understand the most likely reasons why ME exists. -Alberto On 12/24/2017 08:46 PM, echelon(a)free.fr wrote: > By the way you said : "ODMs/OEMs are the real customers of Intel/AMD" and "Intel/AMD serve them law" (which law???) > I have a scoop : a friend of mine happened to work in the marketing department of a (very large) OEM, and speaking about ME he told me that Intel OBLIGED them to adopt and integrate the ME! (in the beging the OEM guys were reluctant..) > Of course this is only "street whispering" (and I will not force you to buy this..) but, but, as we say in Romanian "there is no smoke without fire..." ;-) > Just my 2 satoshis.. > Florentin > > ----- Mail d'origine ----- > De: echelon(a)free.fr > À: coreboot(a)coreboot.org > Envoyé: Sun, 24 Dec 2017 20:31:53 +0100 (CET) > Objet: Re : Re: [coreboot] Coreboot Purism BIOS is free? open? > > No you didn't answer my question Peter, sorry!.. > I am NOT questioning the "legitimacy" of ME/PSP (be it from a purely corporate/financial point of view..). (By the way I have no "legitimacy" myself to put this question of "legitimacy" to begin with..) > I simply don't understand (and this is why I pollute the coreboot ML with this blah-blah..) why ALL (I insist on capital letters _ALL_) the systems (consumer/office even .. industrial..) have to have this kind of .. "technology" activated ALL the time (at least from the Intel/AMD point of view)?? > For me this is simply irrational!.. Period!.. > (And for the fact that consumer devices outnumber office/industrial/governmental devices, I will belive you when I see REAL statistics, sorry!..) > Florentin > > ----- Mail d'origine ----- > De: Peter Stuge <peter(a)stuge.se> > À: coreboot(a)coreboot.org > Envoyé: Sun, 24 Dec 2017 18:29:48 +0100 (CET) > Objet: Re: [coreboot] Coreboot Purism BIOS is free? open? > > echelon(a)free.fr wrote: >> (can we anymore speak about "owner"?..) > We can and we must, if we want to own anything at all. > > Don't get tricked into merely consuming services and products; > take ownership and shape your reality. > > > echelon(a)free.fr wrote: >> But what has Netflix (or Sony, or the entertainment industry in >> general...) to LEGALLY gain by strongarming Intel/AMD to keep >> ME/PSP activated on all x86 platforms (not only consumer ones!..)? > Philipp Stanner wrote: >> I don't get it, too. ME has nothing to do with what you can do >> with your machine and what it can perform. >> >> Even if 90% of users use their machine for multimedia purposes... > Follow the money. What drives Intel sales? We can't know. Who are the > strongest partners officially? That would be Microsoft (with Windows) > and ODMs/OEMs. Intel serves them, by law. > > I guess that consumer devices significantly outnumber office devices. > That's where the content industry comes into play. > > > MSFT wants UEFI Secure Boot, so that OEMs are not required to deliver > security. > > Content industry wants PAVP, so that hardware owners can not legally > access unecrypted versions of the content. > > ME is Intel's answer to both those requirements and a few more, as > described pretty clearly in the PSTR[1] book. > > And the DMCA and EUCD legal foundations align (un?)surprisingly well > with the technical implementation details. > > > //Peter > > [1] http://www.apress.com/9781430265719 >

2 1

Re: [coreboot] Coreboot Purism BIOS is free? open?
by Todd Weaver Dec. 24, 2017

Dec. 24, 2017

On Sun, 2017-12-24 at 01:30 -0500, Youness Alaoui wrote: > I think people buying a TALOS 2 and people buying a Librem are two > very distinct types of people. I very much doubt that someone has > ever had to decide between buying a Librem and a TALOS. I think this is correct as well. > > > > > A good summary is that we want to "bring > > > > > blob-free to the hardware that people want", rather than > > > > > "bring > > > > > blob-free hardware to the people who want it". > > This is great; and I may quote you on that :) > > Yeah, Todd, you can quote me. I also really liked that when I thought > of it :p Funny, it also helps define the different approaches succinctly. > And thanks for answering Nico's questions and correcting my > statements. I didn't even know an i.mx8 librem 13/15 had already been > thought of, that's pretty cool if it's in the plans! It is early yet, but on the Librem 5 hardware side (not coreboot related), it has been discussed as the follow-on to phone mobo design. Todd.

1 0