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

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

[Youness Alaoui]

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

First, here's a timeline of the coreboot work explained here :
https://puri.sm/coreboot/timeline/
That timeline mentions for example that the original port was made by
coreboot developers (which seems to be a huge scandal for some reason)
after Purism donated 4 laptops for that work.
You can also read my blog posts on what exactly I have done (in great
detail) in order to bring coreboot to the Librem (from the "I'm a total
n00b" to the "I'm still a n00b but slightly less") :
https://puri.sm/posts/diving-back-into-coreboot-development/
https://puri.sm/posts/librem-13-coreboot-report-january-12-2017/
https://puri.sm/posts/librem-13-coreboot-report-february-3rd-2017/
https://puri.sm/posts/librem-13-coreboot-report-february-25th-2017/
https://puri.sm/posts/preventing-interference-from-the-old-bios-while-flashing-coreboot/
There's also a pretty big article about NVMe issues that I'm (currently)
fixing, which is half-written and which I'd be happy to send you the link
to once it's published.

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

You can also see my actual contributions to coreboot (and one unmerged to
SeaBIOS) here : https://review.coreboot.org/#/q/owner:%22Alaoui%22
I have also contributed in the past couple of weeks to flashrom by
reviewing and commenting in Nico Huber's branch which adds Skylake support
to flashrom : https://review.coreboot.org/#/q/topic:intel_chipset_support

Now that was the coreboot work that was done, here is the ME work that was
done :
While the me_cleaner was tested and verified to work on the Librem (see
here:
https://puri.sm/posts/neutralizing-intel-management-engine-on-librem-laptops/),
the actual work of me_cleaner was done by someone else, but the testing and
verification was still done by us, I think that counts for something. Also
note that an advantage of the librems here is that they come unfused which
is what allows me_cleaner to work on them (see
https://puri.sm/learn/intel-me/). Any laptop with the boot guard fuse
enabled will shut down immediatly if the ME is cleaned with me_cleaner.

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, but I do
want to give credit to Igor Skochinsky for his help (which saved me
weeks/months of work) as he shared his notes of his ME reverse engineering
efforts (memory layouts, RAPI structures and address->function_name

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

[ron minnich]

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

>
>
> Name one thing that they have done themselves?
>
>
Until you've done a port of a new board and taken it all the way through
manufacturing test and verification, interfacing with folks at the vendor,
and dealing with all the nasty stuff that comes up, I don't think you can
fully appreciate just how much work that is. The code is in many ways the
least part.

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

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

[Trammell Hudson]

On Mon, May 01, 2017 at 10:44:45PM +, ron minnich wrote:
> On Mon, May 1, 2017 at 1:17 PM Rene Shuster 
> > 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.

I've spoken with the puri.sm team about their coreboot plans and, beyond
just my delight that they are working on using the Heads bootloader, I'm
really pleased that they've committed to adding hardware features like a
discrete TPM, supporting coreboot, testing with the ME cleaner scripts,
and really significantly, ensuring that Bootguard can be implemented in
a way that preserves user freedom while also protecting against many
classes of physical attacks on the system.

-- 
Trammell

-- 
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 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
-- 
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 Mon, May 1, 2017 at 2:54 PM Raphael Jacquot  wrote:

>
>
> what kind of performance can be expected from RiscV ?
>
>
Performance is not the issue. The issue is when it will be ready, and in a
laptop you like, and the answer is "not for a while".

Further, while the RISCV instruction set and architecture are open source,
that really doesn't imply that  things such as SMM can't be implemented on
them. RISC-V M mode will allow such things in fact. I failed to convince
the RISCV community that M-mode code should be part of the kernel, in the
hopes of making it impossible to have something like SMM. I failed.

Don't assume, just because the instruction set is open source, that all the
problems go away. They don't. System vendors can still do a lot.
-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

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

[Raphael Jacquot]

On 05/01/2017 11:44 PM, taii...@gmx.com wrote:

Once my opteron systems are no good anymore my next computer purchases
will be POWER and ARM for sure, I refuse to buy insecure intel/new amd
garbage.

POWER is reasonably priced for what you get, it simply isn't meant for
the entry level server market for 10K you're getting comparable power
(and better security) to an intel/amd system.


Tim:
Can you play games on POWER with the VM emulation layer you guys were
talking about with TALOS?

What do you think about the desktop/server ARM boards such as the MP30
from Gigabyte?



what kind of performance can be expected from RiscV ?

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

[coreboot] PCI-e hot plug on KGPE-D16 [SR-5690]

[taii...@gmx.com]

I checked the SR-5690 datasheet and I noticed it supports PCI-e hotplug, 
I was wondering if anyone has done this and if so how I can do it?


I want to be able to hard reset cards don't play nice with VFIO and end 
up non-responsive and requiring a system reboot to be assigned again 
(nvidia of course)



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

Once my opteron systems are no good anymore my next computer purchases 
will be POWER and ARM for sure, I refuse to buy insecure intel/new amd 
garbage.


POWER is reasonably priced for what you get, it simply isn't meant for 
the entry level server market for 10K you're getting comparable power 
(and better security) to an intel/amd system.



Tim:
Can you play games on POWER with the VM emulation layer you guys were 
talking about with TALOS?


What do you think about the desktop/server ARM boards such as the MP30 
from Gigabyte?


--
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 Mon, May 1, 2017 at 1:43 PM Timothy Pearson <
tpear...@raptorengineering.com> wrote:

>
>
> As an unofficial poll, if POWER server hardware were ever to come down
> in price to more reasonable levels, would you consider switching given
> the vulnerabilities in Intel hardware?
>


In many places I think the answer would be yes.  Sadly, in a lot of places
the answer would still be "sure, what version of windows does this 'POWER'
thing run?"

I only wish I were joking.

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

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

[Timothy Pearson]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 05/01/2017 03:32 PM, Trammell Hudson wrote:
> On Mon, May 01, 2017 at 05:13:10PM +0100, Sam Kuper wrote:
>> Has anyone here got a link describing or including the fix, either
>> directly from Intel, or from an OEM?
> 
> Intel just posted one:
> 
> https://security-center.intel.com/advisory.aspx?intelid=INTEL-SA-00075&languageid=en-fr
> 

So it's confirmed then.  Our decision to avoid ME-enabled systems even
at higher cost was just validated...

As an unofficial poll, if POWER server hardware were ever to come down
in price to more reasonable levels, would you consider switching given
the vulnerabilities in Intel hardware?  Similarly, on the consumer side
would you consider switching to ARM or is x86 gaming /  too important?

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

iQEcBAEBAgAGBQJZB52tAAoJEK+E3vEXDOFb0U8H/i5Pgufe0aymGqa0xl2b7qTr
yUZkF9Q6LIESqmi09kFvRtfTjh/IbrZraY3CrxzSU31Yt1/7jylQvoecp2LfKDKV
sC2CsQBOkp8Ywq2gqmMigJyCBEo2pKIYp4u1gmHicQsLHEkiv+o+jAJariToLyuO
lcAYOgdAsa9U2rOcxS3lnNjqhIMCXG17UgSRMzq6XFZ4K6NhffFvKnLcJwLynyud
YRbgFg17cW/FneckMZnFXMI/POg6LwA+HwyOcAojBd49WMwulK2W7qfR8MQ8bJOu
9+CkbmyNuKDJs4K7G5N8CKlkjp+5n1Dr/UgH4KOXnwF6OL1W7juGuVZ8cnhXX4M=
=kVlW
-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

[Trammell Hudson]

On Mon, May 01, 2017 at 05:13:10PM +0100, Sam Kuper wrote:
> Has anyone here got a link describing or including the fix, either
> directly from Intel, or from an OEM?

Intel just posted one:

https://security-center.intel.com/advisory.aspx?intelid=INTEL-SA-00075&languageid=en-fr

-- 
Trammell

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

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

[Timothy Pearson]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 05/01/2017 03:15 PM, Rene Shuster wrote:
> Yes Puri.sm has been debunked. Can someone confirm that if you want
> recent hardware without Intel ME then Chromebooks with MrChromebox.tech
> SeaBIOS ( https://mrchromebox.tech/#devices ) is the way to go?
> 

No, that is not the way to go.  Those machines still require the ME (or
a "cleaned" ME) to operate.  The "cleaned" ME is still suspect in my
book due to the fact that we have no idea what mode the ME hardware is
operating in, combined with the fact that Intel would have no
responsibility for any data breaches arising from a "cleaned" ME since
the hardware is operating in a mode it was never intended to operate in
outside of potentially Intel's facilities.

If you want to avoid the ME, you will need to switch to ARM or POWER or
use older x86 hardware from the 2012 era.  The ARM Chromebooks aren't
bad, but I personally find the keyboard and trackpad on the ASUS models
lacking.

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

iQEcBAEBAgAGBQJZB5muAAoJEK+E3vEXDOFbGn8H/Az6let+sT1qB84iU+XZ+Zmu
eGCUCeeG25E99QYf0h4mTkzmlsWijWNKxsqeoD3zDeku67ANBEmG2QO0Lsde21k+
vFqggIR2nh0+552j1xVRZPAkQlJyGkTSeCkyTTq8qb1VmSXJJuhpfTmIAzX9rdSG
xPVI/8elBDPE05P33fOlBEyOs1K3ADKyJRO7MpWvw+I1ppcVqlPz1CwEgDuqAfcq
gQzyzSvLla2o2anGSPS3ht5xXSgnocCsgOSMeKPMUtC9rciH7zVimMng9qbwbMxZ
yenI0Lt11NsTsAAsZd4nDczc8SSOtSt99a0GpWp5w0V7KYp/bdLNH1tILap4cm0=
=uP7X
-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

[Rene Shuster]

Yes Puri.sm has been debunked. Can someone confirm that if you want recent
hardware without Intel ME then Chromebooks with MrChromebox.tech SeaBIOS (
https://mrchromebox.tech/#devices ) is the way to go?

On Mon, May 1, 2017 at 3:34 PM, BogDan Vatra  wrote:

> Ah, I thought it's something inside the CPUs :) It sound so familiar ...
>
> On May 1, 2017 21:38, "mdn"  wrote:
>
>>
>>
>> Le 01/05/2017 19:59, BogDan Vatra a écrit :
>> > Hi Ron,
>> >
>> > If anyone can *prove* that it is/was possible to remotely access *any*
>> > Intel (from 2008+) based computer, it's the beginning of the end of
>> > Intel.
>> >
>> > BogDan.
>> >
>> > P.S. I know what Intel ME and AMD PSP are*, but I have no idea what
>> > WEP is. So, sorry for my stupid question, but what is WEP?
>> https://en.wikipedia.org/wiki/Wired_Equivalent_Privacy
>> > * Well, I only know that they are some buzzwords to sell/describe
>> > nicely some sort of *unproven* backdoors inserted in every consumer
>> > computer, even we, the users, didn't ask for such things. What makes
>> > me suspicious is the lack of any documentation (at least AMD's PSP)...
>> >
>> > 2017-05-01 20:36 GMT+03:00 ron minnich :
>> >>
>> >>
>> >> On Mon, May 1, 2017 at 10:30 AM BogDan Vatra  wrote:
>> >>>
>> >>> Maybe this is a new fools' day joke? May fools' day joke?
>> >>> This looks way too bad to be true ...
>> >>>
>> >>
>> >> Not too bad to be true, not surprising to many of us who have been
>> warning
>> >> of this since, say, 2004. It's just that nobody seemed to care (I'm
>> speaking
>> >> as someone who gave his share of talks to different parts of USG --
>> people
>> >> always acted worrried, nothing changed. I don't expect anything to
>> change
>> >> this time either).
>> >>
>> >> This will probably be another object listen like WEP, only much, much
>> worse.
>> >>
>> >> ron
>> >
>>
>> --
>> Note: veuillez s'il vous plaît utiliser GnuPg pour nos futures
>> conversations
>> https://emailselfdefense.fsf.org/fr/
>> Plus d'info ici:
>> http://www.bibmath.net/crypto/index.php?action=affiche&quoi=moderne/pgp
>>
>> Message envoyé avec GNU Icedove un fork de Thunderbird
>> https://directory.fsf.org/wiki/Icedove
>>
>>
>> --
>> 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
>



-- 
Tech III * AppControl * Endpoint Protection * Server Maintenance
Buncombe County Schools Technology Department Network Group
ComicSans Awareness Campaign 
-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

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

[BogDan Vatra]

Ah, I thought it's something inside the CPUs :) It sound so familiar ...

On May 1, 2017 21:38, "mdn"  wrote:

>
>
> Le 01/05/2017 19:59, BogDan Vatra a écrit :
> > Hi Ron,
> >
> > If anyone can *prove* that it is/was possible to remotely access *any*
> > Intel (from 2008+) based computer, it's the beginning of the end of
> > Intel.
> >
> > BogDan.
> >
> > P.S. I know what Intel ME and AMD PSP are*, but I have no idea what
> > WEP is. So, sorry for my stupid question, but what is WEP?
> https://en.wikipedia.org/wiki/Wired_Equivalent_Privacy
> > * Well, I only know that they are some buzzwords to sell/describe
> > nicely some sort of *unproven* backdoors inserted in every consumer
> > computer, even we, the users, didn't ask for such things. What makes
> > me suspicious is the lack of any documentation (at least AMD's PSP)...
> >
> > 2017-05-01 20:36 GMT+03:00 ron minnich :
> >>
> >>
> >> On Mon, May 1, 2017 at 10:30 AM BogDan Vatra  wrote:
> >>>
> >>> Maybe this is a new fools' day joke? May fools' day joke?
> >>> This looks way too bad to be true ...
> >>>
> >>
> >> Not too bad to be true, not surprising to many of us who have been
> warning
> >> of this since, say, 2004. It's just that nobody seemed to care (I'm
> speaking
> >> as someone who gave his share of talks to different parts of USG --
> people
> >> always acted worrried, nothing changed. I don't expect anything to
> change
> >> this time either).
> >>
> >> This will probably be another object listen like WEP, only much, much
> worse.
> >>
> >> ron
> >
>
> --
> Note: veuillez s'il vous plaît utiliser GnuPg pour nos futures
> conversations
> https://emailselfdefense.fsf.org/fr/
> Plus d'info ici:
> http://www.bibmath.net/crypto/index.php?action=affiche&quoi=moderne/pgp
>
> Message envoyé avec GNU Icedove un fork de Thunderbird
> https://directory.fsf.org/wiki/Icedove
>
>
> --
> 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

[mdn]

Le 01/05/2017 19:59, BogDan Vatra a écrit :
> Hi Ron,
> 
> If anyone can *prove* that it is/was possible to remotely access *any*
> Intel (from 2008+) based computer, it's the beginning of the end of
> Intel.
> 
> BogDan.
> 
> P.S. I know what Intel ME and AMD PSP are*, but I have no idea what
> WEP is. So, sorry for my stupid question, but what is WEP?
https://en.wikipedia.org/wiki/Wired_Equivalent_Privacy
> * Well, I only know that they are some buzzwords to sell/describe
> nicely some sort of *unproven* backdoors inserted in every consumer
> computer, even we, the users, didn't ask for such things. What makes
> me suspicious is the lack of any documentation (at least AMD's PSP)...
> 
> 2017-05-01 20:36 GMT+03:00 ron minnich :
>>
>>
>> On Mon, May 1, 2017 at 10:30 AM BogDan Vatra  wrote:
>>>
>>> Maybe this is a new fools' day joke? May fools' day joke?
>>> This looks way too bad to be true ...
>>>
>>
>> Not too bad to be true, not surprising to many of us who have been warning
>> of this since, say, 2004. It's just that nobody seemed to care (I'm speaking
>> as someone who gave his share of talks to different parts of USG -- people
>> always acted worrried, nothing changed. I don't expect anything to change
>> this time either).
>>
>> This will probably be another object listen like WEP, only much, much worse.
>>
>> ron
> 

-- 
Note: veuillez s'il vous plaît utiliser GnuPg pour nos futures conversations
https://emailselfdefense.fsf.org/fr/
Plus d'info ici:
http://www.bibmath.net/crypto/index.php?action=affiche&quoi=moderne/pgp

Message envoyé avec GNU Icedove un fork de Thunderbird
https://directory.fsf.org/wiki/Icedove



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

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

[BogDan Vatra]

Hi Ron,

If anyone can *prove* that it is/was possible to remotely access *any*
Intel (from 2008+) based computer, it's the beginning of the end of
Intel.

BogDan.

P.S. I know what Intel ME and AMD PSP are*, but I have no idea what
WEP is. So, sorry for my stupid question, but what is WEP?
* Well, I only know that they are some buzzwords to sell/describe
nicely some sort of *unproven* backdoors inserted in every consumer
computer, even we, the users, didn't ask for such things. What makes
me suspicious is the lack of any documentation (at least AMD's PSP)...

2017-05-01 20:36 GMT+03:00 ron minnich :
>
>
> On Mon, May 1, 2017 at 10:30 AM BogDan Vatra  wrote:
>>
>> Maybe this is a new fools' day joke? May fools' day joke?
>> This looks way too bad to be true ...
>>
>
> Not too bad to be true, not surprising to many of us who have been warning
> of this since, say, 2004. It's just that nobody seemed to care (I'm speaking
> as someone who gave his share of talks to different parts of USG -- people
> always acted worrried, nothing changed. I don't expect anything to change
> this time either).
>
> This will probably be another object listen like WEP, only much, much worse.
>
> ron

-- 
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 Mon, May 1, 2017 at 10:30 AM BogDan Vatra  wrote:

> Maybe this is a new fools' day joke? May fools' day joke?
> This looks way too bad to be true ...
>
>
Not too bad to be true, not surprising to many of us who have been warning
of this since, say, 2004. It's just that nobody seemed to care (I'm
speaking as someone who gave his share of talks to different parts of USG
-- people always acted worrried, nothing changed. I don't expect anything
to change this time either).

This will probably be another object listen like WEP, only much, much worse.

ron
-- 
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]

I don't like that article because they shill for purism at the end.

Nothing that purism does is special they're just an overpriced quanta 
laptop that they ran someone elses tools on - they'll never figure out 
how to really disable ME because it can't be done.


I can't understand why they didn't just go with a realistic option that 
can be free such as FM2.


On 05/01/2017 01:13 PM, Timothy Pearson wrote:


-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 05/01/2017 11:16 AM, persmule wrote:

We could just remove or cleanse 
the ME to seal this loophole.

This particular hole, perhaps.  Do we know that "cleansing" the ME
doesn't simply introduce a bigger hole?  Why are the non-removable bits
so heavily obfuscated, anyway?
It is disturbing that intel is so evasive on the ME question, why is it 
present on every platform even consumer ones that lack remote management 
anyway? (besides the DRM stuff no one uses like PAVP)

The ME is bad news from a security perspective, period.  Security
conscious organisations, or those handling high value data, should not
be using Intel products (unless perhaps they have a signed financial
guarantee of data privacy and integrity from Intel...)

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

iQEcBAEBAgAGBQJZB2yrAAoJEK+E3vEXDOFboYUH/i00HzanuLFUOyBJxHt+AFtJ
//nV6o+1h9H7u4RmoH3kQXzIJB8KXhrhkFH0SYIJtrQGswjDMPp0FIpWa/slRwym
NqmaTKKpBivJzfBHTv/UQJ0tp4IddVuhyF8eKvDb6R/hM76RlFGsQ4aZoqq88UD4
ZzizORd1ktmO8Qe2waxYds9Mi8pUj/wGyjOdGFWEbOs0Syw/k1azSsng+8wR72y1
Fn37VMku/GChTM6bjw1zrObUVOm77QO5FD/5OqvC8H+ruyTqSPHwunUUd+z6DGby
Bw0ZKidi0+kqhPiPY76duEhVDkaiy9YinH66p5EQW4B5bJGNn03lhSJERnR5jVc=
=9hlc
-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

[BogDan Vatra]

Maybe this is a new fools' day joke? May fools' day joke?
This looks way too bad to be true ...

BogDan.

P.S. I didn't found any Intel patches from April 25th...

2017-05-01 18:38 GMT+03:00 Shawn :
> https://semiaccurate.com/2017/05/01/remote-security-exploit-2008-intel-platforms/
>
> --
> 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] Recommended memory for coreboot + ASUS KGPE-D16

[taii...@gmx.com]

I use a KGPE-D16 for gaming and it works great, why? why not? libre 
firmware should be the expected default.

I updated the wiki article a few months ago to include recommended CPU's.

C32 - dual channel max
G34 - quad channel + more RAM

The only reason to use C32 is the EE cpu's for routers firewalls etc.

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

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

[Timothy Pearson]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 05/01/2017 11:16 AM, persmule wrote:
> 
> We could just remove or cleanse 
> the ME to seal this loophole.

This particular hole, perhaps.  Do we know that "cleansing" the ME
doesn't simply introduce a bigger hole?  Why are the non-removable bits
so heavily obfuscated, anyway?

The ME is bad news from a security perspective, period.  Security
conscious organisations, or those handling high value data, should not
be using Intel products (unless perhaps they have a signed financial
guarantee of data privacy and integrity from Intel...)

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

iQEcBAEBAgAGBQJZB2yrAAoJEK+E3vEXDOFboYUH/i00HzanuLFUOyBJxHt+AFtJ
//nV6o+1h9H7u4RmoH3kQXzIJB8KXhrhkFH0SYIJtrQGswjDMPp0FIpWa/slRwym
NqmaTKKpBivJzfBHTv/UQJ0tp4IddVuhyF8eKvDb6R/hM76RlFGsQ4aZoqq88UD4
ZzizORd1ktmO8Qe2waxYds9Mi8pUj/wGyjOdGFWEbOs0Syw/k1azSsng+8wR72y1
Fn37VMku/GChTM6bjw1zrObUVOm77QO5FD/5OqvC8H+ruyTqSPHwunUUd+z6DGby
Bw0ZKidi0+kqhPiPY76duEhVDkaiy9YinH66p5EQW4B5bJGNn03lhSJERnR5jVc=
=9hlc
-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]

The ME is the WEP of motherboards.

On Mon, May 1, 2017 at 9:18 AM persmule  wrote:

> We could just remove or cleanse  the
> ME to seal this loophole.
>
>
> 在 2017年05月02日 00:13, Sam Kuper 写道:
>
> On 01/05/2017, Shawn   wrote:
>
> https://semiaccurate.com/2017/05/01/remote-security-exploit-2008-intel-platforms/
>
>
> The piece states, "on April 25, Intel released a firmware fix for this
> unnamed issue. It affects every Intel machine from Nehalem in 2008 to
> Kaby Lake in 2017."
>
> Has anyone here got a link describing or including the fix, either
> directly from Intel, or from an OEM? At the moment, there are no
> advisories listed at https://security-center.intel.com/advisories.aspx
> newer than April 3, so presumably either the piece is false, or else
> the firmware fix was released to OEMs but not publicly.
>
> Discussion elsewhere:
> https://news.ycombinator.com/item?id=14237266
> https://www.reddit.com/r/linux/comments/68ma1a/every_intel_platform_with_amt_ism_and_sbt_from/
>
>
> --
> 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

[persmule]

We could just remove or cleanse 
the ME to seal this loophole.

在 2017年05月02日 00:13, Sam Kuper 写道:
> On 01/05/2017, Shawn  wrote:
>> https://semiaccurate.com/2017/05/01/remote-security-exploit-2008-intel-platforms/
> The piece states, "on April 25, Intel released a firmware fix for this
> unnamed issue. It affects every Intel machine from Nehalem in 2008 to
> Kaby Lake in 2017."
>
> Has anyone here got a link describing or including the fix, either
> directly from Intel, or from an OEM? At the moment, there are no
> advisories listed at https://security-center.intel.com/advisories.aspx
> newer than April 3, so presumably either the piece is false, or else
> the firmware fix was released to OEMs but not publicly.
>
> Discussion elsewhere:
>
> https://news.ycombinator.com/item?id=14237266
>
> https://www.reddit.com/r/linux/comments/68ma1a/every_intel_platform_with_amt_ism_and_sbt_from/
>

-- 
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 01/05/2017, Shawn  wrote:
> https://semiaccurate.com/2017/05/01/remote-security-exploit-2008-intel-platforms/

The piece states, "on April 25, Intel released a firmware fix for this
unnamed issue. It affects every Intel machine from Nehalem in 2008 to
Kaby Lake in 2017."

Has anyone here got a link describing or including the fix, either
directly from Intel, or from an OEM? At the moment, there are no
advisories listed at https://security-center.intel.com/advisories.aspx
newer than April 3, so presumably either the piece is false, or else
the firmware fix was released to OEMs but not publicly.

Discussion elsewhere:

https://news.ycombinator.com/item?id=14237266

https://www.reddit.com/r/linux/comments/68ma1a/every_intel_platform_with_amt_ism_and_sbt_from/

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

how can this be? Intel has promised me for 15 years now that this would
never be an issue! There just has to be some mistake.

Oh, right, now I remember. The ME is the mistake.

ron

On Mon, May 1, 2017 at 8:39 AM Shawn  wrote:

>
> https://semiaccurate.com/2017/05/01/remote-security-exploit-2008-intel-platforms/
>
> --
> 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] Remote security exploit in all 2008+ Intel platforms

[Shawn]

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

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

Re: [coreboot] Recommended memory for coreboot + ASUS KGPE-D16

[Daniel Kulesz via coreboot]

Hi BogDan,

> Run *dmidecode* and search for "Interleaved Data Depth" to check if
> the ram is running in quadchnnel mode you (check
> https://unix.stackexchange.com/questions/215206/detect-number-of-ram-channels
> for more info on this matter). In your case you should have two
> "Interleaved Data Depth: 4"

Unfortunately, it seems like coreboot does not supply this in dmidecode (I X'd 
out the serial numbers):

Handle 0x0006, DMI type 16, 23 bytes
Physical Memory Array
Location: System Board Or Motherboard
Use: System Memory
Error Correction Type: Single-bit ECC
Maximum Capacity: 256 GB
Error Information Handle: Not Provided
Number Of Devices: 16

Handle 0x0007, DMI type 17, 40 bytes
Memory Device
Array Handle: 0x0006
Error Information Handle: Not Provided
Total Width: 72 bits
Data Width: 64 bits
Size: 8192 MB
Form Factor: DIMM
Set: None
Locator: NODE 0 DIMM_A1
Bank Locator: Not Specified
Type: DDR3
Type Detail: Synchronous Registered (Buffered)
Speed: 667 MHz
Manufacturer: Samsung
Serial Number: 
Asset Tag: Not Specified
Part Number: M393B1K70DH0-YK0  
Rank: 2
Configured Clock Speed: 667 MHz
Minimum Voltage: 1.35 V
Maximum Voltage: 1.5 V
Configured Voltage: 1.35 V

Cheers, Daniel

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

Re: [coreboot] Recommended memory for coreboot + ASUS KGPE-D16

[BogDan Vatra]

Hi Daniel,

Run *dmidecode* and search for "Interleaved Data Depth" to check if
the ram is running in quadchnnel mode you (check
https://unix.stackexchange.com/questions/215206/detect-number-of-ram-channels
for more info on this matter). In your case you should have two
"Interleaved Data Depth: 4"

BogDan.

2017-05-01 16:34 GMT+03:00 Daniel Kulesz :
> Hi Bogdan,
>
> I am running my KGPE-D16 with 2x6276 and 16 of these 8GB Samsung RDIMMs:
>
> M393B1K70DH0-YK0
>
> They work fine in coreboot. If you want to run them at 1600MHz, you need to 
> raise the voltage to 1.5V even if the vendor bios clocks them at 1600MHz with 
> 1.35V. They work fine in this setting as well, although this is out-of-spec 
> according to Timothy Pearson. I have no idea how to check if they run in 
> quadchannel but appreciate any hints. You can find more info on this thread:
>
> https://mail.coreboot.org/pipermail/coreboot/2017-February/083151.html
>
> Please be aware that power consumption in idle on the KGPE-D16 is still a 
> major issue with coreboot (~150W with coreboot while ~80W with vendor bios in 
> dual-cpu config):
>
> https://mail.coreboot.org/pipermail/coreboot/2017-February/083195.html
>
> Also, if running the board populated with DIMMs in all slots the best bootup 
> time for coreboot I could get was around 30s:
>
> https://mail.coreboot.org/pipermail/coreboot/2017-March/083595.html
>
> On the contrary, with just 2 UDIMMs, it booted up almost instantly. Please 
> consider this as well when making the decision.
>
> Yet, I am happy to welcome more KGPE-D16 users and share experience.
>
> Cheers, Daniel

-- 
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 
0a4a4f7ae4188bccf4147196f08620453ef0633c

The following tests failed:
BOOT_FAILURE

Commits since last successful test:
0a4a4f7 mb/*/mainboard.c: Get rid of SPI AFC register

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


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

Re: [coreboot] Recommended memory for coreboot + ASUS KGPE-D16

[Daniel Kulesz via coreboot]

Hi Bogdan,

I am running my KGPE-D16 with 2x6276 and 16 of these 8GB Samsung RDIMMs:

M393B1K70DH0-YK0

They work fine in coreboot. If you want to run them at 1600MHz, you need to 
raise the voltage to 1.5V even if the vendor bios clocks them at 1600MHz with 
1.35V. They work fine in this setting as well, although this is out-of-spec 
according to Timothy Pearson. I have no idea how to check if they run in 
quadchannel but appreciate any hints. You can find more info on this thread:

https://mail.coreboot.org/pipermail/coreboot/2017-February/083151.html

Please be aware that power consumption in idle on the KGPE-D16 is still a major 
issue with coreboot (~150W with coreboot while ~80W with vendor bios in 
dual-cpu config):

https://mail.coreboot.org/pipermail/coreboot/2017-February/083195.html

Also, if running the board populated with DIMMs in all slots the best bootup 
time for coreboot I could get was around 30s:

https://mail.coreboot.org/pipermail/coreboot/2017-March/083595.html

On the contrary, with just 2 UDIMMs, it booted up almost instantly. Please 
consider this as well when making the decision. 

Yet, I am happy to welcome more KGPE-D16 users and share experience.

Cheers, Daniel

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

Re: [coreboot] Recommended memory for coreboot + ASUS KGPE-D16

[PeerCorps Trust Fund]

Hi BogDan,

Your build is going to be really nice :). My comment was simply a generalized 
curiosity about how the Opterons stacked up against each other. Also as far as 
I can tell, the G34 motherboards seem to be somewhat easier to source.

On 05/01/2017 03:42 PM, BogDan Vatra wrote:

Hi,

Well, as I said I already bought the motherboard and the CPUs and now
is too late for me to consider other configs.
IMHO it will be nice to have a wiki entry with coreboot friendly
(full?) configs.
Regarding the CPU power, I hope that my yocto/qt builds will be faster
on 2 x 16 Core 6276  than my current intel machine (i7-4770) and most
probably 32 core will do better than 12 cores at 3.5GHz.

Cheers,
BogDan.

2017-05-01 12:23 GMT+03:00 PeerCorps Trust Fund :

Hi,

Apart from features such as greater memory bandwidth, more cores, and more
CPUS in an MP configuration (2/4), what are the advantages of the G34 vs C32
sockets? The C32s have CPUs with TDPs as low as 35w and more cores with
higher clocks in a dual CPU configuration, i.e. the 4340 has 6 cores with a
base clock of 3.5GHz. Two of these in configuration and you have 12 cores at
3.5 GHz. By comparison the highest clocked G34 is the 6308 at 3.5 GHz but
with four cores, this in a two CPU configuration you get 8 instead of 12
cores at 3.5GHz. Is there a substantial difference in performance between
these CPUs in practice (core and clocks being equal)?

Michael


On 05/01/2017 10:21 AM, BogDan Vatra wrote:


Hi Zoran,

Is not for gaming only :), it's *also* for gaming. I play games once
per week and then I want my games to run ok.
I'll usually using it for programming.
Regarding why use coreboot instead of (AMI) BIOS, well, I think the
question is why to use (AMI) BIOS when I can use coreboot ;-).
I also want to *try* to help coreboot folks by testing coreboot and
who knows maybe with patches.

BogDan.

2017-05-01 9:22 GMT+03:00 Zoran Stojsavljevic
:


Hello Bogdan,

One question for you: why you are using specifically Coreboot as
boot-loader, instead of (AMI) BIOS?

The question is because you are using desktop with AMD CPU for gaming. No
specific needs for Coreboot, which is mainly for embedded applications.

Any specific reason why you are using Coreboot instead of full fledged
AMI
BIOS?

Thank you,
Zoran

On Sun, Apr 30, 2017 at 2:05 PM, BogDan Vatra  wrote:



Hi,

I'd like to build desktop/workstation for my personal use (lots of
compilations + of course gaming on linux)
I bought 2 x 6276 CPUs and a KGPE-D16, eprom programmer, etc. now I'm
looking to buy some RAM.
My goal is to have a quad channel 64Gb and because I looking for a
desktop/workstation I think the best choice will be ECC UDIMMs and not
RDIMMs.
Will coreboot support 8 x 8Gb DDR3 UDIMMs 1600Mhz? If yes, there are
any recommended brands/product series?
If not, then what is the best option for achieving my goal?

Thanks!

Yours,
BogDan.

--
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] Recommended memory for coreboot + ASUS KGPE-D16

[BogDan Vatra]

Hi,

Well, as I said I already bought the motherboard and the CPUs and now
is too late for me to consider other configs.
IMHO it will be nice to have a wiki entry with coreboot friendly
(full?) configs.
Regarding the CPU power, I hope that my yocto/qt builds will be faster
on 2 x 16 Core 6276  than my current intel machine (i7-4770) and most
probably 32 core will do better than 12 cores at 3.5GHz.

Cheers,
BogDan.

2017-05-01 12:23 GMT+03:00 PeerCorps Trust Fund :
> Hi,
>
> Apart from features such as greater memory bandwidth, more cores, and more
> CPUS in an MP configuration (2/4), what are the advantages of the G34 vs C32
> sockets? The C32s have CPUs with TDPs as low as 35w and more cores with
> higher clocks in a dual CPU configuration, i.e. the 4340 has 6 cores with a
> base clock of 3.5GHz. Two of these in configuration and you have 12 cores at
> 3.5 GHz. By comparison the highest clocked G34 is the 6308 at 3.5 GHz but
> with four cores, this in a two CPU configuration you get 8 instead of 12
> cores at 3.5GHz. Is there a substantial difference in performance between
> these CPUs in practice (core and clocks being equal)?
>
> Michael
>
>
> On 05/01/2017 10:21 AM, BogDan Vatra wrote:
>>
>> Hi Zoran,
>>
>> Is not for gaming only :), it's *also* for gaming. I play games once
>> per week and then I want my games to run ok.
>> I'll usually using it for programming.
>> Regarding why use coreboot instead of (AMI) BIOS, well, I think the
>> question is why to use (AMI) BIOS when I can use coreboot ;-).
>> I also want to *try* to help coreboot folks by testing coreboot and
>> who knows maybe with patches.
>>
>> BogDan.
>>
>> 2017-05-01 9:22 GMT+03:00 Zoran Stojsavljevic
>> :
>>>
>>> Hello Bogdan,
>>>
>>> One question for you: why you are using specifically Coreboot as
>>> boot-loader, instead of (AMI) BIOS?
>>>
>>> The question is because you are using desktop with AMD CPU for gaming. No
>>> specific needs for Coreboot, which is mainly for embedded applications.
>>>
>>> Any specific reason why you are using Coreboot instead of full fledged
>>> AMI
>>> BIOS?
>>>
>>> Thank you,
>>> Zoran
>>>
>>> On Sun, Apr 30, 2017 at 2:05 PM, BogDan Vatra  wrote:


 Hi,

 I'd like to build desktop/workstation for my personal use (lots of
 compilations + of course gaming on linux)
 I bought 2 x 6276 CPUs and a KGPE-D16, eprom programmer, etc. now I'm
 looking to buy some RAM.
 My goal is to have a quad channel 64Gb and because I looking for a
 desktop/workstation I think the best choice will be ECC UDIMMs and not
 RDIMMs.
 Will coreboot support 8 x 8Gb DDR3 UDIMMs 1600Mhz? If yes, there are
 any recommended brands/product series?
 If not, then what is the best option for achieving my goal?

 Thanks!

 Yours,
 BogDan.

 --
 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] Recommended memory for coreboot + ASUS KGPE-D16

[Zoran Stojsavljevic]

Thank you for the clarification... And help provided to Coreboot community.
:-)

Zoran

On Mon, May 1, 2017 at 9:21 AM, BogDan Vatra  wrote:

> Hi Zoran,
>
> Is not for gaming only :), it's *also* for gaming. I play games once
> per week and then I want my games to run ok.
> I'll usually using it for programming.
> Regarding why use coreboot instead of (AMI) BIOS, well, I think the
> question is why to use (AMI) BIOS when I can use coreboot ;-).
> I also want to *try* to help coreboot folks by testing coreboot and
> who knows maybe with patches.
>
> BogDan.
>
> 2017-05-01 9:22 GMT+03:00 Zoran Stojsavljevic <
> zoran.stojsavlje...@gmail.com>:
> > Hello Bogdan,
> >
> > One question for you: why you are using specifically Coreboot as
> > boot-loader, instead of (AMI) BIOS?
> >
> > The question is because you are using desktop with AMD CPU for gaming. No
> > specific needs for Coreboot, which is mainly for embedded applications.
> >
> > Any specific reason why you are using Coreboot instead of full fledged
> AMI
> > BIOS?
> >
> > Thank you,
> > Zoran
> >
> > On Sun, Apr 30, 2017 at 2:05 PM, BogDan Vatra  wrote:
> >>
> >> Hi,
> >>
> >> I'd like to build desktop/workstation for my personal use (lots of
> >> compilations + of course gaming on linux)
> >> I bought 2 x 6276 CPUs and a KGPE-D16, eprom programmer, etc. now I'm
> >> looking to buy some RAM.
> >> My goal is to have a quad channel 64Gb and because I looking for a
> >> desktop/workstation I think the best choice will be ECC UDIMMs and not
> >> RDIMMs.
> >> Will coreboot support 8 x 8Gb DDR3 UDIMMs 1600Mhz? If yes, there are
> >> any recommended brands/product series?
> >> If not, then what is the best option for achieving my goal?
> >>
> >> Thanks!
> >>
> >> Yours,
> >> BogDan.
> >>
> >> --
> >> 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] Recommended memory for coreboot + ASUS KGPE-D16

[PeerCorps Trust Fund]

Hi,

Apart from features such as greater memory bandwidth, more cores, and more CPUS 
in an MP configuration (2/4), what are the advantages of the G34 vs C32 
sockets? The C32s have CPUs with TDPs as low as 35w and more cores with higher 
clocks in a dual CPU configuration, i.e. the 4340 has 6 cores with a base clock 
of 3.5GHz. Two of these in configuration and you have 12 cores at 3.5 GHz. By 
comparison the highest clocked G34 is the 6308 at 3.5 GHz but with four cores, 
this in a two CPU configuration you get 8 instead of 12 cores at 3.5GHz. Is 
there a substantial difference in performance between these CPUs in practice 
(core and clocks being equal)?

Michael

On 05/01/2017 10:21 AM, BogDan Vatra wrote:

Hi Zoran,

Is not for gaming only :), it's *also* for gaming. I play games once
per week and then I want my games to run ok.
I'll usually using it for programming.
Regarding why use coreboot instead of (AMI) BIOS, well, I think the
question is why to use (AMI) BIOS when I can use coreboot ;-).
I also want to *try* to help coreboot folks by testing coreboot and
who knows maybe with patches.

BogDan.

2017-05-01 9:22 GMT+03:00 Zoran Stojsavljevic :

Hello Bogdan,

One question for you: why you are using specifically Coreboot as
boot-loader, instead of (AMI) BIOS?

The question is because you are using desktop with AMD CPU for gaming. No
specific needs for Coreboot, which is mainly for embedded applications.

Any specific reason why you are using Coreboot instead of full fledged AMI
BIOS?

Thank you,
Zoran

On Sun, Apr 30, 2017 at 2:05 PM, BogDan Vatra  wrote:


Hi,

I'd like to build desktop/workstation for my personal use (lots of
compilations + of course gaming on linux)
I bought 2 x 6276 CPUs and a KGPE-D16, eprom programmer, etc. now I'm
looking to buy some RAM.
My goal is to have a quad channel 64Gb and because I looking for a
desktop/workstation I think the best choice will be ECC UDIMMs and not
RDIMMs.
Will coreboot support 8 x 8Gb DDR3 UDIMMs 1600Mhz? If yes, there are
any recommended brands/product series?
If not, then what is the best option for achieving my goal?

Thanks!

Yours,
BogDan.

--
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] Recommended memory for coreboot + ASUS KGPE-D16

[BogDan Vatra]

Hi Zoran,

Is not for gaming only :), it's *also* for gaming. I play games once
per week and then I want my games to run ok.
I'll usually using it for programming.
Regarding why use coreboot instead of (AMI) BIOS, well, I think the
question is why to use (AMI) BIOS when I can use coreboot ;-).
I also want to *try* to help coreboot folks by testing coreboot and
who knows maybe with patches.

BogDan.

2017-05-01 9:22 GMT+03:00 Zoran Stojsavljevic :
> Hello Bogdan,
>
> One question for you: why you are using specifically Coreboot as
> boot-loader, instead of (AMI) BIOS?
>
> The question is because you are using desktop with AMD CPU for gaming. No
> specific needs for Coreboot, which is mainly for embedded applications.
>
> Any specific reason why you are using Coreboot instead of full fledged AMI
> BIOS?
>
> Thank you,
> Zoran
>
> On Sun, Apr 30, 2017 at 2:05 PM, BogDan Vatra  wrote:
>>
>> Hi,
>>
>> I'd like to build desktop/workstation for my personal use (lots of
>> compilations + of course gaming on linux)
>> I bought 2 x 6276 CPUs and a KGPE-D16, eprom programmer, etc. now I'm
>> looking to buy some RAM.
>> My goal is to have a quad channel 64Gb and because I looking for a
>> desktop/workstation I think the best choice will be ECC UDIMMs and not
>> RDIMMs.
>> Will coreboot support 8 x 8Gb DDR3 UDIMMs 1600Mhz? If yes, there are
>> any recommended brands/product series?
>> If not, then what is the best option for achieving my goal?
>>
>> Thanks!
>>
>> Yours,
>> BogDan.
>>
>> --
>> 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