Re: [coreboot] Coreboot Purism BIOS is free? open?

[Todd Weaver]

On Sun, 2017-12-24 at 01:30 -0500, Youness Alaoui wrote:
> I think people buying a TALOS 2 and people buying a Librem are two
> very distinct types of people. I very much doubt that someone has
> ever had to decide between buying a Librem and a TALOS.

I think this is correct as well.

> > > > > A good summary is that we want to "bring
> > > > > blob-free to the hardware that people want", rather than
> > > > > "bring
> > > > > blob-free hardware to the people who want it".
> > This is great; and I may quote you on that :)
> 
> Yeah, Todd, you can quote me. I also really liked that when I thought
> of it :p

Funny, it also helps define the different approaches succinctly.

> And thanks for answering Nico's questions and correcting my
> statements. I didn't even know an i.mx8 librem 13/15 had already been
> thought of, that's pretty cool if it's in the plans!

It is early yet, but on the Librem 5 hardware side (not coreboot
related), it has been discussed as the follow-on to phone mobo design.

Todd.

signature.asc
Description: This is a digitally signed message part
-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Coreboot Purism BIOS is free? open?

[Todd Weaver]

On Sat, 2017-12-23 at 23:32 -0500, taii...@gmx.com wrote:
> You will never have that type of leverage, if google can't pull it
> off then no one can.

There are a lot of assumptions you are making.

First off, having leverage doesn't only mean with Intel, it also means
with competitors or alternatives; we are fighting for user freedom and
ethical computing. Having leverage is better than no leverage.

Second, I'm not convinced Google's goals were exactly that, so saying
"If Google can't pull it off then no one can." is a defeatist attitude.
You may as well say "nobody has done it, so nobody can." There are a
lot of avenues to take, and giving up before attempting is of no
interest to me.

> Even the NSA only got HAP, not a CPU without ME all together and the
> US government probably spends hundreds of millions with intel every
> year.

Sure, but that may have been what they asked for. Projecting the NSA's
request to be what you would have asked for is a huge assumption.
"Which makes an 'ass' out of 'u' and 'mption'." :)

> x86-64 will always have ME/PSP and it simply can't be disabled,

It can be disabled, but I suppose you are meaning that it can be re-
enabled again via software update; but we have plans (and will be
releasing) the ability to measure the ME region (via TPM) to flag any
re-enablement attempts. Disable ME, measure it is tampered with, notify
tampering (via coreboot+TPM+Heads).

NOTE: This is not "removal" which is the process of never initializing
the ME, which is the end goal for user freedom. This term is how we
distinguish between the progress being made, as we clearly posted
previously.

> pretending otherwise is doing a disservice to many who look to the
> big shots for advice and pipe dreams like that being spread to the
> masses are the main reason I dislike purism so much.

Our approach is to grow, gain leverage, and influence positive change.
Everything we do is about creating ethical computing; and we will
continue to do so. You are more than welcome to dislike our path or
approach, even though it sounds like we share the same end-goal.


> People will think "well gee why buy an actually-libre-right-now TALOS
> 2 when I can simply wait a few years when the eggheads have cracked
> ME and I can keep getting cheap soul-less computers" as tim said the
> discovery of HAP etc probably set back libre computing a decade.

This is projecting an individual opinion onto others, our users are not
buying Librem laptops over Talos 2, they're drastically different
products, prices, and capabilities.

Todd.

signature.asc
Description: This is a digitally signed message part
-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Coreboot Purism BIOS is free? open?

[Todd Weaver]

On Fri, 2017-12-22 at 22:06 -0500, Youness Alaoui wrote:
> On Tue, Dec 19, 2017 at 3:54 PM, Timothy Pearson
>  wrote:
> > 
> > Thank you for the detailed explanation.  I guess this is an area in
> > which experience matters; it is absolutely unacceptable (and not
> > unexpected) that Intel misled your CEO, but this is sadly not an
> > uncommon tactic in the industry.

Intel has not misled anything. We knew the ME/FSP/vBIOS were the issues
(from my first questions to this coreboot mailing list and the replies
from the community), but there was no perfect alternative, so we chose
Intel to get hardware (more) people wanted and work and invest toward
liberating it.

I can say, without much doubt, that if we chose any other platform we
would have struggled in volume and not advanced any faster or farther
than we have already.

To liberate hardware, there are three larger paths:
1) use existing liberated hardware (gets older and older)
2) design using freed chips (low performance)
3) use products people want that are not yet fully liberated, invest in
liberating.

For laptops:
#1 is already being done by many
#2 is also being done
#3 is the path we are doing for laptops.

For a phone:
#1 doesn't exist
#2 is the path we are doing
#3 others are trying

We can then cross-polinate our investment efforts into the phone
motherboard into a laptop with #2.

I have a published business vision page here:
https://puri.sm/about/business-model-and-vision/


> > One item I would like to call out though is the following:
> > 
> > > if old or non-x86 architectures were so appealing, you would have
> > > seen that become the norm rather than the exception)

This statement is accurate. The volume of sales would be significantly
less if we tried non-x86. And then our growth would be smaller; and our
investment toward freeing future hardware would not happen; and then
there would be no advancement toward convenient ethical products, which
is our goal.

> > Trying to switch architectures may be hard, but it is only
> > going to get harder day after day as people continue to cling to
> > false hope that the x86 platform may ever be brought under their
> > control.

It's pretty simple. With leverage we can change businesses. This is not
a short-term game, but a long-term... grow-gain leverage-influence
change-repeat. And this is what we are doing at Purism, and will
continue. We are not griping about the state of affairs, we have a plan
to change the future, and are executing on it.


> > I wonder, though, if given this information if possibly Raptor and
> > Purism might have some common business ground here?  Purism has
> > experience with laptop mechanicals and related concerns, and we
> > have experience with truly blob-free, powerful hardware --
> > combining those two could yield an interesting machine...

Ping me off list to discuss. We are always looking for aligned-
partnerships or collaboration.


> > > The main question I have, and this is an honest question, is why
> > > Purism chose to use the x86 platform as a base for libre
> > > hardware, when it has been known for some time that said hardware
> > > could never be made fully blob-free?

See above, I think I laid out and answered this clearly. It's not just
technical, there is a strong business model behind our approach.

> > > There were (and are) other good ways to make a system that could
> > > be fully blob-free, for instance ARM, and given the engineering
> > > effort that is said to have been put into the Purism machines I
> > > wonder what we could have had if said effort had been put into an
> > > aarch64 system instead of an x86 system?

Sure, that would sell a small fraction of the quantity, and fail to
impact the future of computing in a way we model out.

> > > > The second reason is that Todd (CEO) was in talks with Intel
> > > > and was unfortunately lead to believe that they were open to
> > > > release an ME-less design CPU for his needs, it ended up not
> > > > being the case.

Intel did not mislead, we told them, and continue to, that we _want_ an
ME-less design (which is their term for what we asked for). And as we
grow our leverage will grow, and our influence will grow. This is a
long-term strategy and is playing out as planned.

They will not adjust based on small quantities, but quantity =
leverage, and our influence changes as volumes grow. (e.g. $ =
influence)

> > > > Todd thought that it would be possible to get a binary blob
> > > > free coreboot/CPU with a few months of work.

Not binary-blob free. It was always known this will be a large
investment of both time and money. But coreboot ported to hardware
within a few months is an accurate assessment of what I heard, and that
turned out to be much longer, not in technical nature, but finding the
right people/developers to do it properly. Now all our (x86) products
are running coreboot, and will continue to.

> > > > A good summary is that we want to "bring
> > 

Re: [coreboot] Coreboot Purism BIOS is free? open?

[Todd Weaver]

On Sat, 2017-12-23 at 11:39 +0100, Nico Huber wrote:
> If you get the i.MX8 for it (and it turns out to be as good
> documented), all you have to do is to ask for a board with the most
> powerful version that physically fits a Librem 13 [1]. Then you can
> offer trustworthy hardware vs. performance and let your customers
> chose.

"all you have to do" is simplifying the "all we have to do" a little.

But let me confirm our top-level plans as it relates...

The Librem 5 is the catalyst for us to produce a motherboard that fits
into the Librem 13/15 ... etc. So that part is spot-on.

We will then offer:
Librem 13 i7
Librem 13 i.mx8
Librem 15 i7
Librem 15 i.mx8
etc.

This will probably be able to happen in 2019. The "all we have to do"
is (not even limited to) design, prototype, test, modify, tool, fund,
fabricate, productize, develop, inventory, quality control, ship,
publish, and support.

> There are ofc alternatives to i.MX. Most use a graphics core where
> free drivers are a problem. Though, a proprietary driver in the OS is
> far less troublesome than blobs in your firmware (or the ME).

I am not convinced this is the consensus. For one critical test that
this would fail: PureOS being listed as an FSF endorsed distribution =
no proprietary drivers in the OS (plus a lot of other things, but that
is the only relevant part to the comparison).

So our approach I believe is still the best approach. Start with
hardware people want, work to free it (NOTE: This is how GNU started in
OS freedom, and I believe that was the best approach there as well).
Since we have to invest in i.mx8 for the phone, then we can cross-
polinate that investment into a lesser expensive, lesser performance,
RYF compatible laptop board that fits into our existing cases.

> Once you buy a reasonable quantity of an SoC, you can ask if they can
> make the next generation with RISC-V instead of ARM. Unlikely to get
> that soon, but way more likely than Intel changing their silicon for
> you.

Moving to RISC-V is on the "we will evaluate and would love to do it."
roadmap, and we will continue to follow the progress there to produce a
device that is RISC-V when it crosses the threshold of "stable
available product". Part of that determination is based on the talented
coreboot community, talking to Ron about this at the last coreboot
conference helped guage the tests for "when" this will be able to be
put into a product.

> 
> Nico
> 
> [1] I'm convinced that this is easily doable.

"easily doable" see above.

Todd.

signature.asc
Description: This is a digitally signed message part
-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] VGA and Graphics

[Todd Weaver]

On 04/01/2017 04:55 PM, Trammell Hudson wrote:
> On Sat, Apr 01, 2017 at 07:43:40PM +, ron minnich wrote:
>> Annnd with the linux payload we're back to linuxbios :-)
> It was a good idea in 1999, and it is still a good idea.

We *may* party like it's 1999 in 2017 then...

>> For a payload chooser and such I can offer two options:
>> 1) petitboot has a boot menu type thing
>> 2) u-root (u-root.tk) is going to have a boot menu type thing, as we've
>> been asked to do one.
> Heads is coming along in usability and has a strong focus on securing
> the boot process through TPM measurement and using the flash security
> features.

Trammell,
One of the three reasons we are including TPM in hardware is because of
your great talk at 33c3 on Heads! But I failed to see that it offered
"boot menu type thing"

> It fits the 4.9.20 Linux kernel + initrd into 4 MB, including
> all of the crypto, networking and other features.  The eventual user
> kernel (or Xen hypervisor and dom0 kernel) are GPG verified and invoked via
> kexec for a slightly more secure, legacy free boot process.

So this is referring more about "linux payload" than "boot menu type
thing" correct?

> More docs are online and pull requests are always appreciated:
>
>   http://osresearch.net/
>

What we are looking at is to include or develop a solution that
accomplishes these goals:
1) allows us to skip most of vbios (but sounds like still needs the VBT)
2) deliver a payload that has a path toward securing the boot process
(e.g. Heads)
3) deliver a payload that can still offer a user to install their own OS
(thus allowing user-configuration and control)

Thanks for writing!

Todd.



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

Re: [coreboot] VGA and Graphics

[Todd Weaver]

On 04/01/2017 05:24 AM, Nico Huber wrote:
> On 01.04.2017 00:49, Todd Weaver wrote:
>> On a related topic, but not related to vbios gfx; I met with
>> Matthew Garrett while at LibrePlanet, and he mentioned that we needn't
>> worry about graphics within coreboot or the vbios, but could just
>> deliver Linux kernel and use the graphics stack from there.
>>
>> Can we bypass the vbios/graphics within
>> coreboot and deliver the Linux kernel payload and use its graphics?
> Yes, that would work. (In the case of Intel hardware) the Linux grap-
> phics driver does a superset of the things the VBIOS does. Actually,
> its default case is to ignore what the VBIOS did and start all over
> again. (One technical detail: You'd still have to put the Video BIOS
> Table, VBT into coreboot.)

OK, we will research that.

> However, you'd have no display before the kernel boots. That's a nit,
> if you use the Linux kernel as payload but that comes with other impli-
> cations. Currently, that would kill what I'd call the "legacy boot
> experience". Without a payload like SeaBIOS, you can't just plug a USB
> drive with a random OS on it and expect the system to boot from it.

Yes, skipping "legacy boot experience" while a benefit (to avoid vbios)
has the disadvantage of user control of replacing an OS with ease. So
the next question is can we offer something similar after linux kernel
payload? such as even a console based menu of boot options on esc? There
may be existing projects I am unaware of that already look at linux
kernel driven usb boot options.

> Again, feel free to throw things at the coreboot mailing list.

I am sending this there now. Thanks for your help!

Todd.



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

Re: [coreboot] New board with unsupported cpu, chipset, and superIO

[Todd Weaver]

 Am 2014-08-28 23:38, schrieb Todd Weaver:
 Comparing the blob-free versions from Intel (which are apparently
 signed, so according to http://www.coreboot.org/Binary_situation are
 at a 9000+ panic level), would it be possible to have blob-free
 (probably through RE) that would work (meaning does not require signed
 binaries) on an AMD board?
 Newer chipsets (as in yet to be released) come with signed parts, but it 
 seems the scope of the signature is configurable somehow by AMD. There 
 were some mails about that a couple of days ago (AMD PSP”).

Thank you I will research that.

 We will do what we can here. The issue is even with immense leverage,
 having the source released (from AMI, or AMD, (or Intel for that
 matter)) would undermine tremendous profit that these companies make
 by keeping this proprietary.
 AMD claims that they stopped working on open sourcing their 
 initialization code because it's lots of work (ie. money) with limited 
 return on investment. How much work that is isn't here or there (most of 
 that is because their internal development process is less than optimal 
 and, like most processes in most organizations, hard to change).
 But it means that someone could make it worth their while given the 
 right kind of project.

Very helpful, thank you!

 What they don't provide sources for is CPU microcode updates (no one 
 does since it's of limited value without the microcode development 
 toolchain and the microcode itself that is getting updated) and various 
 smaller firmware (USB3 which is a licensed core, IMC, an embedded 
 controller, and the SMU).
 For IMC and SMU there's some reverse engineering effort, partially 
 documented in the wiki, so by asking the right questions to the right 
 people in this community, plus some development, it might be possible to 
 get them opened up even without AMD's help.

This is extremely helpful in making the case against Intel (which was better 
received than I had thought) we are at least working with the board 
manufacturer about AMD instead of Intel… Here’s hoping.

Thank you all!

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

Re: [coreboot] New board with unsupported cpu, chipset, and superIO

[Todd Weaver]

Wonderful writeup Paul, thank you. see below…

On Aug 28, 2014, at 9:59 AM, Paul Wilcox-Baker wilcoxba...@gmail.com wrote:

 Dear Todd,
 
 It appears (from following the instructions) that I have a new board
 with unsupported cpu, chipset, and superIO.
 
 00:00.0 Host bridge: Intel Corporation Xeon E3-1200 v3/4th Gen Core
 Processor DRAM Controller (rev 06)
 00:1f.0 ISA bridge: Intel Corporation HM86 Express LPC Controller (rev
 05)
 
 We are interested in a BIOS for the same processor family, but a different
 PCH device.

Maybe we can work together in this effort, I did track down a longtime 
developer relationship I have, who did BIOS development for Xerox, and is 
available to get involved with coreboot.

 c) If there is any coreboot developers that would be willing to contract
 for hire to develop coreboot for this board?
 
 There is a company, Sage Engineering that ports coreboot to various
 processors.  We are probably going to use them.   See
 http://www.se-eng.com or to ask a question use:
 http://www.se-eng.com/contact/

I was referred to them yesterday, and am in contact with them, we will very 
likely use their expertise.

 From what I have been able to find out you need some binary secret sauce
 that comes from Intel.  This allows coreboot to do things like set up the
 DRAM controller and video.  The problem is that Intel only lets a few
 people have access to this code.
 
 For instance, for one of the people who could get this code, they claim
 the process is this simple:
 http://www.coreboot.org/pipermail/coreboot/2014-July/078275.html
 

The above information is remarkably helpful in figuring out how to proceed! I 
really appreciate getting this overview.

 It appears If it is not supported by coreboot then you will have a lot
 of work in front of you.
 
 This view, is based on not having the Intel code and writing your own code
 to set up the DRAM controllers.  I imagine that it would be very difficult
 to write code for modern DRAM controllers, you have to read the EEPROMs
 on the DIMMs to determine the DRAM size and other characteristics, then
 set up the controller to match.  Finally, DDR3 (used by this processor) has a
 training phase to get data accesses aligned in time.  This might be 
 implemented
 in hardware, or you might have to write code to do it.  I don't know!
 

The truth here is that we NEED to have a blob-free version (libreboot), so I 
have a lot of work ahead of me :)

 If you get a different story about this, I would love to hear it.
 
 Thanks, Paul

The story I’ve heard thus far is exactly as you spell it out, even though you 
have provided more information in certain parts.

Thanks Paul, and let me know if we can pool resources to get this to happen!

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

Re: [coreboot] New board with unsupported cpu, chipset, and superIO

[Todd Weaver]

On Aug 28, 2014, at 10:36 AM, David Hubbard 
david.c.hubbard+coreb...@gmail.com wrote:
  The truth here is that we NEED to have a blob-free version (libreboot), so 
  I have a lot of work ahead of me :)
 
 The reality is that Intel has no plans to release code for Xeon E3-1200 v3 
 and HM86 Express. Coreboot's progress so far has been to integrate the blobs.

That is helpful to know, I was considering funding coreboot development, 
coupled with a libreboot (to deblob it) dual effort, and now I know it will be 
more than just a consideration.
-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] New board with unsupported cpu, chipset, and superIO

[Todd Weaver]

On Aug 28, 2014, at 10:59 AM, ron minnich rminn...@gmail.com wrote:
 The truth here is that we NEED to have a blob-free version (libreboot), so I 
 have a lot of work ahead of me :)
 
 How much time and money for the RE effort did you have again? It needs
 to be a lot. Were I you I would not expect much help from the vendor
 to RE their code :-)

Time was measured in months. Not weeks nor years. Funds varied, which is why we 
are gathering interested developers to get some quotes to propose funding the 
effort.

 And you're still going to need the microcode blob, almost certainly,
 unless you don't like having a working main board.

We require blob-free and a working main board, so this sounds like a really 
challenging RE effort indeed!

 If you NEED blob-free, you may need to go ARM.

We cannot easily (actually it would be quite impossible) to move from the Intel 
hardware at this point.

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

Re: [coreboot] New board with unsupported cpu, chipset, and superIO

[Todd Weaver]

On Aug 28, 2014, at 11:26 AM, Todd Weaver t...@m2n.com wrote:
 On Aug 28, 2014, at 10:59 AM, ron minnich rminn...@gmail.com wrote:
 The truth here is that we NEED to have a blob-free version (libreboot), so 
 I have a lot of work ahead of me :)
 If you NEED blob-free, you may need to go ARM.
 
 We cannot easily (actually it would be quite impossible) to move from the 
 Intel hardware at this point.

Per the private messages, I am asking upstream if we can switch to AMD, is AMD 
in a state where we can attain (meaning it is possible (comparing that to 
Intel)) a binary free BIOS?


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

Re: [coreboot] New board with unsupported cpu, chipset, and superIO

[Todd Weaver]

On Aug 28, 2014, at 2:29 PM, Carl-Daniel Hailfinger 
c-d.hailfinger.devel.2...@gmx.net wrote:
 Am 28.08.2014 23:16 schrieb Todd Weaver:
 On Aug 28, 2014, at 11:26 AM, Todd Weaver t...@m2n.com wrote:
 On Aug 28, 2014, at 10:59 AM, ron minnich rminn...@gmail.com wrote:
 The truth here is that we NEED to have a blob-free version (libreboot), 
 so I have a lot of work ahead of me :)
 If you NEED blob-free, you may need to go ARM.
 We cannot easily (actually it would be quite impossible) to move from the 
 Intel hardware at this point.
 Per the private messages, I am asking upstream if we can switch to AMD, is 
 AMD in a state where we can attain (meaning it is possible (comparing that 
 to Intel)) a binary free BIOS?
 
 You can, but with chipsets/CPUs released in the last few months you may
 be out of luck. Right now, it appears AMD does not see compelling enough
 business reasons to publish the source code for the newest hardware
 generations, but you may be able to get the source code for the blobs
 under NDA.

Thanks, that helps set the stage with AMD discussions.

 That said, there are quite a few pieces of recent (and still in
 production) AMD hardware which do have full coreboot support. Exceptions
 from the blob-free guarantee are graphics firmware and USB3 firmware,
 which are both not executed on the main CPU.

Comparing the blob-free versions from Intel (which are apparently signed, so 
according to http://www.coreboot.org/Binary_situation are at a 9000+ panic 
level), would it be possible to have blob-free (probably through RE) that would 
work (meaning does not require signed binaries) on an AMD board?

 Depending on how big your order is (not just enthusiasts all over the
 world will surely buy it, but real money spent by your
 company/organization), you might have some real leverage, even for
 getting code published.

We will do what we can here. The issue is even with immense leverage, having 
the source released (from AMI, or AMD, (or Intel for that matter)) would 
undermine tremendous profit that these companies make by keeping this 
proprietary. So I’m leaning toward the direction that we’d have to RE the 
missing pieces (but could be wrong, thus the questions).

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

[coreboot] New board with unsupported cpu, chipset, and superIO

[Todd Weaver]

It appears (from following the instructions) that I have a new board
with unsupported cpu, chipset, and superIO.

00:00.0 Host bridge: Intel Corporation Xeon E3-1200 v3/4th Gen Core
Processor DRAM Controller (rev 06)
00:1f.0 ISA bridge: Intel Corporation HM86 Express LPC Controller (rev
05)

From this page:
http://www.coreboot.org/Developer_Manual#Supporting_a_new_board_with_a_unsupported_cpu.2C_chipset_or_superIO

It appears If it is not supported by coreboot then you will have a lot
of work in front of you.

What I need to find out is:

a) If it is even possible to get coreboot to work with this board?
b) How much time would it take to get coreboot to work with this board?
c) If there is any coreboot developers that would be willing to contract
for hire to develop coreboot for this board?

It is a requirement to replace the bios with coreboot, so I am tasked
with making sure it is possible (a), a rough idea of how long (b), and
if we can hire somebody to develop it (c).

I appreciate any replies to any parts of the above, and I am hopeful
somebody would be able to have the time needed to get paid to get
coreboot onto this board.

Thank you!

Todd Weaver


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