Re: [coreboot] Fund a TALOS Secure Workstation as coreboot build system

[ron minnich]

Speaking from a former buyer of hardware, I can tell you from long
experience, it is *really* hard to specify coreboot as a mandatory
requirement. I've got stories going back 17 years now.

Even when it makes sense, it's hard.

I don't think we should count on the gov't to do the right thing.

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

Re: [coreboot] Fund a TALOS Secure Workstation as coreboot build system

[Timothy Pearson]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 01/17/2017 06:13 PM, taii...@gmx.com wrote:
> Tim, how come you guys didn't go after government and corporate sources
> of funding? I read DARPA is really interested in assured computing these
> days.

Government procurement in the United States operates very differently
than civilian procurement.  Most agencies start by initiating a public
request to accept bids to build a particular type of system, meaning
that first you have to convince them that they need something badly
enough to put out this first public request.  We did attempt this but
without prototype hardware in hand we were not able to proceed further;
i.e. it ended up being a classic "chicken or egg" scenario.

> Maybe there should be a fund for a IBM/TYAN POWER system for the
> coreboot project?, maybe better than being stuck doing development on an
> older platform?

I believe I have mentioned before that Raptor would be willing to
consider this, but the sticker shock would probably mean it would not be
funded.  The cost for legally reverse engineering a Tyan machine and
porting over the entire IBM firmware stack + OpenBMC would probably be
north of $100k USD.

> Does anyone know how long ASUS will keep making new ones?

That is uncertain.  I would expect at *least* until Zen is shipping, and
possibly a bit longer than that.

> Something for people to think about - In 2012 a brand new KGPE-D16
> spec'ed out with cpus and memory would have been just as much as a
> POWER8 system is now (I read on a forum that someone got a S822LC for 5K
> through an IBM corporate rep)

Be careful here; there are now two different S822LC models!  The one
that is nearly free (i.e just needs some additional "elbow grease" to
free up the rest of the way) is codenamed Firestone and still retails
for around $10k USD.  The other one has unknown freedom status; I'd need
to know the codename to check in the main repositories.

> (I would just buy you guys one but I am unemployed despite the bogus "it
> worker shortage")
> 

It is interesting, isn't it?  I think that's just code for "no one wants
the job at the wages we're willing to pay for the hours worked / IP
transfer requirements".

- -- 
Timothy Pearson
Raptor Engineering
+1 (415) 727-8645 (direct line)
+1 (512) 690-0200 (switchboard)
https://www.raptorengineering.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJYfrWqAAoJEK+E3vEXDOFbLPEH/3ldlTF+qng8NwpVNK12EW5R
6YdU/kfpuwPkGMPTUurs7YbS5h5NUBhyi8VYzjCGC87eHLGRjrXwx0Le+vJSgqBA
FV8LETNWC7CZS5uLZApd6kzcz8EGX6eIjOemOgeMuZ9Jq2F0J5J7kzUV+1TK794D
T3RT7WzGZ3Zm54oLnkG5JpGNHGk6rzbRG/76JBS9RK5J97F3+hec8Ics2vC2ppZx
hB8HwobeLnsEFbiFsZ4JJG7o4MRfY1g0xFhfW5/jwWhykJtc0ZC0ZeOxMBKq1r0j
L3U082eMUYsITpPKAQ1hmAxD3c714RbvD4cR29t337qhwko7QOkBzYY/tujHH3k=
=/XdI
-END PGP SIGNATURE-

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

Re: [coreboot] Fund a TALOS Secure Workstation as coreboot build system

[taii...@gmx.com]

Tim, how come you guys didn't go after government and corporate sources 
of funding? I read DARPA is really interested in assured computing these 
days.


Maybe there should be a fund for a IBM/TYAN POWER system for the 
coreboot project?, maybe better than being stuck doing development on an 
older platform?


Does anyone know how long ASUS will keep making new ones?

Something for people to think about - In 2012 a brand new KGPE-D16 
spec'ed out with cpus and memory would have been just as much as a 
POWER8 system is now (I read on a forum that someone got a S822LC for 5K 
through an IBM corporate rep)


(I would just buy you guys one but I am unemployed despite the bogus "it 
worker shortage")


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

Re: [coreboot] Fund a TALOS Secure Workstation as coreboot build system

[Timothy Pearson]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 01/17/2017 04:52 PM, Trammell Hudson wrote:
> On Tue, Jan 17, 2017 at 02:24:16PM -0600, Timothy Pearson wrote:
>> [...]
>> Regarding the BMC work, we're looking to enable a fully libre BMC on the
>> KGPE-D16.  This is a complex process involving significant reverse
>> engineering efforts, writing new kernel drivers for the BMC, etc.  With
>> the BMC enabled, proper fan control can be established on the KGPE-D16,
>> in addition to remote console access and of course remote power on /
>> power off / reset functionality.
> 
> Is your plan to base it on the existing OpenBMC project?
> 
> https://code.facebook.com/posts/1601610310055392/introducing-openbmc-an-open-software-framework-for-next-generation-system-management/
> 
> https://github.com/facebook/openbmc
> 

That is correct.  We've done some initial work on this and a lot of
functionality needed for the D16 is broken and / or completely missing
from any of the OpenBMC trees; the work required to get everything
functioning properly on the D16 (which OpenBMC was never designed for)
is quite extensive.

- -- 
Timothy Pearson
Raptor Engineering
+1 (415) 727-8645 (direct line)
+1 (512) 690-0200 (switchboard)
https://www.raptorengineering.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJYfqH0AAoJEK+E3vEXDOFbZBYH/R9bPQ+4D0SpCq0X8AYOgv33
BQJqFEkGq4e+sWDM4myH7NP0GkHAfiGIOmLSTqG4Gb2Bz4QyIPy805Jk3qO1mLR/
WVCMaU2xK7BcmqCVi3JWsGalwCKmp9HeMmTvCxeXVkTCxkT7yFt4Cp+Y1d+HU1X6
HxFxbLjnMW/+//yfhbYGY89DFhpw6anhRQlCmrjBKhLEbXCI8Oxxkpr9P2fCPzEQ
q6ppyT4D/eVFpnHB9z+hiarvLzlXE11bd7/Z+V+esuG2z6odDbzTB+QuwPJ38Xw7
WxbJBYe3XiNVNEi49S26cEHNJ21cpaVDrnAKOpuuP0Gm3CrjJ5m316/siKVAVvA=
=47Qd
-END PGP SIGNATURE-

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

Re: [coreboot] Fund a TALOS Secure Workstation as coreboot build system

[Trammell Hudson]

On Tue, Jan 17, 2017 at 02:24:16PM -0600, Timothy Pearson wrote:
> [...]
> Regarding the BMC work, we're looking to enable a fully libre BMC on the
> KGPE-D16.  This is a complex process involving significant reverse
> engineering efforts, writing new kernel drivers for the BMC, etc.  With
> the BMC enabled, proper fan control can be established on the KGPE-D16,
> in addition to remote console access and of course remote power on /
> power off / reset functionality.

Is your plan to base it on the existing OpenBMC project?

https://code.facebook.com/posts/1601610310055392/introducing-openbmc-an-open-software-framework-for-next-generation-system-management/

https://github.com/facebook/openbmc

-- 
Trammell

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

Re: [coreboot] Fund a TALOS Secure Workstation as coreboot build system

[Timothy Pearson]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 01/17/2017 02:53 PM, Merlin Büge wrote:
> On Tue, 17 Jan 2017 14:24:16 -0600
> Timothy Pearson  wrote:
> 
> 
> 
>> Regarding the BMC work, we're looking to enable a fully libre BMC on
>> the KGPE-D16.  This is a complex process involving significant reverse
>> engineering efforts, writing new kernel drivers for the BMC, etc.
>> With the BMC enabled, proper fan control can be established on the
>> KGPE-D16, in addition to remote console access and of course remote
>> power on / power off / reset functionality.
>>
>> If this work can be funded, Raptor would chip in a matching amount to
>> lower the costs to the community; essentially we're looking to fund
>> half of the work internally but cannot justify the full cost of the
>> work as the sole sponsor.  Every little bit helps, so even if you can
>> only chip in $100 please consider doing so.
> 
> Do you think running a crowdfunding campaign again would help getting
> this funded / collecting donations? I don't know if you have to pay any
> fees for the various platforms out there, but I bet there are some for
> which you don't have to pay much.
> 
> I'm not thinking of a campaign like the Talos one, I just think it
> would be useful to keep track on how many people already donated, and
> how much is still missing to meet the goal. With 'useful' I
> mean it'd probably boost donations, in contrast to accepting donations
> quietly. So no big updates etc., just using their infrastructure for
> collecting donations. But after all, I've no idea about R etc. :P
> 
> If this is not too straight forward, may I ask of how much of
> community support you are thinking?
> 
> 
> Thank you,
> 
> Merlin

Given our past experience with crowdfunding I would rather this be
handled by the community itself; this allows the funds to go straight to
the work instead of partially being used to pay for the platform and
advertising costs.

We would like to see $20k USD from the community; we'll match (and
actually slightly exceed) that internally to get the port completed and
production qualified.  From what I understand this amount is very close
to what had been allocated originally for a Talos coreboot build server;
the BMC work would allow more KGPE-D16 systems to be used to host pieces
of coreboot worldwide.

As an added bonus, the BMC work would be directly applicable to the
KGPE-D16's little sister, the KCMA-D8.  The same (or slightly modified)
BMC firmware should work on both machines.

Thanks!

- -- 
Timothy Pearson
Raptor Engineering
+1 (415) 727-8645 (direct line)
+1 (512) 690-0200 (switchboard)
https://www.raptorengineering.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJYfp1mAAoJEK+E3vEXDOFbLZgH/jS05CjmnfIB08X9YeR6qiPo
mZn1j0QkuEa8bIVQG6DCer405gywPJzaYd3zlahTPBjG2D8LM8F2YEp/KXvB+eId
kuV8SYqq2W9tTMrrCP4m/5wbfEhku1SpU8j0kEnCD14UCNjjEmd2eJ2ZK6rHJf9p
YvrGXyzPHBl3fNJaTEoLCGEzhEozX8M4rYdcKpLEbQZXWmJe9r94TXxMD5TIWlkZ
TPhUsVdrPLpEMmzDSa8EOB3lGx9bMTR+GplKpAHnKg0+ZbeerEePyBnd4rzTjRAj
Pk/iOvWWwdtYj1W5eIkCHtwsj4coyos1Pjq6opNfNlJQSbvKCZ3kH90TTV2Binc=
=CT6t
-END PGP SIGNATURE-

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

Re: [coreboot] Fund a TALOS Secure Workstation as coreboot build system

[Merlin Büge]

On Tue, 17 Jan 2017 14:24:16 -0600
Timothy Pearson  wrote:



> Regarding the BMC work, we're looking to enable a fully libre BMC on
> the KGPE-D16.  This is a complex process involving significant reverse
> engineering efforts, writing new kernel drivers for the BMC, etc.
> With the BMC enabled, proper fan control can be established on the
> KGPE-D16, in addition to remote console access and of course remote
> power on / power off / reset functionality.
> 
> If this work can be funded, Raptor would chip in a matching amount to
> lower the costs to the community; essentially we're looking to fund
> half of the work internally but cannot justify the full cost of the
> work as the sole sponsor.  Every little bit helps, so even if you can
> only chip in $100 please consider doing so.

Do you think running a crowdfunding campaign again would help getting
this funded / collecting donations? I don't know if you have to pay any
fees for the various platforms out there, but I bet there are some for
which you don't have to pay much.

I'm not thinking of a campaign like the Talos one, I just think it
would be useful to keep track on how many people already donated, and
how much is still missing to meet the goal. With 'useful' I
mean it'd probably boost donations, in contrast to accepting donations
quietly. So no big updates etc., just using their infrastructure for
collecting donations. But after all, I've no idea about R etc. :P

If this is not too straight forward, may I ask of how much of
community support you are thinking?


Thank you,

Merlin


> 
> Thanks!
> 
> - -- 
> Timothy Pearson
> Raptor Engineering
> +1 (415) 727-8645 (direct line)
> +1 (512) 690-0200 (switchboard)
> https://www.raptorengineering.com
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
> 
> iQEcBAEBAgAGBQJYfn1uAAoJEK+E3vEXDOFbTV4H+QHqUiszRRI7kp5Qd0p/uI7G
> tOyL32CzMrUqekDj+A/V1gC5lYtQbjN6WzcMrBFQ9lvJrQy/GxFoRn0cHaZtteya
> MmqugPSGotjARM2quWCkbIdhNGgyzKWr+BHwpImH9SyiJ0nozl4RDGDfqhqdPI3+
> 7nt4TAc54Kq9yhUlP9XLpYq6Gi67sYt0qgVXyNhekiT4a7HrG+0aLtu8mzOVMktc
> /oIqnhHlZQnX6LDvNkKJkifanrjL5NXigEEB/iwaFW56Pm9avs07pQeU0wnJjL4G
> pcNKQ7/4j2opEn//bBqofU3u60thdbxb16O3aBcAJTkUDFtNjeX0VNPNb56/5HQ=
> =uc5x
> -END PGP SIGNATURE-
> 
> -- 
> coreboot mailing list: coreboot@coreboot.org
> https://www.coreboot.org/mailman/listinfo/coreboot


-- 
Merlin Büge 

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

Re: [coreboot] SMBIOS table enablement in coreboot

[David Hendricks via coreboot]

Hi Mayuri,

On Sun, Jan 15, 2017 at 5:40 PM, Mayuri Tendulkar <
mayuri.tendul...@aricent.com> wrote:

> Hi David
>
>
>
> Yes, below are settings for our system. As we are using Intel Baytrail,
> does this SMBIOS manufacturer shd be Intel?
>

That's up to you. Mainboard manufacturer, along with product name, serial
number, and version, are strings which are expected to be assigned by the
vendor. You may set these in your mainboard's Kconfig file. The Macbook 2.1
port shows an example of how to do this:
https://review.coreboot.org/cgit/coreboot.git/tree/src/mainboard/apple/macbook21/Kconfig#n32
.

Other SMBIOS tables such as memory info is generated automatically by
coreboot. For example, the type 4 table should have details about your
processor manufacturer (Intel) as well as information which implies
Baytrail (CPU family, model, and stepping).


>
>
> CONFIG_MAINBOARD_SMBIOS_MANUFACTURER="x"
>
> # CONFIG_SMBIOS_PROVIDED_BY_MOBO is not set
>
> CONFIG_GENERATE_SMBIOS_TABLES=y
>
> CONFIG_MAINBOARD_SMBIOS_PRODUCT_NAME=""
>
>
>
> Regards
>
> Mayuri
>
>
>
> *From:* David Hendricks [mailto:dhend...@google.com]
> *Sent:* 14 January 2017 08:19
> *To:* Mayuri Tendulkar 
> *Cc:* coreboot 
> *Subject:* Re: [coreboot] SMBIOS table enablement in coreboot
>
>
>
> Hi Mayuri,
>
> Do you have GENERATE_SMBIOS_TABLES enabled in your config?
>
>
>
> On Fri, Jan 13, 2017 at 12:56 AM, Mayuri Tendulkar <
> mayuri.tendul...@aricent.com> wrote:
>
> Hi
>
> We are using coreboot for our board based on Intel Baytrail 3845.
>
>
>
> When we use *dmidecode –t *to get DDR details, we get empty. It means
> data is missing in SMBIOS.
>
>
>
> Are there any settings in coreboot to enable this?
>
>
>
> Regards
>
> Mayuri
>
> "DISCLAIMER: This message is proprietary to Aricent and is intended solely
> for the use of the individual to whom it is addressed. It may contain
> privileged or confidential information and should not be circulated or used
> for any purpose other than for what it is intended. If you have received
> this message in error, please notify the originator immediately. If you are
> not the intended recipient, you are notified that you are strictly
> prohibited from using, copying, altering, or disclosing the contents of
> this message. Aricent accepts no responsibility for loss or damage arising
> from the use of the information transmitted by this email including damage
> from virus."
>
>
> --
> coreboot mailing list: coreboot@coreboot.org
> https://www.coreboot.org/mailman/listinfo/coreboot
>
>
>
>
>
> --
>
> David Hendricks (dhendrix)
> Systems Software Engineer, Google Inc.
> "DISCLAIMER: This message is proprietary to Aricent and is intended solely
> for the use of the individual to whom it is addressed. It may contain
> privileged or confidential information and should not be circulated or used
> for any purpose other than for what it is intended. If you have received
> this message in error, please notify the originator immediately. If you are
> not the intended recipient, you are notified that you are strictly
> prohibited from using, copying, altering, or disclosing the contents of
> this message. Aricent accepts no responsibility for loss or damage arising
> from the use of the information transmitted by this email including damage
> from virus."
>



-- 
David Hendricks (dhendrix)
Systems Software Engineer, Google Inc.
-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Fund a TALOS Secure Workstation as coreboot build system

[Timothy Pearson]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 01/17/2017 11:24 AM, Martin Roth wrote:
> Hi Everyone,
>   I suspect that everyone has already heard that unfortunately, the
> funding for Raptor Engineering's Talos workstation project was not
> successful, so I wanted to make a final post to wrap this up.  Between
> 12 people, we had raised enough to buy the full system and a
> processor, and I'd like to once again thank everyone who committed
> money to helping the project.
> 
> If you haven't read Timothy's final post, I thought it was fairly
> relevant, although I suspect that many of the people in the coreboot
> community already know many of his points.
> https://www.crowdsupply.com/raptor-computing-systems/talos-secure-workstation/updates/the-state-of-owner-controlled-computing-as-talos-winds-down
> 
> Also in the final update, Timothy mentions some of the future projects
> that Raptor is planning to work on, including developing an open BMC
> board for the Asus KGPE-D16 board.  If anyone would like to help fund
> that, or transfer any of the money that they were going to use to
> support the Talos project, I'll match contributions with the money I
> was going to put towards Talos.  He also mentions that he's going to
> keep working on open-power solutions, so I'm definitely looking
> forward to seeing what happens with that.

Regarding the BMC work, we're looking to enable a fully libre BMC on the
KGPE-D16.  This is a complex process involving significant reverse
engineering efforts, writing new kernel drivers for the BMC, etc.  With
the BMC enabled, proper fan control can be established on the KGPE-D16,
in addition to remote console access and of course remote power on /
power off / reset functionality.

If this work can be funded, Raptor would chip in a matching amount to
lower the costs to the community; essentially we're looking to fund half
of the work internally but cannot justify the full cost of the work as
the sole sponsor.  Every little bit helps, so even if you can only chip
in $100 please consider doing so.

I strongly encourage the community to assist in this effort; until
OpenPOWER systems come down in price or RISC-V improves in performance
(likely over a decade or more), the KGPE-D16 represents the maximum
performance hardware available to those requiring a fully libre,
blob-free firmware and kernel stack.  Enabling a libre BMC option on
these boards will make it easier for the organizations that rely on this
hardware to manage their systems, helping them spend less time on
routine maintainance and more time on their mission and/or further libre
software development.

Thanks!

- -- 
Timothy Pearson
Raptor Engineering
+1 (415) 727-8645 (direct line)
+1 (512) 690-0200 (switchboard)
https://www.raptorengineering.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJYfn1uAAoJEK+E3vEXDOFbTV4H+QHqUiszRRI7kp5Qd0p/uI7G
tOyL32CzMrUqekDj+A/V1gC5lYtQbjN6WzcMrBFQ9lvJrQy/GxFoRn0cHaZtteya
MmqugPSGotjARM2quWCkbIdhNGgyzKWr+BHwpImH9SyiJ0nozl4RDGDfqhqdPI3+
7nt4TAc54Kq9yhUlP9XLpYq6Gi67sYt0qgVXyNhekiT4a7HrG+0aLtu8mzOVMktc
/oIqnhHlZQnX6LDvNkKJkifanrjL5NXigEEB/iwaFW56Pm9avs07pQeU0wnJjL4G
pcNKQ7/4j2opEn//bBqofU3u60thdbxb16O3aBcAJTkUDFtNjeX0VNPNb56/5HQ=
=uc5x
-END PGP SIGNATURE-

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

Re: [coreboot] Fund a TALOS Secure Workstation as coreboot build system

[ron minnich]

The Talos was a noble effort. One way or another, we're going to get where
we need to go.
-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Fund a TALOS Secure Workstation as coreboot build system

[Martin Roth]

Hi Everyone,
  I suspect that everyone has already heard that unfortunately, the
funding for Raptor Engineering's Talos workstation project was not
successful, so I wanted to make a final post to wrap this up.  Between
12 people, we had raised enough to buy the full system and a
processor, and I'd like to once again thank everyone who committed
money to helping the project.

If you haven't read Timothy's final post, I thought it was fairly
relevant, although I suspect that many of the people in the coreboot
community already know many of his points.
https://www.crowdsupply.com/raptor-computing-systems/talos-secure-workstation/updates/the-state-of-owner-controlled-computing-as-talos-winds-down

Also in the final update, Timothy mentions some of the future projects
that Raptor is planning to work on, including developing an open BMC
board for the Asus KGPE-D16 board.  If anyone would like to help fund
that, or transfer any of the money that they were going to use to
support the Talos project, I'll match contributions with the money I
was going to put towards Talos.  He also mentions that he's going to
keep working on open-power solutions, so I'm definitely looking
forward to seeing what happens with that.

Martin

On Mon, Dec 5, 2016 at 10:48 AM, Martin Roth  wrote:
> Update:
> I've added coreboot's commitment to purchase a board and a processor
> to the crowdsupply site.
>
> Board: 3700
> Processor: 1240
>
> We've got $6,200 committed from 11 contributors.  If things work out,
> the rest of the money will be used for the additional components
> needed, and an upgraded processor.
>
> Thanks to everyone who committed to supporting the purchase.
>
> Martin
>
>
> On Thu, Nov 10, 2016 at 10:36 AM, Martin Roth  wrote:
>> Update:
>>   We've got $4400 promised, with 7 contributors.
>>
>> On Mon, Nov 7, 2016 at 2:22 PM, Martin Roth  wrote:
>>>
>>> Update:
>>>   After the weekend, we're up to $3700 with 5 contributors.
>>>
>>> Martin
>>>
>>> On Sun, Nov 6, 2016 at 1:01 PM, David Hendricks
>>>  wrote:



 On Fri, Nov 4, 2016 at 9:36 AM, Martin Roth  wrote:
>
> Is getting a Talos workstation as a build server something that people
> are interested in contributing money for?


 Yes, this needs to happen.

>
> So far, we've got $2500 pledged from two contributors out of the $7500
> needed to get a server.


 I'll match up to $2000 worth of small/moderate pledges ($250 or less). So
 if 10 people pledge $200 I'll chip in $2000 to bring us to $6500.
>>>
>>>
>>

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

Re: [coreboot] [Resend] Tapping into the core (33C3)

[ron minnich]

I'm putting my time into riscv nowadays. The breaking point for me with ARM
was their move to UEFI a few years back for 64 bit.

And remember, as open as ARM is now, that can end any time. It's still a
licensed architecture. There was a time when x86 implementations were
everywhere, in the way that ARM is today. You can see how that went.

I like Power but they've always had the problem that they're hot and
expensive and power hungry, and while that's fine in their target
environment it's not where I want to be.

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

Re: [coreboot] [Resend] Tapping into the core (33C3)

[Maxim Goryachy]

Sorry, I forgot to attach slides.

On 16.01.2017 18:41, Denis 'GNUtoo' Carikli wrote:

Hello Denis.

Thank you for interest to our talk.

Hi,

I saw your presentation "Tapping into the core"[1] that you gave at the
last CCC.

As I understand from the slides DCI can be activated trough:
- The flash descriptor
- UEFI
- The P2SB register

Are skylake platform safe if:
- DCI is disabled in the flash descriptor.
- DCI is not activated by the boot firmware(UEFI or coreboot).
- DCI is not activated troug the P2SB register.

All the above require either code execution on the machine or to open
the machine with a screwdriver and reprogram the flash with an external
flash programmer.

If DCI is enabled in the flash descriptor, then the following attacks
can benefit from an enabled-by-default DCI:
- Malicious USB devices trying to take over the computer.
- Evil maid attacks when trying to bypass the TPM. This might or might
  not work depending on how the TPM application inside the Management
  engine works.

If I understand correctly, when DCI is disabled in the flash
descriptor, such attacks are not possible and the computer is safe.

Unfortunately no, DCI can be activated through P2SB device at any
time.  We checked it on Skylake and Kabylake.



Since skylake computer can be secured, the feature would become an
enormous advantage: Coreboot developers might be able to use that
feature to make debugging and replacing intel blobs faster and easier.
Having more information on the protocol or free software and open
source tools would help. This might also be useful for debugging the
Linux kernel or other hardware related projects.

It might also be possible to run coreboot on laptops with bootguard:
Some programable[1] USB3 device controller exist, if a tiny enough USB
key can be made, it might be possible to bypass bootguard this way.
Users doing that would then be able to use coreboot on more recent
computers.

I think it is possible. I'm using DCI for BIOS research.



Some questions:
- Can the debug port be used as an usb device controller?

Sorry? I don't understand the question.


- What is the relationship between DCI and the Management Engine?
  Can the Management Engine be controlled trough DCI?

I think it is two different device into PCH. They have some
shared register, but We haven't research it yet entirely .


- Do you have more documentation on the protocol? Is it possible to
  have the slides?

We are planning to write a paper about protocol and driver for
support DCI.



By the way, coreboot and libreboot have several utilities related to
the flash descriptor:
- ifdtool[3]
- ich9gen[4]

PS: Sorry for the inconvenience, due to bad exim configuration which
will hopefully be fixed now, I've to resend the mail.

References:
---
[1]https://media.ccc.de/v/33c3-8069-tapping_into_the_core
[2]http://www.cypress.com/products/ez-usb-fx3-superspeed-usb-30-peripheral-controller
[3]utils/ifdtool in coreboot sources.
[4]resources/utilities/ich9deblob in libreboot sources.

Denis.




-- 
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.

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


** CID 1368527:(UNINIT)
/src/arch/riscv/mcall.c: 81 in mcall_set_timer()
/src/arch/riscv/mcall.c: 84 in mcall_set_timer()



*** CID 1368527:(UNINIT)
/src/arch/riscv/mcall.c: 81 in mcall_set_timer()
75  die("mcall_shutdown is currently not implemented");
76  return 0;
77 }
78 
79 uintptr_t mcall_set_timer(uint64_t when)
80 {
>>> CID 1368527:(UNINIT)
>>> Using uninitialized value "sp".
81  uint64_t *timecmp = HLS()->timecmp;
82 
83  if (mcalldebug)
84  printk(BIOS_SPEW,
85 "hart %d: HLS %p: mcall timecmp@%p to 0x%llx\n",
86 HLS()->hart_id, HLS(), timecmp, when);
/src/arch/riscv/mcall.c: 84 in mcall_set_timer()
78 
79 uintptr_t mcall_set_timer(uint64_t when)
80 {
81  uint64_t *timecmp = HLS()->timecmp;
82 
83  if (mcalldebug)
>>> CID 1368527:(UNINIT)
>>> Using uninitialized value "sp".
84  printk(BIOS_SPEW,
85 "hart %d: HLS %p: mcall timecmp@%p to 0x%llx\n",
86 HLS()->hart_id, HLS(), timecmp, when);
87  *timecmp = when;
88  clear_csr(mip, MIP_STIP);
89  set_csr(mie, MIP_MTIP);



To view the defects in Coverity Scan visit, 
https://u2389337.ct.sendgrid.net/wf/click?upn=08onrYu34A-2BWcWUl-2F-2BfV0V05UPxvVjWch-2Bd2MGckcRbLuoVetFLSjdonCi1EjfHRqWGQvojmmkYaBE-2BPJiTQvQ-3D-3D_q4bX76XMySz3BXBlWr5fXXJ4cvAsgEXEqC7dBPM7O5apw23LnV6Q-2BIdJFNUYMBJMRkFTYuOZfnAFtq6mwp-2FG-2BeMKUotgTw-2FwdKkZEshw9xTgI0HBO9rl3vFdJP2eYxeHs3D8jSwY-2BvroyqvCeAlGcbaIK-2BPJZ-2FIh3rn3jFDFic5GAYFJCOXYbokfEKVwGuYm6oKI82U7Z8ED2vAk8mezSOqk2mYTa0QpXrAOzGzeA1w-3D

To manage Coverity Scan email notifications for "coreboot@coreboot.org", click 
https://u2389337.ct.sendgrid.net/wf/click?upn=08onrYu34A-2BWcWUl-2F-2BfV0V05UPxvVjWch-2Bd2MGckcRbVDbis712qZDP-2FA8y06Nq4e-2BpBzwOa5gzBZa9dWpDbzfofODnVj1enK2UkK0-2BgCCqyeem8IVKvTxSaOFkteZFcnohwvb2rnYNjswGryEWCURnUk6WHU42sbOmtOjD-2Bx5c-3D_q4bX76XMySz3BXBlWr5fXXJ4cvAsgEXEqC7dBPM7O5apw23LnV6Q-2BIdJFNUYMBJMqMO9VjyywIXdVJol-2FQfK3JWH4yMfFPLPo5g680DgqvHykOVGqafPnmpIhEcnkSc4cnrrn6GdDzAD-2BZtpjCJaMnXLQt0KZJEFcrmhMeRw7Vpo3VOlwAbs1TAoc1i9VeXXZtUEgtpNFDxINBlAK12lqSCFqEJKFfqr33aN8bF-2BiSg-3D


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

Re: [coreboot] [Resend] Tapping into the core (33C3)

[Maxim Goryachy]

On 16.01.2017 18:41, Denis 'GNUtoo' Carikli wrote:

Hello Denis.

Thank you for interest to our talk.

Hi,

I saw your presentation "Tapping into the core"[1] that you gave at the
last CCC.

As I understand from the slides DCI can be activated trough:
- The flash descriptor
- UEFI
- The P2SB register

Are skylake platform safe if:
- DCI is disabled in the flash descriptor.
- DCI is not activated by the boot firmware(UEFI or coreboot).
- DCI is not activated troug the P2SB register.

All the above require either code execution on the machine or to open
the machine with a screwdriver and reprogram the flash with an external
flash programmer.

If DCI is enabled in the flash descriptor, then the following attacks
can benefit from an enabled-by-default DCI:
- Malicious USB devices trying to take over the computer.
- Evil maid attacks when trying to bypass the TPM. This might or might
  not work depending on how the TPM application inside the Management
  engine works.

If I understand correctly, when DCI is disabled in the flash
descriptor, such attacks are not possible and the computer is safe.

Unfortunately no, DCI can be activated through P2SB device at any
time.  We checked it on Skylake and Kabylake.




Since skylake computer can be secured, the feature would become an
enormous advantage: Coreboot developers might be able to use that
feature to make debugging and replacing intel blobs faster and easier.
Having more information on the protocol or free software and open
source tools would help. This might also be useful for debugging the
Linux kernel or other hardware related projects.

It might also be possible to run coreboot on laptops with bootguard:
Some programable[1] USB3 device controller exist, if a tiny enough USB
key can be made, it might be possible to bypass bootguard this way.
Users doing that would then be able to use coreboot on more recent
computers.

I think it is possible. I'm using DCI for BIOS research.




Some questions:
- Can the debug port be used as an usb device controller?

Sorry? I don't understand the question.



- What is the relationship between DCI and the Management Engine?
  Can the Management Engine be controlled trough DCI?

I think it is two different device into PCH. They have some
shared register, but We haven't research it yet entirely .



- Do you have more documentation on the protocol? Is it possible to
  have the slides?

We are planning to write a paper about protocol and driver for
support DCI.




By the way, coreboot and libreboot have several utilities related to
the flash descriptor:
- ifdtool[3]
- ich9gen[4]

PS: Sorry for the inconvenience, due to bad exim configuration which
will hopefully be fixed now, I've to resend the mail.

References:
---
[1]https://media.ccc.de/v/33c3-8069-tapping_into_the_core
[2]http://www.cypress.com/products/ez-usb-fx3-superspeed-usb-30-peripheral-controller
[3]utils/ifdtool in coreboot sources.
[4]resources/utilities/ich9deblob in libreboot sources.

Denis.



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