Re: [coreboot] Anyone got an opinion, technical or otherwise, on this?

[Zoran Stojsavljevic]

I also read in details some of the emails from the previous threads. I
downloaded SCSDiscovery tool:
https://downloadcenter.intel.com/download/26691/Intel-SCS-System-Discovery-Utility
and ran it on my notebook.

I got as response a bunch of nonsense info (basically, it failed
everywhere) :

C:\Program Files\Intel_SCS_Discovery_11.1.0.75>type
SCSDiscoverylog_DESKTOP-@@@_2017-05-03-06-15-18.Log
2017-05-03 06:15:19:(INFO) : ACU Configurator , Category: HandleOutPut:
Starting log 2017-05-03 06:15:19
2017-05-03 06:15:19:(INFO) : SCSDiscovery, Category: -SystemDiscovery-:
DESKTOP-@@@: Discovering the System information...
2017-05-03 06:15:33:(WARN) : SCSDiscovery.exe, Category: System Discovery:
System Discovery finished with warnings: System Discovery failed to get
data from some of the interfaces on this system.  (0xc00027ff). Failed to
get data from the OS Registry interface.   (0xc0002840). Failed to read the
registry value (Primary DNS suffix).  (0xc0001f52). Failed to open the
registry Key (SYSTEM\CurrentControlSet\Services\LMS).  The system cannot
find the file specified. (0xc0001f50). The registry key not
found.(SYSTEM\CurrentControlSet\Services\LMS)  (0xc0001f58). Failed to get
data from the GetDNSLookupName interface.   (0xc0002842). Failed to
retrieve the host onboard IPv4 IP (please check the LAN settings).
(0xc0002836).
2017-05-03 06:15:33:(INFO) : SCSDiscovery, Category: Exit: ***Exit
with code 32 - Intel(R) AMT operation completed with warnings: Details:
Success. System Discovery finished with warnings: System Discovery failed
to get data from some of the interfaces on this system.  (0xc00027ff).
Failed to get data from the OS Registry interface.   (0xc0002840). Failed
to read the registry value (Primary DNS suffix).  (0xc0001f52). Failed to
open the registry Key (SYSTEM\CurrentControlSet\Services\LMS).  The system
cannot find the file specified. (0xc0001f50). The registry key not
found.(SYSTEM\CurrentControlSet\Services\LMS)  (0xc0001f58). Failed to get
data from the GetDNSLookupName interface.   (0xc0002842). Failed to
retrieve the host onboard IPv4 IP (please check the LAN settings).
(0xc0002836).

C:\Program Files\Intel_SCS_Discovery_11.1.0.75>

Not surprised, since I do NOT have AMT capabilities (I have 1.5MB ME series
9).

Zoran

On Tue, May 2, 2017 at 11:56 PM, Vadim Bendebury 
wrote:

> I wonder if anyone ever completely trusted AMT - maybe some naive
> excessive cool-aid drinkers :)
>
> -vb
>
> On Tue, May 2, 2017 at 11:27 AM, ron minnich  wrote:
>
>> I wonder if anyone is going to completely trust AMT after this problem.
>> It goes back almost 10 years. So for all those users who had it on for
>> almost 10 years, the question becomes, how much did we lose and when did we
>> lose it? The answer? We'll never know. Are we still owned? We don't know.
>> Can we actually trust any reflash procedure, if the ME is owned while we
>> try to reflash? Well, I hope so, but how can we know?
>>
>> It's a worrisome situation.
>>
>> ron
>>
>> On Tue, May 2, 2017 at 11:01 AM Patrick Georgi via coreboot <
>> coreboot@coreboot.org> wrote:
>>
>>> Semi-Accurate only claims accuracy according to what's on the box. The
>>> official documentation of the issue can be found at
>>> https://security-center.intel.com/advisory.aspx?intelid=INTEL-SA-00075
>>>
>>> It looks like a software bug in the AMT firmware. Therefore:
>>> - No AMT (eg on non-business consumer devices) -> no (bug | exploit).
>>> - Present but disabled AMT (eg. on business devices without AMT
>>> enrollment) -> no (bug | exploit). (although there's apparently a way
>>> to enable AMT unsupervised under some circumstances with some level of
>>> local access. or something.)
>>>
>>>
>>> Patrick
>>>
>>> 2017-05-02 19:31 GMT+02:00 John Lewis :
>>> > https://semiaccurate.com/2017/05/01/remote-security-exploit-
>>> 2008-intel-platforms/
>>> >
>>> > The article says "all" Intel boards since 2008 are locally vulnerable
>>> > (ME exploit), but the Intel advisory (linked within) says consumer
>>> > devices are okay.
>>> >
>>> > What the article says about even low end devices still having the
>>> > features albeit turned "off" rings true to me, based on stuff I've read
>>> > here and elsewhere. What's your take (bearing in mind the technical
>>> > details aren't available, yet)?
>>> >
>>> >
>>> > --
>>> > coreboot mailing list: coreboot@coreboot.org
>>> > https://mail.coreboot.org/mailman/listinfo/coreboot
>>>
>>>
>>>
>>> --
>>> Google Germany GmbH, ABC-Str. 19, 20354 Hamburg
>>> Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft:
>>> Hamburg
>>> Geschäftsführer: Matthew Scott Sucherman, Paul Terence Manicle
>>>
>>> --
>>> coreboot mailing list: coreboot@coreboot.org
>>> https://mail.coreboot.org/mailman/listinfo/coreboot
>>
>>
>> --
>> coreboot mailing list: coreboot@coreboot.org
>> https://mail.coreboot.org/mailman/listinfo/coreboot
>>
>
>
> --
> coreboot 

Re: [coreboot] Remote security exploit in all 2008+ Intel platforms

[Youness Alaoui]

Looks like I failed at answering Taiidan without generating a flame war.
Sorry if anyone got offended, that wasn't my aim.
To answer the various questions that were thrown, here's what I think :

Taiidan, you ask why Purism doesn't just create laptops using FX2 or ARM or
whatever... Well, because that's not what most people want, out there. If
you want a RYF laptop using old or underpowered hardware or non-x86
architectures, that's a problem that has already been solved, there are
various resellers of such devices. The idea here is not to "Use what we can
find to make RYF" but rather "Bring RYF to the hardware that people want".
What I believe Purism is trying to do is to create a modern laptop for
*everyone* with the extra value of security and privacy, and in the process
make FLOSS appealing to mainstream instead of letting it be confined in a
niche. I think everyone will be better off with tools to protect their
privacy/security without asking them to throw the baby with the bathwater
by requiring them to use hardware that does not interest them (otherwise,
if old or non-x86 architectures were so appealing, you would have seen that
become the norm rather than the exception).

As for the ME and DMCA, I believe this exempts us from it :
https://www.ftc.gov/news-events/blogs/techftc/2016/10/
dmca-security-research-exemption-consumer-devices
...Considering that the research is done in order to protect users. Also,
an exploit to run a custom firmware on the ME isn't something that gives
access to copyrighted material, so I'm not sure why the DMCA would even
apply here.
As for your argument of an arms race and Intel "fixing" the weaknesses
allowing us to neutralize the ME, I don't see how that would matter either,
because you will be able to control the image on your own machine
*today*... if you neutralize it today, even if Intel wanted to take over
the ME in your system to patch it, well... they can't get in, because you
already neutralized it. And if they want to change it for future models,
they will have to change it in the silicon of future models, which is way
out in the future.

To answer Sam:
Thanks for the kudos! The reason C is used is because I didn't think to use
anything else. I love C and that's what I like to use. But beyond that
answer, there are many reasons for using C. It's because this is an
assembly to C translation, if the code is 'prone to errors' it's only
because the original ME binary instructions had those errors in it, which
is good for us, since we're looking for exploits. Also, the long term goal
is to be able to generate binary-compatible images (imagine, you compile
the ME source and get a binary with the same hash as the one intel is
providing, so you can be 100% sure that it's the same code that you're
auditing as the one that is running). If we were to use any high level
language, we would never have enough fine control over the resulting binary
to be able to get binary compatibility.

Zoran: Thanks for your comments and encouragement! :) the talks with Intel
as far as I know are not for open-sourcing the ME (which is a much harder
thing to ask for), but rather for a ME-less design. Basically, for Intel to
release a chip with the ME core simply disabled and with no firmware
running on it. That's a much easier goal to attain, but then again, we're
talking about Intel, so it's still a difficult goal to attain, but Todd has
been bugging them for a while and is constantly in talks with Intel to try
and achieve that.


to answer Nico's other post:
I'm quite surprised and disappointed by your answer. You have every right
to say that you are disappointed or distrusting Purism due to past actions,
but I find it harsh for you to be repeatedly saying "fraud" and "scammed"
when that is not the case at all. I think Ron has responded quite well to
that and said exactly what I wanted to say, there is a difference between
being naive and underestimating the task, vs actively "trying to scam
people". If they were scamming people, they wouldn't have shipped any
product and they wouldn't have reimbursed those who changed their mind or
were unsatisfied with what they got, and actually, I wouldn't even have
been contracted in the first place.

Attributing to malice what was the result of honest mistakes, while you
know how complex this is both on the software and hardware side, is why
your tone was disappointing. Careless name-calling leads to people getting
hurt and flame wars and all that.

I would just like to answer you with a few more items that I believe are
true (I may be mistaken myself as I'm still quite new to Purism):

   - Everything that was promised is still on the roadmap and a
   work-in-progress (as far as I know), so it's more of an issue of missing
   the deadlines/estimates rather than not wanting to deliver anything that
   was promised. The "Vision" of the company in an initial crowdfunding
   campaign does not mean "this is an immediately attainable milestone".
   - The 

Re: [coreboot] Anyone got an opinion, technical or otherwise, on this?

[Vadim Bendebury]

I wonder if anyone ever completely trusted AMT - maybe some naive excessive
cool-aid drinkers :)

-vb

On Tue, May 2, 2017 at 11:27 AM, ron minnich  wrote:

> I wonder if anyone is going to completely trust AMT after this problem. It
> goes back almost 10 years. So for all those users who had it on for almost
> 10 years, the question becomes, how much did we lose and when did we lose
> it? The answer? We'll never know. Are we still owned? We don't know. Can we
> actually trust any reflash procedure, if the ME is owned while we try to
> reflash? Well, I hope so, but how can we know?
>
> It's a worrisome situation.
>
> ron
>
> On Tue, May 2, 2017 at 11:01 AM Patrick Georgi via coreboot <
> coreboot@coreboot.org> wrote:
>
>> Semi-Accurate only claims accuracy according to what's on the box. The
>> official documentation of the issue can be found at
>> https://security-center.intel.com/advisory.aspx?intelid=INTEL-SA-00075
>>
>> It looks like a software bug in the AMT firmware. Therefore:
>> - No AMT (eg on non-business consumer devices) -> no (bug | exploit).
>> - Present but disabled AMT (eg. on business devices without AMT
>> enrollment) -> no (bug | exploit). (although there's apparently a way
>> to enable AMT unsupervised under some circumstances with some level of
>> local access. or something.)
>>
>>
>> Patrick
>>
>> 2017-05-02 19:31 GMT+02:00 John Lewis :
>> > https://semiaccurate.com/2017/05/01/remote-security-exploit-
>> 2008-intel-platforms/
>> >
>> > The article says "all" Intel boards since 2008 are locally vulnerable
>> > (ME exploit), but the Intel advisory (linked within) says consumer
>> > devices are okay.
>> >
>> > What the article says about even low end devices still having the
>> > features albeit turned "off" rings true to me, based on stuff I've read
>> > here and elsewhere. What's your take (bearing in mind the technical
>> > details aren't available, yet)?
>> >
>> >
>> > --
>> > coreboot mailing list: coreboot@coreboot.org
>> > https://mail.coreboot.org/mailman/listinfo/coreboot
>>
>>
>>
>> --
>> Google Germany GmbH, ABC-Str. 19, 20354 Hamburg
>> Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft:
>> Hamburg
>> Geschäftsführer: Matthew Scott Sucherman, Paul Terence Manicle
>>
>> --
>> coreboot mailing list: coreboot@coreboot.org
>> https://mail.coreboot.org/mailman/listinfo/coreboot
>
>
> --
> coreboot mailing list: coreboot@coreboot.org
> https://mail.coreboot.org/mailman/listinfo/coreboot
>
-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] BIOSBits ...

[Timothy Pearson]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 05/02/2017 04:04 PM, Kashif Ali wrote:
> Hi all,
> 
> We modified coreboot for the OpenCellular project and looking to have
> test suite for BIOS, specially during manufacturing. The OpenCellular is
> based on Intel Atom E3845, similar to minnowboard. I came across
> biosbits.org , have anyone tried this?. Is this the
> right approach or there is better approach to this?. 

We offer an integrated coreboot test solution here:

https://www.raptorengineering.com/content/REACTS/intro.html

We can scale this from single board test through production scale QA if
desired; it is capable of testing internal branches and/or the public
code as needed.

Additionally, the REACTS is currently used on two public instances to
provide up to date test results on a number of coreboot supported
boards; one of these instances is currently hosted by Raptor Engineering
and the other is hosted by the coreboot project itself.

If you have any further questions please feel free to contact me directly.

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/

iQEcBAEBAgAGBQJZCPmSAAoJEK+E3vEXDOFb0kQH/R0Aq7NiSwe0xq3AjXzu9XUK
nUqNP/4ag31GwRkayUlG/dibAbJ6j2nwiZxCGCsiW05sZtRghm1VwClsDDG9Z09A
GXJXoDHn9s8DqDpLu1ulVyuwTzxbUiZsEc6sAjdg3tuvEylVny6HKyg5zkiJyRUQ
/s+qV9Bg0JrGStCjJ7P5GfBkbxFwZJkD30xn2AoEOcd4VSEXZLRJFhTGNiVpwzAC
ej/+Mx5veteh0sFFgNDDUS9rZVGl+w0Pjli+E7SHP3qeJyl2OFttAk2hMX7jfnNY
NXJyXMiWayVYRveuaB7ihCcJTLmqpn6OXA4HrPLcu9klOiekZ4Cn8/UHMRlisq0=
=W7B7
-END PGP SIGNATURE-

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

Re: [coreboot] Remote security exploit in all 2008+ Intel platforms

[ron minnich]

On Tue, May 2, 2017 at 2:08 PM Zoran Stojsavljevic <
zoran.stojsavlje...@gmail.com> wrote:

> OK. I will rephrase my statement. :-)
>
> Ron, you can believe in Snow White, in Santa Clause, in INTEL to be
> good/reasonable and to engage with Google, or Purism in ME Open Source
> effort.
>
> Good Luck with that, you'll certainly need it!
>

You have to remember, in 1995, I asked intel for docs to write an ethernet
driver for Linux. I got 19 badly copied, uninformative, useless pages, and
lots of verbal abuse for even asking for such a thing -- "Just run windows"
I was told.

Now who would have expected, from that time to now, that Intel would have
become such a supporter of Linux?

Change can happen and it pays to keep asking. You never know when or how it
will happen, but if you don't ask, you miss the chance to hear a good
answer.

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

Re: [coreboot] Remote security exploit in all 2008+ Intel platforms

[Zoran Stojsavljevic]

OK. I will rephrase my statement. :-)

Ron, you can believe in Snow White, in Santa Clause, in INTEL to be
good/reasonable and to engage with Google, or Purism in ME Open Source
effort.

Good Luck with that, you'll certainly need it!

I'll rather believe in Igor Skochinsky, Dmitry Sklyarov and Black Hat
hackers. True believer in AMD and ARM, if they start significantly engaging
(taking significant share) in Server space, then INTEL will suddenly
convert to good guy (and start contributing MUCH MORE to Open Source)...
Claiming God, Church, Bible and similar type of work (enlightenment). Way
to go! ;-)

Zoran

On Tue, May 2, 2017 at 10:41 PM, ron minnich  wrote:

>
>
> On Tue, May 2, 2017 at 11:38 AM Zoran Stojsavljevic <
> zoran.stojsavlje...@gmail.com> wrote:
>
>> > But I also saw Todd working very hard to try *to engage Intel*, over a
>> period of years.
>>
>> Whoever might be believing in this statement: Good luck to you all.
>> You'll need it, really! :-(
>>
>>>
>>>
>
> I can't understand your comment.
>
-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

[coreboot] BIOSBits ...

[Kashif Ali]

Hi all,

We modified coreboot for the OpenCellular project and looking to have test
suite for BIOS, specially during manufacturing. The OpenCellular is based
on Intel Atom E3845, similar to minnowboard. I came across biosbits.org,
have anyone tried this?. Is this the right approach or there is better
approach to this?.

Thoughts?

Thanks,
+Kashif
-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Remote security exploit in all 2008+ Intel platforms

[ron minnich]

On Tue, May 2, 2017 at 11:38 AM Zoran Stojsavljevic <
zoran.stojsavlje...@gmail.com> wrote:

> > But I also saw Todd working very hard to try *to engage Intel*, over a
> period of years.
>
> Whoever might be believing in this statement: Good luck to you all. You'll
> need it, really! :-(
>
>>
>>

I can't understand your comment.
-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Remote security exploit in all 2008+ Intel platforms

[Zoran Stojsavljevic]

> But I also saw Todd working very hard to try *to engage Intel*, over a
period of years.

Whoever might be believing in this statement: Good luck to you all. You'll
need it, really! :-(

Zoran

On Tue, May 2, 2017 at 7:56 PM, ron minnich  wrote:

>
>
> On Tue, May 2, 2017 at 10:39 AM Nico Huber  wrote:
>
>>
>> Sorry Ron, I didn't write it to offend you.
>>
>
> No problem. It hurt a bit because I respect you so much :-)
>
> I find that people's take on Purism varies depending on whether they have
> personally interacted with Todd or not. Up here in Mountain View we've had
> multiple meetings as we tried to provide guidance to Todd. From that
> experience I've come to believe that Purism, like so many of us when we
> started out, was extremely naive about what was possible, and made claims
> based on their lack of knowledge. But I also saw Todd working very hard to
> try to engage Intel, over a period of years. I saw a sincere effort to
> achieve their goals, coupled with a complete lack of knowledge about how
> much effort it was, which led to them making claims that could not be
> supported.
>
> I hope they are cleaning up their claims.  They made a lot of mistakes
> over the first few years, and were way too optimistic about how all this
> was going to work, which cost them a lot of trust, and that is their fault.
> Adding Youness was a good move, and has got them going in the right
> direction.
>
> If anyone at Purism is listening, could you please take the time to talk
> to people from this group about your web site and the claims you are
> making? From what Nico says, you're still overdoing it. It just makes you
> look bad and you don't need that.
>
> At the same time, we need to be realistic about what's going to be
> possible in x86 universe. And the answer, I'm afraid, is "less and less".
> I'm afraid blobs are a permanent part of the picture on any new x86 design,
> and if you don't like that (I don't) then it's time to find a new
> architecture to work on, as Tim and others are doing.
>
> [Nico, this last part is not about what you said.] I realize feelings are
> strong about these issues, but calling people and projects "corrupt" is
> unacceptable and, in my view anyway, I'd like people who say such things to
> find another project. I watched the Plan 9 mailling list get destroyed by a
> few bad actors and I don't want to see that happen here.
>
> Thanks
>
> ron
>
> --
> coreboot mailing list: coreboot@coreboot.org
> https://mail.coreboot.org/mailman/listinfo/coreboot
>
-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Anyone got an opinion, technical or otherwise, on this?

[ron minnich]

I wonder if anyone is going to completely trust AMT after this problem. It
goes back almost 10 years. So for all those users who had it on for almost
10 years, the question becomes, how much did we lose and when did we lose
it? The answer? We'll never know. Are we still owned? We don't know. Can we
actually trust any reflash procedure, if the ME is owned while we try to
reflash? Well, I hope so, but how can we know?

It's a worrisome situation.

ron

On Tue, May 2, 2017 at 11:01 AM Patrick Georgi via coreboot <
coreboot@coreboot.org> wrote:

> Semi-Accurate only claims accuracy according to what's on the box. The
> official documentation of the issue can be found at
> https://security-center.intel.com/advisory.aspx?intelid=INTEL-SA-00075
>
> It looks like a software bug in the AMT firmware. Therefore:
> - No AMT (eg on non-business consumer devices) -> no (bug | exploit).
> - Present but disabled AMT (eg. on business devices without AMT
> enrollment) -> no (bug | exploit). (although there's apparently a way
> to enable AMT unsupervised under some circumstances with some level of
> local access. or something.)
>
>
> Patrick
>
> 2017-05-02 19:31 GMT+02:00 John Lewis :
> >
> https://semiaccurate.com/2017/05/01/remote-security-exploit-2008-intel-platforms/
> >
> > The article says "all" Intel boards since 2008 are locally vulnerable
> > (ME exploit), but the Intel advisory (linked within) says consumer
> > devices are okay.
> >
> > What the article says about even low end devices still having the
> > features albeit turned "off" rings true to me, based on stuff I've read
> > here and elsewhere. What's your take (bearing in mind the technical
> > details aren't available, yet)?
> >
> >
> > --
> > coreboot mailing list: coreboot@coreboot.org
> > https://mail.coreboot.org/mailman/listinfo/coreboot
>
>
>
> --
> Google Germany GmbH, ABC-Str. 19, 20354 Hamburg
> Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft:
> Hamburg
> Geschäftsführer: Matthew Scott Sucherman, Paul Terence Manicle
>
> --
> coreboot mailing list: coreboot@coreboot.org
> https://mail.coreboot.org/mailman/listinfo/coreboot
-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Anyone got an opinion, technical or otherwise, on this?

[Patrick Georgi via coreboot]

Semi-Accurate only claims accuracy according to what's on the box. The
official documentation of the issue can be found at
https://security-center.intel.com/advisory.aspx?intelid=INTEL-SA-00075

It looks like a software bug in the AMT firmware. Therefore:
- No AMT (eg on non-business consumer devices) -> no (bug | exploit).
- Present but disabled AMT (eg. on business devices without AMT
enrollment) -> no (bug | exploit). (although there's apparently a way
to enable AMT unsupervised under some circumstances with some level of
local access. or something.)


Patrick

2017-05-02 19:31 GMT+02:00 John Lewis :
> https://semiaccurate.com/2017/05/01/remote-security-exploit-2008-intel-platforms/
>
> The article says "all" Intel boards since 2008 are locally vulnerable
> (ME exploit), but the Intel advisory (linked within) says consumer
> devices are okay.
>
> What the article says about even low end devices still having the
> features albeit turned "off" rings true to me, based on stuff I've read
> here and elsewhere. What's your take (bearing in mind the technical
> details aren't available, yet)?
>
>
> --
> coreboot mailing list: coreboot@coreboot.org
> https://mail.coreboot.org/mailman/listinfo/coreboot



-- 
Google Germany GmbH, ABC-Str. 19, 20354 Hamburg
Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft: Hamburg
Geschäftsführer: Matthew Scott Sucherman, Paul Terence Manicle

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

Re: [coreboot] Remote security exploit in all 2008+ Intel platforms

[ron minnich]

On Tue, May 2, 2017 at 10:39 AM Nico Huber  wrote:

>
> Sorry Ron, I didn't write it to offend you.
>

No problem. It hurt a bit because I respect you so much :-)

I find that people's take on Purism varies depending on whether they have
personally interacted with Todd or not. Up here in Mountain View we've had
multiple meetings as we tried to provide guidance to Todd. From that
experience I've come to believe that Purism, like so many of us when we
started out, was extremely naive about what was possible, and made claims
based on their lack of knowledge. But I also saw Todd working very hard to
try to engage Intel, over a period of years. I saw a sincere effort to
achieve their goals, coupled with a complete lack of knowledge about how
much effort it was, which led to them making claims that could not be
supported.

I hope they are cleaning up their claims.  They made a lot of mistakes over
the first few years, and were way too optimistic about how all this was
going to work, which cost them a lot of trust, and that is their fault.
Adding Youness was a good move, and has got them going in the right
direction.

If anyone at Purism is listening, could you please take the time to talk to
people from this group about your web site and the claims you are making?
>From what Nico says, you're still overdoing it. It just makes you look bad
and you don't need that.

At the same time, we need to be realistic about what's going to be possible
in x86 universe. And the answer, I'm afraid, is "less and less". I'm afraid
blobs are a permanent part of the picture on any new x86 design, and if you
don't like that (I don't) then it's time to find a new architecture to work
on, as Tim and others are doing.

[Nico, this last part is not about what you said.] I realize feelings are
strong about these issues, but calling people and projects "corrupt" is
unacceptable and, in my view anyway, I'd like people who say such things to
find another project. I watched the Plan 9 mailling list get destroyed by a
few bad actors and I don't want to see that happen here.

Thanks

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

[coreboot] ASUS KGPE-D16 Automated Test Failure [master]

[Raptor Engineering Automated Coreboot Test Stand]

The ASUS KGPE-D16 fails verification for branch master as of commit 
e70142c9c2e2b7b4fbf8883790df72b6d5536c19

The following tests failed:
BOOT_FAILURE

Commits since last successful test:
e70142c soc/intel/apollolake: Clean up code by using common FAST_SPI module
7146445 soc/intel/skylake: Clean up code by using common FAST_SPI module

See attached log for details

This message was automatically generated from Raptor Engineering's ASUS 
KGPE-D16 test stand
Want to test on your own equipment?  Check out 
https://www.raptorengineering.com/content/REACTS/intro.html

Raptor Engineering also offers coreboot consulting services!  Please visit 
https://www.raptorengineering.com for more information

Please contact Timothy Pearson at Raptor Engineering 
 regarding any issues stemming from this 
notification


1493747141-3-automaster.log.bz2
Description: application/bzip2
-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Remote security exploit in all 2008+ Intel platforms

[Nico Huber]

On 02.05.2017 16:20, ron minnich wrote:
> On Tue, May 2, 2017 at 3:54 AM Nico Huber  wrote:
> 
>>
>>
>> You sound much like their advertisement.
>>
>>
> 
> OK, I'm done here. Have a nice project everyone. When people start making
> statements like this and accusing the project of being corrupt, it's time
> to stop reading a list.

Sorry Ron, I didn't write it to offend you. I just read their product
page before writing that stupid statement above. And that page seemed to
smash again empty promises into my face. That's no excuse for what I
wrote, just trying to explain how it happened.

Please understand that talking about Purism may still reawake bad fee-
lings. At the beginning they sold so much and shipped nothing. And
people believe that they have drawn customers away from vendors who
actually supported free firmware. By that, making people who wanted to
pay for free firmware pay for proprietary firmware instead.

At least this is how I remember the story. Obviously we have a very dif-
ferent view on it. And also how far x86 can be freed from blobs. I still
hope Purism will, in the end, accomplish more than you say is possible.

Nico

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

[coreboot] Anyone got an opinion, technical or otherwise, on this?

[John Lewis]

https://semiaccurate.com/2017/05/01/remote-security-exploit-2008-intel-platforms/

The article says "all" Intel boards since 2008 are locally vulnerable
(ME exploit), but the Intel advisory (linked within) says consumer
devices are okay.

What the article says about even low end devices still having the
features albeit turned "off" rings true to me, based on stuff I've read
here and elsewhere. What's your take (bearing in mind the technical
details aren't available, yet)?


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

Re: [coreboot] Why does src/soc/intel/ exist?

[Marc Jones]

On Tue, May 2, 2017 at 10:30 AM Arthur Heymans  wrote:

> Ok thanks for clarifying.
>
> Aaron Durbin  writes:
>
> > On Tue, May 2, 2017 at 5:24 AM, Arthur Heymans 
> wrote:
> >> Hi
> >>
> >> I am wondering why newer intel code is being pushed to src/soc/intel/*/
> >> instead of the traditional src/{cpu,southbridge,northbridge}/intel ?
> >
> > The era of mix and match ICs is pretty much gone. Even when there are
> > separate chips on a board there's only a single variant which actually
> > works in conjunction with the parts. Similarly to the socket
> > abstraction that closely coupled features to physical sockets it's not
> > really applicable any longer. It'd be forcing one to separate out
> > support where things are actually closely related.
> >
> Ok that explains a lot. Southbridges could often occur with 2-3
> different memory controllers and a similar amount of different CPU.
>
> >>
> >> I know that physically things are now on one chip hence the soc but the
> >> code itself is often very similar to older cpu/southbridge/northbridge
> >> code. A good example is for instance smbus:
> >> https://review.coreboot.org/#/c/19372/ (unify src/soc/intel smbus code)
> >> https://review.coreboot.org/#/c/19258/ (unify src/southbridge/intel
> >> smbus code)
> >> with code that is almost identical so it would be beneficial to have
> >> this code in common for all intel targets, which is somewhat hindered or
> >> unpractical due to this dir separation.
> >
> > How is that unpractical? I think you are assuming a specific directory
> > layout? Regardless of where code resides it's certainly possible to
> > share code. I think what you've pointed out is the timeline when new
> > development cutover to use src/soc for all the parts as the parts
> > really are SoC with a close coupling of implementations. The logic
> > blocks inside the parts are definitely forks of one another just like
> > software so there is re-use at play. With your change and the other
> > one we'd have 2 parallel implementations that could be tested for
> > parity and combined. That said, one needs to be careful in the details
> > for determining where something can be truly common. In the smbus
> > stuff specifically I'm sure there has be no real modification in a
> > very long time, but that isn't true for all blocks.
> >
>
> My main thought was that is a bit sad that efforts to make more code
> common happens in src/soc/intel/ while there is a lot in
> src/southbridge/intel that can be set up with identical code (but maybe
> smbus is indeed the only thing that can cleanly be common without too
> much per platform guarding).
>
> >
> > The newer code is not separated. It's actually combined? Benefit is
> > one stop shopping for a given platform for code to reside instead of
> > laying down multiple directories in various places that doesn't
> > reflect the construction of the systems. That said, with the
> > introduction of the common modules the soc/intel directories will
> > become thinner with selecting the common modules. That reflects more
> > closely how hardware development is being done.
> >
> > Though the soc/ directory layout isn't the only way of making the
> > following work, it certainly helps. For the purposes of porting a
> > board based off of another board of a different platform it makes the
> > code maintenance easier solely based on #include files. There's really
> > not reason to have to #include a/specific/directory/header to make
> > something work. If the abstractions are done correctly one can
> > #include genericpath/header with a conforming API. That allows code
> > reuse and porting to go more smoothly. If you are having to #ifdef
> > CONFIG to figure out the include path in the c files that makes the
> > source ugly and a maintenance burden. This isn't the only the example,
> > but a good one where there's a ton of #ifdef for include paths:
> > src/cpu/x86/smm/smmrelocate.S. That's also ignoring the "common"
> > headers which do or don't expose certain functions that are found in
> > specific places as well. In short, I think the
> > southbridge/cpu/northbridge split in how it's been done in the past
> > actually creates more of a burden. Again, that doesn't mean things
> > can't be fixed by using consistent and namespaced include paths.
> >
>
> Ok thanks for the insight. Some things that were used by different
> IC combinations were indeed a mess with amd in particular (but that is
> probably because a lot of code was not linked)
>
>
>
We are starting to look at this structure for amd. There really isn't a
hard line between the device internally no and find a lot of dependency on
each of the silicon directories. The soc/ is a much better representation
of the devices and the setup. Getting the right level of common code is the
trick.

Marc





> --
> Arthur Heymans
>
> --
> coreboot mailing list: coreboot@coreboot.org
> 

Re: [coreboot] Why does src/soc/intel/ exist?

[Arthur Heymans]

Ok thanks for clarifying.

Aaron Durbin  writes:

> On Tue, May 2, 2017 at 5:24 AM, Arthur Heymans  wrote:
>> Hi
>>
>> I am wondering why newer intel code is being pushed to src/soc/intel/*/
>> instead of the traditional src/{cpu,southbridge,northbridge}/intel ?
>
> The era of mix and match ICs is pretty much gone. Even when there are
> separate chips on a board there's only a single variant which actually
> works in conjunction with the parts. Similarly to the socket
> abstraction that closely coupled features to physical sockets it's not
> really applicable any longer. It'd be forcing one to separate out
> support where things are actually closely related.
>
Ok that explains a lot. Southbridges could often occur with 2-3
different memory controllers and a similar amount of different CPU.

>>
>> I know that physically things are now on one chip hence the soc but the
>> code itself is often very similar to older cpu/southbridge/northbridge
>> code. A good example is for instance smbus:
>> https://review.coreboot.org/#/c/19372/ (unify src/soc/intel smbus code)
>> https://review.coreboot.org/#/c/19258/ (unify src/southbridge/intel
>> smbus code)
>> with code that is almost identical so it would be beneficial to have
>> this code in common for all intel targets, which is somewhat hindered or
>> unpractical due to this dir separation.
>
> How is that unpractical? I think you are assuming a specific directory
> layout? Regardless of where code resides it's certainly possible to
> share code. I think what you've pointed out is the timeline when new
> development cutover to use src/soc for all the parts as the parts
> really are SoC with a close coupling of implementations. The logic
> blocks inside the parts are definitely forks of one another just like
> software so there is re-use at play. With your change and the other
> one we'd have 2 parallel implementations that could be tested for
> parity and combined. That said, one needs to be careful in the details
> for determining where something can be truly common. In the smbus
> stuff specifically I'm sure there has be no real modification in a
> very long time, but that isn't true for all blocks.
>

My main thought was that is a bit sad that efforts to make more code
common happens in src/soc/intel/ while there is a lot in
src/southbridge/intel that can be set up with identical code (but maybe
smbus is indeed the only thing that can cleanly be common without too
much per platform guarding). 

>
> The newer code is not separated. It's actually combined? Benefit is
> one stop shopping for a given platform for code to reside instead of
> laying down multiple directories in various places that doesn't
> reflect the construction of the systems. That said, with the
> introduction of the common modules the soc/intel directories will
> become thinner with selecting the common modules. That reflects more
> closely how hardware development is being done.
>
> Though the soc/ directory layout isn't the only way of making the
> following work, it certainly helps. For the purposes of porting a
> board based off of another board of a different platform it makes the
> code maintenance easier solely based on #include files. There's really
> not reason to have to #include a/specific/directory/header to make
> something work. If the abstractions are done correctly one can
> #include genericpath/header with a conforming API. That allows code
> reuse and porting to go more smoothly. If you are having to #ifdef
> CONFIG to figure out the include path in the c files that makes the
> source ugly and a maintenance burden. This isn't the only the example,
> but a good one where there's a ton of #ifdef for include paths:
> src/cpu/x86/smm/smmrelocate.S. That's also ignoring the "common"
> headers which do or don't expose certain functions that are found in
> specific places as well. In short, I think the
> southbridge/cpu/northbridge split in how it's been done in the past
> actually creates more of a burden. Again, that doesn't mean things
> can't be fixed by using consistent and namespaced include paths.
>

Ok thanks for the insight. Some things that were used by different
IC combinations were indeed a mess with amd in particular (but that is
probably because a lot of code was not linked)


-- 
Arthur Heymans

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

Re: [coreboot] Why does src/soc/intel/ exist?

[Aaron Durbin via coreboot]

On Tue, May 2, 2017 at 5:24 AM, Arthur Heymans  wrote:
> Hi
>
> I am wondering why newer intel code is being pushed to src/soc/intel/*/
> instead of the traditional src/{cpu,southbridge,northbridge}/intel ?

The era of mix and match ICs is pretty much gone. Even when there are
separate chips on a board there's only a single variant which actually
works in conjunction with the parts. Similarly to the socket
abstraction that closely coupled features to physical sockets it's not
really applicable any longer. It'd be forcing one to separate out
support where things are actually closely related.

>
> I know that physically things are now on one chip hence the soc but the
> code itself is often very similar to older cpu/southbridge/northbridge
> code. A good example is for instance smbus:
> https://review.coreboot.org/#/c/19372/ (unify src/soc/intel smbus code)
> https://review.coreboot.org/#/c/19258/ (unify src/southbridge/intel
> smbus code)
> with code that is almost identical so it would be beneficial to have
> this code in common for all intel targets, which is somewhat hindered or
> unpractical due to this dir separation.

How is that unpractical? I think you are assuming a specific directory
layout? Regardless of where code resides it's certainly possible to
share code. I think what you've pointed out is the timeline when new
development cutover to use src/soc for all the parts as the parts
really are SoC with a close coupling of implementations. The logic
blocks inside the parts are definitely forks of one another just like
software so there is re-use at play. With your change and the other
one we'd have 2 parallel implementations that could be tested for
parity and combined. That said, one needs to be careful in the details
for determining where something can be truly common. In the smbus
stuff specifically I'm sure there has be no real modification in a
very long time, but that isn't true for all blocks.

>
> The same could be said about a lot of LPC code, which has parts that are
> very similar across multiple generations, like pirq routing.
>
> Another thing to note is that dir names are often poorly named like amd
> where in src/northbridge/amd memory controller code resides, while in
> src/southbridge the code for both the northbridge and the southbridge
> resides.

I think you are seeing a reflection of how closely coupled certain
support and features are. There isn't always a hard split/separation
into those directory names because one needs to deal with configuring
multiple ip blocks for a feature.

>
> So my question is why does the newer codebase need to be separated like
> this and what is the benefit of doing so?

The newer code is not separated. It's actually combined? Benefit is
one stop shopping for a given platform for code to reside instead of
laying down multiple directories in various places that doesn't
reflect the construction of the systems. That said, with the
introduction of the common modules the soc/intel directories will
become thinner with selecting the common modules. That reflects more
closely how hardware development is being done.

Though the soc/ directory layout isn't the only way of making the
following work, it certainly helps. For the purposes of porting a
board based off of another board of a different platform it makes the
code maintenance easier solely based on #include files. There's really
not reason to have to #include a/specific/directory/header to make
something work. If the abstractions are done correctly one can
#include genericpath/header with a conforming API. That allows code
reuse and porting to go more smoothly. If you are having to #ifdef
CONFIG to figure out the include path in the c files that makes the
source ugly and a maintenance burden. This isn't the only the example,
but a good one where there's a ton of #ifdef for include paths:
src/cpu/x86/smm/smmrelocate.S. That's also ignoring the "common"
headers which do or don't expose certain functions that are found in
specific places as well. In short, I think the
southbridge/cpu/northbridge split in how it's been done in the past
actually creates more of a burden. Again, that doesn't mean things
can't be fixed by using consistent and namespaced include paths.

>
> Kind regards
> 
>
> Arthur Heymans
>
>
> --
> coreboot mailing list: coreboot@coreboot.org
> https://mail.coreboot.org/mailman/listinfo/coreboot

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

Re: [coreboot] Remote security exploit in all 2008+ Intel platforms

[ron minnich]

On Tue, May 2, 2017 at 3:54 AM Nico Huber  wrote:

>
>
> You sound much like their advertisement.
>
>

OK, I'm done here. Have a nice project everyone. When people start making
statements like this and accusing the project of being corrupt, it's time
to stop reading a list.

I'll see you at the meetings, those who come.

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

Re: [coreboot] Remote security exploit in all 2008+ Intel platforms

[Zoran Stojsavljevic]

I would not be so critique oriented to Youness Alaoui, but much more
appreciative. Do not know too much about Purism as company, but if Purism
made some fraud/false promises to its customers, it is another story, which
does NOT have anything to do with Youness and his published work here.

Every Open Source effort to debug/explain INTEL ME and its modules, even in
"C" pseudo code which does NOT compile makes VERY great/positive effort
toward mysteries resolved. At least to me. It reveals more missing puzzles
to the PCH/ME architectural picture, at least.

To me, it means a lot. I do need to know as much of the picture as
possible. You all guess why?! ;-)

I will certainly encourage Youness to continue with his work. Great work
(explaining additional black holes in ME) done!

Please, keep up the good work! :-)

Zoran Stojsavljevic

On Tue, May 2, 2017 at 1:02 PM, Nico Huber  wrote:

> On 02.05.2017 04:52, Youness Alaoui wrote:
> > Ron couldn't be more right when he says that you can't appreciate how
> much
> > work it is to go from a "it works" to a "it's tested/verified and made
> into
> > a *product* for actual users". It took me 6 months of work to finish the
> 4
> > days of work that Duncan Laurie did (I believe it took him 4 days to do
> the
> > initial port, feel free to correct me if I'm mistaken, and yes of
> course, I
> > am totally new to the coreboot world, so a lot/most of that time was
> spent
> > on the learning curve).
>
> Well, I interpret Ron very differently... I think you are at the "it
> works" state. 6 months of coding are the easy part where you don't have
> to convince other entities to use your code. Let's wait until you have
> made it into a shipping product and reflect then. I guess the really
> tricky part comes when you ask your contractor not to license the UEFI
> they usually ship (i.e. don't let your coreboot customers pay for the
> other side).
>
> Nico
>
> --
> coreboot mailing list: coreboot@coreboot.org
> https://mail.coreboot.org/mailman/listinfo/coreboot
>
-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Remote security exploit in all 2008+ Intel platforms

[Nico Huber]

On 02.05.2017 04:52, Youness Alaoui wrote:
> Ron couldn't be more right when he says that you can't appreciate how much
> work it is to go from a "it works" to a "it's tested/verified and made into
> a *product* for actual users". It took me 6 months of work to finish the 4
> days of work that Duncan Laurie did (I believe it took him 4 days to do the
> initial port, feel free to correct me if I'm mistaken, and yes of course, I
> am totally new to the coreboot world, so a lot/most of that time was spent
> on the learning curve).

Well, I interpret Ron very differently... I think you are at the "it
works" state. 6 months of coding are the easy part where you don't have
to convince other entities to use your code. Let's wait until you have
made it into a shipping product and reflect then. I guess the really
tricky part comes when you ask your contractor not to license the UEFI
they usually ship (i.e. don't let your coreboot customers pay for the
other side).

Nico

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

Re: [coreboot] Remote security exploit in all 2008+ Intel platforms

[Nico Huber]

On 02.05.2017 00:44, ron minnich wrote:
> On Mon, May 1, 2017 at 1:17 PM Rene Shuster 
> wrote:
> 
>> Yes Puri.sm has been debunked.
>>
> 
> I disagree. I've seen the systems. From what I can see, Puri.sm has made a
> good faith effort to go as far possible *with modern x86 chipsets* toward
> getting rid of the blobs. They can't get to 100%, but they're trying to get
> as close as possible.

You sound much like their advertisement.

But that's just not true. They haven't made any effort, they just star-
ted it. Even if this effort brings us a machine that ships with coreboot
in the future, you seem to forget all the 1st generation machines that
were promised an open coreboot + open ME firmware. These were a fraud.
People paid for something they didn't get and still nobody is working
on it (at least I don't know about any coreboot effort for the Librem
15 gen1, or any 15 or 11 at all).

I guess things are moving towards the right direction. But denying that
the first Purism customers were scammed won't help Purism's reputation
in the community. (Not to mention that their advertisement still scams
a lot.)

Regarding the started effort: AFAIK, it's not (yet) about shipping with
coreboot. The current port uses a blob that Purism can't license so the
users only get a script to gather blobs and put it together into a blob-
boot that they have to install themselves. And even the effort for the
next gen doesn't come close to the possible for Intel's x86. Reversing
FSP seems pretty easy compared to the ME stuff going on, yet they will
ship a fully blobbed coreboot.

Nico


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

[coreboot] Why does src/soc/intel/ exist?

[Arthur Heymans]

Hi

I am wondering why newer intel code is being pushed to src/soc/intel/*/
instead of the traditional src/{cpu,southbridge,northbridge}/intel ?

I know that physically things are now on one chip hence the soc but the
code itself is often very similar to older cpu/southbridge/northbridge
code. A good example is for instance smbus:
https://review.coreboot.org/#/c/19372/ (unify src/soc/intel smbus code)
https://review.coreboot.org/#/c/19258/ (unify src/southbridge/intel
smbus code)
with code that is almost identical so it would be beneficial to have
this code in common for all intel targets, which is somewhat hindered or
unpractical due to this dir separation.

The same could be said about a lot of LPC code, which has parts that are
very similar across multiple generations, like pirq routing.

Another thing to note is that dir names are often poorly named like amd
where in src/northbridge/amd memory controller code resides, while in
src/southbridge the code for both the northbridge and the southbridge
resides.

So my question is why does the newer codebase need to be separated like
this and what is the benefit of doing so?

Kind regards


Arthur Heymans


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

Re: [coreboot] Remote security exploit in all 2008+ Intel platforms

[Sam Kuper]

On 02/05/2017, Youness Alaoui  wrote:
> For actual ME-related work that wasn't done by someone else, I will point
> you to this file :
> https://github.com/kakaroto/purism-playground/blob/master/me_re/romp.c
> That is a full C re-implementation of the ROMP module (the smallest of the
> two modules that me_cleaner does not remove).
> This is the RAPI header it uses :
> https://github.com/kakaroto/purism-playground/blob/master/me_re/rapi.h
> That code is a C reimplementation with every instruction accounted for. It
> has not been compiled (it serves more as a proof of concept/pseudocode,
> although it should probably compile), and it's not meant to generate a
> binary-compatible file (that could be a long term goal to generate binary
> compatible images from C source with official intel-provided images).
> Note that I have done the entire Assembly->C conversion myself
>
> [...]
>
> Ultimately I hope we can get full unsigned code execution running, and full
> auditable C code equivalent of any binary code that gets executed between
> power-on and the exploit/custom code being executed.

Kudos for this work. It would be great to have auditable code running there.

Forgive my noob question, but: why C instead of a safer language or
language subset (e.g. Coq, Agda, Idris, SPARK, Compcert (if you don't
mind the non-free license), or even Go or Rust), especially given how
small yet fundamental that code is to the system?

Within and outside Coreboot, the desire to use safer techniques than C
programming, and the actual shift to using them, is, thankfully,
starting to happen. See:


Nico Huber's use of SPARK for Coreboot graphics:

- https://firmwaresecurity.com/2016/09/20/coreboot-now-supports-ada/


Trammell Hudson's wish for a formally-verifiable Coreboot payload such
as sel4 or CertiKOS:

- https://mail.coreboot.org/pipermail/coreboot/2016-December/082606.html


Ron Minnich points out the advantage of using Go rather than C for u-root:

- https://mail.coreboot.org/pipermail/coreboot/2017-April/083891.html


Quinn Norton's epigram, "C is good for two things: being beautiful and
creating catastrophic 0days in memory management." (N.B. I'm not sure
about the first thing):

- https://medium.com/message/everything-is-broken-81e5f33a24e1


Reasons why Xen should consider taking langsec seriously:

- http://trevorjim.com/deconstructing-xen-snark/

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

Re: [coreboot] Coreboot on the Supermicro H8SCM-F

[PeerCorps Trust Fund]

Hi!

Thanks for the feedback on this. It is a decent motherboard, but it wasn't for 
anything critical. It just seemed like a nice low barrier (cost wise) entry to 
a desktop. It might be nice however if some of the other Supermicro Opteron 
boards could be made coreboot capable. Supermicro seems to have a lot of boards 
that remain in production for quite some time after other vendors have EOL'd 
theirs.


On 05/02/2017 11:47 AM, taii...@gmx.com wrote:

Hey OP so you know I wouldn't hold your breath on this, getting even serial 
output on this board is being difficult I assume due to the fact that the 
actual serial port connects to the WPCM-450-M BMC chip.

If you want this for some project or whatever I would pay for a professional to 
do it (such as tim)



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

Re: [coreboot] Coreboot on the Supermicro H8SCM-F

[taii...@gmx.com]

Hey OP so you know I wouldn't hold your breath on this, getting even 
serial output on this board is being difficult I assume due to the fact 
that the actual serial port connects to the WPCM-450-M BMC chip.


If you want this for some project or whatever I would pay for a 
professional to do it (such as tim)


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

Re: [coreboot] Remote security exploit in all 2008+ Intel platforms

[taii...@gmx.com]

On 05/01/2017 10:52 PM, Youness Alaoui wrote:


On Mon, May 1, 2017 at 7:22 PM, taii...@gmx.com  wrote:


On 05/01/2017 06:44 PM, ron minnich wrote:

On Mon, May 1, 2017 at 1:17 PM Rene Shuster 

wrote:

Yes Puri.sm has been debunked.

I disagree. I've seen the systems. From what I can see, Puri.sm has made

a
good faith effort to go as far possible *with modern x86 chipsets* toward
getting rid of the blobs. They can't get to 100%, but they're trying to
get
as close as possible.

ron


Name one thing that they have done themselves?

https://www.reddit.com/r/linux/comments/3anjgm/on_the_librem
_laptop_purism_doesnt_believe_in/ (yeah its leah but shes right about the
coreboot community being corrupted)

Everything they "do" is someone elses code, and their "coreboot" has zero
actual init code it is entirely blobbed.

Their marketing is the only thing that is good.


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


Without entering into a flamewar, you're asking "name one thing that they
have done themselves" and I will answer that.
Full disclaimer: I am working for Purism, and I have been a paid contractor
working since last December (part time initially, full time since March) on
bringing coreboot and the ME-disablement effort to the Librem line of
laptops (more precisely Librem 13 v1, and now working on the Librem 13 v2
hardware which is set to be released/shipped next month).
I don't wanna argue this as it never leads anywhere but one more thing 
why haven't you guys set realistic easily attainable goals such as:

FM2 laptop.
KCMA-D8 laptop, with an 35W EE CPU, custom case battery keyboard ETC.
multi-core ARM laptop - see the Gigabyte MP30 for an example of a 
non-mobile, performance ARM system.


Both can easily be brought up to an RYF standard, but as it stands your 
products still don't have even native init - making "coreboot" pointless 
as it is simply a wrapper layer. The only way a new intel/amd laptop is 
going to be "RYF" is if the standard is diluted.


It doesn't matter if you eventually somehow figure out how to run 
unsigned ME code, that is illegal under the DMCA so it can't be sold.


Anything is possible if you throw millions of reverse engineering 
dollars at it, but all that is good for is black hat stuff because the 
moment you release it to the world intel will patch the "security flaw" 
- which brings me back to the realistic goals.


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