Re: [coreboot] Unable to build coreboot with Intel FSP debug binary on BayleyBay

[Aaron Durbin via coreboot]

On Fri, May 6, 2016 at 12:39 AM, Kathappan E
 wrote:
> Hi all,
>
>
>
> I am able to build Coreboot with FSP Baytrail release
> binary(BAYTRAIL_FSP_GOLD_004_22-MAY-2015.fd).
>
>
>
> But I am unable to build with FSP Baytrail debug binary
> (BAYTRAIL_FSP_GOLD_004_22-MAY-2015_DEBUG.fd) and it throws the below error
> says that binary size is large and fails to add into image.
>
>
>
> The sections containing CBFSes are: COREBOOT
>
> Performing operation on 'COREBOOT' region...
>
> Created CBFS (capacity = 2096856 bytes)
>
> Performing operation on 'COREBOOT' region...
>
> Performing operation on 'COREBOOT' region...
>
> CBFS   fsp.bin
>
> Performing operation on 'COREBOOT' region...
>
> E: Not enough space for content.
>
> E: Could not add [fsp, 294912 bytes (288 KB)@0x1bff00]; too big?
>
> E: Failed to add '../intel/fsp/baytrail/BAYTRAIL_FSP_D.fd' into ROM image.
>
> E: Failed while operating on 'COREBOOT' region!
>
> E: The image will be left unmodified.
>
> make: *** [build/coreboot.pre] Error 1
>
>
>
> Can you please anyone help me on this?
>

You likely need to adjust the FSP_LOC kconfig variable to match the
debug FSP binary. Most likely the debug binary is large and not linked
at the same address which in this case breaks building because there's
not enough flash space.

>
>
> Thanks in advance,
>
> Kathappan
>
> L Technology Services Ltd
>
> www.LntTechservices.com
>
> This Email may contain confidential or privileged information for the
> intended recipient (s). If you are not the intended recipient, please do not
> use or disseminate the information, notify the sender and delete it from
> your system.
>
>
> --
> coreboot mailing list: coreboot@coreboot.org
> https://www.coreboot.org/mailman/listinfo/coreboot

-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

[coreboot] New Defects reported by Coverity Scan for coreboot

[scan-admin]

Hi,

Please find the latest report on new defect(s) introduced to coreboot found 
with Coverity Scan.

148 new defect(s) introduced to coreboot found with Coverity Scan.
92 defect(s), reported by Coverity Scan earlier, were marked fixed in the 
recent build analyzed by Coverity Scan.

New defect(s) Reported-by: Coverity Scan
Showing 20 of 148 defect(s)


** CID 1355008:  Code maintainability issues  (UNUSED_VALUE)
/src/mainboard/siemens/mc_tcu3/lcd_panel.c: 69 in setup_lcd_panel()



*** CID 1355008:  Code maintainability issues  (UNUSED_VALUE)
/src/mainboard/siemens/mc_tcu3/lcd_panel.c: 69 in setup_lcd_panel()
63  break;
64  case LCD_PANEL_TYPE_EDID:
65  strcpy(blockname, "hwinfo.hex");
66  break;
67  default:
68  printk(BIOS_ERR, "LCD: No supported panel found.\n");
>>> CID 1355008:  Code maintainability issues  (UNUSED_VALUE)
>>> Assigning value "1" to "status" here, but that stored value is 
>>> overwritten before it can be used.
69  status = 1;
70  break;
71  }
72  /* Now that we have the panel type, setup the DP2LVDS converter */
73  status = ptn3460_init(blockname);
74  if (status)

** CID 1354970:  Memory - corruptions  (ARRAY_VS_SINGLETON)
/src/lib/selfboot.c: 239 in build_self_segment_list()



*** CID 1354970:  Memory - corruptions  (ARRAY_VS_SINGLETON)
/src/lib/selfboot.c: 239 in build_self_segment_list()
233 
234 memset(head, 0, sizeof(*head));
235 head->next = head->prev = head;
236 
237 first_segment = _payload->segments;
238 
>>> CID 1354970:  Memory - corruptions  (ARRAY_VS_SINGLETON)
>>> Using "current_segment" as an array.  This might corrupt or 
>>> misinterpret adjacent memory locations.
239 for (current_segment = first_segment;; ++current_segment) {
240 printk(BIOS_DEBUG,
241 "Loading segment from rom address 0x%p\n",
242 current_segment);
243 
244 cbfs_decode_payload_segment(, current_segment);

** CID 1354852:  Memory - corruptions  (OVERRUN)
/3rdparty/chromeec/common/thermal.c: 265 in thermal_control()



*** CID 1354852:  Memory - corruptions  (OVERRUN)
/3rdparty/chromeec/common/thermal.c: 265 in thermal_control()
259 #ifdef CONFIG_FANS
260 /* TODO(crosbug.com/p/23797): For now, we just treat all fans 
the
261  * same. It would be better if we could assign different thermal
262  * profiles to each fan - in case one fan cools the CPU while 
another
263  * cools the radios or battery.
264  */
>>> CID 1354852:  Memory - corruptions  (OVERRUN)
>>> Checking "i < 2" implies that "i" may be up to 1 on the true branch.
265 for (i = 0; i < CONFIG_FANS; i++)
266 fan_set_percent_needed(i, fmax);
267 #endif
268 }
269 
270 /* Don't forget to signal any DPTF thresholds */

** CID 1354849:  Insecure data handling  (INTEGER_OVERFLOW)
/src/arch/x86/tables.c: 85 in write_mptable()



*** CID 1354849:  Insecure data handling  (INTEGER_OVERFLOW)
/src/arch/x86/tables.c: 85 in write_mptable()
79  }
80 
81  printk(BIOS_DEBUG, "MP table: %ld bytes.\n",
82  new_high_table_pointer - high_table_pointer);
83  }
84 
>>> CID 1354849:  Insecure data handling  (INTEGER_OVERFLOW)
>>> Overflowed or truncated value (or a value computed from an overflowed 
>>> or truncated value) "rom_table_end" used as return value.
85  return rom_table_end;
86 }
87 
88 static unsigned long write_acpi_table(unsigned long rom_table_end)
89 {
90  unsigned long high_table_pointer;

** CID 1354778:  Uninitialized variables  (UNINIT)
/src/soc/intel/fsp_broadwell_de/uart.c: 104 in uart_fill_lb()



*** CID 1354778:  Uninitialized variables  (UNINIT)
/src/soc/intel/fsp_broadwell_de/uart.c: 104 in uart_fill_lb()
98  uart8250_tx_flush(uart_platform_base(idx));
99 }
100 
101 #if ENV_RAMSTAGE
102 void uart_fill_lb(void *data)
103 {
>>> CID 1354778:  Uninitialized variables  (UNINIT)
>>> Declaring variable "serial" without initializer.
104 struct lb_serial serial;
105 serial.type = LB_SERIAL_TYPE_IO_MAPPED;
106 serial.baseaddr = 

Re: [coreboot] How to protect binary in flash chip? OTP?

[Carl-Daniel Hailfinger]

On 06.05.2016 09:49, Patrick Rudolph wrote:
> On 2016-05-06 02:45 AM, Zheng Bao wrote:
>> Is there any way to protect the binary image in flash chip from being
>> copied? Once the customers
>> gets the image, they can produce millions of board and do not tell me.
>> I just want to know the
>> amount of the mass production.
>> [...]
> 
> As you want to execute code from it, it needs to be readable.
> Protecting it from software doesn't make much sense as you could just
> de-solder the flash chip.
> 
> I guess what you want to know is: Should a copied image boot on another
> board ?
> 
> I've got two solutions:
> 1.
> You could encrypt the binary and store the secret in a TPM.
> That way every board would have the same encryption key.
> No idea if this is possible on your platform and how much work it would
> be to implement in coreboot.
> That'd be a good GSoC project :-)
> 
> 2.
> If you don't have a TPM you could use serial numbers of
> CPU/Southbridge/SoC.
> That way every board would have it's own encryption key.
> But I guess the decryption code could easily be reversed engineered.

I wouldn't go with encryption, but rather with some check which refuses
to boot if serial number (SoC, MAC address, ...) and a hash of it (in
OTP) mismatch. That way even reflashing the board won't erase the hash
by accident, and you can just give the manufacturer as many OTP images
as needed. They just need to supply the serial numbers to you in advance.


> An end user would be able to do a backup and would be able to reflash
> the bios *on the same board*.

Yes, ability to reflash is important.

Regards,
Carl-Daniel

-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] How to protect binary in flash chip? OTP?

[Zaolin]

Hi Zheng,

it is really hard to do that. I guess you'll need to have platform support
for such a feature. Maybe you could ask Christopher Tarnovsky
about such technologies (chris.tarnov...@ioactive.com). He is a
kind guy and an expert when it comes to security chips/technologies
on the hardware level :) .

Best Regards
Zheng

On 05/06/2016 02:45 AM, Zheng Bao wrote:
> Hi, All,
> Is there any way to protect the binary image in flash chip from being copied? 
> Once the customers
> gets the image, they can produce millions of board and do not tell me. I just 
> want to know the
> amount of the mass production.
>
> OTP seems to be a way, but it is not 100%. The data in OTP is readable and 
> can be copied to a new chip's
> OTP erea.
>
> Do you guys have any more suggestion?
>
> Zheng
>
> 



0xD81427AB.asc
Description: application/pgp-keys


signature.asc
Description: OpenPGP digital signature
-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] How to protect binary in flash chip? OTP?

[Patrick Rudolph]

On 2016-05-06 02:45 AM, Zheng Bao wrote:
> Hi, All,
> Is there any way to protect the binary image in flash chip from being
> copied? Once the customers
> gets the image, they can produce millions of board and do not tell me.
> I just want to know the
> amount of the mass production.
> 
> OTP seems to be a way, but it is not 100%. The data in OTP is readable
> and can be copied to a new chip's
> OTP erea.
> 
> Do you guys have any more suggestion?
> 
> Zheng

As you want to execute code from it, it needs to be readable.
Protecting it from software doesn't make much sense as you could just
de-solder the flash chip.

I guess what you want to know is: Should a copied image boot on another
board ?

I've got two solutions:
1.
You could encrypt the binary and store the secret in a TPM.
That way every board would have the same encryption key.
No idea if this is possible on your platform and how much work it would
be to implement in coreboot.
That'd be a good GSoC project :-)

2.
If you don't have a TPM you could use serial numbers of
CPU/Southbridge/SoC.
That way every board would have it's own encryption key.
But I guess the decryption code could easily be reversed engineered.

An end user would be able to do a backup and would be able to reflash
the bios *on the same board*.

Regards,
Patrick

-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] How to protect binary in flash chip? OTP?

[David Hendricks]

On Thu, May 5, 2016 at 8:39 PM, Zheng Bao  wrote:

> I don't protect my source. I gave the source to customers. I just want to
> protect binary.
> Customer doesnt know how to build.
>
> In a business, customer dont tell the correct production amount as what is
> wrote in the contract.


I think Patrick is correct when he mentioned that the only way to get the
information is with remote attestation. But that can become complicated and
if the customer is determined they may break the scheme.

Can you describe the business model in more detail? It appears that you
have a royalty-based agreement with the customer, but the customer is being
dishonest. Maybe others have a better idea of what kind of business
arrangements can work better in the future - Upfront payment for porting,
time-based support contract, etc.
-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Unable to build coreboot with Intel FSP debug binary on BayleyBay

[Zoran Stojsavljevic]

Hello Kathappan,

As my understanding is (I might be wrong, please, others correct), you
should have the whole Coreboot + BYT-I FSP build of maximum 2MB (last/top
2MB on the top of 8MB board SPI flash). The line:

*E: Could not add [fsp, 294912 bytes (288 KB)@0x1bff00]; too big?*

Says that you are trying to add some entity (fsp) of size 288KB on the
0x20 - 0x1BFF00 = 256KB + 256B.

The other line:

*E: Failed to add '../intel/fsp/baytrail/BAYTRAIL_FSP_D.fd' into ROM image.*

Implies that your BAYTRAIL_FSP_D.fd image is 288KB size wide, so you left
too narrow space for FSP image to fit in Coreboot build.

You need to go back to Coreboot .config (to run make menuconfig) and
understand what additional Coreboot features you need to deprecate/exclude
(to make more space), in order to make this last region at least minimum of
288KB or bigger/wider.

Zoran


On Fri, May 6, 2016 at 7:39 AM, Kathappan E  wrote:

> Hi all,
>
>
>
> I am able to build Coreboot with FSP Baytrail release binary(
> *BAYTRAIL_FSP_GOLD_004_22-MAY-2015.fd*).
>
>
>
> But I am unable to build with FSP Baytrail debug binary  (
> *BAYTRAIL_FSP_GOLD_004_22-MAY-2015_DEBUG.fd*) and it throws the below
> error says that binary size is large and fails to add into image.
>
>
>
> *The sections containing CBFSes are: COREBOOT*
>
> *Performing operation on 'COREBOOT' region...*
>
> *Created CBFS (capacity = 2096856 bytes)*
>
> *Performing operation on 'COREBOOT' region...*
>
> *Performing operation on 'COREBOOT' region...*
>
> *CBFS   fsp.bin*
>
> *Performing operation on 'COREBOOT' region...*
>
> *E: Not enough space for content.*
>
> *E: Could not add [fsp, 294912 bytes (288 KB)@0x1bff00]; too big?*
>
> *E: Failed to add '../intel/fsp/baytrail/BAYTRAIL_FSP_D.fd' into ROM
> image.*
>
> *E: Failed while operating on 'COREBOOT' region!*
>
> *E: The image will be left unmodified.*
>
> *make: *** [build/coreboot.pre] Error 1*
>
>
>
> Can you please anyone help me on this?
>
>
>
> Thanks in advance,
>
> Kathappan
>
> *L Technology Services Ltd*
>
> www.LntTechservices.com 
>
> This Email may contain confidential or privileged information for the
> intended recipient (s). If you are not the intended recipient, please do
> not use or disseminate the information, notify the sender and delete it
> from your system.
>
> --
> coreboot mailing list: coreboot@coreboot.org
> https://www.coreboot.org/mailman/listinfo/coreboot
>
-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] How to protect binary in flash chip? OTP?

[Patrick Georgi via coreboot]

2016-05-06 6:49 GMT+02:00 Persmule :
> DRM methods cannot "protect" anything. They can only do harm to end users.
That's an interesting statement for a political outreach discussion
group (although the relevant activist groups probably beat that
particular horse to death several times over.)
Please note that coreboot@ isn't that kind of place.

To go back to the original question, any such approach fails here (at
least on somewhat regular x86/arm designs on the market):
> The data in OTP is readable

Since the CPU needs to read the flash at some point, you can't avoid
it to read it (without breaking the legitimate use case). Sounds
circular - because it is.
The only scheme that could allow you to figure out sales numbers would
be some remote attestation scheme - but they'd need to be interested
in using it in the first place (plus, there's the assumption that the
device is networked).


Regards,
Patrick

-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot