[coreboot] Re: TigerLake RVP TCSS init failure

[Guillermo Placencia]

KEnviado desde HUAWEI Y6 2019 Mensaje original De: Michal Zygowski Fecha: mar., 9 feb. 2021 10:38Para: coreboot@coreboot.orgCC: wonkyu@intel.com, john.z...@intel.com, twawrzync...@google.com, furquan.m.sha...@gmail.comAsunto: [coreboot] Re: TigerLake RVP TCSS init failure
Any ideas what may be wrong?
  
  I can share more details/logs if needed.

On 01.02.2021 16:48, Michal Zygowski
  wrote:


  
  Dear coreboot community,

I have encountered problem with silicon init on Tiger Lake RVP
platform. I managed to resolve previous issues with memory
initialization and now hitting an error with TCSS init. The FSP
asserts on IOM ready check, which is 0. The configuration has
selected CONFIG_USE_INTEL_FSP_MP_INIT (without MP PPI service).

When the CONFIG_USE_INTEL_FSP_TO_CALL_COREBOOT_PUBLISH_MP_PPI is
selected, then the FSP-S returns smoothly (at least from one of
the phases I guess) and resets after clearing MCEs in coreboot's
CPU init:

CPU: vendor Intel device 806c0
CPU: family 06, model 8c, stepping
  00
Clearing out pending MCEs
Setting up local APIC...
apic_id: 0x00 done.
Turbo is available but hidden
Turbo is available and visible
CPU #0 initialized
Initializing CPU #2
Initializing CPU #6
Initializing CPU #7
CPU: vendor Intel device 806c0
CPU: family 06, model 8c, stepping
  00
CPU: vendor Intel device 806c0
CPU: family 06, model 8c, stepping
  00
Clearing out pending MCEs
Cl (tutaj następuje reset)
  
Any ideas what may cause these issues? When I clean this up, I
will upstream the DDR4 variant of TGL UP3 RVP.
  
  -- 
Michał Żygowski
Firmware Engineer
https://3mdeb.com | @3mdeb_com
  
  
  ___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org


-- 
Michał Żygowski
Firmware Engineer
https://3mdeb.com | @3mdeb_com
  
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: Intel CBnT tooling and dealing with NDA

[Arthur Heymans]

Hi

Thanks for your input!

Peter Stuge  writes:

> Arthur Heymans wrote:
>> To make Intel CBnT (Converged Bootguard and TXT) useful in coreboot
some
>> tooling is required to generate both a Key Manifest (A signed
binary, that
>> is checked against a key fused into the ME, holding keys that OEM
can use
>> to sign the BPM) and a Boot Policy Manifest (signed binary, has a
digest
>> of IBBs, Initial Boot Blocks).
>
> This seems like something that could be put together even by a shell
> script calling openssl the right way.
>
>

Shell scripts are a very bad way to construct binary data structures.

>> 9elements has written some open source tooling (BSD-3 clause) to
generate
>> both KM and BPM. The code for this tool is not yet public
>
> You can't pretend that something is open source until you've
published it.
>

Being open source does not require to be public. FWIW we couldn't
publish our tool as a binary-only if it was not licenqed as it
currently
is (BSD-3 clause). I'm not claiming the binary is open source ofc, but
we are
committed to publish the code ASAP.

>> Intel is currently reviewing this to allow us to make it public, but
this
>> takes time.
> ..
>> My question to the community is if it would be ok to allow for the
build
>> system integration code for KM and BPM generation to be integrated
into
>> the master branch before the code to the tooling is made public.
>
> I don't think that is at all acceptable, even if it may be
technically OK.
>
> If you push this problem upstream you would surrender part of your
> responsibility for delivering an open source solution to your
customer,
> and push the burden of the blobbyness you have created (for your
customer)
> onto the community.
>
> I don't think that's a very good move.
>

I don't like this very much either, but it looks like it is the best
move
available.
Silicon vendors being overprotective over their IP is a recurring
issue.
Developing everything on a private branch and doing a big code dump
once
the silicon vendor gives a green light is an even bigger disservice to
the community.
- Big code dumps are a huge strain on the community and proved to cause
problems in the past.
- The rate at which new silicon and platforms are pushed is staggering.
If one has to wait for the silicon vendor green light before publishing
code the platform might already being to old to be very interesting.
We saw this issue in the past where AGESA srubbing took so long that
the
platforms were not interesting anymore. Intel also publishes FSP glue
code without FSP being published. Relying on things not yet published
seems to be a necessary compromise to have upstream development in the
master branch for new silicon.

One of the things the coreboot project and community does very well at
the moment is to develop everything in one master branch, compared to
the UEFI world where everything lives in a branch and where there is
pretty much 0 community. To keep this upstream development model in
line
with new silicon development it looks like some compromises are
necessary.

>
>> we propose to add a binary tool (it's written in go so it's
>> automatically build as a static binary) to the blobs repo under a
>> licence similar to the one used for Intel FSP and MCU (allows
>> redistribution). We hope to remove it ASAP from there and build it
>> from source from 3rdparty/intel-sec-tools.
>
> Especially given that you seem to have good support for pushing Intel
> forward on this, it doesn't seem urgent to accept what is essentially
> your problem into upstream.
>

If we always have to wait for the silicon vendor to be able to
upstream,
the platform would already be in production and upstreaming is less
interesting for both the vendor and the community. So yes, in a sense
it's urgent and this is how a lot of upstream development is going on
anyway at the moment.

>
>> We'd like to develop as close as possible to the coreboot master
branch,
>> so we hope that this is an acceptable solution to the community.
>
> While it is honorable that you want to work as close to master as
possible,
> I do think you should have considered that a lot earlier in this
process,
> before getting tangled up in Intel's net of NDA nonsense.
>

So no upstream Intel support in coreboot anymore? I'll put it on the
agenda tomorrow ;-)

I wish we had enough leverage as a community to change the silicon
vendors way, but that is just not the case. I feel however that things
improve in the right direction. OSF on server hardware is becoming a
thing again, which was not the case at all a few years back.

>
> Sorry, x86 sucks.
>

On a philosophical note, it's always possible to define goals and
desires
against which everything sucks. It's a cheap trick of the mind. The
goal
should be to make tomorrow better than today, even if the progress is
small ;-)

Kind regards

-- 
==
Arthur Heymans
 

___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe 

[coreboot] Re: Intel CBnT tooling and dealing with NDA

[Peter Stuge]

Arthur Heymans wrote:
> To make Intel CBnT (Converged Bootguard and TXT) useful in coreboot some
> tooling is required to generate both a Key Manifest (A signed binary, that
> is checked against a key fused into the ME, holding keys that OEM can use
> to sign the BPM) and a Boot Policy Manifest (signed binary, has a digest
> of IBBs, Initial Boot Blocks).

This seems like something that could be put together even by a shell
script calling openssl the right way.


> 9elements has written some open source tooling (BSD-3 clause) to generate
> both KM and BPM. The code for this tool is not yet public

You can't pretend that something is open source until you've published it.


> Intel is currently reviewing this to allow us to make it public, but this
> takes time.
..
> My question to the community is if it would be ok to allow for the build
> system integration code for KM and BPM generation to be integrated into
> the master branch before the code to the tooling is made public.

I don't think that is at all acceptable, even if it may be technically OK.

If you push this problem upstream you would surrender part of your
responsibility for delivering an open source solution to your customer,
and push the burden of the blobbyness you have created (for your customer)
onto the community.

I don't think that's a very good move.


> At the moment coreboot has code for xeon_sp in the master
> branch without a public FSP too

Even if everyone at your school smokes in every break it's still bad for
your health to start smoking.


> we propose to add a binary tool (it's written in go so it's
> automatically build as a static binary) to the blobs repo under a
> licence similar to the one used for Intel FSP and MCU (allows
> redistribution). We hope to remove it ASAP from there and build it
> from source from 3rdparty/intel-sec-tools.

Especially given that you seem to have good support for pushing Intel
forward on this, it doesn't seem urgent to accept what is essentially
your problem into upstream.


> We'd like to develop as close as possible to the coreboot master branch,
> so we hope that this is an acceptable solution to the community.

While it is honorable that you want to work as close to master as possible,
I do think you should have considered that a lot earlier in this process,
before getting tangled up in Intel's net of NDA nonsense.


Sorry, x86 sucks.

//Peter
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: Intel CBnT tooling and dealing with NDA

[Jonathan Zhang (Infra) via coreboot]

Regarding Intel approval of the content, We (Facebook) has been working with 
Intel to get this moved forward as soon as possible.

Thanks,
Jonathan

From: Patrick Georgi via coreboot 
Reply-To: Patrick Georgi 
Date: Tuesday, February 9, 2021 at 2:40 AM
To: Arthur Heymans 
Cc: coreboot 
Subject: [coreboot] Re: Intel CBnT tooling and dealing with NDA

Am Di., 9. Feb. 2021 um 11:34 Uhr schrieb Arthur Heymans 
mailto:arthur.heym...@9elements.com>>:
So TL;DR:
- Is (temporarily) adding a tool to the blobs repo ok?
If it matches the requirements of the blobs repo wrt. license terms and 
documentation, I don't see why not from a formal perspective.
It's telling though (in the sense of a Freudian slip) that you put the 
"temporarily" in parentheses already: interim solutions like these tend to 
survive their best due date ;-)

- Is integrating an (optional) not yet open tool into the build system ok?
This one is IMHO the bigger issue: that tool will only run on Linux/x86(-64?), 
and probably only with a select set of libc implementations. While we have 
portability issues every now and then, they're always accidentally introduced 
because our testing isn't good enough while adding this to the build flow 
deliberately makes all other platforms second tier build hosts.


Regards,
Patrick
--
Google Germany GmbH, ABC-Str. 19, 20354 Hamburg
Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft: Hamburg
Geschäftsführer: Paul Manicle, Halimah DeLaine Prado
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: TigerLake RVP TCSS init failure

[Michal Zygowski]

Any ideas what may be wrong?

I can share more details/logs if needed.

On 01.02.2021 16:48, Michal Zygowski wrote:
>
> Dear coreboot community,
>
> I have encountered problem with silicon init on Tiger Lake RVP
> platform. I managed to resolve previous issues with memory
> initialization and now hitting an error with TCSS init. The FSP
> asserts on IOM ready check, which is 0. The configuration has selected
> CONFIG_USE_INTEL_FSP_MP_INIT (without MP PPI service).
>
> When the CONFIG_USE_INTEL_FSP_TO_CALL_COREBOOT_PUBLISH_MP_PPI is
> selected, then the FSP-S returns smoothly (at least from one of the
> phases I guess) and resets after clearing MCEs in coreboot's CPU init:
>
> CPU: vendor Intel device 806c0
> CPU: family 06, model 8c, stepping 00
> Clearing out pending MCEs
> Setting up local APIC...
> apic_id: 0x00 done.
> Turbo is available but hidden
> Turbo is available and visible
> CPU #0 initialized
> Initializing CPU #2
> Initializing CPU #6
> Initializing CPU #7
> CPU: vendor Intel device 806c0
> CPU: family 06, model 8c, stepping 00
> CPU: vendor Intel device 806c0
> CPU: family 06, model 8c, stepping 00
> Clearing out pending MCEs
> Cl (tutaj następuje reset)
>
>
> Any ideas what may cause these issues? When I clean this up, I will
> upstream the DDR4 variant of TGL UP3 RVP.
>
> -- 
> Michał Żygowski
> Firmware Engineer
> https://3mdeb.com | @3mdeb_com
>
> ___
> coreboot mailing list -- coreboot@coreboot.org
> To unsubscribe send an email to coreboot-le...@coreboot.org

-- 
Michał Żygowski
Firmware Engineer
https://3mdeb.com | @3mdeb_com

___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] New Defects reported by Coverity Scan for coreboot

[scan-admin--- via coreboot]

Hi,

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

122 new defect(s) introduced to coreboot found with Coverity Scan.
11 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 122 defect(s)


** CID 1446367:  Integer handling issues  (CONSTANT_EXPRESSION_RESULT)
/3rdparty/chromeec/common/usb_pd_policy.c: 422 in is_usb4_vdo()



*** CID 1446367:  Integer handling issues  (CONSTANT_EXPRESSION_RESULT)
/3rdparty/chromeec/common/usb_pd_policy.c: 422 in is_usb4_vdo()
416 if (IS_PD_IDH_UFP_PTYPE(ptype)) {
417 /*
418  * Ref: USB Type-C Cable and Connector Specification
419  * Figure 5-1 USB4 Discovery and Entry Flow Model
420  * Device USB4 VDO detection.
421  */
>>> CID 1446367:  Integer handling issues  (CONSTANT_EXPRESSION_RESULT)
>>> "({...; 0;}) && is_vdo_present(cnt, 4)" is always false regardless of 
>>> the values of its operands. This occurs as the logical first operand of 
>>> "&&".
422 return IS_ENABLED(CONFIG_USB_PD_USB4) &&
423 is_vdo_present(cnt, VDO_INDEX_PTYPE_UFP1_VDO) &&
424 
PD_PRODUCT_IS_USB4(payload[VDO_INDEX_PTYPE_UFP1_VDO]);
425 }
426 return false;
427 }

** CID 1446366:  Parse warnings  (PARSE_ERROR)
/3rdparty/chromeec/common/motion_lid.c: 104 in ()



*** CID 1446366:  Parse warnings  (PARSE_ERROR)
/3rdparty/chromeec/common/motion_lid.c: 104 in ()
98 static const struct motion_sensor_t * const accel_base =
99  _sensors[CONFIG_LID_ANGLE_SENSOR_BASE];
100 static const struct motion_sensor_t * const accel_lid =
101 _sensors[CONFIG_LID_ANGLE_SENSOR_LID];
102 
103 STATIC_IF(CONFIG_TABLET_MODE) void motion_lid_set_tablet_mode(int 
reliable);
>>> CID 1446366:  Parse warnings  (PARSE_ERROR)
>>> expression must be an integral constant expression
104 STATIC_IF(CONFIG_TABLET_MODE) int lid_angle_set_tablet_mode_threshold(
105 int angle, int hys);
106 
107 STATIC_IF(CONFIG_TABLET_MODE) fp_t tablet_zone_lid_angle;
108 STATIC_IF(CONFIG_TABLET_MODE) fp_t laptop_zone_lid_angle;
109 STATIC_IF(CONFIG_TABLET_MODE) int tablet_mode_lid_angle;

** CID 1446365:(DEADCODE)
/3rdparty/chromeec/driver/charger/isl923x.c: 512 in isl923x_init()
/3rdparty/chromeec/driver/charger/isl923x.c: 608 in isl923x_init()
/3rdparty/chromeec/driver/charger/isl923x.c: 473 in isl923x_init()
/3rdparty/chromeec/driver/charger/isl923x.c: 577 in isl923x_init()
/3rdparty/chromeec/driver/charger/isl923x.c: 591 in isl923x_init()



*** CID 1446365:(DEADCODE)
/3rdparty/chromeec/driver/charger/isl923x.c: 512 in isl923x_init()
506 reg |
507 ISL9237_C1_SWITCH_FREQ_599K))
508 goto init_fail;
509 }
510 
511 if (IS_ENABLED(CONFIG_TRICKLE_CHARGING))
>>> CID 1446365:(DEADCODE)
>>> Execution cannot reach this statement: "if (raw_write16(chgnum, 62,...".
512 if (raw_write16(chgnum, ISL923X_REG_SYS_VOLTAGE_MIN,
513 precharge_voltage))
514 goto init_fail;
515 
516 /*
517  * [10:9]: Prochot# Debounce time
/3rdparty/chromeec/driver/charger/isl923x.c: 608 in isl923x_init()
602 if (IS_ENABLED(CHARGER_ISL9238X) ||
603 IS_ENABLED(CONFIG_CHARGER_RAA489000)) {
604 /*
605  * Don't reread the prog pin and don't reload the ILIM 
on ACIN.
606  * For the RAA489000, just don't reload ACLIM.
607  */
>>> CID 1446365:(DEADCODE)
>>> Execution cannot reach this statement: "if (raw_read16(chgnum, 76, ...".
608 if (raw_read16(chgnum, ISL9238_REG_CONTROL3, ))
609 goto init_fail;
610 reg |= ISL9238_C3_NO_RELOAD_ACLIM_ON_ACIN;
611 if (!IS_ENABLED(CONFIG_CHARGER_RAA489000))
612 reg |= ISL9238_C3_NO_REREAD_PROG_PIN;
613 
/3rdparty/chromeec/driver/charger/isl923x.c: 473 in isl923x_init()
467 int reg;
468 const struct battery_info *bi = battery_get_info();
469 int precharge_voltage = bi->precharge_voltage ?
470 bi->precharge_voltage : bi->voltage_min;
471 
472

[coreboot] Re: Intel CBnT tooling and dealing with NDA

[Christian Walter]

Hi Michal,

this _could_ have been a good starting point - however we decided to 
integrate this into the Converged Security Suite 
(github.com/9elements/converged-security-suite 
) which already is 
part of coreboot as a 3rdparty module. However even if we _would_ extend 
your tooling - NDA issues still are not resolved. As Arthur pointed out, 
we would hope to integrate this as a binary as a temporary solution, 
until Intel clears out the NDA issues. And also in the sense of moving 
forward, I would like to choose Golang over C in this case.


Best,
Chris

Am Di., 9. Feb. 2021 um 12:14 Uhr schrieb Michal Zygowski 
mailto:michal.zygow...@3mdeb.com>>:


   Hi Christian,

   On 09.02.2021 11:58, Christian Walter wrote:

> Hi Michal,
>
> mind pointing me to the tooling you make for *creating* these
   manifests?
>
   There is a whole intel_bootguard topic:
   https://review.coreboot.org/q/topic:intel_bootguard
   
   In particular have a look at these patches:
   - Tool: https://review.coreboot.org/c/coreboot/+/43403
   
   - Hook manifest creation into build system:
   https://review.coreboot.org/c/coreboot/+/43404
   

   The manifests layout is implemented in the tool. Although it creates the
   v1.0 manifests and AFAIK CBnT required v2.1 format, but this tool can be
   a good base, isn't it?


   Best regards,

   -- 
   Michał Żygowski

   Firmware Engineer
   https://3mdeb.com  | @3mdeb_com

   ___
   coreboot mailing list -- coreboot@coreboot.org
   
   To unsubscribe send an email to coreboot-le...@coreboot.org
   

___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: Intel CBnT tooling and dealing with NDA

[Michal Zygowski]

Hi Christian,

On 09.02.2021 11:58, Christian Walter wrote:

> Hi Michal,
>
> mind pointing me to the tooling you make for *creating* these manifests?
>
There is a whole intel_bootguard topic:
https://review.coreboot.org/q/topic:intel_bootguard
In particular have a look at these patches:
- Tool: https://review.coreboot.org/c/coreboot/+/43403
- Hook manifest creation into build system:
https://review.coreboot.org/c/coreboot/+/43404

The manifests layout is implemented in the tool. Although it creates the
v1.0 manifests and AFAIK CBnT required v2.1 format, but this tool can be
a good base, isn't it?


Best regards,

-- 
Michał Żygowski
Firmware Engineer
https://3mdeb.com | @3mdeb_com

___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: Intel CBnT tooling and dealing with NDA

[Arthur Heymans]

Patrick Georgi via coreboot  writes:

> Am Di., 9. Feb. 2021 um 11:34 Uhr schrieb Arthur Heymans
:
>
>  So TL;DR:
>  - Is (temporarily) adding a tool to the blobs repo ok?
>
> If it matches the requirements of the blobs repo wrt. license terms
and documentation, I don't see why not from a formal perspective.
> It's telling though (in the sense of a Freudian slip) that you put
the "temporarily" in parentheses already: interim solutions like these
tend to survive
> their best due date ;-)

I was told this typically takes Intel a few months.

>  - Is integrating an (optional) not yet open tool into the build
system ok?
>
> This one is IMHO the bigger issue: that tool will only run on
Linux/x86(-64?), and probably only with a select set of libc
implementations. While we
> have portability issues every now and then, they're always
accidentally introduced because our testing isn't good enough while
adding this to the
> build flow deliberately makes all other platforms second tier build
hosts.
>

Good point!
Tools build with go include the go runtime so they should be fully
standalone. Adding different ARCH + OS is very easy with go, so adding
other platforms can be done very quickly if desired.

Kind regards

-- 
==
Arthur Heymans

___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: Intel CBnT tooling and dealing with NDA

[Christian Walter]

Hi Michal,

mind pointing me to the tooling you make for *creating* these manifests?

Am Di., 9. Feb. 2021 um 11:46 Uhr schrieb Michal Zygowski <
michal.zygow...@3mdeb.com>:

> Hi,
>
> On 09.02.2021 11:02, Arthur Heymans wrote:
> > Hi
> >
> > To make Intel CBnT (Converged Bootguard and TXT) useful in coreboot some
> > tooling is required to generate both a Key Manifest (A signed binary,
> > that is checked
> > against a key fused into the ME, holding keys that OEM can use to sign
> the BPM)
> > and a Boot Policy Manifest (signed binary, has a digest of IBBs,
> > Initial Boot Blocks).
> > At the moment these are included as binaries by the build system.
> >
> > Obviously this only works if the IBB hasn't changed. If it changed, you'd
> > need to regenerate the BPM. 9elements has written some open source
> tooling
> > (BSD-3 clause) to generate both KM and BPM. The code for this tool is
> not yet
> > public as it was written using NDA documentation. Intel is currently
> reviewing
> > this to allow us to make it public, but this takes time. It will be
> > part of the 3rdparty/intel-sec-tools
> > submodule.
>
> What is the diff between BtG and CBnT manifests format? Is the work that
> we (3mdeb) did, not usable?
>
> Best regards,
>
> --
> Michał Żygowski
> Firmware Engineer
> https://3mdeb.com | @3mdeb_com
> ___
> coreboot mailing list -- coreboot@coreboot.org
> To unsubscribe send an email to coreboot-le...@coreboot.org
>
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: Intel CBnT tooling and dealing with NDA

[Michal Zygowski]

Hi,

On 09.02.2021 11:02, Arthur Heymans wrote:
> Hi
>
> To make Intel CBnT (Converged Bootguard and TXT) useful in coreboot some
> tooling is required to generate both a Key Manifest (A signed binary,
> that is checked
> against a key fused into the ME, holding keys that OEM can use to sign the 
> BPM)
> and a Boot Policy Manifest (signed binary, has a digest of IBBs,
> Initial Boot Blocks).
> At the moment these are included as binaries by the build system.
>
> Obviously this only works if the IBB hasn't changed. If it changed, you'd
> need to regenerate the BPM. 9elements has written some open source tooling
> (BSD-3 clause) to generate both KM and BPM. The code for this tool is not yet
> public as it was written using NDA documentation. Intel is currently reviewing
> this to allow us to make it public, but this takes time. It will be
> part of the 3rdparty/intel-sec-tools
> submodule.

What is the diff between BtG and CBnT manifests format? Is the work that
we (3mdeb) did, not usable?

Best regards,

-- 
Michał Żygowski
Firmware Engineer
https://3mdeb.com | @3mdeb_com
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: Intel CBnT tooling and dealing with NDA

[Patrick Georgi via coreboot]

Am Di., 9. Feb. 2021 um 11:34 Uhr schrieb Arthur Heymans <
arthur.heym...@9elements.com>:

> So TL;DR:
> - Is (temporarily) adding a tool to the blobs repo ok?
>
If it matches the requirements of the blobs repo wrt. license terms and
documentation, I don't see why not from a formal perspective.
It's telling though (in the sense of a Freudian slip) that you put the
"temporarily" in parentheses already: interim solutions like these tend to
survive their best due date ;-)


> - Is integrating an (optional) not yet open tool into the build system ok?
>
This one is IMHO the bigger issue: that tool will only run on
Linux/x86(-64?), and probably only with a select set of libc
implementations. While we have portability issues every now and then,
they're always accidentally introduced because our testing isn't good
enough while adding this to the build flow deliberately makes all other
platforms second tier build hosts.


Regards,
Patrick
-- 
Google Germany GmbH, ABC-Str. 19, 20354 Hamburg
Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft:
Hamburg
Geschäftsführer: Paul Manicle, Halimah DeLaine Prado
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Intel CBnT tooling and dealing with NDA

[Arthur Heymans]

Hi

To make Intel CBnT (Converged Bootguard and TXT) useful in coreboot some
tooling is required to generate both a Key Manifest (A signed binary,
that is checked
against a key fused into the ME, holding keys that OEM can use to sign the BPM)
and a Boot Policy Manifest (signed binary, has a digest of IBBs,
Initial Boot Blocks).
At the moment these are included as binaries by the build system.

Obviously this only works if the IBB hasn't changed. If it changed, you'd
need to regenerate the BPM. 9elements has written some open source tooling
(BSD-3 clause) to generate both KM and BPM. The code for this tool is not yet
public as it was written using NDA documentation. Intel is currently reviewing
this to allow us to make it public, but this takes time. It will be
part of the 3rdparty/intel-sec-tools
submodule.

My question to the community is if it would be ok to allow for the build system
integration code for KM and BPM generation to be integrated into the
master branch
before the code to the tooling is made public.
CBnT is an optional feature on Intel hardware and is implemented as an
optional feature in
coreboot. The tool is standalone and coreboot can still be built fine
without it.

At the moment coreboot has code for xeon_sp in the master
branch without a public FSP too, with the promise that it will be
publicly released later
on by Intel. Compared to that the situation would be a little better:
we propose to add a binary tool (it's written in go so it's
automatically build as a static binary) to the blobs repo under a
licence similar to the one used for Intel FSP and MCU (allows
redistribution). We hope to remove it ASAP from there and build it
from source from 3rdparty/intel-sec-tools.

We'd like to develop as close as possible to the coreboot master
branch, so we hope that this is an acceptable solution to the
community.

So TL;DR:
- Is (temporarily) adding a tool to the blobs repo ok?
- Is integrating an (optional) not yet open tool into the build system ok?

Let me know what you think.

Kind regards.

Arthur Heymans



9elements GmbH, Kortumstraße 19-21, 44787 Bochum, Germany
Email:  arthur.heym...@9elements.com
Phone:  +49 234 68 94 188
Mobile:  +32 478499445

Sitz der Gesellschaft: Bochum
Handelsregister: Amtsgericht Bochum, HRB 17519
Geschäftsführung: Sebastian Deutsch, Eray Basar

Datenschutzhinweise nach Art. 13 DSGVO
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org