[coreboot] Re: Issue tracker version update / disabling of login methods

[Sam Kuper]

On Thu, Aug 04, 2022 at 10:26:25PM +, Felix Singer wrote:
> However, I have an idea for a solution. I took a look at the Redmine
> database and I played around with the Google login method. My tests
> showed that it creates a normal user account, as it is done with the
> registration, just with the little difference that no password is set
> disabling the login over password. These accounts also have an user
> name and an email address. As soon as I set a password, I was able to
> login using the user name.
> 
> So, my idea is that we just go with these changes and affected users
> use the functionality to reset their password, which means they will
> have a "normal" user account then. In preparation to that version
> update, we should disable these login methods so that no new users will
> make use of them.
> 
> Other ideas? What's your opinion?

I'm a bit unclear what you are proposing.

I'm also unclear whether, under your proposal, users without Google
accounts would be able to register or log in to the Redmine instance.

Please can you clarify?

Thanks,

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

[coreboot] Re: Custom coreboot installer and license

[Sam Kuper]

On Thu, Jul 28, 2022 at 06:33:15PM +, Sam Kuper wrote:
> If I were you, I would unpublish the GPLv2 commit ASAP (before too
> many people pull it - though the genie can't really be put back in the
> bottle), and would instead make a new HEAD on top of 077e2f4 with the
> AGPLv3 as your license.  This way, at least future commits to your
> software will be protected by AGPLv3.


P.S.  Please read my "If I were you", above, in the sense of, "If I were
in your shoes, wanting strong copyleft AND GPLv2 compatibility".

Not in the sense of "You should/must do this!"  :D

I.e. My earlier message in this thread was given as a well-intentioned
suggestion, not as any kind of order or diktat :)


As you may know, one of the problems with GPLv2 in embedded contexts was
"Tivoisation".  This is an example of why you might want to use AGPLv3
(which protects against Tivoisation) rather than GPLv2 (which doesn't).


Whatever you decide, it's great that you're working to increase the
number of computers in the world with free software as standard.  Kudos!
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: Custom coreboot installer and license

[Sam Kuper]

Hi Felix,

On Thu, Jul 28, 2022 at 12:48:37PM -0400, Felix Freeman via coreboot wrote:
>> Please use a known compatible license instead... :)
> 
> Who can deny such a kind request, consider it done:
> https://git.sr.ht/~hacktivista/hackware-boot/commit/abb9e059c17f719a28f3243dfacac1646d37c774

I just saw this thread and looked at the diff.  I see that you replaced
the Hacktivista General Public License (which I'll call the HGPL) with
GPLv2.

The HGPL notes that it is based on AGPLv3.

Given that:

-  the HGPL wording makes it clear that your aim is strong copyleft
   (which I support!); and

-  you are willing to ensure GPLv2 compatibility (in order to comply
   with Coreboot's license),

it seems to me that the most appropriate license for your software would
be the AGPLv3, NOT the GPLv2.


AGPLv3 would comply with Coreboot's license AND would give you the
strongest copyleft available among standard free software licenses.


GPLv2 would comply with Coreboot's license BUT would *not* give you the
strongest copyleft available among standard free software licenses - not
even close.


If I were you, I would unpublish the GPLv2 commit ASAP (before too many
people pull it - though the genie can't really be put back in the
bottle), and would instead make a new HEAD on top of 077e2f4 with the
AGPLv3 as your license.  This way, at least future commits to your
software will be protected by AGPLv3.


Sam


P.S.  I am not a lawyer, just someone with a strong interest in free
software licensing.
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: Systems that use coreboot

[Sam Kuper]

On Mon, May 02, 2022 at 07:00:57PM +0300, Valerii Gugnin wrote:
> Hello!
> I have some questions about coreboot:
> 
> What are the most popular systems on which coreboot is typically used?

See the systems listed at https://coreboot.org/users.html

ChromeOS devices (Chromebooks, Chromeboxes, Chromebit, etc) are quite
popular.


> What mainboards, southbridges, SoCs etc do these systems use?

A variety.


> What is the most used part of code (for which system) in coreboot?

What do you mean?

Sam

-- 
A: When it messes up the order in which people normally read text.
Q: When is top-posting a bad thing?

()  ASCII ribbon campaign. Please avoid HTML emails & proprietary
/\  file formats. (Why? See e.g. https://v.gd/jrmGbS ). Thank you.
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: Deprecation of the Intel Quark SoC

[Sam Kuper]

(I'm not a Coreboot dev/maintainer, so apologies for commenting from the
peanut gallery...)


On Mon, Apr 18, 2022 at 04:32:36AM +0200, Martin Roth wrote:
> [...]
> 2) Decide on a set of criteria that we can use to evaluate whether or
> not things should be removed from the master branch and maintained on
> a release branch.

Makes sense.


> Currently, the only reason we have specified that a platform will be
> moved to a release branch is if it's hindering progress.  Basically if
> it's not using an API we want to mark a required, or using code that
> is being deprecated.
> 
> If hindering progress is the only reason that something should ever be
> removed from the master branch, I'm fine with that.  Let's decide that
> and document it so we don't have to have this discussion in the
> future.

Surely there will sometimes be platforms/chips that, for good reason,
the community wants to keep in master - even if this would mean rewrites
for those platforms/chips re the two matters you mentioned above:

a.  not using APIs that future versions of coreboot will require;

b.  using code that is being deprecated?


Such "good reasons" could include that the plaform/chip:

1.  is in widespread use with coreboot, even if long out of production
(e.g. certain server boards or Thinkpad models); or

2.  is targeted by related projects (e.g. Heads) that coreboot
developers would prefer to avoid unnecessarily inconveniencing; or

3.  has active coreboot testers/maintainers able to integrate relevant
updates, and is passing all significant CI tests.


> Other options we could look at:
>
> - A platform has not been sold in X years.
>
> - A chip has not been produced for X years.

I can see the appeal of these criteria: they are easy to define.
However, they are probably not wise criteria, as they may conflict with
one or more of the "good reasons" above, especially reason 1.


> - A platform has not been tested in X years.
>
> - A platform hasn't had an active maintainer for X years.  (Maybe the
>   maintainer should be asked to test a platform as well?)

These seem much better criteria.

To make them easier to apply, should coreboot comprehensively track, for
platforms/chips (roughly as Debian does for packages):

-   the current maintainer(s) for that platform/chip,

-   the current tester(s) for that platform/chip,

-   when that platform/chip was last tested, and

-   what the test results were?

I think coreboot already tracks some of this data via
https://lava.9esec.io or https://qa.coreboot.org/ - I'm not certain.

That being so, I propose some draft policy wording (please
change/improve...):

"For any given platform or chip that has ever been targeted by the
coreboot project:

-   For each coreboot "version" (point release, master, or
hardware-specific branch):

-   if the platform/chip has been tested on that version, but
the test was unsuccessful, the platform/chip shall be
labelled *broken* re that version; else

-   if the test was successful, the platform/chip shall be
labelled *working* re that version; else

-   the platform/chip shall be labelled *untested* re that
version.

-   If the platform/chip has known security vulnerabilities on that
version, the shall be labelled *vulnerable* re that version.

-   If the platform/chip has a person/team assigned to test/maintain
it re master, it shall be labelled *maintained*, unless it has
been *vulnerable*, *broken*, or *untested* re master for at
least 6 months in which case it shall be labelled
*unmaintained*,

-   If a platform/chip has been labelled *unmaintained* for at least
6 months, a branch shall be created for it, from the last
coreboot point-release for which it was tested and found to be
working.  Such a platform/chip shall be labelled *relegated*.

-   A person/team who merges subsequent updates from master into
such a branch, such that the branch becomes acceptable to the
gatekeepers of master for merging back into master, and who also
successfully tests the relegated platform/chip on the resulting
codebase, and who volunteers to maintain that platform/chip for
the foreseeable future, may become that platform/chip's
maintainer, and upon the relevant changes being merged into
master, the platform/chip shall no longer be labelled
*relegated* but instead shall be labelled *tested* and
*maintained*."


> Thanks everyone [...]  I'm not trying to argue with anyone, just
> looking to get an actual decision of some sort out of this thread.

Ditto!

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

[coreboot] Re: Deprecation of the Intel Quark SoC

[Sam Kuper]

On Fri, Apr 15, 2022 at 06:28:37PM +, Zimmer, Vincent wrote:
> Andy Pont wrote:
>> Vincent wrote:
>>> I can provide some Galileo h/w for folks if there is interest in
>>> supporting.
>> 
>> [..] If you have both and can get them shipped to the UK that would
>> be great. I suspect I have power supplies and debug cables for them.
>
> Sure. Send me a mailing address.  Unites should have Europe-friendly
> wall-wart/power supplies and cables, etc. in the box.

Note for Vincent: the UK has different mains electricity sockets than
most other European countries:

- UK uses BS 1363 (aka IEC 60083 Type G):
  
https://en.wikipedia.org/wiki/AC_power_plugs_and_sockets:_British_and_related_types#BS_1363_three-pin_(rectangular)_plugs_and_sockets

- Much of the rest of Europe uses CEE 7 sockets, but these are not used
  in the UK:
  https://en.wikipedia.org/wiki/CEE_7_standard_AC_plugs_and_sockets


Mains electrical items shipped to the UK must typically have a BS 1363
plug or risk being delayed/impounded at customs.

(I think this stems from The Plugs and Sockets etc. (Safety)
Regulations 1994: https://www.legislation.gov.uk/uksi/1994/1768/made .)

So, best to check the mains plugs are UK legal before shipping.  If they
aren't, it may be wise to ship the boards without plugs/PSUs and let
Andy source those locally.

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

[coreboot] Re: Deprecation of the Intel Quark SoC

[Sam Kuper via coreboot]

On Sun, Apr 03, 2022 at 11:25:31AM +0200, Michael Niewöhner wrote:
> On Sat, 2022-04-02 at 19:08 -0400, Undiscussed Horrific Abuse, One Victim of
> Many wrote:
>> I looked up this board: https://en.wikipedia.org/wiki/Intel_Galileo
>> 
>> It's discontinued, but it's open hardware, runs linux, and is
>> compatible with arduino sketches and shields.
>> 
>> That's very rare and valuable. It should not be removed.
> 
> Well, while that is true, the SoC is not available anymore.
> 
>> If there is specific maintenance burden around a task, this should be
>> identified so it can be addressed.
> 
> It is identified already and can only be addressed by a volunteer
> taking over maintership of the SoC. This should be someone who owns
> the board to be able to test changes.

I checked eBay.  £30 plus postage.  Anyone tempted?

https://www.ebay.co.uk/itm/284509369404
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: Installing coreboot with SeaBIOS

[Sam Kuper]

On Tue, Jan 18, 2022 at 12:21:24PM +0100, Nico Huber wrote:
> On 18.01.22 10:40, bernd...@web.de wrote:
>> How long may the wires be?
> 
> 10 to 20cm works well. Sometimes shorter is better, but the X220
> shouldn't make you any trouble. So I'd rather choose cables that don't
> make handling of the clip too inconvenient.

Nico is right about convenience.


Still, I experienced inconsistent reads almost every time I used 20cm
wires.  (Yes, I checked the wires and the clip for resistivity or loose
connections, etc.)

I experienced almost no inconsistent reads with 10cm wires.

When I shielded the 10cm wires with earthed aluminium foil, I got
entirely consistent reads.  Unfortunately, this is much less convenient
to handle than unshielded 20cm leads.


Your luck may depend on how electrically noisy your environment is.


-- 
A: When it messes up the order in which people normally read text.
Q: When is top-posting a bad thing?

()  ASCII ribbon campaign. Please avoid HTML emails & proprietary
/\  file formats. (Why? See e.g. https://v.gd/jrmGbS ). Thank you.
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: Installing coreboot with SeaBIOS

[Sam Kuper]

On Sun, Jan 16, 2022 at 06:43:42PM +0100, bernd...@web.de wrote:
> It's a ThinkPad X220 (notebook version, not tablet version).

The X200 may not be quite the same as the X220, but this guide should at
least give you *some* idea of what's involved, on the hardware side.

https://libreboot.org/docs/install/x200_external.html


> What are PSUs?

Power Supply Units.  In the case of battery-powered devices like phones
or laptops, these may also be called "chargers".

PSUs for computers typically take mains voltage (220V AC, for example)
and convert it to the relevant DC voltage.

Your X220 probably has something like a 20V DC PSU.

Most Raspberry Pis need 5V PSUs, same as most Android phones.

If you use an external monitor for the Raspberry Pi, instead of SSHing
into it, then you might need a PSU for that monitor - although these
days, most LCD monitors have internal PSUs and so just need a mains
cable.



I must say, if you are unsure what a PSU is, then I would recommend
reading some basic electronics textbooks - and familiarising yourself
with the dangers of using incorrect voltages or polarities, the dangers
of static discharge, and the dangers of electrocution - before you
attempt to do anything relatively advanced and delicate like flashing
the ROM chip of an X220.  Using a PSU improperly could brick your
laptop, start a fire, or worse.

So, please take time to understand the principles well first of all.
Then, after that, you would stand a better chance of doing a good job of
flashing your laptop.
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: how intel ME is connected to the internet ?

[Sam Kuper]

On Tue, Oct 05, 2021 at 03:17:13AM +0700, Hendra wrote:
> [..] so, in conclusion:
> 
>- ME has its own MAC and IP address

No.

NICs have MACs.

NICs *may* have IP addresses.


>- ME can access the internet by using the OS's configured network
>connection,

Or perhaps a network connection configured in BIOS or UEFI.


> without the OS ever noticing

Yes, that's how OOB management works.  ME/AMT is a bit like iLO or IPMI,
but implemented via CPU's coprocessor.


>- ME can record network credentials to persistent storage, while
>the main OS is running.

*Maybe*.


>- ME can use the recorded network credentials for internet access,
>while the main OS is not running.

*Maybe*.


>- ME cannot access the internet without Laptop's networking device

Almost certainly correct.  Also, the NIC has to be compatible: the ME
does not, AFAIK, have drivers for all NICs.


>- a secret / hidden independent networking device,

A networking device other than the PC's obvious/legitimate NICs?


>would probably look suspicious under a microscope,

Uncertain.

First of all, you can't tell for sure what a chip does just by looking
at it with a microscope:

https://www.schneier.com/blog/archives/2013/09/surreptitiously.html


Secondly, even if you know what a chip is for, and that it isn't a NIC,
and that it hasn't been tampered with, and that it isn't necessarily
even physically connected to circuitry outside the PC, that doesn't mean
it can't be used to exfiltrate data.  So "networking devices" (in the
loosest sense) could be hiding in plain sight.  E.g. some GPUs can be
used to exfiltrate data wirelessly: https://arxiv.org/abs/1411.0237

AFAIK, there's no evidence existing ME versions contain code for
intentional side-channel data exfiltration.


>nobody has seen something like that in Intel's chipsets.

Again, not clear what you mean.  Marginally relevant reading:

https://www.theregister.com/2021/02/12/supermicro_bloomberg_spying/

https://hackaday.com/2019/05/14/what-happened-with-supermicro/



>- ME without AMT firmware couldn't do out of band management, but
>may still be networking capable.

Uncertain.  Cf. "Lojack for laptops" - IIRC this did not require AMT.


>- ME could set up an ad-hoc wireless network, with other iME chips
>in the local area, then connected to the internet through other iME
>chips.

*Maybe.*

For each PC involved, ME would need PC to have a compatible NIC.

A transport medium would need to be present between those devices: if
WiFi, they'd have to be within range; if ethernet, they'd have to be
plugged in and on a suitable topology.

That's just to make a mesh.

And AFAIK, there's no evidence existing ME versions contain mesh
networking code.


To gain internet access, then in addition to the above, one of the
devices on the mesh would need internet access, e.g. via cached
credentials or credential-free.


> How about an ultrasonic transmitter / receiver ?

There's no shortage of techniques for exfiltrating data over air gaps:

https://thehackernews.com/2020/02/hacking-air-gapped-computers.html

https://www.zdnet.com/article/academics-steal-data-from-air-gapped-systems-using-pc-fan-vibrations/

https://en.wikipedia.org/wiki/TEMPEST

And no reason why control of the CPU can't provide an acoustic
exfiltration channel.  (After all, that's effectively how acoustic
cryptanalysis works.)

But that doesn't mean existing ME versions have code for this, or that
the ME can access the internet that way.


> Can iME communicate with the internet or other nearby iME chips or
> WIFI hotspot through ultrasonic sound ?

*Maybe*.

Most routers don't have audio transducers (speakers/microphones), so
can't detect ultrasonic sound in a traditional way.

Even without audio transducers, wifi routers can in principle be
programmed to convert some kinds of Wifi signal fluctuation into audio:
https://www.theatlantic.com/technology/archive/2016/08/wi-fi-surveillance/497132/

But AFAIK this has been achieved only with fluctuations caused by
macroscopic movement - not with the much smaller fluctuations caused by
ultrasonic sound sources.


> Somehow, I'm not sure, but sometimes I have assumption (maybe wrong
> assumption), that ME still can connect to the internet, without using
> any of these networking devices ( WIFI card / Wwan card / bluetooth /
> wimax / ethernet ) , because: [...]

Unlikely.


>- Or maybe all Wifi hotspot routers have iME similar chips that can
>communicate hidden traffic with iME chips ?

Most wifi routers don't use x86 architecture or Intel CPUs, but some
router chipsets do have coprocessors.  OpenWRT and related projects
maintain databases of router chipsets, if you're interested.

Even if a router's chipset has a coprocessor, though, that doesn't mean
it can or does "communicate hidden traffic with iME chips".
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an 

[coreboot] Re: how intel ME is connected to the internet ?

[Sam Kuper]

On Sun, Oct 03, 2021 at 05:43:38PM +0700, Hendra wrote:
> in my understanding,
> 
> in their office, they know the password of their internet connection,
> therefore they can setup the password in the AMT,
> so they can access the devices remotely,
> 
> but after the products being distributed all over the world,
> then each are connected to different wifi router with different passwords,
> therefore they need to set up another wifi password to the AMT,
> in order for the AMT to be connected with the internet,
> so that they can access it remotely,
> 
> but then how do they know the password ?
> also how do they access it remotely to re-setup the password ?

A while since I last looked into this, but IIRC:

- Important to distinguish between ME OS (a Minix derivative) and "main"
  OS (typically Windows, macOS, GNU/Linux, ...)

- ME can, while main OS is running, view some/all CPU registers, RAM,
  and (in the case of *compatible* NICs), some NIC registers.

- ME can therefore (in principle, at least) record network credentials
  to persistent storage.



That raises questions including the following:

- Does ME in fact extract network credentials from the main OS when
  latter is running?  (IIRC, Snowden indicated the answer is yes - at
  least in some cases.)

- If so, which part(s) of which versions of the ME are responsible?  (A
  binary search like the one Trammell Hudson - I think - used to work
  out how to neutralise the ME might reveal this.)

- Which other variables affect whether the answer is "yes"?

- Does ME in fact store credentials persistently, to give itself network
  access even if main OS is not running?  (IIRC, Snowden indicated the
  answer is yes - at least in some cases.)

- If so, then where do which versions of the ME store those credentials?
  (Do they use persistent storage on the NICs?  BIOS/UEFI?  HDD/SSD?  Or
  somewhere sneakier like in the HDD/SSD controllers?  Maybe some
  combination or fallback of all these?)

- Which other variables affect whether the answer is "yes"?

Someone (a PhD student, maybe?) should make these questions the subject
of a research project.  Perhaps it has already been done.  As I say, I'm
a bit out of the loop just now.
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: Integrating (temporarily) proprietary tooling into our build system (was Re: Intel CBnT tooling and dealing with NDA)

[Sam Kuper]

On Wed, Feb 10, 2021 at 05:28:44PM +0100, Nico Huber wrote:
> Please understand that integration of any new proprietary component
> naturally wakes heavy feelings.

A phrase and a history associated with feelings like that, in contexts a
bit like this, is (as I'm sure Nico and many others of you know; but for
those who don't):

https://en.wikipedia.org/wiki/Embrace,_extend,_and_extinguish

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

[coreboot] Re: Tooling of choice for coordinating and running the coreboot leadership meeting

[Sam Kuper]

On Wed, Jan 13, 2021 at 10:37:14PM +0100, Patrick Georgi wrote:
> when announcing today's leadership meeting on IRC I got some replies
> to the tune of "oh no, Google!" as the meeting minutes are recorded on
> Google Docs and the meeting itself is held using Google Meet.
> Note that both are set up to be usable without a Google account, so
> the impact on users should be limited.

It's good of you to ask about this.

For archival purposes, accessibility, minimising lock-in, & to benefit
from a familiar collaboration workflow, it would be best to for minutes
to be kept as plain text (Markdown, Org, or another lightweight markup
language) in a Git repo.  So, ideally: export the existing Google Docs,
use Pandoc or similar to turn them into the lightweight ML of choice,
put that in Git, & avoid Google Docs thereafter.

Failing that, if you do stick with Google Docs, please could you at
least ensure that any published links to the minutes are to the "web
page" version, not the default version, so that they are accessible and
archivable?  If you could fix the existing links in the .ics file too,
so that those documents become accessible, that would be good.


(If you aren't sure what I mean by the "web page" version, here is an
explanation.  Last time I checked -a couple of years ago - there were
two ways to "publish" Google Docs:


- As a link to the editing interface, which requires the user to have a
  JavaScript-enabled browser and to not have certain kinds of disabily.
  Docs publishes this way are impossible to view/retrieve for users
  browsing with Lynx, w3m, wget, etc, or with some accessibility issues.

  For me and some other people I know, this interface is unreadable.
  Unfortunately, the links in Coreboot's .ics file go to this interface,
  which means I can't read the minutes.


- As "web pages".  This doesn't have those requirements, and is much
  more accessible.  IIRC:  File > Publish to the web > Publish.

  Doing that ought to give you a URL you can share that should work for
  everybody.)



> Note that this project, its developers, contributors and maintainers
> aren't in the business of managing servers or communication suites
> (although we spend a fair amount of time and money on running
> coreboot.org to ensure people can contribute with little restrictions:
> apart from that meeting, everything we do is self-hosted!) so a
> proposal should be low maintenance for us.  [And not exponential
> connection problems like Jitsi.]

That being so, I don't have any suggested video chat solutions, sorry.
Maybe Jami, but I haven't tried it.  Might have the same problems as
Jitsi.  Anyway, I wouldn't be joining the video chat... ;)

Anyway, thanks again for asking about this,

Sam

-- 
A: When it messes up the order in which people normally read text.
Q: When is top-posting a bad thing?

()  ASCII ribbon campaign. Please avoid HTML emails & proprietary
/\  file formats. (Why? See e.g. https://v.gd/jrmGbS ). Thank you.
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

Re: [coreboot] SPI controller and Lock bits

[Sam Kuper]

Hi Youness,

On 15/10/2018, Youness Alaoui  wrote:
> One thing to note is that this week will be my last week at Purism as
> I'm going on sabbatical for a few months, and I may or may not (most
> likely won't) come back to Purism in a few months.

Thank you for your efforts to make Coreboot work on the Librems, and
for the enthusiasm you displayed here in the mailing list and on the
Purism blog.

Although I might have sounded critical on occasion, this was never
personal; it was always out of a concern to avoid missing
opportunities to achieve the most secure and privacy-protecting
machines available within the constraints of the hardware and the
business model. I.e. my "criticisms" were always intended to be
constructive. I hope that they did not form any part of your decision
to take a break from Purism, and if they did, I apologise.

I wish you a good sabbatical, in any case.


> @Sam
> for 90% of the users, they would either :
> - never [flash the ROM]
> - only do it when a new update is released and interests them, i.e:
> once or twice a year.
> So [...] it would be far
> from annoying to users since most won't care or notice that all that
> is needed, and if they do, they won't care to have to do it so rarely.

I fear that even performed rarely, it might be beyond some users'
abilities. But...

> It will however, especially with cover-opening protections (either
> using glitter/whatever methods on screws to notice if they'd been
> opened, or with an EC handling a cover switch notification), that
> could be very helpful to increase their security.

... I agree that making it tamper-evident is indeed potentially valuable.


>> Your assumption fails against a BadHeads attack.
> Yes indeed, I wrote a proof of concept which was a Heads that would
> extend PCRs with the same values that coreboot did (and have a
> coreboot with measured boot disabled) and it passed the TOTP
> authentication.

Many thanks for confirming this to the mailing list. I was hoping to
write and somehow disseminate (e.g. to the Heads developers) a POC
myself, but I'm glad to be spared that need.

If you could send your POC to the Heads team for integration into the
test suite, that would be great. This flaw in Heads needs to be fixed
(if it hasn't already been). Having the POC in the test suite would
also help to detect future regressions, once the issue is fixed (if it
*can* be fixed).

If it hasn't yet been fixed... Thinking aloud: as a community, we need
to find a way (or else, determine that it really is impossible) to
achieve robust mutual authentication between PC and user, with just an
SPI ROM and a boot disk and a TPM and a TOTP/challenge-response token.
Some kind of formal verification might be in order.


> That's something that other possible solutions would
> try to mitigate (such as vboot I think).

In the open world, vboot does seem to be the state of the art.

Apple's T2 chip might also mitigate against this sort of thing,
although it does not authenticate to the user via TOTP: the check is
implicit rather than explicit. I may be wrong, though. Public
documentation seems to be scarce.


>> it would be great if Purism could be
>> sure not only to spec, but also to list on the Librem specification
>> pages on the website, a SPI flash ROM chip that *does* obey its
>> write-protect pin regardless of firmware. Thanks :)
> I didn't realize that "some chips don't obey the write-protect pin",
> but rather my understanding is that the write protect pin is there to
> say "the protected blocks are protected/not-protected according to
> hardware.
> The SPI flash (according to the datasheets I've read) can protect
> regions either with "don't protect" or "protected by WP#" or
> "protected until power-cycle".
> The status register bits can be written to either as volatile or
> non-volatile (for non volatile, you need another command iirc, and you
> can't do it with hardware sequencing, same for the 'protect until
> power cycle', which also needs to write to status-register-2 which
> can't be done with hardware sequencing either).
> So, really, a flash rom chip does obey its WP pin, it just depends on
> how it's set.

Thanks for this. I clearly need to spend more time reading data sheets
and running tests on SPI flash ROM chips.

All best,

Sam

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

Re: [coreboot] SPI controller and Lock bits

[Sam Kuper]

On 02/10/2018, Nico Huber  wrote:
> Am 02.10.18 um 13:48 schrieb Sam Kuper:
>> On 02/10/2018, Nico Huber  wrote:
>>> Separating functional updates from those that change platform-ownership
>>> is a key feature of vboot. Without such separation, you'll either make
>>> owning too easy or updating too hard.
>>
>> In principle, I agree. But in practice, Librems don't seem to possess
>> this kind of separation (yet?).
>
> The software doesn't. But it's much easier to add it later once the
> hardware supports it. IMHO, design decisions for future hardware should
> prepare for state of the art security and not the security of yesterdays
> soft/firmware.

In principle, I agree. I was just trying to clarify the reason for my
choice of earlier comments.


>>> You need to tamper more than just HEADS, otherwise the attestation of
>>> the firmware (e.g. via TOTP or a Librem Key) would fail.
>>
>> That was not my understanding.
>>
>> See this outline of a putative "BadHeads" attack:
>> https://forums.puri.sm/t/prevent-bios-being-flashed-by-root-level-attacker-without-physical-access/3786/3
>>
>> Also see Kyle Rankin's apparent confirmation that such attacks succeed
>> (on current Librems):
>> https://forums.puri.sm/t/prevent-bios-being-flashed-by-root-level-attacker-without-physical-access/3786/4
>
> Sorry, I won't have the time to read through all this. In theory, it
> depends on when the measuring is started. If the measuring starts only
> late in HEADS (and not in coreboot), you are right. Generally you'd have
> to tamper the piece of software that starts the measuring.

The putative attack bypasses the measuring. As such, I can't see why
it makes any difference whether the measuring starts early (in
Coreboot), or late (in Heads). Sorry if I'm misunderstanding something
basic.


>>> there are technical pitfalls that leave the same problem for a momentary
>>> switch: Unless you use real custom chips, you'll have to use the access
>>> protection current chips support and in the case of SPI NOR flashes
>>> there usually is no simple on/off signal that tells the chip to deny
>>> writes. Usually, you only signal it to protect its write-protection
>>> configuration which you could forget to set correctly after flashing
>>> too.
>>
>> Does this mean that Peter Stuge's suggestion to (de-)solder a typical
>> SPI flash chip's write-protect pin was erroneous?
>>
>> https://media.ccc.de/v/30C3_-_5529_-_en_-_saal_2_-_201312271830_-_hardening_hardware_and_choosing_a_goodbios_-_peter_stuge#webm
>
> No, I wouldn't think so (without watching that video). What I meant is
> that lifting your finger from a momentary switch won't be enough. You,
> or the software you use, could still "forget" other things with the same
> effect. The problem is that what the flash chip does when the /WP pin is
> asserted usually depends on the chip's configuration (that you might
> have to change to be able to flash; depends on the chip I guess). Just
> read your chip's datasheet if you want to know the whole story.

On 02/10/2018, Peter Stuge  wrote:
> Indeed soldering the WP#-pin to ground is not sufficient to disable
> writes on any and every flash chip, but for chips where writes *can*
> be disabled electrically it is the key step that overrides software.
>
> Many flash chips support a write enable policy for parts and/or all of
> the chip. (See status register/block protect bits in flash chip data
> sheets.) The WP#-pin usually controls whether software is allowed to
> change that policy. If the WP#-pin is connected to ground then the
> policy can only be changed from write-enable to write-disable, but
> the other way around requires disconnecting WP# from ground first.
> (That's what a switch would do.)
>
> It is worth noting (I think I mentioned it in that talk) that not
> all chips store the policy in non-volatile memory - only some do!
>
> Some flash chips forget the write-protect policy on reset, meaning
> that the WP#-pin has no effect from reset until a software-issued
> command sets a write-protect policy.
>
> That's potentially a problem if something can access the flash chip
> before the x86 root-of-trust runs.

You are both correct that I was assuming a chip that obeys the
write-protect pin regardless of the firmware. I would be surprised if
Purism ordered their motherboards to be built with chips of which that
is not true, but perhaps that was unduly optimistic of me. I have not
attempted to check (yet).

Thank you both for your informative replies :)


Youness and others at Purism: it would be great if Purism could be
sure not only to spec, but also to list on the Librem specification
pages on the website, a SPI flash ROM chip that *does* obey its
write-protect pin regardless of firmware. Thanks :)

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

Re: [coreboot] SPI controller and Lock bits

[Sam Kuper]

On 02/10/2018, Nico Huber  wrote:
> Am 02.10.18 um 11:53 schrieb Sam Kuper:
>> On 01/10/2018, Youness Alaoui  wrote:
> tldr; whether the effort to disable write protection is reasonable
> or not depends on what you want to write protect.

Agreed.


> You two might have different kinds of updates in mind. You don't need
> a switch for every update. With a read-only root of trust, for instance,
> that is secured by the switch or jumper or whatever, you could still
> update everything else with software only. That root of trust could
> either verify a signature of the following firmware parts (like vboot
> does) or start a measuring chain or (ideally) do both.
>
> Separating functional updates from those that change platform-ownership
> is a key feature of vboot. Without such separation, you'll either make
> owning too easy or updating too hard.

In principle, I agree. But in practice, Librems don't seem to possess
this kind of separation (yet?).


>>> As for your question earlier about someone forgetting it. I would
>>> assume that it would be easy to have the Heads menu show a big warning
>>> to the user if it's left unprotected
>>
>> Your assumption fails against a BadHeads attack.
>
> You need to tamper more than just HEADS, otherwise the attestation of
> the firmware (e.g. via TOTP or a Librem Key) would fail.

That was not my understanding.

See this outline of a putative "BadHeads" attack:
https://forums.puri.sm/t/prevent-bios-being-flashed-by-root-level-attacker-without-physical-access/3786/3

Also see Kyle Rankin's apparent confirmation that such attacks succeed
(on current Librems):
https://forums.puri.sm/t/prevent-bios-being-flashed-by-root-level-attacker-without-physical-access/3786/4

If I was mistaken about this, then I apologise.


> But...
> there are technical pitfalls that leave the same problem for a momentary
> switch: Unless you use real custom chips, you'll have to use the access
> protection current chips support and in the case of SPI NOR flashes
> there usually is no simple on/off signal that tells the chip to deny
> writes. Usually, you only signal it to protect its write-protection
> configuration which you could forget to set correctly after flashing
> too.

Does this mean that Peter Stuge's suggestion to (de-)solder a typical
SPI flash chip's write-protect pin was erroneous?

https://media.ccc.de/v/30C3_-_5529_-_en_-_saal_2_-_201312271830_-_hardening_hardware_and_choosing_a_goodbios_-_peter_stuge#webm


> What I'm trying to show here is that there is no simple solution that
> can be implemented in a single spot like putting a switch next to the
> existing kill switches. One shouldn't rush to implement new schemes
> that might seem better (compared to the state of the art, which is
> vboot, imho). If one wants to enhance the security of their next batch
> of laptops, implementing something compatible to what is already there
> and has itself proven to work would be a good approach (and it seems
> to me that is what Youness has in mind).

I agree about not leaping to conclusions. Sorry if it seemed that this
is what I was doing. A couple of posts back, I did try to make clear
that I believe security improvements in the firmware will be valuable
(albeit probably not sufficient; i.e. a hardware switch of some kind
would also be helpful).


> Also, Sam, you seem to be pushing for a hardware addition that suits
> [wanting] to install updates that you just compiled yourself.
> But that's not everybody's use case.

Whether the context is a solo user, a small organisation, or a large
one, it seems to me that upgrading at least *some* parts of the
firmware should require physical access.

As for how much effort it should be to gain that physical access, I
agree with your implicit point that if changing the root of trust is
separated from upgrading other parts of the firmware, then it may make
sense for the former, which should probably be done only rarely, to be
effortful (e.g. to require removal of the bottom case, and use of ESD
precautions). This would reduce the risk of a passer-by being able to
change the root of trust on a laptop that someone has accidentally
left running and unlocked for a moment while going to the bathroom or
whatever.

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

Re: [coreboot] SPI controller and Lock bits

[Sam Kuper]

On 01/10/2018, Youness Alaoui  wrote:
>> [...] Youness and others at Purism: if you are reading this, please do
>> spec a momentary switch to control flashing on future Librems. Your
>> security-conscious users will thank you for it.
>
> Yes, I already suggested it for the next iteration.

Great!

> It wouldn't be a switch though, but rather a low profile 90-degrees
> jumper on the motherboard.

This seems to imply that each time a Librem user wants to internally
flash the ROM, she would have to:

- power down the laptop(?);
- implement ESD precautions;
- remove the half a dozen or so tiny bottom case screws, without
losing them, and without stripping their heads or threads or threaded
inserts;
- remove the bottom case;
- move a tiny motherboard jumper to "write-enable", without losing it;
- power up the laptop with the bottom case off(?);
- run FlashROM (or equivalent);
- power down the laptop again(?);
- move the tiny motherboard jumper to "write-protect", without losing it;
- push-fit the bottom case correctly;
- insert the half a dozen or so tiny bottom case screws, without
losing them, and without stripping their heads or threads or threaded
inserts;
- power the laptop back up(?).

Surely, having a momentary switch next to the existing kill switches
would be *much* more user-friendly! With such a switch, such a user
would just have to:

- hold the switch down while starting Flashrom (or equivalent);
- release the switch and let the flashing process finish.


> As for your question earlier about someone forgetting it. I would
> assume that it would be easy to have the Heads menu show a big warning
> to the user if it's left unprotected

Your assumption fails against a BadHeads attack.


> Right now, if you boot into linux while ignoring tampering, you get
> your ttys in red, as a huge and very visible warning.

Only in the absence of BadHeads.


> Also, yes Sam, you did understand me perfectly, thanks!

Great! :)

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

Re: [coreboot] SPI controller and Lock bits

[Sam Kuper]

On 29/09/2018, ron minnich  wrote:
> On Sat, Sep 29, 2018 at 1:59 PM Sam Kuper  wrote:
>> Small momentary switches cost pennies and laptops usually have about a
>> hundred of them fitted, of various kinds. (Power on/off/suspend;
>> volume up/down; keyboard keys; maybe others.) So, fitting laptops with
>> momentary switches is definitely acceptable to manufacturers.
>
> I'm guessing you don't work in a company that designs or builds laptops :-)

True enough. I have worked at a company that designed and built other
consumer electronics, though, and spent time with people speccing PCBs
and custom silicon.

> b/c they agonize over parts like this. I ran into one situation where the
> ODM removed a single pulldown to save cost. One little
> almost-too-small-to-see part which cost a fraction of a cent. But a laptop
> BOM is a consequence of thousands of decisions of this type.
>
> Nope, the switch is definitely a non-starter, esp. given that there are
> solutions that don't require it.
>
> It's not just the part. A single simple part like that has all kinds of
> follow-on effects that are not obvious unless you've been at a company
> which designs and builds consumer electronics.

Thank you for the perspective. I do understand that changing one
component can affect others.

Purism isn't a typical laptop company. The addition of hardware
switches, to control webcam, mic and Wi-Fi, is one of the USPs for
their Librem models. These undoubtedly had knock-on effects for the
BOM. Purism was undeterred by that. In that context...

I'm just asking for one more switch.

So, Youness and others at Purism: if you are reading this, please do
spec a momentary switch to control flashing on future Librems. Your
security-conscious users will thank you for it.

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

Re: [coreboot] SPI controller and Lock bits

[Sam Kuper]

On 29/09/2018, ron minnich  wrote:
> It's not a screw in Chromebooks any more, see vadim's excellent OSFC.io
> talk on how it works now.

Vadim Bendebury? This talk below?

https://osfc.io/talks/google-secure-microcontroller-and-ccd-closed-case-debugging

If so, is there a video or audio recording available? Thanks.

> I think the momentary switch would not be acceptable to anyone for cost

Small momentary switches cost pennies and laptops usually have about a
hundred of them fitted, of various kinds. (Power on/off/suspend;
volume up/down; keyboard keys; maybe others.) So, fitting laptops with
momentary switches is definitely acceptable to manufacturers.

> and reliability reasons.

Such switches are often rated for ~100,000 cycles. It seems unlikely
that any laptop or its owner would live long enough to flash the ROM
chip even close to 100,000 times. So, I don't anticipate a reliability
problem.

> The way chromebooks do the protection now is really well done.

I look forward to reading Vadim's slides, and perhaps also to watching
or listening to his talk. Thanks for the pointer.

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

Re: [coreboot] SPI controller and Lock bits

[Sam Kuper]

I have been giving Youness's reply some thought.

On 29/09/2018, Peter Stuge  wrote:
> Youness Alaoui wrote:
>> On Thu, Sep 27, 2018 at 10:18 PM Sam Kuper  wrote:
>>> Relevant URL:
>>> https://www.chromium.org/chromium-os/ec-development#TOC-Write-Protect
>>
>> We don't have/use ChromeEC and I think that telling every user that
>> they'd need dedicated hardware to update their BIOS makes no sense.
>
> I think you can decide what hardware your products include, right? I
> meant dedicated hardware on the mainboard.

I think Youness's point, essentially, was that with:

- Heads running from the ROM chip; and
- suitable secrets sealed in the TPM; and
- additional suitable secrets sealed in a Nitrokey;

any additional dedicated hardware on the motherboard would be
unnecessary in order to achieve:

- a "secure", pre-OS environment in which to upgrade Heads; and
- a way to prevent the OS from flashing the ROM.

(Youness, please correct me if I misunderstood you.)

That is all good stuff, and I want it to be achieved. However, I don't
think it goes far enough.

I know that several Chromebooks, as described at the URL above,
include a hardware switch (typically implemented as a screw or bolt
acting as a *latching* SPST switch) that allows ROM flashing to be
enabled/disabled. This seems to me a step in the right direction, but
I don't think it goes far enough, either.

Personally, I would prefer that, in addition to the Heads approach, a
hardware switch should be present, but unlike on the Chromebooks it
should be a *momentary* switch that stays in the write-protect
position by default, and that has to be held in the write-enable
position in order for the flashing process to be able to begin.
(Essentially, a "dead man's handle" or fail-safe.) This mitigates two
potential attack vectors:

1. a user, after she sets her Chromebook-style latching hardware
switch to write-enable and flashes the ROM, forgets to set the
hardware switch back to write-protect, leaving the ROM vulnerable;

2. a remote attacker finds a way to write a "badHeads" to the ROM from
the OS.[1][2][3]


>> > > Looking for a software solution is IMO like Intel trying to secure
>> > > SMM.
>>
>> I don't see why that would be true, the software solution is pretty
>> simple. You boot, you can write to the flash in a secure environment,
>
> Intel also considered SMM a secure environment, until they realised
> that it isn't. These days I think they consider ME a secure environment.

Ouch! It's unkind to liken Heads developers to ME developers... :p

- Sam


[1] 
https://forums.puri.sm/t/prevent-bios-being-flashed-by-root-level-attacker-without-physical-access/3786/3

[2] 
https://forums.puri.sm/t/prevent-bios-being-flashed-by-root-level-attacker-without-physical-access/3786/4

[3] 
https://forums.puri.sm/t/prevent-bios-being-flashed-by-root-level-attacker-without-physical-access/3786/6

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

Re: [coreboot] SPI controller and Lock bits

[Sam Kuper]

On 28/09/2018, Peter Stuge  wrote:
> Youness Alaoui wrote:
>> avoid any malware writing to the flash
>
> Just disallow flash writes by the platform. Allow flash writes only
> by dedicated hardware (maybe ChromeEC?) which implements a simple and
> efficient security protocol.

Relevant URL: 
https://www.chromium.org/chromium-os/ec-development#TOC-Write-Protect


> Looking for a software solution is IMO like Intel trying to secure SMM.

Hear, hear!

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

Re: [coreboot] Who is still using a 1980's tty for coreboot development?

[Sam Kuper]

As mentioned in my earlier message in this thread, I don't have an
iron in this fire. I'm just trying to be helpful.

On 25/05/2018, Nico Huber  wrote:
> So I would compromise as follows:
>
>   o Set a hard limit around 100 chars (96 would be a nice number).
>   o If a line doesn't contain a string literal, recommend a
> visible width <= 72 chars.

This makes good sense except that it would seem to require the editing
environment to be specially configured to recognise lines with string
literals so as to be able to auto-wrap them, or to warn about them,
differently to other lines. Depending upon the text editor involved,
that might be non-trivial; I don't know.

On a more general note: I expect most people on this list are already
aware that there have been various efforts over the years to create
decent coding standards or style guides for various languages,
including conventions about line length, and to translate some of them
into text editor configuration files or linting tools for automated
feedback. For those who weren't aware, see e.g.:

http://editorconfig.org/

https://en.wikipedia.org/wiki/Lint_(software)

https://en.wikipedia.org/wiki/Gnits_standards

https://www.kernel.org/doc/html/v4.10/process/coding-style.html

https://github.com/google/styleguide

It seems to me that sticking to a style guide that is well-supported
by text editors and linting tools would be a wise thing to do, to
minimise manual labour, human error, and development environment
configuration effort, even if it does mean occasionally needing to
manually break string literals at 80chars or suchlike.

(I'll duck out of the conversation now.)

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

Re: [coreboot] Who is still using a 1980's tty for coreboot development?

[Sam Kuper]

On 25/05/2018, Goetz Salzmann  wrote:
> On Fri, May 25 '18 at 10:15, Patrick Georgi via coreboot wrote:
>> That is, who would unbearably suffer from 132 characters per line of
>> code?
>
> See https://mobile.twitter.com/changelog/status/999652792707858433

:D

Like quite a few people I've encountered, I set up my text editing
environment to make ≤80cpl convenient and ergonomic, because:

(a) it is such a prevalent convention; and

(b) ≤80cpl is very readable (at least, it is for me and quite a few
other people; and

(c) typically, when I encounter a codebase that doesn't follow ≤80cpl,
it doesn't follow *any* cpl convention and needs taking in hand.

Sticking to ≤80cpl should make it easier for anyone else, who also
does that, to work with the Coreboot codebase without having to modify
their text editing environment.

However...

> [On] the other hand I do so little
> coreboot development, that you should not base any decision on my humble
> opinion.

Ditto ;)

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

Re: [coreboot] Server systems shipped with coreboot

[Sam Kuper]

On 23/03/2018, Thierry Laurion  wrote:
> If ... ME is disabled with its modules erased, could
> the maker pursue the seller for having made those modifications?

Interesting question. ThinkPenguin seems to be willing to take that
risk, but hedges it by voiding the warranty:

"Backdoors in modern computing devices are unfortunately a certainty
today and while we can't be sure of a fix here it is possible to
partially disable one component believed to be a problem. This option
does have side-effects and will void any return." [1]

(AFAICT, that laptop has the ME "disabled" if the buyer wishes, but it
does not ship with Coreboot or Libreboot.)

[1] https://www.thinkpenguin.com/gnu-linux/penguin-z-gnulinux-laptop

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

Re: [coreboot] smd work

[Sam Kuper]

On 28/12/2017, ron minnich  wrote:
> Soldering irons? hot air guns? magic wands?

I haven't used one so can't comment personally (and I don't have any
stake in it, either), but as it seems both to be incredibly popular
and to be suitable for single chip reworking, I'll mention the TS100,
which is a compact soldering iron with built-in thermostat and
microcontroller.

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

Re: [coreboot] How to properly conform with GPLv2 for Coreboot and SeaBIOS on an embedded system

[Sam Kuper]

Hi Ian,

On 24/12/2017, Lewis, Ian (Microstar Laboratories)  wrote:
> I have read this page
> https://www.softwarefreedom.org/resources/2008/compliance-guide.html
> several times, a number of other sites, as well as reading the GPLv2
> itself.

I want to echo Peter Stuge on these points...

On 24/12/2017, Peter Stuge  wrote:
> Thank you for reaching out to the community with your very valid concerns!
>
> You are asking exactly the right questions.
>
> In the end, the community can't provide you with legal advice

... and to add a caveat to these points from Peter:

>> If this is the wrong forum for this kind of question, I apologies. And,
>> I would appreciate if someone could point me to an appropriate forum.
>
> I think SFLC is a good point of contact, and FSF Europe also have a
> strong focus on applied use of free software code.
>
> http://fsfe.org/activities/ftf/documentation.en.html
> http://fsfe.org/activities/ftf/services.html
> http://gpl-violations.org/faq/vendor-faq/
>
> And if you are interested to connect your legal counsel with experts on
> the field of free software licensing, then this may be relevant:
>
> http://fsfe.org/activities/ftf/ln.en.html

The caveat is that this is all good advice *except* that instead of
contacting the SFLC (i.e. the Software Freedom Law Centre, run by Eben
Moglen et al), it might be better for you to contact the SFC (the
Software Freedom Conservancy, run by Bradley Kuhn, Karen Sandler, et
al).

In my opinion, the SFLC was still giving decent advice in 2008, which
is when it published the post you linked to. But it has, sadly,
behaved rather confusingly of late. By contrast, the SFC has always,
as far as I know, taken a reasonable and consistent stance in its
work. For more about the SFLC's recent, unfortunate behaviour, see:

- https://mjg59.dreamwidth.org/49370.html

- http://www.rants.org/2017/11/conservancy_sflc_dispute/

- https://lwn.net/Articles/738046/

Wishing you a successful and GPL-compliant product!

Sam

-- 
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] 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] Coreboot wiki: what license is the content under?

[Sam Kuper]

On 03/04/2017, Sam Kuper <sam.ku...@uclmail.net> wrote:
> On 03/04/2017, ron minnich <rminn...@gmail.com> wrote:
>> Could we, please, agree on what the question is; write the question; and
>> ask a lawyer, preferably someone involved in the CC license creation in
>> the first place? All this interpretation of legalese by coders is bound to
>> end badly.

Having re-read the emails from Nico Huber and from David Hendricks in
this thread, and having also re-read the relevant parts of the FAQ, I
now agree with Nico and David about how to interpret CC BY.

Even so, I remain in favour of CC BY-SA 3.0 over CC BY, in order to
achieve license compatibility with Wikipedia, Stack Exchange, OpenZFS,
and various other wikis and technical documentation projects that
might want to include content from the coreboot wiki or vice versa.

> Here is the email I sent to Creative Commons. It is imperfect, but I
> hope will be good enough. [...]

Mari from Creative Commons replied to me, offering to check with the
Creative Commons legal team whether CC BY 3.0 gives an adapter
permission to apply a different license to the work as a whole (as I
formerly thought) rather than just to the adapter's contribution (as
David and Nico believe).

Because there now seems to be unanimity within the mailing list on how
to interpret CC BY, getting a lawyer's opinion may be superfluous.
However, I would be happy to accept Mari's offer if you or other core
coreboot contributors would like me to.

Best regards

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

[coreboot] ECC RAM in coreboot-compatible X-series ThinkPads?

[Sam Kuper]

IIUC, conventional ECC RAM requires support from both the motherboard
and the CPU. This support is not present in current
coreboot-compatible X-series ThinkPads (e.g. X60, X200, X201, X220,
X230).

There was a discussion on the coreboot mailing list a couple of months
ago about RAM modules from "I'M Intelligent Memory". That discussion
focused on the fact that they are 16GB in size.
https://mail.coreboot.org/pipermail/coreboot/2017-February/083330.html

Potentially more interesting, though, is that at least some modules
from that company offer *integrated ECC*, which provides ECC in RAM
without requiring support from either the CPU or the motherboard:

http://www.electronicsbus.com/new-256mb-and-512mb-sdram-x8x16x32-memories-with-integrated-error-correction-ecc-from-intelligent-memory/

As I understand it, none of the modules from that manufacturer are
currently able to work in coreboot-compatible X-series ThinkPads, but
this did get me wondering:

- Are there any other manufacturers offering RAM modules with
integrated ECC that *are* compatible with those ThinkPads?

- Is there any other way to achieve ECC in coreboot-compatible
X-series ThinkPads? (E.g. use I'M Intelligent Memory 16GB ECC RAM
sticks but only address the first 8GB of each one?)

This is a shot in the dark, I know, but it seemed worth asking :)

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

Re: [coreboot] ThinkPad X201 status?

[Sam Kuper]

Hi Marek,

On 13/04/2017, Marek Behun  wrote:
> this week I have been trying coreboot master and coreboot-4.5 on my
> ThinkPad X201.

I had a go with coreboot master on the X201 last month.

> coreboot-4.5 does not work (display stays dark)
> coreboot-master boots, is working, but:
>   - when powering off, the system halts (display stays on), the cpu is
> in some kind of a loop since there is heat coming out from the fan
>   - suspending to ram does not work: the same thing happens as when
> powering off, I have to manually disable it

Interesting.

My experiences were slightly different. In case they are useful to
you, you can read about them here:

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

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

Best wishes

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

Re: [coreboot] Coreboot wiki: what license is the content under?

[Sam Kuper]

On 03/04/2017, ron minnich <rminn...@gmail.com> wrote:
> Could we, please, agree on what the question is; write the question; and
> ask a lawyer, preferably someone involved in the CC license creation in the
> first place? All this interpretation of legalese by coders is bound to end
> badly.

Here is the email I sent to Creative Commons. It is imperfect, but I
hope will be good enough.




Dear Creative Commons staff,


The coreboot project is discussing adopting a CC BY or CC BY-SA
license for its wiki content. A question arose about CC BY. Please can
you answer it? (For the source of the confusion, see the postscript to
this email.)

Suppose Alice publishes her work Alpha under CC BY 3.0.

Suppose Bob substantially adapts Alpha into the new work Beta that
bears his personality.

Assuming that wherever Bob publicly performs or distributes Beta, he
notes that it is based on Alpha by Alice that was licensed under CC BY
3.0: **can Bob offer the entire work Beta under CC0**?


Many thanks for your time,

Sam Kuper


P.S. The question seems to hinge on whether the sentence highlighted
with asterisks here in Wikipedia's definition of a derivative work is
correct: a "derivative work is an expressive creation that includes
major copyright-protected elements of an original, previously created
first work (the underlying work). **The derivative work becomes a
second, separate work independent in form from the first.** The
transformation, modification or adaptation of the work must be
substantial and bear its author's personality to be original and thus
protected by copyright." (Source:
https://en.wikipedia.org/w/index.php?title=Derivative_work=769964199
.)

It also hinges on how exactly to interpret the yellow box at the
intersection of the "BY" row and the "PD" column in the "Adapter's
license chart" at https://creativecommons.org/faq/ .

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

Re: [coreboot] Coreboot wiki: what license is the content under?

[Sam Kuper]

Hi David,

Thanks for taking the time to write this. It was very clear.

In the light of your email, and the part of the Creative Commons FAQ
that you quoted, I am questioning my previous position. I will clarify
what it was, in case anyone is interested.



On 02/04/2017, David Hendricks <david.hendri...@gmail.com> wrote:
> On Sun, Apr 2, 2017 at 11:05 AM, Sam Kuper <sam.ku...@uclmail.net> wrote:
> The fundamental disagreement seems to be how an adapter's chosen license
> applies to the original work.

Not quite. I think the disagreement has been about whether the
adapter's chosen license applies to the entire adapted work, or solely
to the adapter's contribution.

In coding terms, I was assuming that the adapter's license applies to
the body of code that results from applying the adapter's patch, but
not necessarily to the patch itself. My understanding was based upon
the text of the licenses, their human-readable summaries, the
"adapter's license chart", and especially the first three sentences of
Wikipedia's article "Derivative work":

A "derivative work is an expressive creation that includes major
copyright-protected elements of an original, previously created first
work (the underlying work). The derivative work becomes a second,
separate work independent in form from the first. The transformation,
modification or adaptation of the work must be substantial and bear
its author's personality to be original and thus protected by
copyright."

(Source: 
https://en.wikipedia.org/w/index.php?title=Derivative_work=769964199
.)

I assumed all three of those sentences were correct. I.e. the
derivative work is a second work that includes elements of the
underlying work, though those elements may have been transformed in
the process of making the derivative work.

I further assumed that the only entities licensable are works, and
that the only two works in the scenario described in those three
sentences were the ones explicitly named as such: the underlying work,
and the derived work.



I now see that there is a third work mentioned, but not explicitly
named as such: the "transformation, modification or adaptation"
itself. In coding terms: the patch. I now also see that you and Nico
were arguing that it is *this* work - the patch - to which the
adapter's license applies.



> Your argument seems to be that when an adapter chooses a license for their
> adaptation that the adaptation's license is applied to the original, i.e.
> the original work is re-licensed under different terms. Correct me if I'm
> wrong in my understanding of your argument.

That isn't quite what I was arguing :)

I did not believe that when an adapter chooses a license for an
adapted work, that this re-licenses the original work.

I believed that an adapter can, unless prevented from doing so by the
underlying work's license, apply a different license to an adapted
work; and that this license would apply to the entirety of the adapted
work.



> The FAQ clarifies the relationship between the license for the original
> work and the license an adapter chooses for their contribution:
> "If I derive or adapt material offered under a Creative Commons license,
> which CC license(s) can I use?
>
> If you make adaptations of material under a CC license (i.e. "remix"), the
> original CC license always applies to the material you are adapting even
> once adapted. The license you may choose for your own contribution (called
> your "adapter's license") depends on which license applies to the original
> material. Recipients of the adaptation must comply with both the CC license
> on the original and your adapter’s license."

Interesting.


> So here's how things would play out in the Alice, Bob and Mallory scenario
> you came up with:
> 1. Alice writes an article, publishes it under BY.
> 2. Bob adapts the article, gives proper attribution to Alice, and decides
> to license his contributions under CC0.
> 3. Mallory adapts Bob's article. Alice's original content is still covered
> by the BY license, so Mallory must give proper attribution to Alice. Bob's
> additions were CC0-licensed and have no such requirement.

(Note that Bob's modifications needn't be additions: they could be
subtractions or other transformations.)

Thank you for spelling this out. Your interpretation does indeed seem
to be consistent with the FAQ, and inconsistent with my previous
understanding as expressed above and in previous emails. I have
written to Creative Commons to seek confirmation, just in case I *was*
correct about the risk posed by CC BY, but it seems I was not.


>> The licenses, the human-readable summaries, and the CC FAQ all seem to
>> me to be consistent with my interpretation.
>
> Mine too ;-)

Indeed :)


> Good discussion, but I suppose it will take somebody with access to a
> l

Re: [coreboot] Coreboot wiki: what license is the content under?

[Sam Kuper]

On 02/04/2017, Nico Huber  wrote:
> As the license doesn't de-
> fine it, I can only assume that copyright applies.

I agree that copyright applies, but AIUI, the rights granted in the
license also apply.

> And copyright doesn't
> magically jump over to a translator, AFAIK.

Agreed.

Anyhow, we're going in circles here. I'll email you off-list to see if
we can agree on a question to submit to Creative Commons (and/or the
Conservancy, if you prefer) in the hope of settling this.

Regards.

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

Re: [coreboot] VGA and Graphics

[Sam Kuper]

On 02/04/2017, Todd Weaver  wrote:
> On 04/01/2017 04:55 PM, Trammell Hudson wrote:
>> On Sat, Apr 01, 2017 at 07:43:40PM +, ron minnich wrote:
>>> 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.
>
> 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? [...]
>
> 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)

Presumably petitboot, u-root, or another "boot menu type thing" could
be included in Heads? This would seem to be the best outcome.*

Whether that would still fit into 4MB is another matter, but it seems
worth a try. Even 8MB or 12MB would make it usable on some existing
motherboards without the need to desolder anything.

I look forward to seeing what emerges from your (hopeful) collaboration!

* Formal verification of all this would be even better, but that's
probably several years in the future :)

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

Re: [coreboot] Coreboot wiki: what license is the content under?

[Sam Kuper]

Hi folks,

I do understand Nico's concern that my interpretation of CC BY 3.0
(see earlier emails in this thread) is inaccurate, and I think it is
right that, having this concern, he should challenge me to back up my
interpretation.

However, as far as I can tell, my interpretation is consistent with
the interpretations given in the CC BY 3.0 license, the CC BY 3.0
"human-readable summary", and also the Creative Commons FAQ:
https://creativecommons.org/faq/ .

Search in that FAQ for the subheading "Adapter's license chart".
Beneath that is written: "When creating an adaptation of material
under the license identified in the lefthand column, you may license
your contributions to the adaptation under one of the licenses
indicated on the top row if the corresponding box is green. CC does
not recommend using a license if the corresponding box is yellow,
although doing so is technically permitted by the terms of the
license."

The box corresponding to the first adaptation example in the scenario
I gave in my earlier email (a CC BY-licensed work being adapted, and
the adaptation being licensed as CC0 (i.e. public domain or "PD")) is
yellow.

So, Creative Commons explicitly acknowledges that an adaptation of a
CC BY-licensed work can indeed be licensed under CC0 (or, at least,
that the adapter's contribution to the adaptation can be; which I note
would be the entire adaptation, in cases such as translations or other
comprehensive adaptations).

A second derivative in such a case (i.e. an adaptation of the
CC0-licensed work) can, of course, be licensed however the second
downstream adaptor wishes, as corroborated by the corresponding solid
green "PD" row in the table.

(Yes, I know that the FAQ also advises people using one of the yellow
cells in the adapter's license chart that they "should take additional
care to mark the adaptation as involving multiple copyrights under
different terms so that downstream users are aware of their
obligations to comply with the licenses from all rights holders." But
a *should* is not a *must*, and as is acknowledged in the previous
sentence in that FAQ, there is no technical requirement for them to do
so.)

As long as there is any *possibility* that my interpretation is
correct, CC BY-SA 3.0 seems like a much safer license for Coreboot to
use.


On 02/04/2017, Nico Huber <nic...@gmx.de> wrote:
> On 01.04.2017 17:19, Sam Kuper wrote:
>> In the case of both CC BY and CC BY-SA, the rights granted to the
>> *recipient of the licensed work* include the freedom to create
>> adaptations and to distribute or publicly perform them, subject *only*
>> to a small list of restrictions. CC BY has a shorter list of
>> restrictions than CC BY-SA.
>
> Perfectly summarized, yet you miss the point. It doesn't say anything
> about granting to change the terms.

I think you misunderstand how permissive licensing works.

You seem to be believe that the license would have to specifically
outline every possible thing that the licensee is permitted to do. I
think that is a false belief.

Licenses often grant the recipient the freedom to do with the work
whatever they like (i.e. including redistribution under a different
license, if they wish) as long as they adhere to some short list of
conditions.

The human-readable summary of CC BY 3.0 is pretty clear: "in any
medium or format", "for any purpose, even commercially", "The licensor
cannot revoke these freedoms as long as you follow the license terms,"
and "No additional restrictions". I'm curious what makes you think
that CC BY does in fact impose some unspecified restriction on the
license for an adapted work?



>> As such, CC BY grants the creator of an adapted work the freedom to
>> publicly performed or distribute that adapted work under a different
>> license.
>
> A license [...] can only restrict
> permissions it granted.

Essentially, yes.


> So again, this is only the case if the license
> explicitly states permission to license the adapted work under different
> terms.

I don't think this is correct.

It can say, "You can do whatever you like with this work except X."
(This is how the CC licenses are constructed, and likewise the various
BSD licenses, the Expat License, and the X11 License.)

It does not have to say, " You can do A or B or C ...  or V or W but not X."


> I see a pattern here: Every time you claim this, you don't quote.

I've been citing the licenses themselves, and their "human-readable"
summaries, which were created by Creative Commons specifically to help
people interpret the licenses properly. That's about as authoritative
and clear a bunch of sources as one could hope for.


> Yet, you write thousands of words, have a quote on every other thing.
> Just to hide that you have nothing to substantiate 

Re: [coreboot] Coreboot wiki: what license is the content under?

[Sam Kuper]

Typo/clarity fixes.

On 01/04/2017, Sam Kuper <sam.ku...@uclmail.net> wrote:
> As such, CC BY grants the creator of an adapted work the freedom to
> publicly performed or distribute that adapted work under a different
> license.

s/performed/perform/

> Respectfully, I think you are still mistaken about this. "Relicensing"
> describes a new license is applied to a work (i.e. without the work
> needing to be altered). See https://en.wikipedia.org/wiki/Relicensing

The same thing, but expressed better:

Respectfully, I think you are still mistaken about this. "Relicensing"
describes a licensed work being made available with a license under
which it was not available (i.e. without the work itself needing to be
altered). See https://en.wikipedia.org/wiki/Relicensing . The key
point in relicensing is that the set of applicable licenses for the
work *does* change, but the work itself *does not* necessarily change.


Regards.

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

Re: [coreboot] Coreboot wiki: what license is the content under?

[Sam Kuper]

On 01/04/2017, Nico Huber <nic...@gmx.de> wrote:
> On 01.04.2017 01:39, Sam Kuper wrote:
>> On 31/03/2017, Nico Huber <nic...@gmx.de> wrote:
>>> On 31.03.2017 23:38, Sam Kuper wrote:
>>>> On 31/03/2017, David Hendricks <david.hendri...@gmail.com> wrote:
>>>>> On Fri, Mar 31, 2017 at 10:20 AM, Sam Kuper <sam.ku...@uclmail.net>
>>>>> wrote:
>>>>>> Also, to further address Patrick's point above about marketing
>>>>>> material: it is important that the provenance of information about
>>>>>> Coreboot can be established. This is a reputational matter. That
>>>>>> means
>>>>>> it is important that people should not legally be able to
>>>>>> misrepresent
>>>>>> Coreboot contributors' views, etc,
>>>>>
>>>>> Both CC-BY and CC-BY-SA have "no endorsement" clauses
>>>>
>>>> Yes, but because CC BY imposes no restrictions on *second*-derivative
>>>> works,
>>>
>>> [...]
>>> I'm not convinced. Relicensing adapted
>>> work under different conditions would require the explicit permission
>>> by the copyright holder.
>>
>> No, it wouldn't. That's what makes CC BY different from CC BY-SA.
>
> So it changes copyright itself?

Absolutely not!

Like any such license, it relies on copyright law to grant the
*recipient of the licensed work* certain rights (a.k.a. freedoms).
I'll explain this in more detail in the next few paragraphs, but
before that, here's a tl;dr right up front.



Read the "human-readable summaries" of CC BY and CC BY-SA, and spot
the difference:

- https://creativecommons.org/licenses/by/3.0/

- https://creativecommons.org/licenses/by-sa/3.0/



In the case of both CC BY and CC BY-SA, the rights granted to the
*recipient of the licensed work* include the freedom to create
adaptations and to distribute or publicly perform them, subject *only*
to a small list of restrictions. CC BY has a shorter list of
restrictions than CC BY-SA.

CC BY-SA's list of restrictions includes a restriction on the license
under which an adapted work can be distributed or publicly performed.
See §4.b "only under the terms of: (i) this License; (ii) a later
version of this License with the same License Elements as this
License; (iii) a Creative Commons jurisdiction license (either this or
a later license version) that contains the same License Elements as
this License (e.g., Attribution-ShareAlike 3.0 US)); (iv) a Creative
Commons Compatible License."

CC BY's list of restrictions does not include such a restriction.


As such, CC BY grants the creator of an adapted work the freedom to
publicly performed or distribute that adapted work under a different
license.


(Put in more traditional terms, CC BY-SA is a copyleft license; CC BY
is a permissive license.)


>>> And I can't find that permission in CC BY.
>>
>> See, especially, §1(a), §1(c), §1(h), §3(b), §3(d), and §4(b):
>> https://creativecommons.org/licenses/by/3.0/legalcode
>
> Seriously, I ask for a single thing and you want me to search the answer
> in six places?

I was trying to be helpful. I did not write the license, and I am not
responsible for how it is laid out. Don't shoot the messenger. Read
those clauses, and they'll basically answer your concern without you
having to read the rest of the license.

Alternatively, read the whole license; it is commendably short. Or,
just compare the "human-readable summary" of CC BY 3.0 with that of CC
BY-SA 3.0, as suggested in my TL;DR above.




> If
> you really doubt the usefulness of CC BY, please take that to CC.

I don't doubt its usefulness. I do, however, severely doubt that it is
a wise choice for the Coreboot wiki content.

I think it is a great license for a creator who only cares about
receiving attribution for some work itself and for first derivatives
of that work, and who is fine with provenance and credit disappearing
or mutating after that. Such people do exist. (If I were writing a
throwaway piece - maybe a poem or a song - and I liked the thought of
pieces of it being adapted and then adapted again, such that my
adapters' adapters wouldn't have to credit me, I might be tempted to
use CC BY.)



>> (And I think you mean "licensing" rather than "relicensing", assuming
>> we are both talking about the first time that the *adapted work* is
>> licensed to the public.)
>
> No, I meant relicensing. If you license adapted work you "relicense" the
> parts which you don't have the copyright for.

Respectfully, I think you are still mistaken about this. "Relicensing"
describes a new license is applied to a work (i.e. without the work
needing t

Re: [coreboot] Coreboot wiki: what license is the content under?

[Sam Kuper]

On 31/03/2017, Nico Huber <nic...@gmx.de> wrote:
> On 31.03.2017 23:38, Sam Kuper wrote:
>> On 31/03/2017, David Hendricks <david.hendri...@gmail.com> wrote:
>>> On Fri, Mar 31, 2017 at 10:20 AM, Sam Kuper <sam.ku...@uclmail.net>
>>> wrote:
>>>> Also, to further address Patrick's point above about marketing
>>>> material: it is important that the provenance of information about
>>>> Coreboot can be established. This is a reputational matter. That means
>>>> it is important that people should not legally be able to misrepresent
>>>> Coreboot contributors' views, etc,
>>>
>>> Both CC-BY and CC-BY-SA have "no endorsement" clauses
>>
>> Yes, but because CC BY imposes no restrictions on *second*-derivative
>> works,
>
> [...]
> I'm not convinced. Relicensing adapted
> work under different conditions would require the explicit permission
> by the copyright holder.

No, it wouldn't. That's what makes CC BY different from CC BY-SA.

(And I think you mean "licensing" rather than "relicensing", assuming
we are both talking about the first time that the *adapted work* is
licensed to the public.)

> And I can't find that permission in CC BY.

See, especially, §1(a), §1(c), §1(h), §3(b), §3(d), and §4(b):
https://creativecommons.org/licenses/by/3.0/legalcode

Regards.

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

Re: [coreboot] Coreboot wiki: what license is the content under?

[Sam Kuper]

On 31/03/2017, Sam Kuper <sam.ku...@uclmail.net> wrote:
> Mallory, a malfeasor, spots Bob's newsletter in a cafe. She smells
> opportunity. She creates a derivative of Bob's piece, comprising "Quul
> Bal Bal Fol." Mallory publishes this under her own name, claiming
> authorship (as she is entitled to do, under CC-0).

That is, under Bob's CC-0 license. Also, Mallory *does not* mention or
credit Alice or Bob in any way. And finally, to be clear, Mallory
*does not* publish "Quul Bal Bal Fol" under a Free Culture license.

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

Re: [coreboot] Coreboot wiki: what license is the content under?

[Sam Kuper]

On 31/03/2017, David Hendricks <david.hendri...@gmail.com> wrote:
> On Fri, Mar 31, 2017 at 10:20 AM, Sam Kuper <sam.ku...@uclmail.net> wrote:
>> Also, to further address Patrick's point above about marketing
>> material: it is important that the provenance of information about
>> Coreboot can be established. This is a reputational matter. That means
>> it is important that people should not legally be able to misrepresent
>> Coreboot contributors' views, etc,
>
> Both CC-BY and CC-BY-SA have "no endorsement" clauses

Yes, but because CC BY imposes no restrictions on *second*-derivative
works, it is powerless to prevent such works from claiming endorsement
(or, indeed, to prevent them from claiming whatever they please).[2]


> and the source
> of derived materials will still be easily traced back to coreboot.org
> (or archive.org or wherever).

Not necessarily, and especially not if no attributions are included
(which, again, could well be the case with second-derivative works if
the wiki used CC BY licensing instead of CC BY-SA).


>> or claim Coreboot contributors'
>> work as their own.
>
> Both BY and BY-SA licenses require attribution.

Yes, but again, because first derivatives of CC BY works are not
required to share alike, second-derivatives of CC BY works are not
necessarily required to provide attribution.


>> [1] How so? Because a licensee who creates a derivative work of a CC
>> BY-licensed work can license that derivative under terms (e.g. CC-0)
>> that would allow *their* licensees do potentially misattribute or
>> otherwise create reputational risk without fear of breaching licensing
>> terms.
>
> Section 3.A.4 of the BY license covers that: "If You Share Adapted
> Material You produce, the Adapter's License You apply must not prevent
> recipients of the Adapted Material from complying with this Public
> License."
>
> So distributing a derived work with a different license does not
> nullify the original terms.

I believe you have misinterpreted that clause. Specifically, you have,
I think, mistakenly interpreted "must not prevent recipients of the
Adapted Material from complying" as meaning "must require recipients
of the Adapted Material to comply".


Regards.


[2] For purely illustrative purposes, suppose the original work
comprised "Foo Bar Baz Quux." (That is obviously too short and
unoriginal to be copyrightable, but this is just an illustration, so
replace it, in your imagination, with a substantial and convincing
copyrightable work.) Suppose it is copyright Alice, and Alice
publishes it under CC BY 3.0 on an obscure, low-traffic wiki, hoping
to capture the public's imagination and gain support for her cause.

Suppose Bob, in good faith, creates a legitimate derivative work
comprising "Fol Bal Bal Quul." Bob publishes this in an obscure,
offline newsletter, under a CC-0 license, noting in a footer that it
is an adaptation of Alice's CC BY 3.0 work, and providing the URL to
the original. He sends a copy to Alice.

Mallory, a malfeasor, spots Bob's newsletter in a cafe. She smells
opportunity. She creates a derivative of Bob's piece, comprising "Quul
Bal Bal Fol." Mallory publishes this under her own name, claiming
authorship (as she is entitled to do, under CC-0). It is extremely
successful, and Mallory is widely given credit, even though in truth
Mallory could never have come up with it by herself. This is extremely
hurtful to Alice, because she finds the message "Quul Bal Bal Fol"
extremely distasteful, and it means nothing like "Foo Bar Baz Quux",
even though she can see that it was ultimately based upon her original
work. Unfortunately, it is too late: Mallory has captured the public's
imagination. Almost everyone who might originally have been interested
in Alice's message are instead distracted by Mallory's vision. Whole
businesses put their weight behind "Quul Bal Bal Fol", even though it
is deeply inferior to "Foo Bar Baz Quux", because they never heard
about "Foo Bar Baz Quux". Mallory earns a fortune from "Quul Bal Bal
Fol". People searching the web for "Quul Bal Bal Fol" never find "Foo
Bar Baz Quux" in their search results, because it is just different
enough to rank poorly compared to all the publicity received by "Quul
Bal Bal Fol". And because Mallory's work was legitimately derived from
Bob's CC-0 work, Alice cannot readily sue Mallory for a breach of
license, and has, essentially, no sure recourse whatsoever.

(Replace "Alice" with "Coreboot" in the above, and you can, I hope,
see why I dislike the idea of Coreboot adopting a CC BY license.)

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

Re: [coreboot] Coreboot wiki: what license is the content under?

[Sam Kuper]

On 31/03/2017, Timothy Pearson <tpear...@raptorengineering.com> wrote:
> On 03/31/2017 11:17 AM, Sam Kuper wrote:
>> On 30/03/2017, Patrick Georgi via coreboot <coreboot@coreboot.org> wrote:
>>> I'd go with CC-BY for the simple reason that documentation acts as
>>> marketing material which should see the widest distribution possible.
>>
>> This does not make sense to me. CC BY-SA would not hinder distribution
>> of documentation.
>
> Documentation, on the other hand, is designed for public consumption and
> is generally a thankless chore for developers who would much rather be
> adding new features to the software than writing things they already
> know down.  Perhaps the knowledge that someone's name will be attached
> in perpetuity to the documentation they write might just motivate
> creation of more material?

Exactly. Which is one of several reasons why I think CC BY-SA would be
better for Coreboot than CC BY would be.

(My understanding, based upon your email above, and upon your first
reply in this thread, is that you agree with me. Thanks again for
caring about this!)

Also, to further address Patrick's point above about marketing
material: it is important that the provenance of information about
Coreboot can be established. This is a reputational matter. That means
it is important that people should not legally be able to misrepresent
Coreboot contributors' views, etc, or claim Coreboot contributors'
work as their own. Sure, there are, in some jurisdictions, protections
against that sort of thing besides licensing provisions, but licensing
provisions can help in this regard. CC BY-SA provides much better
protection on this front than CC BY does[1] which means, in my view,
that even from a purely marketing perspective, CC BY-SA soundly beats
CC BY.

Regards.

[1] How so? Because a licensee who creates a derivative work of a CC
BY-licensed work can license that derivative under terms (e.g. CC-0)
that would allow *their* licensees do potentially misattribute or
otherwise create reputational risk without fear of breaching licensing
terms.

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

Re: [coreboot] Coreboot wiki: what license is the content under?

[Sam Kuper]

On 30/03/2017, Patrick Georgi via coreboot  wrote:
> I'd go with CC-BY for the simple reason that documentation acts as
> marketing material which should see the widest distribution possible.

This does not make sense to me. CC BY-SA would not hinder distribution
of documentation.

> People who dislike licensing their content that freely can publish
> elsewhere and set up a (CC-BY'd) link.

Having people publish content outside the wiki and link to it from the
wiki would obviously lead to even more fragmentation of the
documentation than Coreboot already suffers from, making Coreboot
remain a project that requires a lot of effort to grok, and has slow
uptake. (Cf. Steve Krug's "Don't Make Me Think".)

Surely it would be better to aim to make the Coreboot wiki a "one-stop
shop" for information about Coreboot, as far as possible. This being
so, Coreboot ought to avoid licensing choices that foreseeably
fragment the documentation.

> In any case, we can (and IMHO should) decouple the discussions about
> dealing with current content and about future licensing.

Are you really willing to potentially throw away *that* many hundreds
of hours of volunteer documentation effort?

Regards

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

Re: [coreboot] Lenovo Thinkpad X201: Coreboot incompatible with me_cleaner

[Sam Kuper]

On 27/03/2017, Denis 'GNUtoo' Carikli <gnu...@no-log.org> wrote:
> On Tue, 21 Mar 2017 14:19:18 +0000
> Sam Kuper <sam.ku...@uclmail.net> wrote:
>> Nicola Corna pointed out to me that adding a timeout at
>> https://github.com/coreboot/coreboot/blob/master/src/northbridge/intel/nehalem/raminit.c#L1756
>> might solve this problem.
>>
>> (I guess the idea is that instead of waiting indefinitely for the ME
>> to load, Coreboot should instead just wait for a defined amount of
>> time and then plough on regardless.)
>>
>> Please can anyone here provide a suitable patch for me to test, or
>> failing that, point me to a similar timeout in another architecture's
>> raminit that I might use as a starting point?
>
> I'll send one. I didn't check for typos or spelling yet in the commit
> message.

Many thanks :)

P.S. For the benefit of future readers, the thread with Denis's new
patch for Nehalem/etc can be viewed here:
https://www.coreboot.org/pipermail/coreboot/2017-March/083798.html

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

Re: [coreboot] Coreboot wiki: what license is the content under?

[Sam Kuper]

On 28/03/2017, Dumitru Ursu  wrote:
> On 03/22/2017 12:39 AM, Martin Roth wrote:
>> I guess I dislike this as a reason for choosing our license.  If some
>> future Stack Exchange replacement comes along using a different
>> license, what then?  We're stuck with what we've already picked.
>
> To work around this, either the rights should be transferred to Coreboot
> (if it has a legal entity that is),

A reasonable suggestion. It would allow Coreboot to dual-license the
content under additional licenses as might be necessary.

> or you can license it with something
> like "CC-BY-SA 3.0 or later"

That would not make sense, because all CC BY-SA licenses already
include a clause along the lines "this version of the license or a
later one". For example, see 4(b):
https://creativecommons.org/licenses/by-sa/3.0/legalcode

Regards

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

Re: [coreboot] Lenovo Thinkpad X201: cannot boot encrypted Debian w/Coreboot & GRUB2

[Sam Kuper]

On 24/03/2017, Peter Stuge <pe...@stuge.se> wrote:
> Sam Kuper wrote:
>> GNUtoo in 2013:
>> GNUtoo in 2013:
>> phcoder in 2013:
>> phcoder in 2014:
>> Kl3 in 2015
>>
>> So, it would seem that during 2013-2015, native graphics init became
>> operational within Coreboot for the X201.
>
> TL;DR: That code was always poor, don't expect it to work reliably.
>
> Don't assume that any merged code is general and robust, only
> because it might have worked for some developers in some case.
>
> If you need reliable graphics init then please use the VGA BIOS until
> you can [sponsor someone who can] analyze and address (potentially
> also design) problems in the native graphics init C code.
>
> If you do go on into development, then please do not waste time on
> the native graphics init C code, but instead please work on making
> use of libgfxinit on the platform you are interested in. It is the
> way to go forward.

Thanks Peter. I appreciate your work on Coreboot, and your insight above.

I would still be interested in working .config files for the X201,
though ;) Why? Not only to see if your (or someone else's) .config
would succeed in building Coreboot for my X201 with native graphics
init, but also because more generally, from the perspective of
reproducible builds and reproducible research, it would be great to
see Coreboot users and developers publishing, for builds that they
have made:

- the .config ,

- the Git revision,

- whether me_cleaner was used,

- a hash (e.g. SHA512) of the resulting coreboot.rom , if the build succeeded,

- the success or otherwise of booting the build, and

- maybe the coreboot.rom file itself.

But perhaps I should air that general wish in another thread some
time, instead of hijacking this one! I should also research whether
anyone has aired similar wishes already :)

Best regards.

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

Re: [coreboot] Lenovo Thinkpad X201: cannot boot encrypted Debian w/Coreboot & GRUB2

[Sam Kuper]

On 23/03/2017, Arthur Heymans  wrote:
>> I tried again, this time with SeaBIOS instead of GRUB2 as the primary
>> payload, and with CoreInfo as a secondary payload. As above, I
>> selected "Use native graphics initialization" under "Devices" within
>> `make nconfig`. (See attached .config .)
>>
>> The result was the same as above: the backlight came on, but there was
>> nothing displayed on the screen.
>>
> I would not be too surprised if native graphic init is invalid for
> Nehalem, since looks like a rough copy of ivy/sandy bridge...
>
> (A quick look at the code tells me computing PLL divisors is too rough to
> be right in all cases. When it is too much out range for a display a lit
> up black screen is typically all you get...)

Interesting. Thank you very much for looking into this.

I wonder if this is a regression? The wiki states, "VGA Option ROM
(optional): you need it if you want graphics in SeaBIOS but most
payloads (e.g. GRUB2) work just fine without it (text mode or
corebootfb mode)".

That statement resulted from the following edits:

GNUtoo in 2013:
https://www.coreboot.org/index.php?title=Board:lenovo/x201=prev=11609

GNUtoo in 2013:
https://www.coreboot.org/index.php?title=Board:lenovo/x201=prev=11614

phcoder in 2013:
https://www.coreboot.org/index.php?title=Board:lenovo/x201=prev=12266

phcoder in 2014:
https://www.coreboot.org/index.php?title=Board:lenovo/x201=next=13360

Kl3 in 2015: 
https://www.coreboot.org/index.php?title=Board:lenovo/x201=next=16692

So, it would seem that during 2013-2015, native graphics init became
operational within Coreboot for the X201. So, if it was working then,
but isn't working now, that would seem to indicate a regression. I
have CC'd the people who I understand are the authors of those
commits. I would be grateful if anyone can shed light on this :)



> One option is to extract the option rom from vendor bios and use that
> for init.

True. I was hoping to avoid this, but you are right that I should give
it a go (at least, to rule out whether any other issues are causing
the blank screen).


> Another is to fix up that native graphic init.

That is beyond my present skill level, I fear ;)


> Last option is hook up libgfxinit, an alternative Intel display init
> code written in ada/spark, which might set up display correctly...

Nice. I will look into that when I get a chance. It might take me a
while. I haven't built an Ada toolchain before. Would be great if it
works, though!


>> Is there anyone on the list who has Coreboot working on an X201 who
>> would be willing to share their .config file, so that I might see how
>> they succeeded where I am failing?

This question still stands, especially for those I have CC'd, who seem
to have been successful with Coreboot and native graphics
initialization on the X201 :)

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

Re: [coreboot] Lenovo Thinkpad X201: cannot boot encrypted Debian w/Coreboot & GRUB2

[Sam Kuper]

On 22/03/2017, Sam Kuper <sam.ku...@uclmail.net> wrote:
> On 22/03/2017, Sam Kuper <sam.ku...@uclmail.net> wrote:
>> On 22/03/2017, Nico Huber <nic...@gmx.de> wrote:
>>> Easiest option seems to be to select CONFIG_MAINBOARD_DO_NATIVE_VGA_INIT
>>
> Based on your suggestion above, I kept everything as described in my
> first email in this thread, except that to build Coreboot, I also
> selected "Use native graphics initialization" under "Devices" within
> `make nconfig`. (This sets CONFIG_MAINBOARD_DO_NATIVE_VGA_INIT=y in
> the .config .)
>
> Unfortunately, my results were exactly the same as before, except that
> this time the backlight came on. In particular, no GRUB2 prompt
> appeared.

I tried again, this time with SeaBIOS instead of GRUB2 as the primary
payload, and with CoreInfo as a secondary payload. As above, I
selected "Use native graphics initialization" under "Devices" within
`make nconfig`. (See attached .config .)

The result was the same as above: the backlight came on, but there was
nothing displayed on the screen.

I do think you are probably right about this issue (i.e. nothing being
displayed on the screen) being due to a failure to initialise the
graphics properly, and I am open to further attempts to overcome the
issue, as my time allows.

Is there anyone on the list who has Coreboot working on an X201 who
would be willing to share their .config file, so that I might see how
they succeeded where I am failing?

Thanks!


.config
Description: Binary data
-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Lenovo Thinkpad X201: cannot boot encrypted Debian w/Coreboot & GRUB2

[Sam Kuper]

On 22/03/2017, Sam Kuper <sam.ku...@uclmail.net> wrote:
> On 22/03/2017, Nico Huber <nic...@gmx.de> wrote:
>> On 22.03.2017 17:03, Sam Kuper wrote:
>> The GRUB payload, by default, doesn't have any configuration file and
>> will wait at the prompt (no matter if the disk is encrypted or not).
>
> Good to have this confirmed. From a GRUB prompt, I hope I will be able
> to find and boot the Debian installation.
>
>>> In any case, how would more
>>> experienced Corebooters suggest I proceed?
>>
>> Easiest option seems to be to select CONFIG_MAINBOARD_DO_NATIVE_VGA_INIT
>
> [Will] try it ASAP. Thank you!

Thanks again for this suggestion. I do feel it's getting me closer to
having Coreboot boot to Debian with FDE on the X201. However, there's
still a way to go...

Based on your suggestion above, I kept everything as described in my
first email in this thread, except that to build Coreboot, I also
selected "Use native graphics initialization" under "Devices" within
`make nconfig`. (This sets CONFIG_MAINBOARD_DO_NATIVE_VGA_INIT=y in
the .config .)

Unfortunately, my results were exactly the same as before, except that
this time the backlight came on. In particular, no GRUB2 prompt
appeared.

Is this expected? From your email, it sounds as though it isn't what
you expected.

I would be grateful for additional suggestions from you or other
experienced Corebooters :)

Thanks again!

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

Re: [coreboot] Lenovo Thinkpad X201: cannot boot encrypted Debian w/Coreboot & GRUB2

[Sam Kuper]

On 22/03/2017, Nico Huber <nic...@gmx.de> wrote:
> On 22.03.2017 17:03, Sam Kuper wrote:
>> -- Choose "GRUB2" as payload.
> You didn't select any option to initialize the display.
[...]
>> - After about 10 minutes, the fan spins up for a few seconds, then
>> spins back down. This repeats roughly every 10 minutes.
> I guess, you are at the GRUB console here, just without display.
[...]
> The only thing that is skipped is the display initialization. SeaBIOS
> does a legacy boot and detects the installed GRUB, runs it etc...
[...]

Interesting. A few days ago, I tried running Coreboot on the X201 with
a SeaBIOS payload and no SSD installed. IIRC, SeaBIOS did provide a
display at that point. But maybe I am misremembering, and the SeaBIOS
display was actually something I only saw in QEMU.

That aside (which on reflection probably *was* in QEMU), your
explanation makes perfect sense :) I hadn't realised that Coreboot's
default would be *not* to initialise a display.

> The GRUB payload, by default, doesn't have any configuration file and
> will wait at the prompt (no matter if the disk is encrypted or not).

Good to have this confirmed. From a GRUB prompt, I hope I will be able
to find and boot the Debian installation.

>> In any case, how would more
>> experienced Corebooters suggest I proceed?
>
> Easiest option seems to be to select CONFIG_MAINBOARD_DO_NATIVE_VGA_INIT
>
> Hope that helps,

Very much so; will try it ASAP. Thank you!

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

[coreboot] Lenovo Thinkpad X201: cannot boot encrypted Debian w/Coreboot & GRUB2

[Sam Kuper]

Steps followed:

- Switch off X201; disconnect X201 PSU and battery.

- Flash X201 using Bus Pirate, with OEM BIOS that has had its ME
neutralised with me_cleaner, noting that Flashrom reported "VERIFIED".

- Disconnect Bus Pirate from X201.

- Reconnect X201 PSU.

- Press power button, then F12 to select CD-ROM as boot media.

- Boot Debian Jessie AMD64 NetInstall CD-ROM.

- Install Debian Jessie to X201's SSD, using guided install (full disk
with encrypted LVM, and GRUB2 on the SSD).

- Eject CD.

- Boot X201 from SSD; everything works as expected.

- Boot X201 from SSD again; again, everything works as expected.

- Switch off X201 and disconnect X201 PSU.

- On spare PC, in Coreboot directory:

-- make distclean && make nconfig

-- Choose "Lenovo" as mainboard vendor.

-- Choose "ThinkPad X201 / X201s / X201t" as mainboard.

-- Choose "Add Intel descriptor.bin file".

-- Choose "Add Intel ME/TXE firmware".

-- Choose "GRUB2" as payload.

-- make

- Flash resulting build/coreboot.rom to X201 with Bus Pirate, noting
that Flashrom reported "VERIFIED".

- Disconnect Bus Pirate from X201.

- Reconnect X201 PSU, confirming that "plugged in" LED indicator turns
on, just beneath the X201's display.

- Press power switch on X201.

- The X201's fan spins up, and the following LED indicators light up,
in addition to the power "plugged in" indicator: NumLock, CapsLock,
On, and Sleep.

- After about 1 second, the NumLock and Sleep LEDs turn off, and the
fan starts to spin down.

- After about 1 more second, the CapsLock LED turns off, leaving just
the "on" and "plugged in" LEDs lit.

- Nothing further happens for some time. The backlight doesn't turn
on, and the screen stays blank.

- After about 10 minutes, the fan spins up for a few seconds, then
spins back down. This repeats roughly every 10 minutes.

N.B. with the same X201, a day or two ago, I was able to use a
Coreboot build with a SeaBIOS payload to boot a non-encrypted Debian
installation from the SSD. Oddly, when I did that, there was no
SeaBIOS menu displayed, nor any GRUB2 menu displayed, even though the
unencrypted Debian install had placed a GRUB2 instance on the SSD: it
was as though Coreboot skipped both its own SeaBIOS payload in the
flash chip, AND the Debian-installed GRUB2 on the SSD, and somehow
went straight to the Debian login prompt.

Anyhow, I didn't want a non-encrypted Debian installation, I wanted an
encrypted one: hence the attempt above. I guess maybe what's happening
is that Coreboot is somehow this time skipping its GRUB2 payload much
as it previously seemed to skip its SeaBIOS payload, and likewise
skipping the Debian-installed GRUB2 instance on the SSD as it did
previously. Only this time, instead of finding an unencrypted drive
with a Debian kernel that it knows how to boot, Coreboot is instead
finding an encrypted partition that it doesn't know how to do anything
with.

Is my interpretation plausible? In any case, how would more
experienced Corebooters suggest I proceed?

I certainly would have expected, based on the Coreboot wiki's GRUB2
page,[1] at least a GRUB2 console.

In case it is useful, I have attached my .config file.

Many thanks in advance!


.config
Description: Binary data
-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Add me_cleaner to automated tests?

[Sam Kuper]

On 22/03/2017, Martin Roth  wrote:
> Here's the list of boards I've got for coreboot testing.
>
> https://www.coreboot.org/User:MartinRoth#Platforms_supported_by_coreboot
>
> My plan is to get as many of these as I can set up for automated testing.
>
> When new boards are added to the tree, I try to buy them if possible,
> but that's a lot of boards.  I've told my wife that every time she
> buys a pair of shoes, I get to buy a new computer.  It works out well
> for both of us, but she's still winning.  :)

Thanks :)

Interesting to see that there are no X-series laptops on your list,
given how much attention they receive from the Coreboot community. Did
you say your wife is a few pairs of shoes ahead of your board
collection? ;)

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

Re: [coreboot] Coreboot wiki: what license is the content under?

[Sam Kuper]

On 22/03/2017, Sam Kuper <sam.ku...@uclmail.net> wrote:
> On 21/03/2017, Martin Roth <gauml...@gmail.com> wrote:
>> Wouldn't selecting CC BY-SA 4.0 also prevent that, if they're licensed
>> at CC BY-SA 3.0?
>
> No, it would not prevent *importing* it, as the CC BY-SA licenses are
> forward-compatible.
>
> However, it would prevent *exporting* material from the Coreboot wiki
> to a CC BY-SA 3.0-licensed resource.

N.B. I might have used "forward-compatible" incorrectly above (perhaps
it should have been "backward-compatible"? I get those terms mixed
up...). Everything else there is correct, though. In short, CC
BY-SA-licensed material under a given version of that license can be
re-used under the same or later versions of the license but not under
earlier versions of the license. (I'm assuming all the other
requirements of the license are complied with.)

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

Re: [coreboot] Coreboot wiki: what license is the content under?

[Sam Kuper]

On 21/03/2017, Martin Roth  wrote:
> So from the start, I just want to say that I'm not arguing just to
> argue - I want to make sure we pick the correct license here.

Likewise, and thanks for clarifying :)

I appreciate your questions and have done my best to answer them.
IANAL, though...

>>> Is there a reason we shouldn't switch to CC BY 4.0?
>>
>> Arguably, yes: doing so would permit the use of Coreboot wiki material
>> in proprietary works, which some wiki contributors might be opposed
>> to.
>
> [...]
>
> If *SOME*
> contributor to the wiki wanted a penny for anyone who used their
> documentation, should we write that into the license?

No, as that would be a crayon license. See
https://meta.stackexchange.com/questions/271080#271083

> Is picking BY
> over BY-SA actually going to prevent anyone from contributing?

I can't speak for anyone else, but I would be more hesitant to
contribute under a BY license than a BY-SA one.

> It
> seems like it PREVENTS distribution, since we need to pick the exact
> version of the license selected by other sites so that we can share
> documentation between them.

I think this is a misunderstanding. Like all licenses, it only
prevents usage that is not compliant with the license.

>> It would also prevent importing material from Wikipedia or Stack
>> Exchange into the Coreboot wiki.
>
> Wouldn't selecting CC BY-SA 4.0 also prevent that, if they're licensed
> at CC BY-SA 3.0?

No, it would not prevent *importing* it, as the CC BY-SA licenses are
forward-compatible.

However, it would prevent *exporting* material from the Coreboot wiki
to a CC BY-SA 3.0-licensed resource.

>>> How much of the coreboot documentation is
>>> applicable anywhere else?
>>
>> That remains to be seen. As Coreboot grows in popularity, its
>> documentation is likely to be more widely applicable.
>
> This also seems like an argument for CC BY over CC BY-SA.

I disagree. I'm not aware of any websites on the scale of Wikipedia or
SE that use CC BY.

>>> - Do we really care what Stack Exchange or any other group is using?
>>> How much are we copying from them?
>>
>> At the moment, I don't know of any Coreboot wiki content that was
>> copied from SE or Wikipedia. This is probably just as well, because
>> such material would be in breach of its license ;)
>>
>> But as Coreboot becomes more popular, the likelihood increases that
>> someone might post an answer on SE, or a description on Wikipedia,
>> that is good enough that it is worth including it (either verbatim or
>> appropriately edited) in the Coreboot wiki. For such inclusion to be
>> possible, the Coreboot wiki's license obviously needs to be compatible
>> with SE's license and Wikipedia's license.
>
> I guess I dislike this as a reason for choosing our license.  If some
> future Stack Exchange replacement comes along using a different
> license, what then?  We're stuck with what we've already picked.

It probably makes more sense to make the Coreboot wiki compatible with
the most obvious existing major collaborative websites than it does to
speculate about potential future websites that might never in fact
come into existence.

Besides, there's no guarantee that your hypothetical SE replacement
would use a license that is compatible with CC BY, either.

>> As an aside: it is certainly possible in principle to dual-license (or
>> even triple-license, etc) the Coreboot wiki's content. So, Coreboot
>> could, for instance, decide to use CC BY-SA 3.0 *and* GFDL, with the
>> licensee allowed to choose whichever they prefer. On the plus side,
>> this would avoid the community having to choose between them (i.e. it
>> avoids the "versus" aspect of the discussion you linked to). On the
>> down side, it would prevent bi-directional compatibility with SE, as I
>> pointed out here:
>> https://www.coreboot.org/pipermail/coreboot/2017-March/083614.html .
>
> I'm fine with people dual licensing individual documents, the same as
> we allow someone who creates a new file to choose to license it in
> ways other than GPLv2, but I'd like to have a single license that
> governs the coreboot documentation as well.  Maybe that's not needed,
> I'm not sure.  It seems like we want to be able to say though "By
> contributing documentation here, you agree that contributions are
> licensed as X".

I agree with your position.

> I guess we also need to be careful about copying code into the
> documentation as well, since it seems like nothing's compatible with
> pulling GPL code into it.  At least CC BY allows you to pull the
> documentation into the code if there were ever a reason we wanted to
> do that.

I think that having a footer on the Coreboot wiki along the lines "All
material herein is published under CC BY-SA 3.0 unless stated
otherwise" would cover that eventuality, as long as any GPL code
excerpts in the wiki were clearly marked as such. Best to ask the SFC
for certainty on this point, though.

Thanks again :)

-- 
coreboot mailing 

Re: [coreboot] Add me_cleaner to automated tests?

[Sam Kuper]

On 21/03/2017, Martin Roth  wrote:
> Most of our current automated testing is just build testing, although
> we're working to expand that.  The boot testing we DO have doesn't
> currently include any boards with an ME - they're currently all boards
> that don't require any blobs.

Thanks for the info :)

Is it on Coreboot's roadmap to do automated boot testing of boards
that have a Management Engine? If so, is my suggestion to also test
for incompatibilities with me_cleaner a feasible one?

Thanks again :)

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

Re: [coreboot] Coreboot wiki: what license is the content under?

[Sam Kuper]

On 21/03/2017, Martin Roth  wrote:
> Hey Sam. You're absolutely right, and I appreciate you pointing this
> out.  We need to get this fixed.  Actually, as part of coreboot
> joining the Software Freedom Conservancy, our documentation NEEDS an
> open license of one sort or another.

Thanks, Martin. Good to know I'm not barking in the dark.

> Is there a reason we shouldn't switch to CC BY 4.0?

Arguably, yes: doing so would permit the use of Coreboot wiki material
in proprietary works, which some wiki contributors might be opposed
to.

It would also prevent importing material from Wikipedia or Stack
Exchange into the Coreboot wiki.

CC BY 4.0 is a free culture license, though, and would definitely be
better than no license at all :)

> - Do we really need BY-SA?

Strictly speaking, no; but see above.

> How much of the coreboot documentation is
> applicable anywhere else?

That remains to be seen. As Coreboot grows in popularity, its
documentation is likely to be more widely applicable.

> Why not just go with the least restrictive
> license?

See above.

> - Do we really care what Stack Exchange or any other group is using?
> How much are we copying from them?

At the moment, I don't know of any Coreboot wiki content that was
copied from SE or Wikipedia. This is probably just as well, because
such material would be in breach of its license ;)

But as Coreboot becomes more popular, the likelihood increases that
someone might post an answer on SE, or a description on Wikipedia,
that is good enough that it is worth including it (either verbatim or
appropriately edited) in the Coreboot wiki. For such inclusion to be
possible, the Coreboot wiki's license obviously needs to be compatible
with SE's license and Wikipedia's license.

> Here are the CC licenses: https://creativecommons.org/licenses/
> Discussion of CC BY-SA vs GFDL
> :https://wiki.creativecommons.org/wiki/GFDL_versus_CC-by-sa

As an aside: it is certainly possible in principle to dual-license (or
even triple-license, etc) the Coreboot wiki's content. So, Coreboot
could, for instance, decide to use CC BY-SA 3.0 *and* GFDL, with the
licensee allowed to choose whichever they prefer. On the plus side,
this would avoid the community having to choose between them (i.e. it
avoids the "versus" aspect of the discussion you linked to). On the
down side, it would prevent bi-directional compatibility with SE, as I
pointed out here:
https://www.coreboot.org/pipermail/coreboot/2017-March/083614.html .

> Once we decide which license to switch to, I think we're going to have
> to remove or rewrite any documentation contributions from people who
> don't want to agree to the license or who can't be reached.

Agreed: I can't see any way around that, sadly.

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

Re: [coreboot] Coreboot wiki: what license is the content under?

[Sam Kuper]

On 17/03/2017, Sam Kuper <sam.ku...@uclmail.net> wrote:
> Also: sanity check. Does anyone else here besides me and Timothy feel
> that making the wiki documentation available under a free culture
> license would be a good idea?

A few other wiki users agreed with us, which is great:

https://www.coreboot.org/User:GNUtoo#Wiki_contributions

https://www.coreboot.org/User:Samnob

https://www.coreboot.org/User_talk:Kl3

The relative silence about this topic on this mailing list makes me
wonder, though: does anyone here think it would be a *bad* idea for
the Coreboot wiki contents to be under a free culture license? If you
do, would you mind explaining why?

Thanks!

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

[coreboot] Add me_cleaner to automated tests?

[Sam Kuper]

I am still very new to Coreboot.

I understand that Coreboot has an automated test system, so that each
push to the repo builds and tests the result automatically.

I also see that me_cleaner is now part of the Coreboot repo, under
coreboot/util/me_cleaner/ .

Instead of relying on manual test reports for me_cleaner,[0] would it
be possible for Coreboot's automated test system to be extended such
that it additionally attempts to apply me_cleaner, and to test the
results?

That way, incompatibilities between Coreboot and me_cleaner might be
more readily discovered and fixed.[1]

Thanks,

Sam

[0]  E.g. https://github.com/corna/me_cleaner/issues/3

[1] E.g. https://www.coreboot.org/pipermail/coreboot/2017-March/083686.html

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

Re: [coreboot] Lenovo Thinkpad X201: Coreboot incompatible with me_cleaner

[Sam Kuper]

On 21/03/2017, Sam Kuper <sam.ku...@uclmail.net> wrote:
> I have been investigating booting my X201 on two axes:
>
> - Coreboot vs stock BIOS
>
> - Intel Management Engine left alone vs neutralised with me_cleaner.
>
> Of the four quadrants created by those two axes, only one quadrant
> does not work: Coreboot + neutralised ME

Apologies if that was confusingly-worded. What I meant was this:

   | OEM BIOS |   Coreboot   |
---|--|--|
  Stock ME |  Works   | Works|
Neutralised ME |  Works   | Doesn't work |

Best wishes,

Sam

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

[coreboot] Lenovo Thinkpad X201: Coreboot incompatible with me_cleaner

[Sam Kuper]

Dear all,

I have been investigating booting my X201 on two axes:

- Coreboot vs stock BIOS

- Intel Management Engine left alone vs neutralised with me_cleaner.

Of the four quadrants created by those two axes, only one quadrant
does not work: Coreboot + neutralised ME:

- Stock BIOS: boots fine.

- Stock BIOS, neutralised: doesn't boot boots fine after a delay of <1 minute.

- Coreboot with SeaBIOS payload, based on descriptor & ME regions from
stock BIOS: boots fine.

- Coreboot with SeaBIOS payload, based on descriptor & ME regions from
neutralised BIOS: **doesn't boot**.

See additional details here, including the output of intelmetool:
https://github.com/corna/me_cleaner/issues/24 .

Nicola Corna pointed out to me that adding a timeout at
https://github.com/coreboot/coreboot/blob/master/src/northbridge/intel/nehalem/raminit.c#L1756
might solve this problem.

(I guess the idea is that instead of waiting indefinitely for the ME
to load, Coreboot should instead just wait for a defined amount of
time and then plough on regardless.)

I am not a C programmer, so am not competent to add that timeout.

Please can anyone here provide a suitable patch for me to test, or
failing that, point me to a similar timeout in another architecture's
raminit that I might use as a starting point?

Thanks,

Sam

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

Re: [coreboot] Lenovo Thinkpad X201: recipe for target 'add_intel_firmware' failed

[Sam Kuper]

On 19/03/2017, Sam Kuper <sam.ku...@uclmail.net> wrote:
> I am trying to build Coreboot for the X201, and to improve the
> Coreboot wiki's X201 page as I go along.
>
> I am presently following the instructions at this permalink:
> https://www.coreboot.org/index.php?title=Board:lenovo/x201=24764#Method_1:_external_flasher
>
> [...]
>
> Everything went fine, so far, until this step:
> https://www.coreboot.org/index.php?title=Board:lenovo/x201=24764#Compile_Coreboot

I tracked down the source of the error. The instructions here (
https://www.coreboot.org/index.php?title=Board:lenovo/x201=24764#Extract_descriptor_and_Management_Engine_regions
) specify that the "descriptor" and "Management Engine" regions should
be extracted to the following directory:

coreboot/3rdparty/mainboard/lenovo/x201/

However, the Coreboot build process instead expects to find those
extracts in this directory:

coreboot/3rdparty/blobs/mainboard/lenovo/x201/

After moving the extracted files from the former directory to the
latter, the build proceeds without errors. I will amend the
instructions in the wiki's X201 page to specify extraction of those
regions to the latter directory, instead of the former.

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

[coreboot] Lenovo Thinkpad X201: recipe for target 'add_intel_firmware' failed

[Sam Kuper]

I am trying to build Coreboot for the X201, and to improve the
Coreboot wiki's X201 page as I go along.

I am presently following the instructions at this permalink:
https://www.coreboot.org/index.php?title=Board:lenovo/x201=24764#Method_1:_external_flasher

(I decided to skip the step to neuter the ME:
https://www.coreboot.org/index.php?title=Board:lenovo/x201=24764#Neutralize_the_Intel_Management_Engine_.28optional.29
. Maybe I will try neutering the X201's ME another day, but first of
all I would like to at least achieve Coreboot running on the X201.)

Everything went fine, so far, until this step:
https://www.coreboot.org/index.php?title=Board:lenovo/x201=24764#Compile_Coreboot

Let me describe how I attempted to implement that step.

I ran `make distclean`.

I ran `make nconfig`, and selected:

- "Lenovo" under Mainboard > Mainboard vendor

- "ThinkPad X201 / X201s / X201t" under Mainboard > Mainboard model

- "Add Intel descriptor.bin file" under Chipset

- "Add Intel ME/TXE firmware" under Chipset

Then I pressed F9 ("Exit") and saved the config to the default
location ( coreboot/.config ).

Then I ran `make`, which seemed to be going fine until the following output:

Compile IFDTOOL
HOSTCC util/ifdfake/ifdfake
DD Adding Intel Firmware Descriptor
src/southbridge/intel/common/firmware/Makefile.inc:50: recipe for
target 'add_intel_firmware' failed
make: *** [add_intel_firmware] Error 1

Can anyone suggest how to overcome this error?

I have attached the .config generated by `make nconfig`, and the full
output of `make`, in case that is useful.

Many thanks!


.config
Description: Binary data
#
# configuration written to /home/sampablokuper/Documents/projects/coreboot/.config
#
HOSTCC util/sconfig/lex.yy.o
HOSTCC util/sconfig/sconfig.tab.o
HOSTCC util/sconfig/main.o
HOSTCC util/sconfig/sconfig (link)
SCONFIGmainboard/lenovo/x201/devicetree.cb
HOSTCC nvramtool/cli/nvramtool.o
HOSTCC nvramtool/cli/opts.o
HOSTCC nvramtool/cmos_lowlevel.o
HOSTCC nvramtool/cmos_ops.o
HOSTCC nvramtool/common.o
HOSTCC nvramtool/compute_ip_checksum.o
HOSTCC nvramtool/hexdump.o
HOSTCC nvramtool/input_file.o
HOSTCC nvramtool/layout.o
HOSTCC nvramtool/accessors/layout-common.o
HOSTCC nvramtool/accessors/layout-text.o
HOSTCC nvramtool/accessors/layout-bin.o
HOSTCC nvramtool/lbtable.o
HOSTCC nvramtool/reg_expr.o
HOSTCC nvramtool/cbfs.o
HOSTCC nvramtool/accessors/cmos-mem.o
HOSTCC nvramtool/nvramtool (link)
OPTION option_table.h
CC bootblock/mainboard/lenovo/x201/static.o
CC bootblock/arch/x86/boot.o
GENgenerated/bootblock.ld
CP bootblock/arch/x86/bootblock.ld
HOSTCC util/romcc/romcc (this may take a while)
ROMCC  generated/bootblock.inc
CC bootblock/arch/x86/bootblock_romcc.o
CC bootblock/arch/x86/cpu_common.o
GENbuild.h
CC bootblock/arch/x86/id.o
CC bootblock/arch/x86/memcpy.o
CC bootblock/arch/x86/memset.o
CC bootblock/arch/x86/mmap_boot.o
CC bootblock/arch/x86/walkcbfs.o
CC bootblock/commonlib/cbfs.o
CC bootblock/commonlib/lz4_wrapper.o
CC bootblock/commonlib/mem_pool.o
CC bootblock/commonlib/region.o
CC bootblock/console/die.o
CC bootblock/console/post.o
CC bootblock/cpu/x86/lapic/boot_cpu.o
CC bootblock/cpu/x86/mtrr/earlymtrr.o
CC bootblock/cpu/x86/tsc/delay_tsc.o
CC bootblock/device/device_simple.o
CC bootblock/device/i2c.o
CC bootblock/drivers/spi/adesto.o
CC bootblock/drivers/spi/amic.o
CC bootblock/drivers/spi/atmel.o
CC bootblock/drivers/spi/eon.o
CC bootblock/drivers/spi/gigadevice.o
CC bootblock/drivers/spi/macronix.o
CC bootblock/drivers/spi/spansion.o
CC bootblock/drivers/spi/spi-generic.o
CC bootblock/drivers/spi/spi_flash.o
CC bootblock/drivers/spi/sst.o
CC bootblock/drivers/spi/stmicro.o
CC bootblock/drivers/spi/winbond.o
CC bootblock/lib/boot_device.o
CC bootblock/lib/bootmode.o
HOSTCC cbfstool/fmaptool.o
HOSTCC cbfstool/cbfs_sections.o
HOSTCC cbfstool/fmap_from_fmd.o
HOSTCC cbfstool/fmd.o
HOSTCC cbfstool/fmd_parser.o
HOSTCC cbfstool/fmd_scanner.o
HOSTCC cbfstool/fmap.o
HOSTCC cbfstool/kv_pair.o
HOSTCC cbfstool/valstr.o
HOSTCC cbfstool/fmaptool (link)
FMAP   build/util/cbfstool/fmaptool -h build/fmap_config.h build/fmap.fmd build/fmap.fmap
SUCCESS: Wrote 182 bytes to file 'build/fmap.fmap' (and generated header)
The sections containing CBFSes are: COREBOOT
CC 

Re: [coreboot] Conventions for describing flash memory layouts

[Sam Kuper]

On 18/03/2017, Patrick 'P. J.' McDermott <p...@pehjota.net> wrote:
> On 2017-03-18 at 18:00, Sam Kuper wrote:
>> The page
>> https://www.coreboot.org/index.php?title=Board:lenovo/x201=24709#Flashing
>> says:
>>
>> > The flash memory in the X201 is divided into roughly 4 parts:
>> >
>> > - Descriptor (12K)
>> > - ME firmware (5M-12K)
>> > - Rewriteable flash (3M-96K)
>> > - Locked bootblock (96K)
>>
>> I guess that "K" refers to kibibytes and that "M" refers to mebibytes.
>
> Correct.
>
>> I also guess that the values in parentheses refer to the sizes of the
>> corresponding occupants of the flash memory, with the "-" symbol
>> representing "minus". This was not my first guess, but is the one that
>> seems to make the most sense.
>
> I'm not familiar with Ibex Peak's standard flash layout, but this sounds
> correct.  The 12-KiB "Descriptor" should contain both the Intel Flash
> Descriptor and the Gigabit Ethernet Region.  And the region sizes by
> that math add up to 8 MiB, which sounds right.

Many thanks for corroborating!

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

[coreboot] Conventions for describing flash memory layouts

[Sam Kuper]

The page 
https://www.coreboot.org/index.php?title=Board:lenovo/x201=24709#Flashing
says:

> The flash memory in the X201 is divided into roughly 4 parts:
>
> - Descriptor (12K)
> - ME firmware (5M-12K)
> - Rewriteable flash (3M-96K)
> - Locked bootblock (96K)

I guess that "K" refers to kibibytes and that "M" refers to mebibytes.

I also guess that the values in parentheses refer to the sizes of the
corresponding occupants of the flash memory, with the "-" symbol
representing "minus". This was not my first guess, but is the one that
seems to make the most sense.

Are my guesses correct? If not, what do the values in parentheses mean?

Thanks!

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

Re: [coreboot] Coreboot wiki: what license is the content under?

[Sam Kuper]

On 16/03/2017, Sam Kuper <sam.ku...@uclmail.net> wrote:
> Ideally, Coreboot would dual-license the content under the GFDL and CC
> BY-SA 3.0, making the content entirely license compatible with content
> from Wikipedia and from the Stack Exchange network of websites.

Actually, CC BY-SA 3.0 alone would be better. That is because copying
CC BY-SA 3.0-licensed content from Stack Exchange, and then publishing
it under both CC BY-SA 3.0 *and* GFDL, would be a breach of CC BY-SA
3.0.


On 16/03/2017, Timothy Pearson <tpear...@raptorengineering.com> wrote:
> On 03/16/2017 04:10 PM, Sam Kuper wrote:
>> Looks like there are only 172 additional Coreboot wiki contributors to
>> account for :)
>
> Yep :-)  I just figured that if the major contributors on this list
> specified a license we'd be well on our way to fixing this!

For the (re-)licensing effort to succeed:

- the remaining 172 people need to be contacted;

- there needs to be a way to keep track of who has been responded, and
what their response was.

Contacting the wiki contributors would seem to require the involvement
of a person with privileged access to the wiki, such as Patrick Georgi
or Stefan Reinauer (CC'd). In the first instance, perhaps that person
should attempt to reach those users via MassMessage:

https://www.mediawiki.org/wiki/Help:Extension:MassMessage

Collating replies: I'm not sure. Make a table on the wiki with two
columns: one with all the usernames in, and one for the users to put
their signatures in to indicate willingness to license their
contributions under the proposed terms? Any better suggestions?

Also: sanity check. Does anyone else here besides me and Timothy feel
that making the wiki documentation available under a free culture
license would be a good idea?

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

Re: [coreboot] Coreboot wiki: what license is the content under?

[Sam Kuper]

On 16/03/2017, Sam Kuper <sam.ku...@uclmail.net> wrote:
> Looks like there are only 172 additional Coreboot wiki contributors to
> account for :)
>
> curl -s \
> 'https://www.coreboot.org/index.php?title=Special:ListUsers==500'
> \
> | grep '^' coreboot_users.html \
> | sed 's//\n/g' \
> | grep 'Special:Contributions/[^"]*">' \
> | perl -pe 's/^(.+?User:)([^"&]+?)(["&].*$)/$2/g' \
> | wc -l

Sorry for the typo on line 3 of the above script. That should have been:

curl -s \
'https://www.coreboot.org/index.php?title=Special:ListUsers==500' \
| grep '^' \
| sed 's//\n/g' \
| grep 'Special:Contributions/[^"]*">' \
| perl -pe 's/^(.+?User:)([^"&]+?)(["&].*$)/$2/g' \
| wc -l

N.B. If you want to see the usernames of the Coreboot wiki users who
have actually made contributions, just leave off the last line.

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

Re: [coreboot] Coreboot wiki: what license is the content under?

[Sam Kuper]

On 16/03/2017, Timothy Pearson <tpear...@raptorengineering.com> wrote:
> On 03/16/2017 02:27 PM, Sam Kuper wrote:
>> My understanding is that means that much (maybe all) of the
>> documentation in the Coreboot wiki is proprietary (at least, in the
>> overwhelming majority of jurisdictions). IANAL, though.
>
> This is a good point.  For what it's worth, anything contributed by
> Raptor Engineering to the Wiki should be considered at least dual
> licensed CC BY-SA 3.0 and GDFL; we'd love to see our content remixed /
> improved by the community as long as attribution and share-alike is
> maintained.

Thanks. I guess that would be this content?

https://www.coreboot.org/Special:Contributions/Tpearson

Looks like there are only 172 additional Coreboot wiki contributors to
account for :)

curl -s \
'https://www.coreboot.org/index.php?title=Special:ListUsers==500' \
| grep '^' coreboot_users.html \
| sed 's//\n/g' \
| grep 'Special:Contributions/[^"]*">' \
| perl -pe 's/^(.+?User:)([^"&]+?)(["&].*$)/$2/g' \
| wc -l

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

[coreboot] Coreboot wiki: what license is the content under?

[Sam Kuper]

Hi folks,

I have looked at a number of pages on the Coreboot wiki, though not all of them.

None of the pages I have looked at mentioned the license (if any)
under which their content is available.

My understanding is that means that much (maybe all) of the
documentation in the Coreboot wiki is proprietary (at least, in the
overwhelming majority of jurisdictions). IANAL, though.

If my understanding is incorrect, please could you point me towards
information that should correct it?

Alternatively, it would be great if Coreboot could license the
documentation in the wiki under one or more free culture licenses:
https://freedomdefined.org/Licenses

Ideally, Coreboot would dual-license the content under the GFDL and CC
BY-SA 3.0, making the content entirely license compatible with content
from Wikipedia and from the Stack Exchange network of websites.

Thanks,

Sam

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

Re: [coreboot] Does the 62xx Series Opteron work *securely* without microcode?

[Sam Kuper]

On 25/01/2017, ron minnich  wrote:
> If you have a machine with microcode updates, you
> should load the updates. I have never understood the objections to
> microcode blobs. If you accept the microcode that's on the machine already,
> then objecting to the microcode blob is creating a distinction without a
> difference.

That reasoning ignores the case where the user might consider the
manufacturer(s) to have been (relatively) trustworthy at the time the
machine and it's components were manufactured, but to have
subsequently become less trustworthy.

In such a case, the user would be right to avoid the microcode updates.

Hypothetical example: I buy a machine with built-in microcode from the
young Anakin Skywalker. A decade later, Darth Vader releases a
microcode update. Should I apply it?

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

Re: [coreboot] Proposal: "Freedom level" field for boards supported by coreboot

[Sam Kuper]

On 19/01/2017, Andrés Domínguez  wrote:
> 2017-01-18 23:39 GMT+01:00 Timothy Pearson :
>> https://www.coreboot.org/Board_freedom_levels
>
> There are a few things that I don't like about your categories,
> specially the "scary red Pwned": Don't you think that people reading
> the coreboot web page, will think that the "Pwned" are worse than
> buying any random board not supported by coreboot, with the same
> freedom issues?

Any random board that *isn't* pre-2010 Intel or pre-2014 AMD?

I think the "Pwned" category is pretty well described.

Timothy: good work. Thank you for doing it.

Btw, about SBCs, might be worth seeing if the classifications used on
the FSF's SBC page, and those used within Coreboot (if Timothy's
proposal is adopted), could be harmonised. That would, I hope, improve
clarity/standardisation, and reduce confusion. I'm CC'ing Paul
Kocialkowsi, the maintainer of the FSF page.
https://www.fsf.org/resources/hw/single-board-computers

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

Re: [coreboot] TALOS project short of funding goals - where to now?

[Sam Kuper]

On 14/12/2016, Timothy Pearson  wrote:
> Not everything can be created on a smart phone or tablet, and in
> point of fact, _most_ things cannot.
>
> I understand that many users or developers of small projects don't need
> powerful hardware, but please don't make the grave mistake of assuming
> that everything will continue as-is on the development side if said
> hardware is not available.

Timothy, thank you for your work to design and crowdfund TALOS. TALOS
is the first platform I have seen advertised that has:

- auditable schematics, firmware, and software;

- ECC;

- IOMMU and other features that might support the security features in
Qubes or similar;

- at least as much power (RAM, CPU speed, etc) as a typical mid-range laptop.

That is a very compelling combination of properties: auditability is
important for avoiding malicious corruption or disclosure of data; ECC
is important for avoiding accidental corruption of data (and perhaps
for foiling "rowhammer" attacks); IOMMU/virtualisation/etc are
important for allowing the user to benefit from "security by
isolation"; and the prospect of having enough power to run a few
moderately demanding desktop applications simultaneously, on top of
VMs, is crucial in order for the user to actually make use of all the
aforementioned properties in a practical way.

Wherever the TALOS project goes from here, I do hope we shall see a
computer with those properties available on the market soon, at an
affordable price. If it comes from Raptor, so much the better.

I wish you the best of luck for the remaining hours of the crowd-funder.

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

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

[Sam Kuper]

On 03/12/2016, Merlin Büge  wrote:
> To me, the point of this campaign is not to get cool free hardware, but to
> create/restore the very foundations that are needed to have them, i.e.
> research (so we can build on that and have that knowledge) and development
> (so we / other people have the ability to buy free and high-performance
> computing hardware).
>
> Really, if you're reading a bit on what's going on in the world regarding
> the freedom of hardware (e.g. article above, more and more lockdowns), imo
> it's easily justified to spend a few hundred dollars or, if you can, a few
> thousands for it -- without obtaining any actual hardware.
>
> Just imagine that *awesome* moment when Talos got funded, knowing that
> *you* were an indispensable part of it!

I agree with all of this.

I have done my best to persuade people I know who might be able to
influence institutional budgets, to seriously consider the TALOS; and
to spread the word to others who might at least be able to donate.

I take my hat off to everyone who has supported the project.

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

Re: [coreboot] T430s or T430 (Was: latest greatest thinkpad with coreboot)

[Sam Kuper]

On 04/12/2016, Pok Gu  wrote:
> It seems there is not a strong motivation for doing
> the T430/T530 port. [...] What are the
> explicit benefits that coreboot can bring to the T430/T530 except
> opensource/security?

Freedom & security are, arguably, *very* strong motivations.

> -Unlock RAM speed and WIFI whitelist removel? There are already Modded BIOS
> for this

The modded BIOSes lack the freedom and security enhancements offered
by Coreboot.

> -Remove evil ME?

This is a huge freedom and security enhancement, if achievable on the T430(s).

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

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

[Sam Kuper]

On 03/12/2016, Paul Menzel via coreboot  wrote:
> I pledge 1,000 $.

Awesome!

> Everyone, the TALOS campaign only reached 10 % of the funding goal, and
> there are only twelve days left. [...]
> Currently, it looks like free software people don’t care about getting
> control over their hardware back.

People care, and ~$380k over 280+ pledges confirms this. But the TALOS
project is asking for about an order of magnitude more funding, and
2-100x more money per working end product, than pretty much any other
CrowdSupply hardware platform crowdfunding effort likely to be of
interest to free software people (Novena, Librem 13, Librem 15,
EOMA68, USB Armory, etc).

I realise that the TALOS is unique in its combination of technologies,
and that these technologies were chosen for very good reasons. But I
also realise that not many people can afford to buy a $7100 computer,
especially if one of the existing Libreboot or coreboot-supported
devices would meet most of their needs.

As for the non-hardware options TALOS offers, I suspect people have
some difficulty justifying making charitable donations towards a
for-profit enterprise, or paying for SaaSS under a time limit and with
only fairly limited use-cases.

I'm sure the TALOS developers have done their best to make the
fundraiser successful, but I wish it had been possible for them to
offer some hardware at a price that would let non-wealthy people buy
it; and I likewise wish it had been viable for them to set a lower
overall funding target.

I can't be the only one who saw them launch and thought, "This is
amazing, and I really hope they succeed... but I fear they are asking
more of the community than it can afford to pledge."

Maybe a miracle will happen.

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

Re: [coreboot] T430s or T430 (Was: latest greatest thinkpad with coreboot)

[Sam Kuper]

On 02/12/2016, Nico Huber  wrote:
> The T430 seems to be unsupported.
> Also I guess, it would only be one or two days of work

One or two days of work for whom? E.g. did you have in mind a specific
person (if so, who?), or a non-specific person with a specific skill
set (if so, which skill set?)?

Is anyone reading this planning to spend that time on the T430 or
T430s in the coming weeks?

Thanks :)

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

[coreboot] T430s or T430 (Was: latest greatest thinkpad with coreboot)

[Sam Kuper]

On 01/12/2016, Nico Huber  wrote:
> On 01.12.2016 18:50, Klemens Nanni wrote:
>> On Thu, Dec 01, 2016 at 05:04:36PM +, ron minnich wrote:
>>> what's the latest best one?
>>>
>> X230 if you'd ask me: 16G RAM, 12M ROM. runs fine with reduced
>> (830K) ME
>>
> Everything Klemens said about the X230 should also apply to the
> T430s. It's just 14" instead of 12".

Has anyone here actually tried running Coreboot with a reduced ME on a
T430 or T430s?

The Coreboot wiki does not even have pages for those models...

https://www.coreboot.org/Board:lenovo/t430

https://www.coreboot.org/Board:lenovo/t430s

Thanks!

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

Re: [coreboot] Friendly reminder: Please just send plain text messages to the list

[Sam Kuper]

On Mar 10, 2014 3:32 PM, Björn Busse m...@baerlin.eu wrote:
 On Mon, Mar 10, 2014 at 04:21:00PM +0100, Peter Stuge wrote:
  Corey Osgood wrote:
   Can you please point me to when this became policy on the coreboot
   mailing list?
  I think it's pretty much a common sense policy on every mailing list.
 +1, Also my understanding.

The trouble with invoking common sense is that what constitutes it isn't
universally agreed.
-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Are any Chromebooks able to run fully libre?

[Sam Kuper]

On Jan 4, 2014 12:56 AM, Peter Stuge pe...@stuge.se wrote:

 Sam Kuper wrote:
  Brossard

 Not a very nice word around here.

Sorry; I didn't know there was bad feeling.

 Don't take people's word for things, Sam, but do more research yourself.

 The internet and even people presenting at conferences are not
 indisputable sources.

Very much agreed; but we each have to start somewhere :)

 Brossard included the abbreviation PIC in one of the slides for his
 talk about how he supposedly created a backdoored BIOS (using an open
 source x86 firmware implementation).

 He identified PIC as one of the components on PC mainboards.

 Unfortunately he seems to think that PIC refers to the family of
 microcontrollers developed by Microchip instead of what it really
 refers to; something very different, a quite well-understood and
 rather fundamental component for everyone with strong knowledge about
 PC technology.

What would you recommend as a good primer (textbook; website; manual;
whatever) that would give someone with limited experience enough knowledge
to avoid making that mistake and others like it?

Many thanks,

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

Re: [coreboot] Are any Chromebooks able to run fully libre?

[Sam Kuper]

On Jan 4, 2014 12:56 AM, Peter Stuge pe...@stuge.se wrote:

 Sam Kuper wrote:
  Brossard

 Not a very nice word around here.

 Don't take people's word for things, Sam

For clarity, do you think Brossard was wrong about microcode? If so, please
could you explain why?

He and Blank - and indeed Stallman - aren't the only authorities who've
stated misgivings about (closed-source) microcode updates.

Thanks again,

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

Re: [coreboot] Are any Chromebooks able to run fully libre?

[Sam Kuper]

On 20/12/2013, ron minnich rminn...@gmail.com wrote:
 I can go
 into more detail if you want to know the particulars, but there's so
 many places in our systems containing blobs

As I understand it, there are two distinct reasons why some BLOBs, in
certain systems, cannot be eliminated/replaced by executing
appropriate software on those systems:

1. Because the BLOB is stored in a genuine ROM (or equivalent or EPROM
or equivalent; but not an EEPROM or equivalent) and therefore cannot
physically be eliminated/replaced just by (setting a jumper if
necessary, and) executing software;

2. Because although the BLOB could in principle be
eliminated/replaced, no libre (or even open-source) alternative for it
exists yet that would lead to error-free operation of the hardware.
(Intel CPU microcode updates are a prime example of such BLOBs.)

Assuming I haven't got the wrong end of this stick, I would be
grateful if you (or anyone else reading this) could go into more
detail (or point me to a resource that does) regarding which BLOBs
exist on the following two models of Chromebook, and which of those
two cases they fall under:

- Acer C7/C710
- HP Pavilion 14

For instance, I've not yet figured out whether those Chromebook models
currently upload microcode to the Celeron 847 (or Celeron 1007U).
(Unless my search-fu has failed me, Intel doesn't seem to have
released any microcode updates for the 847 or 1007U; but perhaps that
is irrelevant, because BIOS/OS-uploadable microcode for the 847 might
have been released without any further microcode *updates* being
released?)

Thanks again,

Sam

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

Re: [coreboot] Are any Chromebooks able to run fully libre?

[Sam Kuper]

On 02/01/2014, Patrick Georgi patr...@georgi-clan.de wrote:
 Am 02.01.2014 19:15, schrieb Sam Kuper:
 As I understand it, there are two distinct reasons why some BLOBs, in
 certain systems, cannot be eliminated/replaced by executing
 appropriate software on those systems:

 Option 3:
 The image is signed with some vendor key. You could replace it, but the
 hardware prevents running any unsigned alternative.

I see that coming within case 2. The Intel CPU microcode I gave as an
example has this problem, IIUC. Perhaps I'm wrong, but I see it as
being like the Content Scramble System (CSS), AACS, etc, and we're
waiting for someone to create the equivalent of DeCSS, etc, so that
libre (or at least open source) alternative microcode can be made to
exist that would actually work on the CPU.

In the case of CSS and AACS, software DVD/Blu-Ray/etc players were
targeted rather than hardware ones. Unfortunately, with Intel
microcode, we only have a hardware player' of microcode: the Intel
CPU, so it is more difficult for the community to solve the problem.

Regards,

Sam

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

Re: [coreboot] Are any Chromebooks able to run fully libre?

[Sam Kuper]

On 02/01/2014, Patrick Georgi patr...@georgi-clan.de wrote:
 Am 02.01.2014 21:31, schrieb Sam Kuper:
 Here we have one vendor, and the files are typically not transferrable
 across chip versions, so they can create a new key for every version,
 limiting the impact.

 If I remember things correctly, Intel uses RSA-2048 signatures on a
 SHA256 hash. The capability to crack such a scheme probably provides
 more lucrative opportunities than firmware freedom and that makes me
 guess people would routinely do it, if possible.

Agreed, although the work by Molina and Arbaugh, and by Ben Hawkes,
has started some little inroads towards perhaps eventually unpicking
the microcode.

 How about simply refusing to pay for malfeatures like these instead of
 increasing the platform's value for vendors that absolutely don't want
 you to do it for them (as expressed by both their conduct and their
 signature scheme)?

I'm actively researching alternatives, but because there's no perfect
solution, I have to strike a balance between the freedom I want and
the features/compatibility I want.

My earlier question about the Acer C7/C710 and HP Pavilion 14 was
motivated by the following consideration: if they have not been found
to have CPU errata warranting uploading of CPU microcode, then they
might be (at least in this respect) preferable to the X60 which forces
the user to choose between uploading microcode or running with known
vulnerabilities.*

Regards,

Sam

* Yes, there's debate about the seriousness of some of these
vulnerabilities[1][2]; and yes, Linus did downplay them[3], but I
think he downplayed them on the assumption that users *would* use the
microcode patches to handle those needing microcode patches[4] and
that kernels and compilers would be checked, and updated if necessary,
to handle the rest.

[1] 
http://hardware.slashdot.org/story/07/06/28/1124256/theo-de-raadt-details-intel-core-2-bugs
[2] 
http://www.cs.dartmouth.edu/~sergey/cs258/2010/D2T1%20-%20Kris%20Kaspersky%20-%20Remote%20Code%20Execution%20Through%20Intel%20CPU%20Bugs.pdf
[3] http://www.realworldtech.com/forum/?threadid=78455curpostid=78469
[4] http://www.realworldtech.com/forum/?threadid=78455curpostid=78477

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

Re: [coreboot] Are any Chromebooks able to run fully libre?

[Sam Kuper]

On 02/01/2014, mrnuke mr.nuke...@gmail.com wrote:
 On Thursday, January 02, 2014 09:16:25 PM Sam Kuper wrote:
 My earlier question about the Acer C7/C710 and HP Pavilion 14 was
 motivated by the following consideration: if they have not been found
 to have CPU errata warranting uploading of CPU microcode, then they
 might be (at least in this respect) preferable to the X60 which forces
 the user to choose between uploading microcode or running with known
 vulnerabilities.*

 x86 Chromebooks ship with microcode updates.

On the C7/C710 and Pavilion 14 as shipped, where are those microcode
updates stored?

 And
 how exactly is a CPU different if the microcode update is patched in the
 factory rather than uploaded at boot? It's the same microcode in the end.

First of all, if some microcode is in the CPU from the factory rather
than being uploaded into the CPU's microcode-patchable space[1] then
it's not *patched* in.

If no errata have been reported for the 847 and 1007U for which
microcode updates have been released, then that's one less thing to
keep on top of when building Coreboot or installing an OS. Personally,
I'm in favour of having one less thing to keep on top of in such a
situation.

Also, if no errata have been reported for the 847 and 1007U for which
microcode updates have been released, then it's possible those two
models are - at least compared to Core Solo, Core Duo, Core 2 Duo, etc
- not lemons. Personally, I'd rather not buy a lemon.

Additionally, if no errata can be found by people outside Intel in the
847 and 1007U for which a microcode update would be justified, then
Intel/whoever would be less likely to be able to convincingly foist
compromised microcode for those CPUs on anybody in the future.[2][3]

 This microcode discussion is ridiculous.

Well, that's the problem with proprietary systems; you have to just
make a guess about which of several black boxes is the least worst.
Might as well at least try to make that an educated guess instead of a
blind guess.

Regards,

Sam

[1] 
https://web.archive.org/web/19990219103606/http://eetimes.com/news/97/963news/hole.html
[2] 
http://www.forbes.com/sites/steveblank/2013/07/15/your-computer-may-already-be-hacked-nsa-inside/
[3] 
http://www.afr.com/p/technology/intel_chips_could_be_nsa_key_to_ymrhS1HS1633gCWKt5tFtI

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

Re: [coreboot] Are any Chromebooks able to run fully libre?

[Sam Kuper]

On 20/12/2013, ron minnich rminn...@gmail.com wrote:
 At this point it's harder and harder to escape the Blob. It eats you
 alive! http://www.youtube.com/watch?v=TdUsyXQ8Wrs

In a similar vein :)

https://web.archive.org/web/20130422085916/http://www.openbsd.org/lyrics.html#39


On 02/01/2014, mrnuke mr.nuke...@gmail.com wrote:
 On Thursday, January 02, 2014 11:28:14 PM Sam Kuper wrote:
 On the C7/C710 and Pavilion 14 as shipped, where are those microcode
 updates stored?

 This [1] should help you extract a stock coreboot.rom that you can cbfstool

 with. The rest is left as an exercise to the reader.
 (Short answer: cpu_microcode_blob.bin in CBFS)

Thank you, but unfortunately, I don't own a Samsung Series 5 550 or a
Series 3 Chromebox, nor any other CrOS device from which to extract a
stock coreboot.rom.

  And
  how exactly is a CPU different if the microcode update is patched in
  the
  factory rather than uploaded at boot?

 First of all, if some microcode is in the CPU from the factory rather
 [yada, yada, yada]

 I don't care for any Stallmanian lecturing on how microcode updates work.
 [...] With the risk of sounding arrogant, that
 gives
 me the credit to avoid your uninformed lecturing.

With respect, I wasn't trying to lecture anyone; I was giving a
straight answer to your question.

I freely admit I'm not terribly well-informed on the subject. That's
why I'm reading to learn as much as I can and asking questions here to
fill in the gaps.

 You have the option in
 coreboot to not include them. Period.

That was my understanding, but thanks for confirming it.

 What I gather from your description is that you want is the CPU that works
 best without microcode updates.

I'm after a couple of things:

- Server: x86, not necessarily Intel, with Core Solo performance or
better, that supports 16GB+ of RAM with double bit error correction
(e.g. Chipkill).
- Laptop/netbook: not necessarily x86, with Core Solo performance or
better, that supports 2GB+ of RAM.

And the kicker is that I'd like both to be fully open! Since no such
systems appear to exist, I'm trying in each case to pick the least
worst option.[1] That *doesn't necessarily* mean running without
microcode updates, so even though you may not agree with them, the
reasons I gave for distinguishing between baked-in microcode and
patched-in microcode were earnest ones. It does mean that I've read
the supported motherboards page (for the server) and the X60 and
Chromebook-related pages - plus several other pages - on the Coreboot
wiki.

 Ask around

That's what I'm doing :)

 or test yourself.

I intend to, but first I'm trying to identify the best candidate(s),
because my budget is small. If the C7/C710/HP14 didn't have CPU errata
 corresponding microcode updates, then I'd be tempted to get one for
testing. If not, then probably the X60 is a better option for me.
Hence my questions here :)

 I don't think
 many people have tested without microcode updates.

Some Trisquel folks are running without microcode updates.[2] I don't
know if anyone except Intel and the sort of security folks mentioned
in Kris Kaspersky's presentation[3] are *testing* anything in relation
to that, though.

Anyhow, since I've managed inadvertently to generate a couple of
slightly tetchy replies here since I started this thread (i.e. yours
and the earlier one from Gregg Levine), maybe that's a hint that I'm
asking too many questions or something, and that I should take my
leave for now?

Thanks again for the help you've given,

Sam

[1] I don't have a fixed understanding of what I mean by least worst
option. Each time I learn something relevant, I try to update my
understanding accordingly.
[2] 
http://trisquel.info/en/forum/intel-processor-microcode-security-update-trisquel
[3] 
http://www.cs.dartmouth.edu/~sergey/cs258/2010/D2T1%20-%20Kris%20Kaspersky%20-%20Remote%20Code%20Execution%20Through%20Intel%20CPU%20Bugs.pdf

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

Re: [coreboot] Are any Chromebooks able to run fully libre?

[Sam Kuper]

On 03/01/2014, mrnuke mr.nuke...@gmail.com wrote:
 On Friday, January 03, 2014 12:37:34 AM Sam Kuper wrote:

 There was some guide somewhere on how to download the stock ROM.

Thanks. Bedtime for me now, but if I decide the Chromebooks are still
a potential option for me, I'll try to find time an opportunity to
look it up (or failing that, maybe dissect one of John Lewis's
prebuilt binaries?) another day.

 The presence of CPU microcode should be the least of your concerns. Really.
 How about an out-of-band processor with full DMA access, and networking
 access transparent to the OS?

Already aware of that and I've ruled out everything with vPro/AMT.

 Seriously, the CPU microcode is nothing. Besides, nobody cares if an
 internal PLL is configured properly so that the CPU can switch to its
 highest clock without hanging.

I hear you; but I also hear Jonathan Brossard saying that as far as
security goes, [If you control CPU microcode] updates, you basically
win.

 AMD is your best bet, but be prepared to get your feet wet. Server boards
 are hard to find, and you'll most likely need to port it.

That was my understanding; thank you for confirming it.

 Chromebook, if you actually want to vote on free firmware. If you want to
 stick
 it to Intel (which I think you should), there are ARM models available. I
 also
 hear rumours of an octa-core coming soon. There are also some well-supported
 Lenovos, but getting one counts as not voting.

I'm no Intel boot-licker - I think the way Intel behaved re: OLPC was
appalling (Intel Classmate, etc) - but I haven't found any suitable
ARM models yet.[1] So it's down to:

- C7/C710;
- Pavilion 14;
- X60(s);
- Yeeloong.

All of which are compromises; and (at least in my view) all of which are votes.

 Ask away, but please keep Stallmanism out of it.

I find that if I mute Stallman, I hear Blank and Brossard ;)

Thanks again :)

Sam

[1] Besides, as far as current readily-available laptops are
concerned, it seems that some ARM models are more likely to have
restricted boot than Wintel laptops:
http://media.libreplanet.org/u/libby/m/embracing-secure-boot-and-rejecting-restricted-boot-matthew-garrett/

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

Re: [coreboot] Coreboot and the NSA's expressed preference for subverting BIOSes

[Sam Kuper]

On 31/12/2013, David Hendricks david.hendri...@gmail.com wrote:
 On Sun, Dec 29, 2013 at 5:06 PM, David Collier-Brown
 davecb...@gmail.comwrote:
 May I request you loudly announce how one checksums one's coreboot,
 and in principle other BIOSes, so that one can see if anyone has changed
 firmware critical to one's security.

 For Chromebooks, full verification is built into coreboot and also utilizes
 hardware write-protection

Which other Coreboot-supported systems/motherboards have hardware
write-protection (or can be easily modified to at least write-protect
the BIOS)?

Regards,

Sam

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

Re: [coreboot] Are any Chromebooks able to run fully libre?

[Sam Kuper]

On Dec 24, 2013 11:16 PM, Alex G. mr.nuke...@gmail.com wrote:
 On 12/22/2013 11:45 PM, Olliver Schinagl wrote:
  It is 9k and has no RAM access and as far as we can tell not invoked
  after u-boot (sorry no coreboot (yet?) :p) takes over.

 I must have missed the memo about no coreboot.

Fancy unpacking that statement for those of us who prefer less cryptic
expression? :)

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

Re: [coreboot] Are any Chromebooks able to run fully libre?

[Sam Kuper]

On 25/12/2013, Gregg Levine gregg.drw...@gmail.com wrote:
 Hello!
 He's complaining about a missing memo regarding Coreboot and such like.

How (not) helpful!

 I believe I missed a memo regarding the whole thread. Can we wrap this
 up? It's getting tedious.

With all respect, if you don't like it, please either mute the thread
in your email client, or update the Coreboot wiki to the point where
newcomers to Coreboot can answer questions like these by reading the
wiki rather than needing to ask on the mailing list.

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

Re: [coreboot] Binary situation

[Sam Kuper]

On 24/12/2013, David Hubbard david.c.hubbard+coreb...@gmail.com wrote:
 On Mon, Dec 23, 2013 at 3:21 PM, Rudolf Marek r.ma...@assembler.cz wrote:
 Some time ago Patrick started a
 https://www.coreboot.org/Binary_situation page which I updated in the past
 days. It monitors the various blobs and
 firmwares in the Intel and AMD systems.

Great work, thank you!

 It might be helpful to document the intended use case for each device.
 Basically, the industry has started using overloaded meanings for words
 that a newcomer might find hard to decipher.

As a newcomer, I agree :)

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

[coreboot] Are any Chromebooks able to run fully libre?

[Sam Kuper]

Dear Coreboot folks,

At the present time, are any of the Chromebooks operable (i.e. all
basic functions working, except 3D which I don't care about) without
the need for binary BLOBs in drivers or firmware?

If so, which Chromebook(s)?

Thank you,

Sam

P.S. I am new here, so if you feel this is the wrong place to ask my
question, or if I have overlooked a resource that yields the answer
straightforwardly, please set me straight.

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

Re: [coreboot] Are any Chromebooks able to run fully libre?

[Sam Kuper]

On 20/12/2013, Patrick Georgi patr...@georgi-clan.de wrote:
 Am Freitag, den 20.12.2013, 17:17 + schrieb Sam Kuper:
 At the present time, are any of the Chromebooks operable (i.e. all
 basic functions working, except 3D which I don't care about) without
 the need for binary BLOBs in drivers or firmware?
 No.

Thank you.

Sam

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

Re: [coreboot] Are any Chromebooks able to run fully libre?

[Sam Kuper]

On Dec 21, 2013 1:02 AM, Carl-Daniel Hailfinger 
c-d.hailfinger.devel.2...@gmx.net wrote:
 The big question is why someone doesn't want to have blobs in the system:
 1. Freedom: The FSF/Stallman say that ROMs are hardware and thus the
 software aspect of free software does not apply, i.e. closed source
 ROMs are OK.

I *might* feel closed-source ROMs weren't too bad if they were genuinely
ROMs and were well-studied/fuzzed and found benign.

Are there many genuine ROMs (not, for instance, EEPROMS) in Chromebooks? If
so, how well-studied  by whom?

Thanks,

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