Re: [coreboot] SPI controller and Lock bits

[Youness Alaoui]

On Wed, Oct 17, 2018 at 9:42 AM R S  wrote:
>
> Yes, thanks Youness for all the hard work and research. You provided an 
> exceptional service. I enjoyed your rants and explanations both on Purism's 
> blog and here. Hopefully Purism can fill that void you are leaving behind.
>
Thanks! I had a lot of fun, and this community is really great! I hope
we still get to work together again in the future and cross paths!

> On Tue, Oct 16, 2018 at 7:45 PM Sam Kuper  wrote:
>>
>> 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.
>>
Thanks!
I understand that the criticism was never personal, and I think you
all were justified in being critical as well, but then things started
to change for the better in purism and it took time for people here
(understandably) to see that the change was not just smoke and
mirrors. I hope that with me gone, they'll find a good replacement and
they'll continue working with the coreboot community and keep moving
forward, instead of backward.
No, you or anyone else's criticism here had zero part in my decision
to leave. On the contrary, I really enjoyed working with the coreboot
community, you're all very welcoming, so thanks for that! I'm leaving
because I'm feeling close to a burnout, and I don't want to get stuck
in one, so I dropped both Purism and a second client I had, in order
to concentrate on my health and well being. The reason I might not be
coming back to Purism in the future is because they have a new
contract for employees/contractors which I disagree with and I'm not
ready to sign. It's still a draft though so if the feedback is taken
into consideration and lawyers don't reject the feedback and the final
version of the contract is acceptable to me, then I might come back.
We'll see what happens! :)



>>
>> > @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...
>>
Yeah, it might make someone not update if they realize they need to do
that, but I guess if they'd only need to do it in order to break the
root of trust and overwrite the bootblock or whatever, then that might
be good. Either way, it's better than having the WP# hard wired to VCC
as it is right now.

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

Re: [coreboot] SPI controller and Lock bits

[Youness Alaoui]

Hi Everyone!

Sorry for the 2 weeks late reply, I've read your responses, but I've
been too busy and dealing with stuff and haven't had/taken the time to
reply but your input was very much appreciated and not ignored!
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. So this feature
will probably be my last coreboot contribution (for a while at least).

I'm going to try and reply quickly to some of the comments.
@Sam

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

Yes, updating the flash would be a relatively complicated process
which is ok, because for me and you, sure, we'd update the rom a few
times a day/week, but for 90% of the users, they would either :
- never do it
- only do it when a new update is released and interests them, i.e:
once or twice a year.
So it's a complicated process (as you've outlined) but 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.
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.

> 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. That's something that other possible solutions would
try to mitigate (such as vboot I think).


 @Nico:
> You two might have different kinds of updates in mind. You don't need
a switch for every update.
Well, I hadn't thought this through to be honest, but in theory you
could still flash early in the boot process (in heads) if the
protection bits aren't set on the flash. So using the jumper might
only allow flashing within the OS itself. Or maybe if the bootblock
locks its own region, maybe setting the jumpre would allow the user to
flash a new root of trust only.
I suppose that's where vboot comes through, and I've left Kyle to
investigate all that (though he says we don't need it, but I'm
starting to think he's wrong and I think he could be convinced easily
enough, I'll point him to this thread which should do the trick).
Anyways, I'm leaving Purism now and going on vacation so I'm not going
to bother trying to wrap my head around all that.

FYI: What I'm trying to do is to improve the security for current
machines, so the discussion on the jumper/etc.. is irrelevant for
machines already in the hands of customers.

@ Sam :
>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 :)
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.

On Fri, Oct 5, 2018 at 6:14 AM Nico Huber  wrote:
>
> Hi,
>
> Am 05.10.18 um 08:39 schrieb Martin Kepplinger:
> > is there already a gerrit change you are working on this? Do plan to
> > support / test
> > a X230 flash chip's lock bits?
> > * MX25L6406E/MX25L6408E
> > * EN25QH64
> > * MX25L3206E
>
> not about this request in particular but such flash-chip features in
> general: IMO, the best solution is to implement these in (lib)flashrom
> and integrate that into coreboot. I wouldn't say that it's wasted time
> to implement it in coreboot directly. But, in the long run, taking
> shortcuts or maintaining redundant implementations will slow the pro-
> ject down overall.
>
> Nico
> --
> coreboot mailing list: coreboot@coreboot.org
> https://mail.coreboot.org/mailman/listinfo/coreboot

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

Re: [coreboot] SPI controller and Lock bits

[Youness Alaoui]

On Sat, Sep 29, 2018 at 12:21 PM Nico Huber  wrote:
>
> On 9/27/18 10:29 PM, Youness Alaoui wrote:
> > Thanks everyone for the responses.
> > So far my understanding on the task at hand is :
> > - Add a CONFIG to decide if we set FLOCKDN or not (and one to decide
> > if we lock it on the resume path?)
>
> Maybe no config at all, see discussion of PRR34_LOCKDN below. But if,
> then only one config, IMO: On the resume path FLOCKDN should always be
> set.
>
> > - Remove the chipset_lockdown devicetree config and change the code to
> > always assume it's LOCKDOWN_COREBOOT (this applies to all platforms,
> > right?)
>
> Yes, unless somebody objects. Please make sure to add the right
> reviewers to this patch. I expect some resistance.
>
Ok, this is already done, but I want to finish/test my work before I
send for review and I might not have time until the end of the week.

> > - remove the call to fast_spi_pr_dlock() and fix the comment above
> > that function to be more accurate
>
> Please also check the tree for code that sets PRRs. IIRC, it is used
> somewhere to protect the MRC cache. I would set the discrete lock
> directly after writing the region.
>
Ok, thanks, will do.
Note: I've also changed the fast_spi_pr_dlock() function to take 5 u8
arguments to allow the caller to lock each prr individually instead of
being an all or nothing.

> > - Add .config CONFIG options or maybe optional devicetree configs for
> > how to setup the registers so coreboot can prepare them (due to the
> > resume path) ?
>
> Hmm, I would add Kconfig options for this as well. I you want to match
> the configuration of your payload, it definitely doesn't belong into the
> devicetree. Note that "prepare" also implies to lock them on the resume
> path.
>
Yeah, so far, the KConfigs I added are :
FAST_SPI_LOCK_REGISTERS
FAST_SPI_LOCK_REGISTERS_ON_RESUME
FAST_SPI_LOCK_PRR34_REGISTERS
FAST_SPI_LOCK_PRR34_REGISTERS_ON_RESUME
FAST_SPI_PRR3_REGISTER (hex value)
FAST_SPI_PRR4_REGISTER (hex value)

This way, a user can lock/unlock the register (since it affects more
than just the PRRs) and they can override/set the PRR3 and PRR4 values
and decide whether to lock them or not or only on resume, etc.. I
think those should be enough for most use cases and it's enough for
what I need.

> >> AIUI, FLOCKDN always locks the PRRs.
> > Actually from what I can see, the FLOCKDN will lock a few registers,
> > among which it will lock the "discrete PR locks" register, and it will
> > lock the PR 0, 1 and 2, but there's also a PRR34_LOCKDN bit to
> > separately lock the PRR 3 and 4. So technically, I could leave FLOCKDN
> > set, and in the payload, just set protected range in PRR3 or PRR4,
> > then set the PRR34_LOCKDN. Unfortunately, I can't do that because the
> > PRR3 and 4 were already locked with the discrete lock register (if I
> > remove the call to fast_spi_pr_dlock(), it should be fine for my needs
> > though I think, since you said swseq would also fail for protected
> > ranges).
>
> Ah, that PRR34_LOCKDN was only introduced with SKL. Didn't know it or
> at least didn't remember it. In this case it seems best to always set
> FLOCKDN in coreboot. The payload can then still protect additional
> regions with PRR3/4. On the resume path, coreboot would set both FLOCKDN
> and PRR34_LOCKDN, right?

On resume, even if coreboot sets them, the PRRs need to be filled,
which is why I also added the hex value of the PRR in the KConfig.
I also want to keep FLOCKDN unlocked, so Heads can set the write
protect bits in the flash then prevent writing to the status register
via hwseq before locking it with FLOCKDN.

>
> >> Also note that swseq is not an option anymore since Skylake (IIRC, the
> >> ME protects the flash-cycle go bit in its default configuration). With
> >> only hwseq, you can only access the flash chip's first status register
> >> which makes many security features unusable. So we have to rely on the
> >> protected regions :-/ I hope Intel is going to fix that for future plat-
> >> forms (or with an ME update if that could add more hwseq commands).
> >
> > Well, I saw the opmenu/optypes/etc.. registers still being set in
> > skylake (their offsets were not in the datasheet though), so I figured
> > swseq is still there, just undocumented. It might work on systems
> > where the ME is disabled. I'd have to test. I was thinking of using
> > swseq and add the write-register-2 opcode and use it to set SPR1 and
> > lock the entire flash until it gets power cycled. I don't know if that
> > would work during suspend, but if it does, it might help with the
> > resume path at least (but would prevent up

Re: [coreboot] SPI controller and Lock bits

[Youness Alaoui]

Oh boy, lots of emails to answer! So first, thanks for everyone who
shared their input, I very much appreciate it.

> I think you can decide what hardware your products include, right? I
meant dedicated hardware on the mainboard.

Yes, but I'm currently looking for a solution to existing hardware,
not for the next laptop Purism produces. And by 'dedicated hardware' I
thought you meant only allow users to update their BIOS using an
external SPI flasher, which would be impractical of course.

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

Yes, I already suggested it for the next iteration. It wouldn't be a
switch though, but rather a low profile 90-degrees jumper on the
motherboard.
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 (I assume there would be a way to
detect if WP# is 1/0 through a GPIO (or other method) without being
able to use that GPIO to override the WP# value).
Right now, if you boot into linux while ignoring tampering, you get
your ttys in red, as a huge and very visible warning.
Also, yes Sam, you did understand me perfectly, thanks!


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

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

Re: [coreboot] SPI controller and Lock bits

[Youness Alaoui]

On Thu, Sep 27, 2018 at 10:18 PM Sam Kuper  wrote:
>
> 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

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.

>
>
> > Looking for a software solution is IMO like Intel trying to secure SMM.
>
> Hear, hear!
>

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,
once you decide you don't need to write to the flash, you lock it
until your next reboot.


> This is a pretty useful feature, and it would be nice if it weren't tied to 
> heads (or any payload for that matter). What about tianocore's capsule update 
> mechanism, as well as stuff like fwupd ? Any way to have something like a 
> common solution ?

Tianocore is a payload, so tianocore's update mechanism is still about
doing the update in the payload.. All heads is going to do is to run a
script that calls flashrom (and actually use cbfstool to
extract/inject the heads-specific cbfs files into the new image, such
as the user's pgp keys for example, before flashing).. so it will have
to be tied to heads either way.
Heads is the one booting into your OS, so it can read-only lock the
entire flash before the user (real or malicious) gets control. The use
of heads is already tied in with the use a gpg key (nitrokey, yubikey,
librem key), and you'd already need to have the key inserted (and pin
valid) before it would give you access to a recovery shell, and the
same can be done before it allows the flash to be updated.
I hadn't thought of the use case of fwupd (which we're currently
adding support for) since it wouldn't be able to flash from the OS,
but I think that having the update file deosited in /boot under a
specific filename and rebooting would be all that fwupd would need to
do, then on the next boot, heads would find the file and suggest to
the user to flash it.

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

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

Re: [coreboot] SPI controller and Lock bits

[Youness Alaoui]

Thanks everyone for the responses.
So far my understanding on the task at hand is :
- Add a CONFIG to decide if we set FLOCKDN or not (and one to decide
if we lock it on the resume path?)
- Remove the chipset_lockdown devicetree config and change the code to
always assume it's LOCKDOWN_COREBOOT (this applies to all platforms,
right?)
- remove the call to fast_spi_pr_dlock() and fix the comment above
that function to be more accurate
- Add .config CONFIG options or maybe optional devicetree configs for
how to setup the registers so coreboot can prepare them (due to the
resume path) ?

Can you please confirm the ones with question marks? Is there some
rule on "add as little CONFIG options as possible" ?

> AIUI, FLOCKDN always locks the PRRs.
Actually from what I can see, the FLOCKDN will lock a few registers,
among which it will lock the "discrete PR locks" register, and it will
lock the PR 0, 1 and 2, but there's also a PRR34_LOCKDN bit to
separately lock the PRR 3 and 4. So technically, I could leave FLOCKDN
set, and in the payload, just set protected range in PRR3 or PRR4,
then set the PRR34_LOCKDN. Unfortunately, I can't do that because the
PRR3 and 4 were already locked with the discrete lock register (if I
remove the call to fast_spi_pr_dlock(), it should be fine for my needs
though I think, since you said swseq would also fail for protected
ranges).

On Thu, Sep 27, 2018 at 1:09 PM Dhaval Sharma  wrote:
>
> "but once you boot an OS, Heads would first lock the flash so it can't be 
> written to'. Is this some kind of a OS driver? The typical usage of all 
> locking register which are write once is to have them locked up within BIOS 
> itself which is within the most trusted boundary. Best we could do it push 
> out the locking part to the latest stages but not completely out IMHO.

The problem is we want to allow users to update their flash and
coreboot doesn't have a "flash update utility" integrated, so it has
to happen in the payload, which is why coreboot needs to not lock
anything then let the payload do the locking for us instead. Heads is
the linux-based payload we're using, and the idea is that Heads would
lock the flash before it actually boots any OS (from HDD or from USB),
this way you can only update your flash from within Heads itself and
Heads will ensure that the image you're trying to flash is properly
signed, or that you authenticate first before it would allow you to do
that (prevents someone from booting into a live USB and flash a
malicious bios).

> You can have write opcodes in the menu, they won't work on protected regions. 
> But if you have
> a partially protected flash (e.g. vboot), they are still useful.
Ok, that's interesting. I was actually thinking of just completely
disabling writing to any region, but maybe I can use the PRR instead.

> Also note that swseq is not an option anymore since Skylake (IIRC, the
> ME protects the flash-cycle go bit in its default configuration). With
> only hwseq, you can only access the flash chip's first status register
> which makes many security features unusable. So we have to rely on the
> protected regions :-/ I hope Intel is going to fix that for future plat-
> forms (or with an ME update if that could add more hwseq commands).

Well, I saw the opmenu/optypes/etc.. registers still being set in
skylake (their offsets were not in the datasheet though), so I figured
swseq is still there, just undocumented. It might work on systems
where the ME is disabled. I'd have to test. I was thinking of using
swseq and add the write-register-2 opcode and use it to set SPR1 and
lock the entire flash until it gets power cycled. I don't know if that
would work during suspend, but if it does, it might help with the
resume path at least (but would prevent updating flash after a reboot
and would force user to shut down and boot). I guess I have some
trial-error to do.
Actually, if status register remains the same through a
reboot/suspend/resume, and swseq doesn't work on skylake at all, I
could just set the protect bits and prevent writing to status register
on resume path.

> One way would be to let coreboot decide, e.g. prepare the configuration
> and don't lock it, and let the payload lock. The payload could validate
> this configuration before locking (and issue a warning if coreboot
> didn't set the expected bits).

Thanks, that's a good idea, I forgot about the suspend/resume case.
This implies I need coreboot to know about what config the payload
will want to set. I'm not sure if that should go into a CONFIG or a
devicetree config. Since it might be user-configured, it makes more
sense for it to go into .config, right ?

Thanks again,
Youness.

>
>
> On Thu, Sep 27, 2018 at 9:55 PM Lance Zhao  wrote:
>>
>> Okay, then I believe we should leave the decision on CONFIG instead of force 
>> lockdown blindly. As of now, that's still optional I believe.
>>
>>
>> On Thu, Sep 27, 2018 at 3:49 AM Nico Huber  wrote:
>>>
>>> Am 26.09.18 um 22:26 schrieb Lance 

[coreboot] SPI controller and Lock bits

[Youness Alaoui]

Hi,

I'm trying to add a way to lock the SPI flash to be read-only via
software *after* coreboot boots. The scenario is basically with using
Heads, you could authenticate to it (with a yubikey/nitrokey/librem
key) then be able to flash a new rom (update your BIOS), but once you
boot an OS, Heads would first lock the flash so it can't be written
to.
This should add some security to avoid any malware writing to the
flash, or someone booting into a USB stick and using that to flash a
malicious BIOS, but still gives the user the freedom of updating their
flash whenever they want to.

The problem is that I can't make the flash read-only because the SPI
interface is already locked down by coreboot (see
src/soc/intel/skylake/lockdown.c and
src/soc/intel/common/block/fast_spi/fast_spi.c).

There's a couple of things happening here :
First, the FLOCKDN bit is set which prevents us from enabling the
write protection. the BIOS Interface lock down is controlled by the
chipset_lockdown config variable, but the FLOCKDN is not behind a
config variable.
The second thing is that if I wanted to use the protected ranges
feature to lock specific regions, they are all getting locked using
the discrete lock register even while being unused. The locking of the
protected ranges was added in this change :
https://review.coreboot.org/c/coreboot/+/21064 and it passed without
notice among the move that the commit was supposed to do.

The commit states that the lockdown is meant to "support platform
security guidelines", but I think that this is not actually good
because coreboot leaves everything read-write and locks down the
registers so we can't make it read-only. I think that the security
guidelines would say to disable the write protection before locking
the registers down.

Either way, I'm going to need to add a way to make this configurable,
so my main questions here are :
- Should I create a new config variable to decide on whether or not to
lock the spi registers and another one to decide on whether or not to
lock the protected ranges ?
- Should I make the chipset_lockdown (currently used for locking the
BIOS CNTL register from LPC and SPI controllers) into an OR-ed flags
variable where we can say : chipset_lockdown = LOCKDOWN_COREBOOT |
LOCKDOWN_SPI | LOCKDOWN_PROTECTED_RANGES ?
- Should I make a single new config variable to decide what to
lockdown (LPC_BIOS, SPI_BIOS, SPI_BAR, SPI_PROTECTED_RANGES) and only
set them if the CHIPSET_LOCKDOWN_COREBOOT is set ? And if
chipset_lockdown is set to CHIPSET_LOCKDOWN_FSP not lockdown anything
at all ?
- Do we want to keep the protected ranges locked down at all, have
them configurable or completely remove that as I don't see the point
in using the discrete lock register ?

Once I see a consensus on what's the best way to move forward, I'll
implement it and push it for review.

Note: I think these only affect hardware sequencing though so I assume
someone could always use software sequencing to do the writes. As long
as the FLOCKDN bit isn't set though, I could remove all write-related
opcodes from the software sequencing register, which would also
prevent someone using swseq to do writes.

Thanks,
Youness.

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

Re: [coreboot] T450S + Coreboot

[Youness Alaoui]

On Sat, Sep 8, 2018 at 2:31 PM Peter Stuge  wrote:
>
> Youness Alaoui wrote:
> > So, back to the ME, we know exactly what it does, it's all extremely
> > well documented and explained
>
> I disagree with this.
>
> It is absolutely true that *some* of what the ME does is extremely well
> documented and explained by the vendor, web services APIs and all, but
> I would argue that in fact *most* of what the ME does is *not* documented
> by the vendor, nor by independent research.
>
I mostly agree, I was referring to Mike's talk about the remote
control features, so yes, I should have said "AMT is well documented",
but yes, there are huge portions of what the ME itself does (such as
the power on sequence, or what/how it sets some registers) which are
totally undocumented.
So yes, even if we don't know exactly what the ME does during the
power sequence (among other things), we still know that "it
initializes hardware", we just don't know how it achieves that task.
So we know "what it does", but we don't know "exactly what it does"
and we don't know "how it does it", which is where I was wrong in my
previous statement.

However, we need to differentiate between "this ME is something
obscure that we have no idea what it's for" versus "we know what this
ME thing is supposed to be for or what it's supposed to be doing, we
just have no way to be sure that it doesn't do anything else or that
it does what it's supposed to".
I disagree with the idea that the ME is this black box, this sort of
"hidden spy device" that gives full remote capabilities to some
unknown entity in the same way that I would disagree that because MS
Windows is closed source that any Windows machine is fully
remote-controlled by M$ employees at any time or that the OS is
commissioned by the CIA or whatever. I do agree that because it's
closed source, we can't know whether it is or not, but it's just not a
guarantee that it is.


> Since the ME is colocated with the x86 VM host, has access to all x86 VM
> memory *and* is a proprietary machine or subsystem I actually don't
> believe that we will ever "know exactly what it does".
>
Well, we could know, if we reverse engineer its code from the maskrom
to the BUP, but yes, it would be very hard to fully know for certain.
Besides, I'd assume that anything malicious would probably be written
in silicon rather than in reverse-engineerable code. So I'd apply the
same idea to the whole PCH/CPU. The major problem with the ME when
compared to my previous comparison with MS Windows is that we can
chose Linux instead of Windows, but we can't choose to disable or to
use a custom ME firmware (i.e: the not-user-controlled issue).

>
> > Now the problem is that it's closed source, and not user controlled
>
> Right.
>
>
> //Peter
>
> --
> coreboot mailing list: coreboot@coreboot.org
> https://mail.coreboot.org/mailman/listinfo/coreboot

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

Re: [coreboot] T450S + Coreboot

[Youness Alaoui]

 remote management purposes, perhaps there are
> infinite possibilities of what you could do with this core. So it
> could be turned into the competitive advantage which will be valid
> even from a paranoid point of view. It will be really nice to see it
> happen. But it didn't happen yet - and I am worried that Intel's
> hostile actions might prevent the completion of your benevolent
> research or at least prevent it from going public. Because I remember
> how they took down your "FSP Reverse Engineering" articles as well as
> the source code associated with it. What will prevent them from doing
> it again? And if they can't DMCA your work because the reverse
> engineering is legal at many countries including USA, they could just
> threaten to stop supplying Librem laptops with their CPUs (like they
> probably did) and it's all over now.
Even if I do finish this, the ME wouldn't be "open" because there
would still be code executing from the ROM all the way to the moment
the exploit happens, so it's not a magical solution, but it is better
than nothing and it would give us user-control of the CPU. Also, Intel
didn't "take down" my article, and it had nothing to do with the DMCA
or whatever. It was not a cease letter, it was not an Intel
lawyer contacting us, or anything of the sort. It was a software
manager who sent a nice and respectful email, asking us to remove the
article because the license of the FSP prevents reverse engineering. I
believe we are in the right, and there are plenty of responses we
could have given, but I think it was better to simply remove it
instead of fighting it, no harm done.

>
> Actually it might be a good idea for Purism to at least consider the
> switch to AMD Ryzen CPUs. Yes, unlike the 15h/early16h gen AMD CPUs,
> their new Ryzen CPUs contain the PSP, Platform Security Processor -
> which is also a management engine. But it is significantly younger
> than Intel ME (Skylake's ME is already generation 11), so PSP should
> have less sophisticated protections and it should be easier to
> "jailbreak" this "young PSP" rather than "modern ME". Early ME
> implementations were also weak, after all, and I expect "young PSP" to
> be weak also. Also, those AMD CPUs do not suffer from the
> recently-discovered Intel-specific vulnerabilities and their
> performance-degrading patches will not be required. Finally, AMD had a
> good collaboration history with coreboot (although this collaboration
> is not active currently, it might be renewed if there will be enough
> mutual interest) - and I believe AMD at least will not be as hostile
> towards your opensource/reverse-engineering efforts as Intel is
> currently. If any of these statements seems reasonable to you, please
> think of trying to make your Purism company to at least consider this
> AMD switch.
>
That's a very weak argument. The PSP isn't "less sophisticated" than
the ME because it's younger.. that's just not how software works.
Maybe the PSP is smaller/simpler, and therefore less likely to have
bugs that can be exploited, maybe the QA team at AMD is better than
the one at Intel, or that they have additional tests/steps in their
validation. As for "I believe AMD at least will not be as hostile"..
why do you believe that? what makes you believe that? why would you
suggest AMD, a corporation, would be less likely to try and defend
what it considers to be its rights?
That being said, future hardware is not exclusively Intel, all avenues
are explored. If AMD is indeed better, then AMD might be chosen, but
that decision won't be based on "the PSP will be easier to crack
because it's younger" nor will it be based on "for some unknown
reason, AMD will be fine with us reverse engineering it".
Besides, my understanding is that coreboot does not support ryzen
CPUs, so a huge amount of work would be required if we went that way,
no ?

> Best regards,
> Mike
>
> "disable Intel hyperthreading" :
> [1] - https://news.ycombinator.com/item?id=17829790
> [2] - https://marc.info/?l=openbsd-tech=153504937925732=2
> speaker as a microphone:
> [3] - 
> https://security.stackexchange.com/questions/154343/can-a-speaker-be-used-as-a-microphone
> [4] - https://mail.coreboot.org/pipermail/coreboot/2018-January/085979.html
> On Thu, Aug 30, 2018 at 12:41 AM Youness Alaoui
>  wrote:
> >
> >  Wow, Mike, seriously, I am going to side 100% with Nico, you are
> > spreading FUD, making your own personal opinions (which are themselves
> > derived from other people's FUD) and stating them as the universal
> > law.
> > The ME is not known to be a backdoor. It doesn't mean that it's not a
> > backdoor, it simply means that it's not known to be a backdoor. The
> > fa

Re: [coreboot] T450S + Coreboot

[Youness Alaoui]

On Thu, Aug 30, 2018 at 2:15 AM Brian Herman
 wrote:
>
> Sorry, I'm going to read the documentation more and make this a personal goal 
> by the end of 2019. I didn't want to stir up so much drama. Time and money 
> are not constraints on this particular problem. One way or another by January 
> 22, 2019 I will have either figured it out or I will pay to figure it out. I 
> have used Linux since college. I have no kids. I have no girlfriend. I have 
> tons of free time.
>
Sorry to see your thread going off-topic.
I don't know if it will help you but I've wirtten detailed blog posts
on my experience in getting coreboot to work on the broadwell and
skylake librems. It's not a "guide how to port to coreboot" but it
explains some of the problems I've had and it might help you save some
time.
You can go to https://puri.sm/coreboot/timeline/ and search for
"Youness" to see my blog posts in chronological order on the right
side bar.
Good luck with your project!

> Make It So,
> Brian Herman
>
>
>
>
>
>
>
>
>
>
>
> So you have made it to the end..
> Thanks for reading!
>
> On Wed, Aug 29, 2018 at 4:42 PM Youness Alaoui 
>  wrote:
>>
>>  Wow, Mike, seriously, I am going to side 100% with Nico, you are
>> spreading FUD, making your own personal opinions (which are themselves
>> derived from other people's FUD) and stating them as the universal
>> law.
>> The ME is not known to be a backdoor. It doesn't mean that it's not a
>> backdoor, it simply means that it's not known to be a backdoor. The
>> fact that it's closed source and not user-controlled (Even if you had
>> the sources, you can't modify them and update it to your custom ME
>> version) is where the problem actually is. There *might* be a backdoor
>> hidden somewhere in there, or maybe there isn't, nobody knows, but
>> there has been a lot of research done on the ME and so far, none have
>> been found as far as I know.
>>
>> Your worry about what the ME does, how it can give someone control
>> over the PC, etc.. are NOT what qualifies it as a "backdoor", but like
>> Nico said, it's a frontdoor, it's not a "hidden access", it's a
>> "promoted access" to the PC, it's the main ME functionality which is
>> well documented. You don't have to use some "only known to some secret
>> person" trick to access the ME, you just need to point your web
>> browser to the right port on localhost.
>> Your comparison of saying the ME is a backdoor is like saying that a
>> webcam is a spying device because it can capture images of you! Yeah,
>> sure, that's technically true, it can capture images of you, but only
>> after you plug it in and open an image capture software, and you still
>> have control of those images. The fact that the webcam schematics
>> isn't open means that it could still have a small wifi or GSM chip
>> embedded inside which makes it send the images to the CIA, but it's
>> not a guarantee that it does. So, yes, you can complain that the
>> webcam isn't open hardware so you can't technically trust what it
>> does, but you can't just come out and say with absolute certainty that
>> any and all webcams in the world are spying devices for the CIA,
>> that's just ridiculous.
>>
>> So, back to the ME, we know exactly what it does, it's all extremely
>> well documented and explained, the fact that it allows remote control
>> of the PC is actually the reason for its existence and it's a very
>> very valid reason in the corporate context and the fact that those
>> features also 'coincidentally' resemble the features of an actual
>> 'trojan horse' virus, doesn't mean that the ME itself is a virus..
>> otherwise the 'rm' linux command would be considered a virus since it
>> deletes files and there are some viruses that can delete your files as
>> well
>> Now the problem is that it's closed source, and not user controlled
>> (remote control features *are* user controlled, I'm talking about
>> being able to replace the firmware with your own), so yes, it can't be
>> audited by the larger open source community, but that also doesn't
>> guarantee any security necessarily (how many open source programs
>> still have security bugs?).
>>
>> Either way, you yourself said earlier, when talking about the AtomBIOS
>> that "it could be disassembled quite well with AtomDis -
>> https://github.com/mikebdp2/AtomDis - reducing any security concerns
>> regarding this blob to a minimum.", well, the ME can be disassembled
>> with any x86 disassembler, so why can't you also say that "reduces any

Re: [coreboot] T450S + Coreboot

[Youness Alaoui]

 Wow, Mike, seriously, I am going to side 100% with Nico, you are
spreading FUD, making your own personal opinions (which are themselves
derived from other people's FUD) and stating them as the universal
law.
The ME is not known to be a backdoor. It doesn't mean that it's not a
backdoor, it simply means that it's not known to be a backdoor. The
fact that it's closed source and not user-controlled (Even if you had
the sources, you can't modify them and update it to your custom ME
version) is where the problem actually is. There *might* be a backdoor
hidden somewhere in there, or maybe there isn't, nobody knows, but
there has been a lot of research done on the ME and so far, none have
been found as far as I know.

Your worry about what the ME does, how it can give someone control
over the PC, etc.. are NOT what qualifies it as a "backdoor", but like
Nico said, it's a frontdoor, it's not a "hidden access", it's a
"promoted access" to the PC, it's the main ME functionality which is
well documented. You don't have to use some "only known to some secret
person" trick to access the ME, you just need to point your web
browser to the right port on localhost.
Your comparison of saying the ME is a backdoor is like saying that a
webcam is a spying device because it can capture images of you! Yeah,
sure, that's technically true, it can capture images of you, but only
after you plug it in and open an image capture software, and you still
have control of those images. The fact that the webcam schematics
isn't open means that it could still have a small wifi or GSM chip
embedded inside which makes it send the images to the CIA, but it's
not a guarantee that it does. So, yes, you can complain that the
webcam isn't open hardware so you can't technically trust what it
does, but you can't just come out and say with absolute certainty that
any and all webcams in the world are spying devices for the CIA,
that's just ridiculous.

So, back to the ME, we know exactly what it does, it's all extremely
well documented and explained, the fact that it allows remote control
of the PC is actually the reason for its existence and it's a very
very valid reason in the corporate context and the fact that those
features also 'coincidentally' resemble the features of an actual
'trojan horse' virus, doesn't mean that the ME itself is a virus..
otherwise the 'rm' linux command would be considered a virus since it
deletes files and there are some viruses that can delete your files as
well
Now the problem is that it's closed source, and not user controlled
(remote control features *are* user controlled, I'm talking about
being able to replace the firmware with your own), so yes, it can't be
audited by the larger open source community, but that also doesn't
guarantee any security necessarily (how many open source programs
still have security bugs?).

Either way, you yourself said earlier, when talking about the AtomBIOS
that "it could be disassembled quite well with AtomDis -
https://github.com/mikebdp2/AtomDis - reducing any security concerns
regarding this blob to a minimum.", well, the ME can be disassembled
with any x86 disassembler, so why can't you also say that "reduces any
security concerns regarding the ME to a minimum".

We're about to get full control back of the ME. I've been working for
the past few weeks on reproducing the PTResearch buffer overflow
exploit on the ME, and yesterday they released a PoC for Apollolake
(in case you missed it : https://github.com/ptresearch/IntelTXE-PoC),
so with the progress I made and with that, I should be able to soon
port it to skylake (and write docs on how to port to other platforms
as well) which will at least give us the ability to gain back the
'user-controlled' aspect of it as we'd have code execution on it.
Which by the way, also means that BootGuard can be disabled (since the
ME is the one checking for the boot guard signatures), which should
enable the ability to port coreboot to a lot more machines (including
the T450S that this thread is supposed to be about). Hopefully

On Wed, Aug 29, 2018 at 5:50 AM Mike Banon  wrote:
>
> > What suspicious activities? I know, for many people the Intel ME firmware
> > contains unwanted features. But these features are documented.
> > In your world, a device becomes backdoored because somebody
> > didn't read the manual?!?
>
> Somewhere I've seen a report about Intel ME suspicious network
> activities (if I remember correctly they were using Wireshark on a PC
> placed between a computer with ME and the outside network) which has
> affected my personal opinion. Although it could be argued that its
> just some OEM has set up their ME in such a way, maybe even in a
> documented way (although a way undesirable to the end user), still it
> didn't look good to me. In addition, regarding all those Intel ME
> vulnerabilities recently discovered: one could assume that at least
> some of these "vulnerabilities" @ were actually the backdoors which
> have 

Re: [coreboot] Intel ME what is it? And when did this dangerous thing get installed?

[Youness Alaoui]

I think there's a good explanation of it in the FAQ of the libreboot
project here : https://libreboot.org/faq.html#intelme
If there are more specific questions that you have, ask them and I
might be able to answer them!

On Wed, Aug 29, 2018 at 2:36 AM Gregg Levine  wrote:
>
> Hello!
> Would one of you, or even any of you please take some time out of your
> busy schedule and ponder the subject? And of course try to respond
> accordingly?
>
> Bootguard sadly I am familiar with, but the Intel ME product I confess
> I understand a portion about it. And not enough to mention here.
> -
> Gregg C Levine gregg.drw...@gmail.com
> "This signature fought the Time Wars, time and again."
>
> --
> coreboot mailing list: coreboot@coreboot.org
> https://mail.coreboot.org/mailman/listinfo/coreboot

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

Re: [coreboot] Using linux as payload

[Youness Alaoui]

Hi,

I might not be the best one to answer your question, but here are my thoughts :
- the "unknown type 'payload'" error is probably because cbfs changed
the type name from "payload' to "simple elf" since you can add elfs in
there that are not actual 'payloads'. I think though that it
auto-changed the file type to 'simple elf', since you can see in the
cbfs print :
fallback/payload   0xc7a80simple elf5244700 none
So the payload is added, it has type "simple elf" and is 5.2MB (which
is the bzImage + initrd.cpio size).
Then in your cbmem log you can see that it did find the payload and
that it decompressed all the sections and everything seems fine :
CBFS: Locating 'fallback/payload'
CBFS: Found @ offset c7b80 size 5006d5
[...]

And then it jumps into it (i.e: it executes the payload) :
Jumping to boot code at 0004(8fe11000)

The reason that's the last messages you see is simply because linux
does not print any messages to cbmem (SeaBIOS does, and if you look at
your old logs, you'd see right after that "jumping to boot code"
there's the SeaBIOS debug messages starting).

So I think it's all good for you, but your problem is actually with
your linux (Heads) configuration itself, you probably simply do not
have the right graphics driver enabled in the kernel, so linux boots
but it doesn't initialize the GPU so nothing appears. You can either
find and enable your GPU driver in the kernel and rebuild Heads, or
you can tell coreboot to initialize the gpu (either with the GOP
driver+VBT or by running the option rom) and tell it to initialize the
VGA framebuffer (probably in text mode though I'm not sure) or
whatever is needed to actually get some graphics output.
I remember trying a few different options and configurations for the
Librem and in the end, I simply removed the vgabios/vbt from coreboot,
told coreboot not to initialize the graphics, and added the i915
kernel driver to heads and that was all that was needed. Once heads
booted, the kernel driver initialized the graphics and that's it.

I hope that helps,
Youness.

On Sat, Aug 18, 2018 at 4:51 AM Jorge Fernandez Monteagudo
 wrote:
>
> Hi all!
>
>
> I have a coreboot from master git working ok in my AMD Bettong demoboard with 
> SeaBIOS and now
>
> I'm trying to use a bzImage (2651888 bytes) and initrd.cpio.xz (2604544 
> bytes) generated by Heads in
>
> order to test the linux payload.
>
>
> When I compile the coreboot I see:
>
>
> Created CBFS (capacity = 8388056 bytes)
> CBFS   apu/amdfw
> CBFS   AGESA
> CBFS   fallback/romstage
> CBFS   fallback/ramstage
> CBFS   cmos_layout.bin
> CBFS   pci1002,9874.rom
> CBFS   fallback/dsdt.aml
> CBFS   fallback/payload
> W: Unknown type 'payload' ignored
> CBFS   coreboot.rom
> CBFSLAYOUT  coreboot.rom
>
> This image contains the following sections that can be manipulated with this 
> tool:
>
> 'COREBOOT' (CBFS, size 8388096, offset 512)
>
> It is possible to perform either the write action or the CBFS add/remove 
> actions on every section listed above.
> To see the image's read-only sections as well, rerun with the -w option.
> CBFSPRINT  coreboot.rom
>
> Name   Offset Type   Size   Comp
> cbfs master header 0x0cbfs header32 none
> fallback/romstage  0x80   stage   32220 none
> fallback/ramstage  0x7ec0 stage   56689 none
> cmos_layout.bin0x15c80cmos_layout  1516 none
> fallback/dsdt.aml  0x162c0raw  6673 none
> (empty)0x17d40null32856 none
> apu/amdfw  0x1fdc0raw622592 none
> pci1002,9874.rom   0xb7e00optionrom   64512 none
> fallback/payload   0xc7a80simple elf5244700 none
> (empty)0x5c8200   null   228248 none
> AGESA  0x5ffdc0   raw690436 none
> (empty)0x6a8740   null  1405592 none
> bootblock  0x7ffa00   bootblock 912 none
>
> Built amd/bettong (FP4)
>
>
> The "W: Unknown type 'payload' ignored" message is ok? Maybe the payload 
> doesn't fit in the
>
> coreboot image?
>
>
> Now when I boot the board the last messages I can see on serial console are:
>
>
> ...
>
> Writing table forward entry at 0x0500
> Wrote coreboot table at: 0500, 0x10 bytes, checksum 5ffd
> Writing coreboot table at 0x8fe11000
>  0. -0fff: CONFIGURATION TABLES
>  1. 1000-0009: RAM
>  2. 000c-8fdd9fff: RAM
>  3. 8fdda000-8fff: CONFIGURATION TABLES
>  4. 9000-cfff: RESERVED
>  5. f800-fbff: RESERVED
>  6. fed4-fed44fff: RESERVED
>  7. 0001-00022eff: 

Re: [coreboot] Kaby Lake FSP

[Youness Alaoui]

Great, thanks!
I understand that as platform ages, it gets less development, I was
mostly asking because I saw that coffeelake FSP headers are in
coreboot but there are no FSP images for coffeelake on github yet,
which is basically the same/similar issue as what we complained about
with regards to Kabylake, and your answer was only about Kabylake, so
I was hoping other platforms are "in the works" for being kept up to
date between public and "internal" releases.

Thanks,
Youness.
On Wed, Jul 18, 2018 at 8:05 PM Desimone, Nathaniel L
 wrote:
>
> Hi Youness,
>
> In general yes, Intel does plan to continue developing of FSP for future 
> platforms. We will make a good faith effort to keep the publically posted FSP 
> binary freshly updated. I would like to caution that as a platform ages, our 
> internal development shifts to newer ones. Accordingly, I would expect the 
> frequency of FSP releases to lengthen as a platform ages.
>
> Thanks,
> Nate
>
> -Original Message-
> From: Youness Alaoui [mailto:kakar...@kakaroto.homelinux.net]
> Sent: Monday, July 16, 2018 12:29 PM
> To: Desimone, Nathaniel L 
> Cc: coreboot 
> Subject: Re: [coreboot] Kaby Lake FSP
>
> Hi Nate,
>
> Thanks a lot for listening to our request and taking care of this! I'm happy 
> to see the binaries finally updated and the FSP headers in coreboot having a 
> matching publicly available binary to use.
> You've only mentioned Kabylake in your email, is it safe to assume that 
> you'll use these same practices for future platforms as well ?
>
> Thanks,
> Youness.
> On Tue, Jul 10, 2018 at 9:04 PM Desimone, Nathaniel L 
>  wrote:
> >
> > Hi All,
> >
> > I am a UEFI firmware architect working for Intel Corp. One of my focus 
> > areas is FSP. There was some prior discussion here regarding the lack of 
> > public updates for Kaby Lake FSP binaries and headers and questions 
> > regarding specialized FSP binaries being built for specific boards. I would 
> > like to clear up some of these questions and concerns. We just pushed all 
> > of the recently released versions of Kaby Lake FSP (3.1.0 through 3.6.0) to 
> > https://github.com/IntelFsp/FSP/tree/Kabylake. While there might appear to 
> > be forks of Kaby Lake FSP, they are actually just snapshots at different 
> > points in time. For example, there is one commit labelled as "Gold release 
> > for Kaby Lake FSP" that appears to be special fork for IoT devices... this 
> > commit is actually just Kaby Lake FSP Release 2.6.0 without any IoT 
> > specific modifications. Apologies for the confusing commit messages and for 
> > the temporary lapse in updates.
> >
> > With Best Regards,
> >
> > Nate
> >
> > --
> > coreboot mailing list: coreboot@coreboot.org
> > https://mail.coreboot.org/mailman/listinfo/coreboot

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

Re: [coreboot] Kaby Lake FSP

[Youness Alaoui]

Hi Nate,

Thanks a lot for listening to our request and taking care of this! I'm
happy to see the binaries finally updated and the FSP headers in
coreboot having a matching publicly available binary to use.
You've only mentioned Kabylake in your email, is it safe to assume
that you'll use these same practices for future platforms as well ?

Thanks,
Youness.
On Tue, Jul 10, 2018 at 9:04 PM Desimone, Nathaniel L
 wrote:
>
> Hi All,
>
> I am a UEFI firmware architect working for Intel Corp. One of my focus areas 
> is FSP. There was some prior discussion here regarding the lack of public 
> updates for Kaby Lake FSP binaries and headers and questions regarding 
> specialized FSP binaries being built for specific boards. I would like to 
> clear up some of these questions and concerns. We just pushed all of the 
> recently released versions of Kaby Lake FSP (3.1.0 through 3.6.0) to 
> https://github.com/IntelFsp/FSP/tree/Kabylake. While there might appear to be 
> forks of Kaby Lake FSP, they are actually just snapshots at different points 
> in time. For example, there is one commit labelled as "Gold release for Kaby 
> Lake FSP" that appears to be special fork for IoT devices... this commit is 
> actually just Kaby Lake FSP Release 2.6.0 without any IoT specific 
> modifications. Apologies for the confusing commit messages and for the 
> temporary lapse in updates.
>
> With Best Regards,
>
> Nate
>
> --
> coreboot mailing list: coreboot@coreboot.org
> https://mail.coreboot.org/mailman/listinfo/coreboot

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

Re: [coreboot] Porting coreboot to new board

[Youness Alaoui]

This is the best I can do for you :

https://ark.intel.com/products/89608/Intel-Xeon-Processor-E3-1505M-v5-8M-Cache-2_80-GHz

Product Collection: Intel® Xeon® Processor E3 v5 Family
Code Name: Products formerly Skylake

kakaroto@kakaroto:~/coding/purism/coreboot$ git grep SOC_INTEL_SKYLAKE
| grep mainboard
src/mainboard/google/chell/Kconfig: select SOC_INTEL_SKYLAKE
src/mainboard/google/glados/Kconfig: select SOC_INTEL_SKYLAKE
src/mainboard/google/lars/Kconfig: select SOC_INTEL_SKYLAKE
src/mainboard/intel/kblrvp/Kconfig: select SOC_INTEL_SKYLAKE
src/mainboard/intel/kunimitsu/Kconfig: select SOC_INTEL_SKYLAKE
src/mainboard/intel/saddlebrook/Kconfig: select SOC_INTEL_SKYLAKE
src/mainboard/purism/librem_skl/Kconfig: select SOC_INTEL_SKYLAKE

I'm going to assume that the skylake Xeon is supported and will work
(from a coreboot standpoint) just the same as a Core i5 or whatever,
but it might not be the case. That will be your job to figure the rest
out.

Good luck,
Youness.


On Wed, May 30, 2018 at 3:35 PM, Zvi Vered  wrote:
> Hello Youness,
>
> Thank you very much for the detailed information !
>
> Can you please tell what is the best starting point for a XEON board ?
> I think there are no "Intel® XEON® Processor E3-1505M v5" boards in last
> version of coreboot.
> Am I right ?
>
> Best regards,
> Zvika
>
> On Tue, May 29, 2018 at 9:15 PM Youness Alaoui
>  wrote:
>>
>> Hi,
>>
>> I suggest you read the wiki :
>> https://www.coreboot.org/Developer_Manual and
>> https://www.coreboot.org/Motherboard_Porting_Guide
>> I would also suggest maybe (optional) that you read my blog posts
>> about my own experience porting coreboot to a new motherboard :
>> https://puri.sm/posts/diving-back-into-coreboot-development/
>> https://puri.sm/posts/librem-13-coreboot-report-january-12-2017/
>> https://puri.sm/posts/librem-13-coreboot-report-february-3rd-2017/
>> https://puri.sm/posts/librem-13-coreboot-report-february-25th-2017/
>> https://puri.sm/posts/coreboot-on-the-librem-13-v2-part-1/
>> https://puri.sm/posts/coreboot-on-the-skylake-librems-part-2/
>>
>> To answer your specific questions : It depends on your machine, is it
>> AMD or is it Intel? Is it Ivybridge or Broadwell or Skylake or
>> Apollolake, etc.. ? Does it have soldered RAM or does it use SODIMMs?
>> Depending on the CPU architecture, the CPU 'brand' and even the model
>> of the CPU itself, the port will be done very differently. You'd first
>> want to find a mainboard that is as close as your current one, and
>> start modifying that, there isn't "one mainboard to use as base"
>> because the code, files, etc.. are almost unique depending on the
>> CPU/northbridge/southbridge model, so use the closest one as your
>> base.
>> As far as I know, the file board_info.txt is just information about
>> the board, it's not getting used by coreboot, it's more of an
>> indication for developers.
>> As for the other files, it will depend once again on your board. I'd
>> say Kconfig and devicetree.cb are mandatory, the rest may or may not
>> be mandatory depending on your hardware. The cmos.layout for example
>> isn't mandatory, but you'd probably need it if you enable CMOS support
>> in your KConfig, The 'spd' files containing the RAM's SPD EEPROM
>> information are mandatory only if your board has soldered RAM (common
>> in laptops but not in desktops), but they are not needed (and actually
>> can't be provided) if the motherboard has SODIMM slots instead. So it
>> all depends. Your best bet is to look at what's there and see if you
>> need it or not and if you do, understand what it's for and what needs
>> to be changed in order to match your board.
>> Don't forget that before you get your board to boot with coreboot, you
>> will probably have to flash it and brick your board 100 times, so make
>> sure you have a backup of your original ROM copied somewhere safe and
>> that you have the hardware to re-program the SPI flash externally (and
>> test that it works), before you attempt to flash it.
>> Also, make sure you are patient, and ready to learn!
>>
>> Good luck!
>> Youness.
>>
>>
>> On Mon, May 28, 2018 at 10:31 PM, Zvi Vered  wrote:
>> > Hello,
>> >
>> > I have to port coreboot to a new "Mainboard" not listed in menuconfig.
>> > Is there a basic "Mainboard" I should use as a starting point that will
>> > be
>> > copied to my board ?
>> >
>> > The file board_info.txt contains few parameters.
>> > How can I know the meaning of each parameter and its possible values ?
>> >
>> >

Re: [coreboot] Porting coreboot to new board

[Youness Alaoui]

Hi,

I suggest you read the wiki :
https://www.coreboot.org/Developer_Manual and
https://www.coreboot.org/Motherboard_Porting_Guide
I would also suggest maybe (optional) that you read my blog posts
about my own experience porting coreboot to a new motherboard :
https://puri.sm/posts/diving-back-into-coreboot-development/
https://puri.sm/posts/librem-13-coreboot-report-january-12-2017/
https://puri.sm/posts/librem-13-coreboot-report-february-3rd-2017/
https://puri.sm/posts/librem-13-coreboot-report-february-25th-2017/
https://puri.sm/posts/coreboot-on-the-librem-13-v2-part-1/
https://puri.sm/posts/coreboot-on-the-skylake-librems-part-2/

To answer your specific questions : It depends on your machine, is it
AMD or is it Intel? Is it Ivybridge or Broadwell or Skylake or
Apollolake, etc.. ? Does it have soldered RAM or does it use SODIMMs?
Depending on the CPU architecture, the CPU 'brand' and even the model
of the CPU itself, the port will be done very differently. You'd first
want to find a mainboard that is as close as your current one, and
start modifying that, there isn't "one mainboard to use as base"
because the code, files, etc.. are almost unique depending on the
CPU/northbridge/southbridge model, so use the closest one as your
base.
As far as I know, the file board_info.txt is just information about
the board, it's not getting used by coreboot, it's more of an
indication for developers.
As for the other files, it will depend once again on your board. I'd
say Kconfig and devicetree.cb are mandatory, the rest may or may not
be mandatory depending on your hardware. The cmos.layout for example
isn't mandatory, but you'd probably need it if you enable CMOS support
in your KConfig, The 'spd' files containing the RAM's SPD EEPROM
information are mandatory only if your board has soldered RAM (common
in laptops but not in desktops), but they are not needed (and actually
can't be provided) if the motherboard has SODIMM slots instead. So it
all depends. Your best bet is to look at what's there and see if you
need it or not and if you do, understand what it's for and what needs
to be changed in order to match your board.
Don't forget that before you get your board to boot with coreboot, you
will probably have to flash it and brick your board 100 times, so make
sure you have a backup of your original ROM copied somewhere safe and
that you have the hardware to re-program the SPI flash externally (and
test that it works), before you attempt to flash it.
Also, make sure you are patient, and ready to learn!

Good luck!
Youness.


On Mon, May 28, 2018 at 10:31 PM, Zvi Vered  wrote:
> Hello,
>
> I have to port coreboot to a new "Mainboard" not listed in menuconfig.
> Is there a basic "Mainboard" I should use as a starting point that will be
> copied to my board ?
>
> The file board_info.txt contains few parameters.
> How can I know the meaning of each parameter and its possible values ?
>
> The board kontron/kt690 for example contains few files like: cmos.layout,
> devicetree.cb, etc
> Are all those files mandatory ?
> Is there a list of mandatory files or routines required in order to port a
> board ?
>
> Your help is highly appreciated.
> Best regards,
> Zvika
>
> --
> coreboot mailing list: coreboot@coreboot.org
> https://mail.coreboot.org/mailman/listinfo/coreboot

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

Re: [coreboot] FSP 2.0 headers in coreboot

[Youness Alaoui]

On Fri, May 18, 2018 at 2:59 PM, Nico Huber  wrote:
>
> I have to admit, I don't like your patch. While it gets the job done,
> it brings `MemInfoHob.h` and `FspsUpd.h` out of sync, so the state in
> coreboot as a whole would match neither version.
>
Good point. It is a Frankenstein, but it was either that or have
#ifdefs in the fsp vendorcode itself to determine if attribute X is
available or not, etc..

>> - or abandon my patch (which means I can never send a working
>> board-status for the librems without having a dirty tree or a version
>> commit hash that doesn't match upstream)
>> - or have the possibility to choose between the two (either via
>> #ifdefs or via a variants method).
>
> If we can't get a new, fitting binary out of Intel, I would prefer this,
> or, more bluntly, just copy the GitHub version and revert the changes
> that need the additional UPD.
>
> In other words, whatever happens, I think we should have the headers
> of the latest public release in the tree.
>

I agree, that's probably the cleanest solution, but I didn't suggest
it because I figured people would be yelling about removing
functionality that might need to be re-added eventually if Intel end
up doing an updated release.

>> - or, if Intel people are reading this right now (or someone here can
>> poke them directly), have the public release updated so this matter
>> can be dropped entirely (the public update would need to be released
>> *very* soon though).
>
> Even if you (Purism) poke them about it, that might help. But I would
> like to see that Google does that too (IMHO, they profit most from the
> mess). Any of you should have more leverage than the customer of a
> customer of a customer of a potential customer of Intel has, that I
> work for ;)
I know no-one at Intel to poke them about. I'll ask if Todd has
contacts that might be able to help. I'm hoping that some of the
people that are working for Intel are following this email thread but
if they are, they haven't raised their hands. Anyone knows or can
suggest the name of someone that we might poke ? I'm guessing those
working for Google who actually received the newer FSP from Intel
might know who to ask, and since they are the ones that would be
affected by their code/features being removed if we revert to github
version of header, it might help put some pressure on this issue (so
far, I haven't seen any incentive to make them do that).

>
>> Should we put this to a vote now, or should we discuss the
>> possibilities/alternatives some more, if anyone has ideas on how to
>> tackle this specific issue ?
>
> Well, my vote, in order of preference:
>
>  1. Poke Intel.
>  2. Get a verbatim copy of the GitHub headers in (in a way of [least] effort 
> for
> the community). Maybe in a month from now? no matter the outcome
> from 1.
>
> Nico

I agree, and I give my 100% vote for that as well. It will be much
better than an #ifdef mess and would be a good incentive for the
people from Intel not saying "no, too much hassle to update the file,
we got nothing to lose anyway if we just ignore this".
So let's see who can poke who from Intel, let's give a deadline (1 or
2 months? if bureaucracy means it will take longer, we might revisit
if we at least got a confirmation that the issue is being looked at on
Intel's side), then once deadline is reached, we revert to public
headers and remove functionality that prevents building (access to
nonexistent fields in UPD) and in the future, reject patches on gerrit
for non public blobs.

Thanks!

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

Re: [coreboot] Exception on Skylake after enabling ACPI timer emulation

[Youness Alaoui]

Hi Piotr,

Great, I'm glad the ucode was indeed the issue, and that I was lucky
enough to spot it.
I think it doesn't get added correctly because the path might be wrong
? unless you put the ucode bin file in the root directory of coreboot,
then it might not find it, or maybe it's another option to actually
tell it to add the file to cbfs.
See our ucode related configs in :
https://code.puri.sm/kakaroto/coreboot-files/src/master/configs/config.librem13v2

CONFIG_SUPPORT_CPU_UCODE_IN_CBFS=y
CONFIG_CPU_MICROCODE_CBFS_GENERATE=y
CONFIG_CPU_UCODE_BINARIES="3rdparty/blobs/mainboard/$(MAINBOARDDIR)/cpu_microcode_blob.bin"

Also note these two options which get passed to the FSP so the
microcode can get applied :
CONFIG_CPU_MICROCODE_CBFS_LEN=0x18000
CONFIG_CPU_MICROCODE_CBFS_LOC=0xFFE115A0

That location address makes cbfstool add the ucode binary in cbfs at
the right offset so it's at that address, and the len has to match (or
be superior) to the ucode file size.

I hope that helps,
Youness.



On Sun, May 20, 2018 at 7:25 PM, Piotr Król <piotr.k...@3mdeb.com> wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
>
>
> On 05/18/2018 07:53 PM, Youness Alaoui wrote:
>> Hi Piotr,
>
> Hi Youness,
>
>> Here's my librem13v2 info as reported by coreboot : CPU: Intel(R)
>> Core(TM) i7-6500U CPU @ 2.50GHz CPU: ID 406e3, Skylake D0, ucode:
>> 00c1 CPU: AES supported, TXT NOT supported, VT supported MCH:
>> device id 1904 (rev 08) is Skylake-U PCH: device id 9d48 (rev 21)
>> is Skylake-U Premium IGD: device id 1916 (rev 07) is Skylake ULT
>> GT2
>>
>> So I can see that we have the exact same CPU, MCH, PCH and IGD,
>> but there is one difference that I noticed, your line said : CPU:
>> ID 406e3, Skylake D0, ucode: 
>
> Good catch. I'm not sure why I can't include microcode that I obtained
> using get_blobs.sh. I marked:
>
> CONFIG_CPU_UCODE_BINARIES="cpu_microcode_blob.bin"
>
> But my results is:
>
> Name   Offset Type   Size   Comp
> cbfs master header 0x0cbfs header32 none
> fallback/romstage  0x80   stage   47588 none
> fallback/ramstage  0xbb00 stage   84189 none
> vgaroms/seavgabios.bin 0x20440raw 28672 none
> config 0x274c0raw   457 none
> revision   0x27700raw   580 none
> payload_revision   0x27980raw   239 none
> (empty)0x27ac0null 1240 none
> fspm.bin   0x27fc0fsp389120 none
> payload_config 0x87000raw  1682 none
> (empty)0x87700null 2200 none
> fsps.bin   0x87fc0fsp188416 none
> fallback/postcar   0xb6000stage   31352 none
> fallback/dsdt.aml  0xbdac0raw 12879 none
> fallback/payload   0xc0d80simple elf  73920 none
> (empty)0xd2e80null  2877080 none
> cpu_microcode_blob.bin 0x391540   microcode   0 none
> (empty)0x3915c0   null  1976792 none
> bootblock  0x573fc0   bootblock   49152 none
>
> So something wrong with size. I added microcode manually and things
> look better right now. Thank you.
>
> What is correct way to include binary microcode? In PC Engines we had
> to create our own method [1]. I wonder what would be correct way for tha
> t.
>
> [1] https://github.com/pcengines/coreboot/pull/132/files
>
> Best Regards,
> - --
> Piotr Król
> Embedded Systems Consultant
> https://3mdeb.com | @3mdeb_com
> -BEGIN PGP SIGNATURE-
>
> iQIzBAEBCAAdFiEE4DCbLYWmfoRjKeNLsu5x6WeqnkwFAlsCA90ACgkQsu5x6Weq
> nkwJGQ//e5ujrAgQUyV97vEG92kz/nCv8qYKRAUUvjkeq2htz6RMy/FK74HxbOPM
> ITZvVc14ecWscpNyKCwWeWSAkf9UIxYR4MdN5D7CVsxP1/V3+H0uKi9JbrjPa4qe
> RVbPTpZC0vvadQ797KbVbj/i/i9B1j06LugAMF+utU0bB8oTb0bl2fliD62G7jbp
> JJTgX0cXyVQdfKV8593Wiy2lsrIi7nev701Yynpx4Qap+DBMLfQqFB6QEcCVopH0
> gNIMnLgkK8PKlwfgj4+puAWnObpKkzaXZY1avoxCVzFllYF9Z9UoiNB8ZFjFEJ6P
> GkfNe/gxw8Rnh09eZH2z4peE2Ja0MFiBqyfbyiKMj7f1VYK+qEDhBZoV7NM2agZR
> iExXCINvLvBu8WTkaJ83dKjQwZ+NHqpfngqwdwW9kthMyHLyt0amSyYaJbsHJhAQ
> CDHaXCNFjvFA7BFSKiBuG4FLc+XMHEFSxP3EGfcWq3aPZ2LmjS/GrwRRHYjDvbBR
> JxNkppaWXrPRJ7XOmy94g9gL4hmcWD3QX40lqRGyQt0ZWDpG0FgjsoX6GBxhGSCL
> LH3SGTwYoXKGqUp39YaPPACq0nJtxkTtCMK+ZH0D9Q173lngGewc5BtASgQIGWl6
> UW6G8A/EmDmpCFA3xe3Rlj+PWm46w3cBWEizx4pPSYoycMYlSBk=
> =mfsi
> -END PGP SIGNATURE-
>
> --
> coreboot mailing list: coreboot@coreboot.org
> https://mail.coreboot.org/mailman/listinfo/coreboot

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

Re: [coreboot] Exception on Skylake after enabling ACPI timer emulation

[Youness Alaoui]

Hi Piotr,

The Librems use the FSP 2.0 for SKL because I was told (I can't
remember by who, but I think it was on coreboot IRC channel) that the
FSP 2.0 works for both Skylake and Kabylake and that FSP 2.0 was
better supported within coreboot than FSP 1.1. We had the Librems use
FSP 1.1 before, but when we upgraded from coreboot 4.6 to coreboot
4.7, we also upgraded to using FSP 2.0 (as you can see in our
changelog : 
https://code.puri.sm/kakaroto/coreboot-files/src/master/Changelog.txt)
It wasn't particularly straightforward because of two issues :
1 - the FSP 2.0 headers in coreboot do not match the FSP 2.0 header
from the public github binaries. You can see our patch to fix it here
: https://review.coreboot.org/26108 (once coreboot.org maintenance is
done).
2 - the FSP 2.0 doesn't set the AC and DC Lodline values, so you need
to set those manually in devicetree.cb otherwise the CPU will have a
tendency to overheat under load within a few milliseconds then
shutdown (see patch here : https://review.coreboot.org/25324 )

Other than that, the FSP 2.0 has been working great for our SKL
platform. I don't remember specifics, but I believe it was a lot less
trouble and fixed issues from when we were using the FSP 1.1.

I also can't find any information on MSR 0x121 anywhere, but I can
confirm that it has the expected value that coreboot sets :
root@librem13:~# rdmsr 0x121
2fba2e2501311808

From the crash though, I doubt your problem is the FSP, because it's a
crash on doing the 'wrmsr' instruction, probably because your CPU
doesn't recognize that MSR as being valid or something like that.

Here's my librem13v2 info as reported by coreboot :
CPU: Intel(R) Core(TM) i7-6500U CPU @ 2.50GHz
CPU: ID 406e3, Skylake D0, ucode: 00c1
CPU: AES supported, TXT NOT supported, VT supported
MCH: device id 1904 (rev 08) is Skylake-U
PCH: device id 9d48 (rev 21) is Skylake-U Premium
IGD: device id 1916 (rev 07) is Skylake ULT GT2

So I can see that we have the exact same CPU, MCH, PCH and IGD, but
there is one difference that I noticed, your line said :
CPU: ID 406e3, Skylake D0, ucode: 

It looks like you haven't set a microcode for the CPU, and I think
that might be your actual problem. I remember being unable to boot the
machine without a microcode update, but I think it was because the FSP
itself would crash/refuse to boot if one wasn't set, so the very first
thing I did was to add the microcode update to coreboot and consider
it "on skylake and above, you can't boot without a valid microcode
update". In your case, that looks like that might be your problem. It
might be that the 0x121 MSR didn't exist or wasn't valid in the
default CPU ucode, and is only valid (or can only be set) after the
ucode update is applied, so I suggest you first try that, and see if
it solves any of your issues.

Good luck!
Youness.

On Fri, May 18, 2018 at 1:31 PM, Nico Huber  wrote:
> Hello Piotr,
>
> On 17.05.2018 18:20, Banik, Subrata wrote:
 FSP2.0, I'm following Librem Purism options since they seem to boot the
 same SoC. They use KabyLake FSP obtained by get_blobss.sh [1], if you
 think this is incorrect then I would like to know why, because it may
 mean that Pursim code is also incorrect from Intel point of view.
>>
>> SKL won't be compatible with KBL FSP. Please don’t try to use KBL FSP
>> and mix match with SKL Coreboot. No one tested that combination.
>
> Unless FSP is calling home, we can't say anything about the actual test
> coverage. KBL FSP somehow works on SKL. I assume the code is written for
> both platforms, the binaries are usually just not validated for all SKUs
> supported by the code (and it's often not documented for which they were
> validated).
>
> I wouldn't be surprised if the KBL FSP was more tested on SKL by now;
> not by Intel but by their customers and individuals. There's one simple
> reason: The older SKL FSP lacks most of the configuration options and
> is not well maintained within coreboot. So the KBL FSP works better (but
> you don't get any guarantee for that). OTOH, the KBL FSP release on
> GitHub is also not well integrated (although it was released half a year
> later, it's way behind regarding the header files in coreboot). The only
> Kabylake FSP binary 100% compatible with coreboot is the Google Support
> Package (not published separately, but you can carve it out of their
> firmware images).
>
> To wrap it up, if you want a public FSP binary that was validated for
> SKL, you'll have to use the old FSP1.1 version; or push Intel to publish
> something new. I would talk to your Intel support contact in any case,
> sometimes binaries pop up that nobody knew about.
>
> Nico
>
> PS. I can confirm that the KabylakeFsp0001 drop from last summer works
> with a 25W SKL-S CPU. Judging from the commit date, I also run it
> with that MSR write applied.
>
> --
> coreboot mailing list: coreboot@coreboot.org
> https://mail.coreboot.org/mailman/listinfo/coreboot

-- 

Re: [coreboot] FSP 2.0 headers in coreboot

[Youness Alaoui]

I feel like this discussion is getting slightly out of hand, so let's
try to regroup a bit and move the discussion back to the original
topic : how to handle the FSP headers in coreboot.
I fully understand and agree with Nico's frustration about the blobs
situation and I think that's a bigger conversation than needed right
now. I do encourage discussing it and finding a good solution to avoid
having a similar mess in the future (or now, but in a different thread
to avoid going off-topic). I think Nico's idea of setting up rules for
how/what to merge in the future is a good idea and needs to be further
discussed until everyone is happy with the rules defined.

I would personally say "if the FSP headers in coreboot are for FSP
2.5.0 which is newer, then why isn't that 2.5.0 file made public?". If
we were to have a rule, then maybe forcing blobs to be available
publicly before having coreboot use/integrate them is a good step, so
if you plan on pushing a commit that adds FSP 3.0 to coreboot, then
that commit won't be merged until the associated blob becomes publicly
available (even if it's on intel's github and is non redistributable),
because merging commits that adds headers/support for some blob that
nobody has access to makes no sense if we think of coreboot as a
project that any enthusiast can clone and build for any machine if
they want to.

Now, back to the discussion about the "incompatible FSP headers", here
are the possibilities :
- should we merge my patch that makes the FSP header compatible with
the public blob, and let the CrOs coreboot clone have its own commit
that reverts it,
- or abandon my patch (which means I can never send a working
board-status for the librems without having a dirty tree or a version
commit hash that doesn't match upstream)
- or have the possibility to choose between the two (either via
#ifdefs or via a variants method).
- or, if Intel people are reading this right now (or someone here can
poke them directly), have the public release updated so this matter
can be dropped entirely (the public update would need to be released
*very* soon though).

Should we put this to a vote now, or should we discuss the
possibilities/alternatives some more, if anyone has ideas on how to
tackle this specific issue ?

Thanks,
Youness.



On Thu, May 10, 2018 at 9:34 PM, Nico Huber  wrote:
> On 11.05.2018 01:39, Timothy Pearson wrote:
>> Not to jump too far into the fray, but couldn't this be handled by
>> simply not blocking coreboot development on proprietary blobs?  For
>> instance, if someone wants to implement a feature that requires
>> repository-wide changes (e.g. the timestamp stuff that went in a couple
>> of years back) that happens to break only some blobby boards, that the
>> feature should be implemented anyway and the broken blobby boards added
>> back in as the vendor has time / inclination to fix?
>
> If we maintain the code for end users and not for vendors, vendors won't
> do anything. And the end users can't, I would call them developers
> otherwise.
>
>>
>> Basically, this seems to be what Linux already does for kernel work.
>> The benefit of upstreaming open code is that other people will maintain
>> it for you, but if you really need to publish a binary only driver
>> (NVIDIA) then you have the full burden of maintenance on yourself as the
>> vendor.  This encourages contribution back without putting an arbitrary
>> administrative limit on what kind of blob level is acceptable.
>
> The difference here is that Linux made it. It's not only accepted by
> vendors but actively employed. I fear for coreboot, currently, it's
> mostly the silicon vendor's customers that want (or maybe even only
> accept) it. Plus coreboot is firmware, nobody is used to maintain firm-
> ware.
>
> IMHO, we should make coreboot most easy to port to the widest range of
> boards possible. To extend the community. If that's only feasible
> through blobs (atm?), I can take it. But if a blob only helps that
> one company who built it, I don't see much value in it.
>
> Nico
>
> --
> coreboot mailing list: coreboot@coreboot.org
> https://mail.coreboot.org/mailman/listinfo/coreboot

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

Re: [coreboot] FSP 2.0 headers in coreboot

[Youness Alaoui]

Sorry for being late to answer to my own thread (busy busy busy).

A few notes :
The initial check-in of the kabylake FSP was uploaded with a BSD
license : 
https://github.com/IntelFsp/FSP/tree/d88078a708e768c7b6ee5cbc996299d303c3c702/KabylakeFspBinPkg
Later commits added Intel's Restricted Use License Agreement (which
basically prevents redistribution (and reverse engineering)).
That's also why the header commit I submitted didn't update the
headers to match the Gold release, but only what was in the initial
'BSD' release, which thankfully is compatible with the Gold release
(besides, most of the changes, other than the license header, were to
add typos and remove fields, since the header in coreboot is
technically 'newer').

Regarding Nico's idea of signing blobs, for old unmaintained blobs,
they could still be signed with a coreboot specific "this is a known
working, not guaranteed to be malware free but guaranteed to be
unmodified for years, or unmodified since its official release" key,
and a coreboot maintainer would have the private key to sign old blobs
with that key. That would at least resolve the condition of "all blobs
must be signed".

I do agree with Julius that headers should remain in coreboot, and not
move to the blobs.git, and I agree that removing old boards doesn't
make sense. Yes, I think coreboot is meant for enthusiasts and
tinkerers who want to build an image for their boards, and that's why
I'm suggesting to make the headers match the github version, because
it's now impossible to build anything with FSP (whether a google
board, or a Purism board for example) without first modifying coreboot
because the only FSP available to enthusiasts and tinkerers is the
github one.

In general, I like Nico's idea of setting up rules for blobs, but my
worry is that no matter how great and logical the rules are, the
blob-makers might simply ignore them.. you can ask for signed blobs,
but what if they refuse to sign it? Or even better, you can ask for
redistributable blobs, but what if they refuse to make them
redistributable? Will you simply stop supporting any boards that
depend on those blobs? You'd have to eventually compromise (for the
sake of the users/project) and break your own rules that you worked so
hard to perfect... Since they control the blobs, they have the power,
unless you think "integrate in coreboot" is a hard requirement for
them, and in that case, if you set up those rules, they would be
forced to follow them, that can actually help get things done the
right way instead of just asking nicely and never getting a positive
response. I don't really know... it might work for Intel/CrOS for
example, but maybe not for other vendors who wouldn't need to be
integrated in coreboot...

Anyway, to resolve the immediate issue with the header, how about
adding a 'variants' system, like we already have with mainboards?
Something like :
src/vendorcode/intel/fsp/fsp2_0/variants/google/*.h
src/vendorcode/intel/fsp/fsp2_0/variants/github/*.h
and in the Kconfig, we could just set FSP_VARIANT_DIR="github"
That would be (I assume) much less messy than having #ifdefs to
define-or-not specific fields in the UPD structures.
The only issue would be with regards to fields that coreboot uses that
aren't available in a variant, like for example, the
PcieRpClkSrcNumber field that doesn't exist in the github header but
is used in coreboot, there are a couple of solutions to that :
1 - add #define HAVE_PCIE_RP_CLK_SRC_NUMBER (for example) in the
headers and have #ifdefs everywhere in coreboot code. This is not a
great idea
2 - have something like "#define PcieRpClkSrcNumber UnusedUpdSpace26",
but that would add so much problems that it's a very stupid idea...
why am I ever writing this?
3 - manually add the missing fields somewhere in the Upd and only have
the changes between two variants where the field offsets change in the
structure.
4 - anyone else with better ideas?

Using solution 3 above, The 'google' variant would be the current
header, and the 'github' variant would be the header after my patch
[1] applied to it (so it's a mix between the google and the real
github header, but with field offsets matching what the github blob
would return), all the fields are still there, I think there are 3
fields that coreboot uses which aren't in the official header, and
they just end up in unused space, but at least the MemInfoHob will be
correct.

What do you think ?
Youness.


On Wed, May 9, 2018 at 3:49 AM, Nico Huber  wrote:
> On 09.05.2018 01:04, Nico Huber wrote:
>>  Unless a pointer as described above exists for a given plat-
>>  form that relies on a blob, all changes* to that platform
>>  *shall* be refused.
>>>
>>> I think this is counter-productive, as is removing any old boards that
>>> don't comply. I am okay with creating new rules for future platforms, but
>>> there is no reason to throw perfectly good and working boards out just
>>> because they weren't 

[coreboot] FSP 2.0 headers in coreboot

[Youness Alaoui]

Hi,

I've just pushed a commit for review on gerrit
(https://review.coreboot.org/#/c/coreboot/+/26108/) and I'm hoping to
open the discussion here on whether the public coreboot code should
have the FSP headers that match the public FSP headers or if they
should match the 'google fsp' headers.

My understanding of the situation is that chromebooks ship with a
google-modified FSP image and the fsp headers in coreboot have been
added by google employees even before the FSP was officially made
public by Intel. I also somewhat understood that the fsp headers in
coreboot would not be updated to match the public release because it
would break everyone building coreboot for their chromebooks or
something like that.

I'm a bit tired of always having that commit that fixes the header
applied locally in all my branches, and I think that it makes much
more sense for coreboot to have the fsp headers that match the public
release and for the google/chromebook coreboot repository to have the
"non-standard header" committed to it instead.
Worst case scenario, we could add #ifdefs to determine what the
structure contents should be depending on the target platform.

Maybe everyone will say "of course, that makes sense" or maybe
everyone will say "nope, I disagree", but hopefully we can have the
discussion here (or on gerrit) and decide how to handle this use case.
Note: I only pushed for skylake/kabylake, but apollolake/canonlake are
probably also affected by this mismatch of headers.

Thanks,
Youness.

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

Re: [coreboot] ENE KB3940Q-A1 embedded controller custom firmware

[Youness Alaoui]

An update on the use of Index I/O to access the SPI flash from
software. I figured out the problem with coreboot. We weren't setting
the LPC I/O decode range 0x380-0x383 in the LPC PCI config (gen1_dec
config in devicetree) which would allow us to talk to the EC using
Index I/O on port 0x380. Once I set that, I was able to access Index
I/O on my coreboot-ed machine, and that opens up the software-based
flashing support.


On Mon, Mar 5, 2018 at 5:34 PM, Youness Alaoui
<kakar...@kakaroto.homelinux.net> wrote:
> Thanks for the advice Mike, but I think you misunderstood the issue. I
> wasn't talking about the internal memory of the EC, but rather about
> accessing the EC firmware in SPI flash via an external SPI flasher.
> The problem is that the SPI flash power rail is the same as the EC
> chip, so as soon as we power the SPI flash to read it, it will also
> power the EC chip, which will drive the SPI I/O pins high/low to read
> its firmware, and since the EC executes the firmware from the flash,
> that means that the SPI flash will constantly be accessed by the EC
> and the external flasher can't take control of the I/O.
> However, it looks like if the EC firmware crashes, it will stop using
> the flash and will therefore 'release' the I/O pins for the external
> flasher to use them.
> If I short MISO with VCC, then the EC will read its firmware as being
> all 0xFF (which is the same as when I corrupted the flash by erasing
> its first sector), and that will cause it to crash and release the SPI
> flash, then we can read it. No need to solder or enable debug mode or
> anything like that.
>
> Anyways, my true purpose is to use software flashing only, I already
> have read/write/sector_erase support written but it requires the use
> of the Index I/O (LPC port 0x380) which I can only access when I flash
> the machine with the AMI BIOS, but which becomes inaccessible if I
> only have coreboot. I think it's because AMI will send EC
> vendor-specific commands via LPC port 62h/66h to configure it and
> enable the Index I/O access. I've suggested to Paul if we could a
> reduced firmware that would only log to UART all the accesses to the
> EC via the LPC port 62/66 (kind of like doing SerialICE for the EC) so
> we could document the vendor specific commands AMI uses to enable
> Index I/O. Once we know that, we should be able to read/write to the
> EC flash using software only.
>
>
> On Mon, Mar 5, 2018 at 4:04 PM, Mike Banon <mikeb...@gmail.com> wrote:
>>> otherwise, the EC prevents us from accessing it
>> Maybe KB3940Q has the same protection as KB9012 : unless the EC's
>> ground pin has been shortened with motherboard's ground _before_ you
>> have powered a motherboard, you would not have any access; otherwise,
>> EC will go into debug mode and you'll have the full access to its'
>> internal memory. To avoid the soldering, you could look through the
>> instructions described here -
>> http://dangerousprototypes.com/docs/Flashing_KB9012_with_Bus_Pirate ;
>> in short : use a keyboard flex cable to reach EC spi pins as well as
>> its' ground, and a test hook clip to easily get a ground of your
>> motherboard
>>
>> On Mon, Mar 5, 2018 at 11:00 PM, Youness Alaoui
>> <kakar...@kakaroto.homelinux.net> wrote:
>>> On Sun, Mar 4, 2018 at 4:50 AM, Paul Kocialkowski <cont...@paulk.fr> wrote:
>>>> Hi,
>>>>
>>>> Le vendredi 16 février 2018 à 14:09 -0500, Youness Alaoui a écrit :
>>>>> > > Sure, you can trust hardware flashing more than software flashing,
>>>>> > > but
>>>>> > > I really need software flashing. If it was just for me, yeah, I
>>>>> > > could
>>>>> > > fiddle with it to flash it by hardware for my personal needs, but
>>>>> > > when
>>>>> > > it's about deploying it to all our customer base, that's another
>>>>> > > story, the only solution is software flashing. Obviously, it would
>>>>> > > have to work in coreboot, so whatever coreboot is doing wrong (or
>>>>> > > AMI
>>>>> > > is doing right.. my guess is that it's probably something with the
>>>>> > > EC
>>>>> > > ACPI code), we'd have to figure that out first in order to get the
>>>>> > > read/write support.
>>>>> >
>>>>> > Either way, since the EC firmware resides in the SPI flash, it'll be
>>>>> > no
>>>>> > issue to reflash it both by software and hardware.
>>>>>
>>>>> On the librems, the EC firmware res

Re: [coreboot] ENE KB3940Q-A1 embedded controller custom firmware

[Youness Alaoui]

Thanks for the advice Mike, but I think you misunderstood the issue. I
wasn't talking about the internal memory of the EC, but rather about
accessing the EC firmware in SPI flash via an external SPI flasher.
The problem is that the SPI flash power rail is the same as the EC
chip, so as soon as we power the SPI flash to read it, it will also
power the EC chip, which will drive the SPI I/O pins high/low to read
its firmware, and since the EC executes the firmware from the flash,
that means that the SPI flash will constantly be accessed by the EC
and the external flasher can't take control of the I/O.
However, it looks like if the EC firmware crashes, it will stop using
the flash and will therefore 'release' the I/O pins for the external
flasher to use them.
If I short MISO with VCC, then the EC will read its firmware as being
all 0xFF (which is the same as when I corrupted the flash by erasing
its first sector), and that will cause it to crash and release the SPI
flash, then we can read it. No need to solder or enable debug mode or
anything like that.

Anyways, my true purpose is to use software flashing only, I already
have read/write/sector_erase support written but it requires the use
of the Index I/O (LPC port 0x380) which I can only access when I flash
the machine with the AMI BIOS, but which becomes inaccessible if I
only have coreboot. I think it's because AMI will send EC
vendor-specific commands via LPC port 62h/66h to configure it and
enable the Index I/O access. I've suggested to Paul if we could a
reduced firmware that would only log to UART all the accesses to the
EC via the LPC port 62/66 (kind of like doing SerialICE for the EC) so
we could document the vendor specific commands AMI uses to enable
Index I/O. Once we know that, we should be able to read/write to the
EC flash using software only.


On Mon, Mar 5, 2018 at 4:04 PM, Mike Banon <mikeb...@gmail.com> wrote:
>> otherwise, the EC prevents us from accessing it
> Maybe KB3940Q has the same protection as KB9012 : unless the EC's
> ground pin has been shortened with motherboard's ground _before_ you
> have powered a motherboard, you would not have any access; otherwise,
> EC will go into debug mode and you'll have the full access to its'
> internal memory. To avoid the soldering, you could look through the
> instructions described here -
> http://dangerousprototypes.com/docs/Flashing_KB9012_with_Bus_Pirate ;
> in short : use a keyboard flex cable to reach EC spi pins as well as
> its' ground, and a test hook clip to easily get a ground of your
> motherboard
>
> On Mon, Mar 5, 2018 at 11:00 PM, Youness Alaoui
> <kakar...@kakaroto.homelinux.net> wrote:
>> On Sun, Mar 4, 2018 at 4:50 AM, Paul Kocialkowski <cont...@paulk.fr> wrote:
>>> Hi,
>>>
>>> Le vendredi 16 février 2018 à 14:09 -0500, Youness Alaoui a écrit :
>>>> > > Sure, you can trust hardware flashing more than software flashing,
>>>> > > but
>>>> > > I really need software flashing. If it was just for me, yeah, I
>>>> > > could
>>>> > > fiddle with it to flash it by hardware for my personal needs, but
>>>> > > when
>>>> > > it's about deploying it to all our customer base, that's another
>>>> > > story, the only solution is software flashing. Obviously, it would
>>>> > > have to work in coreboot, so whatever coreboot is doing wrong (or
>>>> > > AMI
>>>> > > is doing right.. my guess is that it's probably something with the
>>>> > > EC
>>>> > > ACPI code), we'd have to figure that out first in order to get the
>>>> > > read/write support.
>>>> >
>>>> > Either way, since the EC firmware resides in the SPI flash, it'll be
>>>> > no
>>>> > issue to reflash it both by software and hardware.
>>>>
>>>> On the librems, the EC firmware resides in a separate 64KB SPI flash,
>>>> it's not shared with the bios, and I haven't found a way to access it.
>>>
>>> Is it really only 64 KiB? The chip definitely supports more and it seems
>>> a bit small to fit the whole firmware.
>>>
>>
>> Yes, it's a MX25L512. I can send you the firmwares that were on it if
>> you're curious (each machine revision had a different firmware, even
>> though it's the same ene chip in all of them, I don't know enough
>> about the EC to know if that's normal).
>>
>> The cool thing is that I was able to flash the chip externally, but
>> only when I corrupted the EC firmware (I erased the first page and the
>> laptop crashed before I finished re-programming it by software). I
>> reproduced it twice again, if the EC firmware has crashed, it stops
>> accessing the SPI flash and we can program it with an external
>> flasher, otherwise, the EC prevents us from accessing it. So I think
>> it might be possible to simply short the MOSI/MISO to VCC to cause the
>> firmware to be unreadable, so the EC doesn't boot, then we should be
>> able to read/write from the EC with a pomona clip.

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

Re: [coreboot] ENE KB3940Q-A1 embedded controller custom firmware

[Youness Alaoui]

On Sun, Mar 4, 2018 at 4:50 AM, Paul Kocialkowski <cont...@paulk.fr> wrote:
> Hi,
>
> Le vendredi 16 février 2018 à 14:09 -0500, Youness Alaoui a écrit :
>> > > Sure, you can trust hardware flashing more than software flashing,
>> > > but
>> > > I really need software flashing. If it was just for me, yeah, I
>> > > could
>> > > fiddle with it to flash it by hardware for my personal needs, but
>> > > when
>> > > it's about deploying it to all our customer base, that's another
>> > > story, the only solution is software flashing. Obviously, it would
>> > > have to work in coreboot, so whatever coreboot is doing wrong (or
>> > > AMI
>> > > is doing right.. my guess is that it's probably something with the
>> > > EC
>> > > ACPI code), we'd have to figure that out first in order to get the
>> > > read/write support.
>> >
>> > Either way, since the EC firmware resides in the SPI flash, it'll be
>> > no
>> > issue to reflash it both by software and hardware.
>>
>> On the librems, the EC firmware resides in a separate 64KB SPI flash,
>> it's not shared with the bios, and I haven't found a way to access it.
>
> Is it really only 64 KiB? The chip definitely supports more and it seems
> a bit small to fit the whole firmware.
>

Yes, it's a MX25L512. I can send you the firmwares that were on it if
you're curious (each machine revision had a different firmware, even
though it's the same ene chip in all of them, I don't know enough
about the EC to know if that's normal).

The cool thing is that I was able to flash the chip externally, but
only when I corrupted the EC firmware (I erased the first page and the
laptop crashed before I finished re-programming it by software). I
reproduced it twice again, if the EC firmware has crashed, it stops
accessing the SPI flash and we can program it with an external
flasher, otherwise, the EC prevents us from accessing it. So I think
it might be possible to simply short the MOSI/MISO to VCC to cause the
firmware to be unreadable, so the EC doesn't boot, then we should be
able to read/write from the EC with a pomona clip.

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

Re: [coreboot] ENE KB3940Q-A1 embedded controller custom firmware

[Youness Alaoui]

>> Sure, you can trust hardware flashing more than software flashing,
>> but
>> I really need software flashing. If it was just for me, yeah, I could
>> fiddle with it to flash it by hardware for my personal needs, but
>> when
>> it's about deploying it to all our customer base, that's another
>> story, the only solution is software flashing. Obviously, it would
>> have to work in coreboot, so whatever coreboot is doing wrong (or AMI
>> is doing right.. my guess is that it's probably something with the EC
>> ACPI code), we'd have to figure that out first in order to get the
>> read/write support.
>
> Either way, since the EC firmware resides in the SPI flash, it'll be no
> issue to reflash it both by software and hardware.

On the librems, the EC firmware resides in a separate 64KB SPI flash,
it's not shared with the bios, and I haven't found a way to access it.
The 'ectool' is able to read it (ram idx reads if i remember
correctly) but it only worked with AMI BIOS. So there will definitely
be some work to be done there. You probably know a lot more about this
already, like what this 'ram idx' is, and why it didn't work in
coreboot, or if it's possible to read/write the flash using this EDI
interface, etc...

>
>> > Latest status update for Origami-EC firmware:
>> > https://www.mail-archive.com/coreboot@coreboot.org/msg50646.html
>>
>> Thanks! Good to see the status update on that.
>
> In order to kickstart the development of the Origami-EC firmware, I am
> designing evaluation boards for both the KB9012 and the KB3930 that
> will expose most of the I/O ports with headers, LEDs, buttons,
> connectors, etc. The design is done with KiCAD and will be released
> under the GPLv3+ as part of the Origami-EC project. I am also preparing
> a debug board to reflash the EC on the G505s from the keyboard
> connector.
>
> There is also ongoing work on the emulator and the SerialICE-like
> library for relatying and tracing I/O on the device via UART. Also,
> note that the emulator can now emulate a virtual console so it's
> already possible to build and interract with the firmware!
>
That's some really great news. A dev board will definitely be useful
for testing/debugging/developing Origami-EC!

> Cheers,
>
> Paul
>
>> > On Mon, Feb 5, 2018 at 9:47 PM, Youness Alaoui
>> > <kakar...@kakaroto.homelinux.net> wrote:
>> > > Hi Marty,
>> > >
>> > > Unfortunately, the EC firmware on the Librems is not open and we
>> > > have
>> > > someone working on that aspect, but with everything we have to
>> > > handle,
>> > > I think it's only being done part time.
>> > > We found something similar to you with the private submodule for
>> > > the
>> > > PS/2 module on the OLPC code.
>> > > More specifically :
>> > > http://lists.laptop.org/pipermail/openec/2011-January/000158.html
>> > > And http://dev.laptop.org/git/users/rsmith/ec-1.75/tree/?h=3930-A
>> > > 1
>> > >
>> > > I had opened a ticket a while ago here :
>> > > https://tracker.pureos.net/T178 which mentions Origami-EC. I
>> > > don't
>> > > know the status of that project, maybe you can contact the
>> > > developer
>> > > (Paul Kocialkowski) and see where he's at with his development of
>> > > that
>> > > project (which, I need to mention, hasn't been publicly launched
>> > > yet,
>> > > as far as I know) and he might benefit from your help if you are
>> > > interested in doing that.
>> > > The last time we spoke he said :
>> > > "The OLPC code is nowhere close to usable on any other platform.
>> > > Additionally, it is so poorly written that I don't think it is a
>> > > suitable codebase for any future development. On the other hand,
>> > > my
>> > > Origami-EC project (that I will publicly launch soon) should
>> > > provide a
>> > > flexible codebase to add support for new devices."
>> > >
>> > > Note that the tracker ticket above is quite outdated, we know how
>> > > to
>> > > dump the EC (the problem was that it can't be done via hardware
>> > > because the EC is on the same power rail as the 64KB flash chip,
>> > > so
>> > > when we power the flash via hardware, the EC boots and takes
>> > > control
>> > > of the SPI lines) but for some reason, we could only dump it via
>> > > software (using ectool) through the AMI BIOS firmware, with
>> > > cor

Re: [coreboot] ENE KB3940Q-A1 embedded controller custom firmware

[Youness Alaoui]

On Tue, Feb 6, 2018 at 4:41 AM, Mike Banon <mikeb...@gmail.com> wrote:
> Thank you very much for telling about EC-1.75 project!
> http://dev.laptop.org/git/users/rsmith/ec-1.75/tree/?h=3930-A1
> Maybe some of its' elements could be borrowed for Origami
> if the hardware is similar? (haven't compared the datasheets)
>

There will probably be some things in common. I don't know how much of
ec-1.75 is good enough to be reused though, or if it's maintainable,
etc.. but yes, it could be a good starting point.

> @ Youness and Marty :
>
> Proprietary firmware of KB9012 explicitly disables EDI - ENE Debug Interface
> (the protocol used to access the internal memory of KB9012) unless pin
> 42 is grounded
> _before_ powering the KB9012 controller ! Maybe its the same with your
> another KB ?
> If you ground that pin (not necessarily 42, your KB's pin number could
> be different)
> to put your EC into debug mode, maybe then you could successfully
> read/write it ?
>
> Here is the full description of my successful KB9012 hardware flashing setup
> through the keyboard port using a flex cable with soldered wires: 0.5mm pitch
> makes it hard to solder directly to keyboard port, and also I like
> flex cable solution
> because its much faster to remove/insert a cable than to
> solder/desolder the wires
>
> http://dangerousprototypes.com/docs/Flashing_KB9012_with_Bus_Pirate
>
> ^^^ Had to unite three grounds ( programmer's, mainboard's and KB9012's 42 
> pin )
> to make it work
>
> Currently we are actively working on the inclusion of KB9012 flashing support
> to the official flashrom - but its already possible via the unofficial 
> patches.
> Changes 23258 - 23263 at the https://review.coreboot.org/#/q/project:flashrom
>
> I haven't compared the datasheets of KB9012 and your KB, so I don't know
> if they are using exactly the same debug interface or it is slightly different
> (please check if there are differences, maybe you'll have to write some code)
>
> I trust hardware flashing more than the software, especially your
> current AMI BIOS setup
> which isn't free software. Maybe the direct hardware flashing is also
> possible for you

Sure, you can trust hardware flashing more than software flashing, but
I really need software flashing. If it was just for me, yeah, I could
fiddle with it to flash it by hardware for my personal needs, but when
it's about deploying it to all our customer base, that's another
story, the only solution is software flashing. Obviously, it would
have to work in coreboot, so whatever coreboot is doing wrong (or AMI
is doing right.. my guess is that it's probably something with the EC
ACPI code), we'd have to figure that out first in order to get the
read/write support.

>
> Latest status update for Origami-EC firmware:
> https://www.mail-archive.com/coreboot@coreboot.org/msg50646.html

Thanks! Good to see the status update on that.

>
> Best regards,
> Mike Banon
>
> On Mon, Feb 5, 2018 at 9:47 PM, Youness Alaoui
> <kakar...@kakaroto.homelinux.net> wrote:
>> Hi Marty,
>>
>> Unfortunately, the EC firmware on the Librems is not open and we have
>> someone working on that aspect, but with everything we have to handle,
>> I think it's only being done part time.
>> We found something similar to you with the private submodule for the
>> PS/2 module on the OLPC code.
>> More specifically :
>> http://lists.laptop.org/pipermail/openec/2011-January/000158.html
>> And http://dev.laptop.org/git/users/rsmith/ec-1.75/tree/?h=3930-A1
>>
>> I had opened a ticket a while ago here :
>> https://tracker.pureos.net/T178 which mentions Origami-EC. I don't
>> know the status of that project, maybe you can contact the developer
>> (Paul Kocialkowski) and see where he's at with his development of that
>> project (which, I need to mention, hasn't been publicly launched yet,
>> as far as I know) and he might benefit from your help if you are
>> interested in doing that.
>> The last time we spoke he said :
>> "The OLPC code is nowhere close to usable on any other platform.
>> Additionally, it is so poorly written that I don't think it is a
>> suitable codebase for any future development. On the other hand, my
>> Origami-EC project (that I will publicly launch soon) should provide a
>> flexible codebase to add support for new devices."
>>
>> Note that the tracker ticket above is quite outdated, we know how to
>> dump the EC (the problem was that it can't be done via hardware
>> because the EC is on the same power rail as the 64KB flash chip, so
>> when we power the flash via hardware, the EC boots and takes control
>> of the SPI lines) but for some reason, we could only d

Re: [coreboot] ENE KB3940Q-A1 embedded controller custom firmware

[Youness Alaoui]

Hi Marty,

Unfortunately, the EC firmware on the Librems is not open and we have
someone working on that aspect, but with everything we have to handle,
I think it's only being done part time.
We found something similar to you with the private submodule for the
PS/2 module on the OLPC code.
More specifically :
http://lists.laptop.org/pipermail/openec/2011-January/000158.html
And http://dev.laptop.org/git/users/rsmith/ec-1.75/tree/?h=3930-A1

I had opened a ticket a while ago here :
https://tracker.pureos.net/T178 which mentions Origami-EC. I don't
know the status of that project, maybe you can contact the developer
(Paul Kocialkowski) and see where he's at with his development of that
project (which, I need to mention, hasn't been publicly launched yet,
as far as I know) and he might benefit from your help if you are
interested in doing that.
The last time we spoke he said :
"The OLPC code is nowhere close to usable on any other platform.
Additionally, it is so poorly written that I don't think it is a
suitable codebase for any future development. On the other hand, my
Origami-EC project (that I will publicly launch soon) should provide a
flexible codebase to add support for new devices."

Note that the tracker ticket above is quite outdated, we know how to
dump the EC (the problem was that it can't be done via hardware
because the EC is on the same power rail as the 64KB flash chip, so
when we power the flash via hardware, the EC boots and takes control
of the SPI lines) but for some reason, we could only dump it via
software (using ectool) through the AMI BIOS firmware, with coreboot,
we only get 0xFF returned, I don't believe we had time to investigate
the cause for that.

Sorry for not having any better news for you, but I hope this helps a
little you at least.

Good luck,
Youness.


On Fri, Feb 2, 2018 at 10:17 AM, Marty E. Plummer
 wrote:
> Greetings,
>
> Currently working on a port for the hp g7-2247us laptop, which features
> an ene kb3940q ec, which hopefully should be very similar to the kb3930
> ec, which has a datasheet available to the public in a few places.
>
> Said similar ec is used in some OLPC devices, as well as some purism
> devices, and I was hoping someone in the list would have some contacts
> with those guys so as to be able to use their ec firmware as a bit of a
> reference design, but the OLPC ec firmware repo has a 'private'
> submodule which I cannot access and I simply cannot find a repo for the
> purism ec firmware to reference.
>
> Any assistance you could provide on this matter would be greatly
> appreciated.
>
> Marty E. Plummer
>
> --
> coreboot mailing list: coreboot@coreboot.org
> https://mail.coreboot.org/mailman/listinfo/coreboot

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

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

[Youness Alaoui]

On Sat, Dec 23, 2017 at 11:32 PM, taii...@gmx.com  wrote:
> On 12/23/2017 07:16 PM, Todd Weaver wrote:
>
>> Intel did not mislead, we told them, and continue to, that we _want_ an
>> ME-less design (which is their term for what we asked for). And as we
>> grow our leverage will grow, and our influence will grow. This is a
>> long-term strategy and is playing out as planned.
>>
>> They will not adjust based on small quantities, but quantity =
>> leverage, and our influence changes as volumes grow. (e.g. $ =
>> influence)
>
> You will never have that type of leverage, if google can't pull it off then
> no one can.

Yeah, I agree with you on that, I don't think any leverage could make
Intel budge on that at this point.

>
> Even the NSA only got HAP, not a CPU without ME all together and the US
> government probably spends hundreds of millions with intel every year.
>
> x86-64 will always have ME/PSP and it simply can't be disabled, pretending
> otherwise is doing a disservice to many who look to the big shots for advice
> and pipe dreams like that being spread to the masses are the main reason I
> dislike purism so much.

You know of the ROM Bypass stuff, right? The first byte of the flash
contains a JMP instruction into the ROMB partition in the flash
(that's why the IFD magic number is at offset 0x10, not 0x0), so if
you put the right flag in the flash to enable ROM Bypass, then you
could get full unsigned/unchecked code (since the code in the ROM is
what checks signatures).
Now, that actually doesn't work because it's a feature that is
disabled on production chips, only pre-production chips allow the ROM
Bypass feature. What if someone finds a way to enable that feature on
a production chip ? What if you can make your CPU think it's in
preproduction mode thanks to some microcode update for example ? Then
you can get fully user controlled ME from the very first instruction.

I'm not saying it's possible or that it will be possible, but I'm
saying that it's not a "pipe dream" like you seem to think.
Even better, forget HAP, forget ROM Bypass, how about using the
exploit that PT announced at BlackHat to get your own unsigned code to
execute on the ME. You get full user control of the ME that way, and
while we know that the HAP bit happens at the end of the BUP module's
task, it's possible the exploit happens at the start (it does happen
when it tries to read a config file, so it could be early in the BUP).
The entire code from the first instruction all the way to the time the
exploit runs, could be reverse engineered, so even if you don't
control what happens there, you could at least have the source for it
and audit it to make sure it's not doing anything you wouldn't want it
to do, then have your exploit run and execute your own user controlled
ME firmware.
It's not an as perfect solution as being able to do a ROM Bypass and
control everything from the very first JMP, but it's something doable
today, it's not even a "maybe", so again, it's not a pipe dream.

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

I think people buying a TALOS 2 and people buying a Librem are two
very distinct types of people. I very much doubt that someone has ever
had to decide between buying a Librem and a TALOS. No one in need of a
computer and in need of a open hardware machine will decide to "wait a
few years" either.. when you need a new PC, you buy a new PC. If you
want a TALOS, then you buy a TALOS, if you don't want it, or you want
a laptop, or if you don't have the budget for it, then you look
elsewhere, you're not going to just read some article and decide to
wait years without a computer in the hope that what you actually want
might be released by then.



> > > > A good summary is that we want to "bring
> > > > blob-free to the hardware that people want", rather than "bring
> > > > blob-free hardware to the people who want it".

> This is great; and I may quote you on that :)

Yeah, Todd, you can quote me. I also really liked that when I thought of it :p
And thanks for answering Nico's questions and correcting my
statements. I didn't even know an i.mx8 librem 13/15 had already been
thought of, that's pretty cool if it's in the plans!

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

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

[Youness Alaoui]

On Sat, Dec 23, 2017 at 12:28 AM, Zoran Stojsavljevic
 wrote:
> Hello Youness,
>
> With all due respect, you write too long emails, trying to defend
> Purism. Lot of yours argument I do not buy.
> Some of them I do.
>
I know I write too long emails, a long time ago I stopped trying to
make them shorter, because I always fail. Some like to read them, some
won't read them, and that's ok.
I wasn't trying to defend Purism though, I was answering Taiidan's
questions. Maybe he'll accept the answers, maybe he'll disagree with
my answer, or maybe he won't bother to read the long email either.


> But, hey, this is what you/Purism have/has to offer, and this is a
> sort of fair deal. We all know what you are offering,
> in regards to x86, so let it be. Some people will buy Taiidan's facts,
> some yours, and some will stay in between.
>
Yes, there is a lot of choices for a lot of needs and the person
making the decision is the user, they decide what they want, so they
can't be wrong. I remember when Purism was even suggesting GluGlub on
the website as an alternative (a "non-competitor"). I think that was
taken down after some political conflict between Leah and us, i'm not
entirely sure though.

Have a nice weekend, happy christmas (if you care) and happy new year!

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

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

[Youness Alaoui]

On Tue, Dec 19, 2017 at 8:04 PM, taii...@gmx.com <taii...@gmx.com> wrote:
> On 12/18/2017 01:59 PM, Youness Alaoui wrote:
>
>> As for Taiidan's response, I think Matt's response to it is pretty
>> good already, and I'm tired of seeing Taiidan jumping at the chance to
>> talk against Purism every chance he gets
>
> I simply want people to have all the facts before they spend thousands on a
> computer - as I have stated before you guys really need to change your
> marketing as it is confusing a lot of people.

First of all, I feel like this email is genuinely curious/humble
rather than hateful as I've had the impression in the past, so thank
you for that. That's why I decided to answer you, as I've previously
preferred not to. This response will probably be long though, so if
anyone reading here decides to TL;DR, that's perfectly fine by me.
The facts are there for people and I don't think that there is
anything wrong with the marketing. Some people might be confused but I
think that's unavoidable, no matter what we do or how we say things or
which things are put on the front, there will always be people who
will be confused.

>
> I of course would be more than happy to assist with this task, please
> remember *people are still going to purchase your products if your marketing
> is entirely up front and honest* - will you loose a few sales? of course,
> but it is better to do that then have unhappy customers.

That's your issue here, you think that the marketing is not honest,
but it is. It's not about losing sales or anything like that. You'd be
surprised to know just how many "unhappy customers" there are compared
to how many customers are actually happy about their devices. Other
than a couple of people (like you or Nico) who have stated that they'd
be unhappy with such a device, I haven't heard of anyone complaining.
I think that you are simply projecting your own needs or wants to a
much larger proportion of our customers. Would some people prefer a
100% open machine, yes, can they buy such a machine from somewhere
else, yes, did they misunderstand what the librem actually was when
they bought it, probably not.

>
> I humbly request:
> Remove "Libre" from the product names,

Now this is ridiculous (sorry) for multiple reasons. First of all, it
would be a nightmare to suddenly change a brand's name just to satisfy
one non-customer, and secondly, it makes no sense, the fact that the
device is called a Librem doesn't mean that it's open source hardware!
What's next, you will ask LibreOffice from refusing to install on any
hardware if they detect binary blobs on it ? Or that they remove
support for non libre document formats? Would you say that libreboot
should not be installed on laptops for which the schematics are not
open source ? etc..
The laptops are the "Librem series" they are not "The Libre hardware
series", and you need to differentiate between the two. The brand name
is not meant to trap customers either.

> Remove "every chip hand selected to respect privacy" (Intel chips do not do
> this),

This one, I kind of agree with you on it. I understand where it comes
from, it's about the peripherals, USB chip, webcam chip, the wifi
chip, the fact that the ethernet chip (on the previous models with
ethernet) was added instead of using the intel integrated one, etc...
So, yes, every chip is indeed hand selected to optimize the privacy
and security when an alternative is available, it is not however a
guarantee that the CPU itself is privacy-respecting. The sentence is
there to basically say "we are not a white-label reseller", but I do
agree with you that it can be (easily) interpreted to mean that the
intel CPU is privacy-respecting when it is not necessarily true.

> Clearly mention and define the difference between a coreboot device with FSP
> and one without in the product description

How and where? There is nothing clearer than the fact that coreboot
comes with binary blobs. We have written countless blog posts about
it, I regularly post progress updates, we have discussed which binary
blobs are present and what they do, we have a link somewhere to point
to the https://www.coreboot.org/Binary_situation page, it's even
actually mentioned that "we have yet to free the Intel FSP" in the
Roadmap page, this is not something that is hidden from customers by
any stretch of the imagination, and your statement makes it sound like
we're hiding this on purpose from the customers.
Would you also suggest to any manufacturer that sells laptops with
Ubuntu on them to specify that "Ubuntu is not really free software
because it has binary firmwares in it" ? No, because the important
part is that you're running Ubuntu, it doesn't matter that it has a
binary firmware file in it somewhere... this is the same thing, it
ships with coreboot, yeay, it has an open so

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

[Youness Alaoui]

I think there is a plan to move librems to non-x86 architecture
eventually (considering that RYF is our long term plan, there is no
choice in moving out of x86 eventually), I think the efforts on the
risc-v front are the most promising and I think that's where the true
competition to x86 will be, but to be honest, I don't really follow,
understand or know much of anything that happens in the hardware space
since I'm a software guy at heart (i.e: all I know is that x86, ARM,
PPC and Risc-V use different instruction sets). I hear a lot about PPC
(with Talos for example), but I don't think PPC is as open as Risc-v
(ISA or something). All I know about PPC really is that it was fun to
reverse engineer during my PS3 days :)
Anyways, as far as I know, for risc-v, it's not there yet, so we're
waiting for that to be ready for the masses before moving to it. I
have absolutely no idea if it's "close" or if it's really a long term
plan for risc-v to be able to compete with x86 in terms of
performance/power usage/features/etc...

Note: this is not an official statement, I never really bothered to
ask in details about such things, I simply write code and yell at it
for not working...

As for the collaboration, again, I have no idea about any of the
business/manufacturing logistics, but if you think there's something
there that can be done, I suggest you contact Todd (I added him in CC)
and you could discuss things, he'll know what to answer you!

Thanks!

On Tue, Dec 19, 2017 at 3:54 PM, Timothy Pearson
<tpear...@raptorengineering.com> wrote:
>
> Thank you for the detailed explanation.  I guess this is an area in
> which experience matters; it is absolutely unacceptable (and not
> unexpected) that Intel misled your CEO, but this is sadly not an
> uncommon tactic in the industry.
>
> One item I would like to call out though is the following:
>
>> if old or non-x86 architectures were so appealing, you would have seen that 
>> become the norm rather than the exception)
>
> No one is denying that the easiest course of action for everyone would
> have been for Intel or AMD to release owner-controllable CPUs.  That
> being said, individuals and organizations needing privacy and owner
> control are /not/ their target market, nor are those entities Intel (or
> AMD)'s secondary (or even tertiary) market.  Both Intel and AMD rely on
> their lock-in and close association with Windows and related software to
> provide cheap, but wholly locked down, CPUs *by design*.  You could look
> at it as the hardware vendor simply providing a leased tool on which to
> run the leased software -- in such a market, cost trumps everything,
> owner control is looked at as "enabling piracy", and as a result x86 is
> not an appropriate platform for anyone needing control or privacy.
>
> In this environment, one must make a choice between convenience (x86)
> and owner control.  As you mentioned, the only middle ground is
> relegated to ancient computers, and that is not where we place any hope
> at all.  Trying to switch architectures may be hard, but it is only
> going to get harder day after day as people continue to cling to false
> hope that the x86 platform may ever be brought under their control.  The
> simple fact is, the purchaser of an x86 machine is not Intel or AMD's
> customer, nor are the ODMs.  Their primary customers, in an odd sort of
> way, are actually the software vendors that require x86 for their
> existing applications, and they are the ones that will call the shots on
> features or antifeatures in the x86 walled garden.
>
> I wonder, though, if given this information if possibly Raptor and
> Purism might have some common business ground here?  Purism has
> experience with laptop mechanicals and related concerns, and we have
> experience with truly blob-free, powerful hardware -- combining those
> two could yield an interesting machine...
>
> On 12/19/2017 02:41 PM, Youness Alaoui wrote:
>> On Tue, Dec 19, 2017 at 2:07 PM, Timothy Pearson
>> <tpear...@raptorengineering.com> wrote:
>> On 12/19/2017 11:51 AM, Dame Más wrote:
>>>>> I finished the University and I have free time to do things. And this
>>>>> seems like an interesting project to which I dedicate many hours.
>>>>>
>>>>> The truth is that I read a lot these days. The work you do kakaroto is
>>>>> impressive.
>>>>> In general Purism is doing something big, and I spoke ahead of time.
>>>>>
>>>>> I saw that in the directory
>>>>> coreboot/3rdparty/blobs/mainboard/purism/
>>>>> there is no content, it is right?
>>>>>
>>>>> Thanks
>>
>> The main question I have, and this is an honest question, is why Purism

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

[Youness Alaoui]

On Tue, Dec 19, 2017 at 2:07 PM, Timothy Pearson
 wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 12/19/2017 11:51 AM, Dame Más wrote:
>> I finished the University and I have free time to do things. And this
>> seems like an interesting project to which I dedicate many hours.
>>
>> The truth is that I read a lot these days. The work you do kakaroto is
>> impressive.
>> In general Purism is doing something big, and I spoke ahead of time.
>>
>> I saw that in the directory
>> coreboot/3rdparty/blobs/mainboard/purism/
>> there is no content, it is right?
>>
>> Thanks
>
> The main question I have, and this is an honest question, is why Purism
> chose to use the x86 platform as a base for libre hardware, when it has
> been known for some time that said hardware could never be made fully
> blob-free?
>
> There were (and are) other good ways to make a system that could be
> fully blob-free, for instance ARM, and given the engineering effort that
> is said to have been put into the Purism machines I wonder what we could
> have had if said effort had been put into an aarch64 system instead of
> an x86 system?

That's a very good question and you're not the first one to ask it.

I think it's a combination of quite a few things. First, the fact that
I don't think there were any realistically powerfuly/competing
ARM/PPC/risc systems available at the time (or if there were, the
price would have been too high to make it a "security focused laptop
for everyone"). The purpose of Purism is not to satisfy a niche
market, but rather to be something everyone will want whether or not
they care about the security like we do, but which would still provide
them with that security that they need. I think even now, you can't
have an ARM device that could compete with an i7 in terms of
performance.

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

The last reason is because I think that through this discussion
(https://mail.coreboot.org/pipermail/coreboot/2014-August/078511.html)
Todd thought that it would be possible to get a binary blob free
coreboot/CPU with a few months of work. He didn't realize that it was
a much harder thing to achieve because the FSP takes a lot of time to
reverse engineer (remember, he thought he would have an ME-less CPU
from Intel), but from what I read in one of his answers, he had
already decided on x86 by the time he wrote that mail to the mailing
list, so I'm not sure if it really answers your question.

I think those that provide non-x86 (or pre-2008 x86) machines are
already there to fill the blob-free need, and it's not healthy to just
compete with them. A good summary is that we want to "bring blob-free
to the hardware that people want", rather than "bring blob-free
hardware to the people who want it".

Finally, I'll paste you one of my explanations from an email I sent
here last May, which kind of summarizes it all (from
https://mail.coreboot.org/pipermail/coreboot/2017-May/084166.html)

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

I hope that fully answers your question.

Thanks!
Youness.


>
> - --
> Timothy Pearson
> Raptor Engineering
> +1 (415) 727-8645 (direct line)
> +1 (512) 690-0200 (switchboard)
> https://www.raptorengineering.com
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1
>
> iQEcBAEBAgAGBQJaOWOAAAoJEK+E3vEXDOFbBZEH/1loBwNG4m2ZrqmQ0qXRrYYy
> 9i+bMDTA/a85sPMWm870rJ2qG79Wy9s1w6P/qXIf3iFACDWWt5DpB6/NP6t8hjUp
> R9848GoBH2oCt0gO2Ydbt2ThGCP96q2JQoz2sz5Qo/CWXeBccTHZogA7CRc/u/zO
> Uj6qSTUUEoxt7Ul0AAoaT0UIYvJJoDjatKX61Rv96hA6RtDGib7nWZ+UwiuD3+wS
> iiYO+lkZzrhAprrLIH8Y58IMQ8RlQYRIguWQhmD5+A6I933Xyv81QTwonaDKATBC
> fwi3psMjmem4vg1pfJdBOowzMwx9ZItjjuvhPVkNfgpUP1gkZb+OQbFjounucaY=
> =iQzP
> -END PGP SIGNATURE-

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

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

[Youness Alaoui]

Hi Dame,

The coreboot on Purism machines is indeed open and available, and it
is all merged into upstream coreboot, so there is no specific
repository for it other than the coreboot repository (the code is in
src/mainboard/purism/ subdirectory).
Here is the build script we use to build coreboot for our machines,
from scratch : 
https://forums.puri.sm/t/building-coreboot-from-source-official-script/1264
I haven't updated the build script in a while, so it's actually
building from here : https://code.puri.sm/kakaroto/coreboot.git but
those commits were merged upstream and the upstream coreboot
repository is all you need now.
Note that to disable the ME, we need to use the '-S -e MFS' option to
me_cleaner (the script also uses my own repository for me_cleaner, but
my patches to me_cleaner were also merged upstream, so you can just
use the upstream repository for me_cleaner. See my pull request here :
https://github.com/corna/me_cleaner/pull/70) .
You can read more about the efforts to disable the ME and the need for
the -e option by reading my blog post here :
https://puri.sm/posts/deep-dive-into-intel-me-disablement/
You said you want to implement coreboot for some 7th and 8th
generation Intel computers. Then you'd probably also be interested in
the blog posts I wrote about the porting experience. You can find all
my posts on the right sidebar of our coreboot timeline page here :
https://puri.sm/coreboot/timeline/
If you still have any questions, feel free to ask.

As for Taiidan's response, I think Matt's response to it is pretty
good already, and I'm tired of seeing Taiidan jumping at the chance to
talk against Purism every chance he gets, but I won't rant about that
today, I will only add this to the discussion :
* The original question was on whether our coreboot port was available
or not because the OP wanted to know how we disable the ME, you
completely missed the question and decided to give advice on what
device to buy instead...
* You seem to think that the purism laptops are selling at a premium
because it comes with coreboot? I'm pretty sure that the Cost/MSRP
margin is the same or lower than from other laptop manufacturers, the
"premium" you'd pay is because of the low volume of machines we are
making, Dell/Lenovo can of course sell for lower prices because they
get economy of scale, which we don't. It's not because we are
increasing our revenue and using coreboot as an excuse to do it.
* You said "they are charging for a whitebox re-brand.", that's
actually a completely false statement, the motherboard is our own and
it is designed to avoid having any firmware-based hardware so a
binary-blob-free linux distribution can run on it. It is not a
whitebox re-brand. If it was a whitebox re-brand, then yeah, we'd be
selling for a lot lower price considering we'd be able to also take
advantage of the economies of scale.
* You are encouraging the purchase of lenovo machines, but as far as I
know, lenovo is not actively working on reverse enginering the FSP.
Also, the only reason that Lenovo can have a libreboot running on it
is because the community did the port, not because the company itself
is working towards freeing it or investing anything to provide more
freedom to users. So yeah, sure, you could say "don't pay a 30$
premium for coreboot, buy a lenovo and do the port yourself" (assuming
you know how to do the port, or you buy one that is already ported) ,
but you might as well say "don't pay a 30$ premium for coreboot, buy a
lenovo, do the port yourself, then reverse engineer the FSP yourself
while you're at it" and it would be more accurate. And that's of
course ignoring the question of the harware kill switches, the fact
that you can't compare a 200$ refurbished laptop from 6 years ago with
a higher priced laptop from today, or that lenovo won't answer you if
you ask tech support questions on coreboot or linux, etc...
* We worked on disabling the ME on the purism laptops. Yes, the lion's
share of the work was done by others (Corna for me_cleaner and
Positive Technologies for the HAP bit), but not only did it require a
significant amount of work from our side as well, to test, validate
and package the ME disablement work (see above blog post link), but we
are the first manufacturer to offer it standard and without us doing
it, it could be argued whether or not this differentiation would have
convinced System76 and Dell to also pursue offering machines with the
ME disabled. So, encouraging those who are trying to pioneer the work
might actually help the entire community. Do you think it might
convince Intel to offer ME-less designs if they see half the
manufacturers starting to ship unofficially-disabled ME machines ?
Maybe, maybe not, but at least someone is trying to move things along
instead of only complaining about the status of things.

I could go on, but I think that's enough.

Hopefully, this helps clarify the situation.

Thanks,
Youness.

On Mon, Dec 18, 2017 at 4:07 AM, Dame Más 

Re: [coreboot] Black screen during SeaBIOS boot

[Youness Alaoui]

Try a 'cbmem -t' to see how long coreboot itself took to boot. There
might be some delay somewhere causing it to take longer to boot
(current system I'm on, it takes 8 seconds, and on other systems I saw
it take 15 seconds, because it waits for the ME to respond until it
times out) so it might not all be seabios' fault.
Also I just tried removing the VGABIOS and setting Coreboot to run the
GOP driver, and I got a black screen in seabios (even in grub, screen
shows text only after linux boots and inits the driver I think). I'd
suggest you try the proper vgabios and no GOP driver, just to see if
it helps, then see what happens without the vgabios.
Note: i only have one VGA device here.

On Fri, Dec 15, 2017 at 12:59 PM, awokd via coreboot
 wrote:
> On Fri, December 15, 2017 11:10 am, Daniel K wrote:
>
>> Starting up with coreboot and SeaBIOS, the screen is completely black for
>> around 30 seconds before my on-disc bootloader (grub2) is loaded and
>> displayed.
>>
>> I'm assuming SeaBIOS counts down with some timer before launching the
>> on-disc bootloader but I don't see anything.
>>
>> I want to use coreboot in text-mode so I'm not including a VGA rom.
>
> That might be why you are getting the delay. Try adding it and see. I ran
> into the delay too and think that's what fixed it.
>
>> According to lspci (attached), I have two VGA devices:
>
> You might need to edit src/device/Kconfig with:
>
> config MULTIPLE_VGA_ADAPTERS
> bool
> default y
>
>
>
> --
> coreboot mailing list: coreboot@coreboot.org
> https://mail.coreboot.org/mailman/listinfo/coreboot

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

Re: [coreboot] Disabling Intel ME 11 via undocumented mode

[Youness Alaoui]

In my opinion, the ME is indeed disabled because the entire ME
functionality is disabled, no ME processes are running, and the kernel
on its own is irrelevant, even if it keeps running.
However, I do not have anymore a strong counter opinion to your
statement that you don't consider the ME to be disabled as I
originally did.
It all depends on how we choose to see it, I consider it to be
disabled, and you consider that it's not. It will always differ on
each person's interpretation of the definition of the word "disabled".

All I could find online about the actual definition of the word
"disabled" is either :
* related to a person, in which the definition is "having a physical
or mental condition that limits movements, senses, or activities."
* related to a device or a mechanism in which the definition is either :
  * "rendered inoperative (as by being damaged or deliberately
altered)" (Merriam-Webster dictionary)
  * "not in proper working order; out of commission" (Collins dictionary)

The definition of "To disable" is better as it has more meanings
("disabled" has the majority of definitions related to a disabled
person) :
  * "put out of action" (Oxford dictionary)
  * "to make ineffective or inoperative" (Merriam-Webster dictionary)
  * "To deprive of capability or effectiveness, especially to impair
the physical abilities of." (The Free Dictionary)
  * "to stop a machine or piece of equipment from working properly"
(The MacMillian dictionary)
  * "If someone or something disables a system or mechanism, they stop
it working, usually temporarily." (The Collins dictionary)
  * "to make ineffective, unfit, or incapable, as by crippling" (The
Collins dictionary)
  * "to switch off (an electronic device)" (The Collins dictionary)

I believe that the ME is "disabled" according to all but the last of
these definitions. The ME 11.x with the HAP bit is rendered
ineffective, it's deprived of functionality and it's not working
properly, etc.. The definition which does not match the current status
is the "to switch off", which is not the case here and which is
probably the definition (or close to it) that you have in your mind
when you think of the word "disabled".

So again, like I said, I believe it it disabled and I don't think I'd
be convinced that it's not, but if you say that you don't think it's
disabled, I won't disagree with you either, I'll simply assume you see
things differently. Hopefully, you are also able to understand that
when I say the ME is disabled, it's not because of a desire to
mislead. I believe therefore that we are both right in our
interpretations.
FYI, for me "limited" means that it retains some functionality, but
not all, like for example, the Consumer version of the ME is a limited
ME when compared to the Corporate version. In our case, no
functionality is left, so I can't consider it merely as being limited.
You could say it's limited because the 'kernel functionality' remains,
but I don't see the kernel as a feature, so for me, it doesn't work.

Thanks for reading!
Youness.


On Thu, Dec 14, 2017 at 11:15 AM, Timothy Pearson
<tpear...@raptorengineering.com> wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Thank you for the detailed response; I figured there had to be some
> basic miscommunication somewhere. :-)  So I assume we now agree that the
> ME on Sylake + is not disabled, merely limited?
>
> On 12/14/2017 01:20 AM, Youness Alaoui wrote:
>> Hi,
>>
>> From the PT article you linked to, after the stage 5 of BUP execution :
>> "It is at this stage that we find HAP processing; in this mode, BUP
>> hangs instead of executing InitScript. This means that the remaining
>> sequence of actions in normal mode has nothing to do with HAP and will
>> not be considered. The main thing we would like to note is that in HAP
>> mode, BUP initializes the entire platform (ICC, Boot Guard) but does
>> not start the main ME processes."
>>
>> As for the kernel, that's my mistake, I remembered that prior to ME
>> 11.x, the KERNEL module was removed by me_cleaner, and BUP was the
>> first process loaded. I hadn't realized that the execution order
>> changed in ME 11.x, and that explains why the KERNEL module cannot be
>> removed by me_cleaner in ME 11.x.
>> On ME 10.x and lower, the BUP module was the first executed, and it
>> would then load the KERNEL, so if BUP is halted before it did that,
>> then the kernel doesn't run. In ME 11.x however, they changed the
>> order, the KERNEL module is first to be loaded, but it only starts the
>> BUP process :
>> "The first process that the kernel creates is BUP, which runs in its
>> own address

Re: [coreboot] Disabling Intel ME 11 via undocumented mode

[Youness Alaoui]

Hi,

>From the PT article you linked to, after the stage 5 of BUP execution :
"It is at this stage that we find HAP processing; in this mode, BUP
hangs instead of executing InitScript. This means that the remaining
sequence of actions in normal mode has nothing to do with HAP and will
not be considered. The main thing we would like to note is that in HAP
mode, BUP initializes the entire platform (ICC, Boot Guard) but does
not start the main ME processes."

As for the kernel, that's my mistake, I remembered that prior to ME
11.x, the KERNEL module was removed by me_cleaner, and BUP was the
first process loaded. I hadn't realized that the execution order
changed in ME 11.x, and that explains why the KERNEL module cannot be
removed by me_cleaner in ME 11.x.
On ME 10.x and lower, the BUP module was the first executed, and it
would then load the KERNEL, so if BUP is halted before it did that,
then the kernel doesn't run. In ME 11.x however, they changed the
order, the KERNEL module is first to be loaded, but it only starts the
BUP process :
"The first process that the kernel creates is BUP, which runs in its
own address space in ring-3. The kernel does not launch any other
processes itself; this is done by BUP itself"
So, you are right, on Skylake+ (ME 11.x), the kernel would be running
but the BUP process is the one halted and no other processes get
launched, but on ME 10.x and lower, the kernel wouldn't be running
since BUP is loaded first (this is true for me_cleaned ME 10.x, and
I'm not sure what exactly the MeAltDisable flag does, which is the
equivalent of HAP on previous versions, but there wasn't any specific
research done on that).

I hadn't realized that until now when researching an error-free
response to you, so thanks for helping me notice that mistake in my
understanding.

Youness.



On Wed, Dec 13, 2017 at 12:54 PM, Timothy Pearson
<tpear...@raptorengineering.com> wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> According to Positive Technologies, on Skylake and higher (like the
> Purism machines) the kernel loads the BUP, and the HAP bit only disables
> the normal userspace processes [1].
>
> What proof do you have that the kernel itself is halted?
>
> [1] http://blog.ptsecurity.com/2017/08/disabling-intel-me.html
>
> On 12/13/2017 11:34 AM, Youness Alaoui wrote:
>>> I guess I still disagree with the use of the word "disabled".  If the ME
>>> wasn't required for boot, and was actually disabled within a few cycles
>>> of its CPU starting, the remaining attack surface simply wouldn't exist.
>>>  This is not what happens though, and AFAIK even the ME kernel continues
>>> to run since the ME needs to continue handling platform power events.
>>> If this many holes are present in even the ROM code, then having the ME
>>> kernel running remains a massive security problem.
>>>
>>
>> I'm just going to answer the bit about the use of the term "disabled".
>> I've explained it in my blog post before (here if you missed it :
>> https://puri.sm/posts/deep-dive-into-intel-me-disablement/) but I do
>> believe the ME is in this case Disabled. What you are thinking about
>> is what I called "Removed". The reason it's called disabled is because
>> the ME stops running, it's not actively doing anything, it doesn't
>> respond to HECI, it doesn't even boot into the kernel. You said that
>> "the ME kernel continues to run", but that's not the case. The entire
>> ME core stops execution during the bring-up phase, so it's technically
>> disabled because it stops itself at some point after boot.
>> Having the ME *removed* would be interesting because that would mean
>> that even the bring up phase wouldn't get executed and we could remove
>> the entire ME firmware from the flash. But that still wouldn't mean
>> that nothing runs on the ME core because there is still some small
>> code embeded in the ROM.
>> Anyways, that's my justification on why using the term "disabled" is
>> valid in this case when HAP is enabled. You are free to disagree if
>> that didn't convince you.
>
>
> - --
> Timothy Pearson
> Raptor Engineering
> +1 (415) 727-8645 (direct line)
> +1 (512) 690-0200 (switchboard)
> https://www.raptorengineering.com
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1
>
> iQEcBAEBAgAGBQJaMWk6AAoJEK+E3vEXDOFbTnkH/30CN22Q0JG0bxxvG7NaRjUX
> i4bsAVpdP+rbd9IlmMHDCPtYnmdoBWq81yXZx8iBAzTx5DJrU0lA0Kqr0RzIyNRx
> pE4omRU2St342bQS5bf/UsFwT2WKR2vlE8u8NR4YiOXnJNySJ1gSQqzxB4uGwd7I
> rcyMnScr4IKEgwiE3GA7HU4vHE2w66M6g0skhYQtquAm3ypajmwLUbFwsgiAp0l1
> Azbt9pUFlp7McZTJusuRroWsDv1oOWQit3nH54i0yP6EajGWbZJ4+sAEQJSXVr9Q
> 6iuVDE8WfZsydARlvfM+hc0TyrGIv08EnLkhNOQjA4bfab6TxK1l2EnNE1STwXc=
> =7rNS
> -END PGP SIGNATURE-
>
> --
> coreboot mailing list: coreboot@coreboot.org
> https://mail.coreboot.org/mailman/listinfo/coreboot

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

Re: [coreboot] Disabling Intel ME 11 via undocumented mode

[Youness Alaoui]

> I guess I still disagree with the use of the word "disabled".  If the ME
> wasn't required for boot, and was actually disabled within a few cycles
> of its CPU starting, the remaining attack surface simply wouldn't exist.
>  This is not what happens though, and AFAIK even the ME kernel continues
> to run since the ME needs to continue handling platform power events.
> If this many holes are present in even the ROM code, then having the ME
> kernel running remains a massive security problem.
>

I'm just going to answer the bit about the use of the term "disabled".
I've explained it in my blog post before (here if you missed it :
https://puri.sm/posts/deep-dive-into-intel-me-disablement/) but I do
believe the ME is in this case Disabled. What you are thinking about
is what I called "Removed". The reason it's called disabled is because
the ME stops running, it's not actively doing anything, it doesn't
respond to HECI, it doesn't even boot into the kernel. You said that
"the ME kernel continues to run", but that's not the case. The entire
ME core stops execution during the bring-up phase, so it's technically
disabled because it stops itself at some point after boot.
Having the ME *removed* would be interesting because that would mean
that even the bring up phase wouldn't get executed and we could remove
the entire ME firmware from the flash. But that still wouldn't mean
that nothing runs on the ME core because there is still some small
code embeded in the ROM.
Anyways, that's my justification on why using the term "disabled" is
valid in this case when HAP is enabled. You are free to disagree if
that didn't convince you.

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

Re: [coreboot] What’s the release plan for coreboot 4.7?

[Youness Alaoui]

Hi,

What happened with the plan for the 4.7 release? I thought it was
supposed to be out at the end of October, now we're approaching the
end of November.
Was it forgotten, delayed or cancelled ? If delayed, what's the
blocking issue ?

Thanks,
Youness.

On Wed, Oct 4, 2017 at 11:24 AM, Martin Roth  wrote:
> The release will happen towards the end of the month.   Generally I
> try to have the release scheduled a bit before the month ends so
> there's a little room to slip. I'll sit down this weekend and start
> sorting out where we are and send out another email with release
> plans.
>
> If there are any bugs in the bug tracker that people would
> specifically like help with getting fixed before the next release,
> please reply here.
>
> If developers could take a look at coverity and see if there are any
> issues there that they can fix, that would be great.
>
> Please start testing any boards that you have and uploading the
> results to the board-status repo so we know what's working.  If you
> have boards that don't boot, please reply here, and try to bisect the
> issue to find where it stopped working.
>
> Martin
>
>
>
> On Tue, Oct 3, 2017 at 9:33 AM, Paul Menzel
>  wrote:
>> Dear coreboot folks,
>>
>>
>> It’s October and coreboot 4.7 is supposed to be tagged in this month.
>>
>> Are there more specific plans already, when the release will happen?
>>
>>
>> Thanks,
>>
>> Paul
>> --
>> coreboot mailing list: coreboot@coreboot.org
>> https://mail.coreboot.org/mailman/listinfo/coreboot
>
> --
> coreboot mailing list: coreboot@coreboot.org
> https://mail.coreboot.org/mailman/listinfo/coreboot

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

Re: [coreboot] greetings and laptop questions

[Youness Alaoui]

> While I understand your frustration, and agree with the general thrust
> of your email, and disregarding the "10 years", the Samsung Chromebook
> Plus (and many other devices of similar age) beg to differ.
> There are devices from 2016 and 2017 shipping with coreboot and no CPU
> level blobs in the firmware (the only CPU side blob would be the
> kernel's GPU driver).

Sorry, I'm so deep into Intel stuff right now that I completely missed
the possibility of non-x86 hardware. Yes, there is newer hardware with
no blobs in coreboot, my statement is only true for intel-related
hardware. I don't even know about AMD actually, but I believe it's a
similar situation for AMD. But in the case of the Chromebook Plus, I
checked, and it's an ARM based CPU, which is why coreboot is blob free
for it.
The original post was about a laptop to run virtual machines, so I
assume x86 is a requirement, but my statement was about coreboot
itself, not about the laptop requirement, which made it false. Thanks
for the correction!



>
> Please keep the dimension right, newest is Ivy Bridge and that is 5
> years old.

My bad, you're right. The '10 years old' was in reference to ME-less
CPU designs and I confused it with FSP-less coreboot.
As for the ivybridge being the newest, that's again my bad, I used
this to look up when the native intel raminit stopped being supported
;
https://www.coreboot.org/Intel_Native_Raminit#Sandybridge.2FIvybridge
and it said sandybridge/ivybridge, and I thought they were the same,
not one being successor of the other.

I guess that will teach me to email while I'm tired and busy/distracted.



>
>> The original email asked about a
>> coreboot port, not a libreboot port. Every time I see purism
>> mentioned, you have to jump in to insult and dishonestly say that
>> Purism is dishonest. If you want to claim bullshit like that, at least
>> find something real and concrete to back it up. I've ignored you many
>> times, but I'm fed up of your one-man vendetta against Purism. What
>> happened to you for you to have so much hate against us?
>
> It's not him alone, you might remember our discussion about it (it
> ended with you writing poems that I didn't even had the time to read
> in the end, please don't do that again).

You're not hateful from what I could see. You disagree with Purism and
you don't like it, but I haven't seen you jumping at every occasion to
talk bad about it.
As for our last discussion, that's what it was, a discussion, which
unfortunately, I got a little over-verbose in my last response and
killed the discussion, but I don't feel like Taiidan wants to discuss
anything. Either way, I don't plan on opening any new discussions
about Purism here.

>
>>
>> Extremely funny how you then say that System76 is "a fine choice"
>> considering that System76 doesn't even come with coreboot, and even if
>> it did come with coreboot, it would of course, still depend on the
>> FSP. Also, System76 hardware depends on components which do require
>> binary blobs, as opposed to Purism laptops, so I don't get why
>> System76 is "a fine choice" if Purism isn't.
>
> It's pretty simple, System76 seems to advertise what say sell, Purism
> doesn't. I'd say they do most things right, but not the advertisement.
> Most Linux supporting vendors are honest about their products. Yet,
> Purism makes claims such as:
>
>"Only by selecting each and every chip in our Librem laptops can
> we guarantee your privacy, security and freedom are protected."
>
> Where I still argue, it's the opposite with Intel inside.
>
> Everything else, they seem to do alright. I'd fully support them if
> they'd stop the false advertisement of being super secure. They are
> not, just a little better than the rest (by hardware design, don't
> know about the details of their software and how secure the hard-
> ware is configured).
>
> So my conclusion, Purism draws customers from other Linux supporting
> vendors with dishonest marketing. If that doesn't bother you, fine.
> But please don't get angry if it bothers honest people.

I disagree with your statement that it's false advertisement and that
it's dishonest marketing. I won't explain why I think you're wrong
here, because :
1 - I already explained it in length in my previous long email that
you never read
2 - It doesn't market itself as "being super secure" as you said, but
rather as being "security and privacy focused", which it is. You are
free to find anywhere on the website where it says security or privacy
without stating "a focus on" or "-focused" along with it.
2 - It's my opinion/interpretation and you have a different one, and
that's fine, you are entitled to it. Your view/interpretation of a
statement does not mean everyone needs to see it your way and that the
conclusion that it's being dishonest which your drew from it, is going
to be the absolute truth.
3 - By stating that it "bothers honest people", right after saying
that it doesn't bother me, you're implying that I'm 

Re: [coreboot] greetings and laptop questions

[Youness Alaoui]

On Sun, Oct 8, 2017 at 6:15 PM, taii...@gmx.com  wrote:
>
>>
>> (I also am looking at system76 and Purism but I am bit leery of spending a
>> lot with a small / new company - comments appreciated)
>
> Purism dishonestly markets their products - while they claim that their
> laptops "respect freedom and privacy" their version of coreboot is nothing
> more than a wrapper layer for intel FSP (binary blob that does all the
> hardware init) which is next to pointless for the amount of money you would
> spend on one as all it does is move trust from vendor to OEM not avoiding
> the hypothetical OEM firmware backdoors.
>
> System76 is a fine choice if all you want is a laptop that runs linux
> without difficulty.
>

I don't get why you constantly try to discredit Purism and insult
everything we do. You complain about coreboot being "useless" because
it uses FSP, but you fail to mention that anything using coreboot will
use the FSP unless it's 10 year old hardware (Sandybridge is the
latest FSP-free supported CPU). The original email asked about a
coreboot port, not a libreboot port. Every time I see purism
mentioned, you have to jump in to insult and dishonestly say that
Purism is dishonest. If you want to claim bullshit like that, at least
find something real and concrete to back it up. I've ignored you many
times, but I'm fed up of your one-man vendetta against Purism. What
happened to you for you to have so much hate against us?

Extremely funny how you then say that System76 is "a fine choice"
considering that System76 doesn't even come with coreboot, and even if
it did come with coreboot, it would of course, still depend on the
FSP. Also, System76 hardware depends on components which do require
binary blobs, as opposed to Purism laptops, so I don't get why
System76 is "a fine choice" if Purism isn't.

To answer Jim, the Purism Librem 15 doesn't support 32 GB of RAM, but
it does run coreboot and will come with a disabled ME (blog post
announcing that is pending). If you need a laptop which runs linux
without the need for any of the binary firmware blobs (firmware-linux
package in debian), where the company is actively working on
eliminating the remaining blobs in the system (the ME, the FSP and
VGABIOS) then you might want to look at Purism, if you don't care
about those issues and/or require 32GB of RAM (which our laptops don't
support), then you should discard Purism from your list of choices and
look for something else.

I hope that helps.
.

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

Re: [coreboot] SPI Flash debug console on H8SCM

[Youness Alaoui]

Hi Fabian,

It was ported to older intel architectures by Nicola Corna here :
https://review.coreboot.org/#/c/21107/
I don't know what would need to be done to port it to work with amd,
but in theory, all it needs is for the chipset to support SPI
operations. If it can read and write to the spi flash for the purposes
of the mrc.cache, then it should be easy to make it work.
The real work to port it to other architectures was pretty much only
to make sure the spi controller doesn't use global variables so it
could be included in the bootblock and romstage.

Good luck.
Youness.


On Fri, Sep 15, 2017 at 12:40 PM, Fabian  wrote:
> Hi everyone,
>
> I try to get coreboot run on my H8SCM. Sadly I get no log over serial or USB. 
> So I want to give SPI console a try. It seems to be a very new feature 
> introduced here [1].
>
> When I compile coreboot it fails with this warning:
> warning: (CPU_SPECIFIC_OPTIONS && CPU_SPECIFIC_OPTIONS && 
> CPU_SPECIFIC_OPTIONS && CPU_SPECIFIC_OPTIONS && CONSOLE_SPI_FLASH) selects 
> BOOT_DEVICE_SPI_FLASH_RW_NOMMAP_EARLY which has unmet direct dependencies 
> (SPI_FLASH && BOOT_DEVICE_SPI_FLASH_RW_NOMMAP)
>
> As written in [1] it's only tested for Skylake. How much effort is necessary 
> to port it to my board? Are there more Information about SPI console? Or is 
> there an other way to get log from my board?
>
> One more question to the AMD experts: There are two motherboard models 
> "H8SCM" and "H8SCM (Fam10)". Whats the difference?
>
> Greetings,
> Fabian
>
> [1] https://mail.coreboot.org/pipermail/coreboot/2017-June/084538.html
>
> --
> coreboot mailing list: coreboot@coreboot.org
> https://mail.coreboot.org/mailman/listinfo/coreboot

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

[coreboot] SPI Flash debug console

[Youness Alaoui]

Hi everyone,

I mentioned this during my presentation at the coreboot conference
last week, and I was waiting for it to be merged before I announced it
on the mailing list.

For those of you working on recent hardware (this was tested on
skylake only, for broadwell to work, we need to add the spi controller
to romstage and convert it to use CAR_GLOBAL, I don't know about other
archs), if you don't have a debug header, or if you don't want to go
through the trouble of soldering on UART pads or you just don't have
any easy access to the debug console, then you can enable the "SPI
Flash console output" option in the Console menu.
It will automatically add an area to the FMAP which will contain your
console log. After you turn on the machine, you can dump the SPI flash
and use cbfstool to get the full console log :
cbfstool coreboot.rom read -r CONSOLE -f console.log

The console log will contain all stages including the bootblock and
romstage, so it's useful to debug memory init issues. Since most of us
debugging coreboot on new mainboards will already have our external
SPI flasher hooked up, we can just read the rom before writing a new
one to it and get the log at the same time.

Note that the console log will not be reset on poweroff/reboot, it
will continue to grow until the whole area is full, at which point it
will stop writing anything to the flash. This is to avoid excessive
SPI writes in case you forget to disable the option once you get the
machine booting.

That's it, I hope it's useful to someone else!

Thanks to Matt DeVillier and Aaron Durbin for helping
debug/test/review the implementation.

Youness.

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

Re: [coreboot] Denver conference

[Youness Alaoui]

lol, I don't know, but I assumed we need to go to a registration desk
and get the https://www.coreboot.org/Denver2017#Goodies and I assumed
a lanyard is included in there :p How else will you know who I am?! :p

On Thu, Jun 1, 2017 at 3:51 PM, Matt DeVillier <matt.devill...@gmail.com> wrote:
> On Thu, Jun 1, 2017 at 2:46 PM, Youness Alaoui
> <kakar...@kakaroto.homelinux.net> wrote:
>>
>> Then I suppose once they arrive at the conference registration booth
>> to get their lanyard, they'll be told hat they haven't paid yet and
>> that they can pay now in cash (and credit cards?). Not that
>> complicated :)
>
>
> wait -- we get lanyards this year?  sweet!

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

Re: [coreboot] Denver conference

[Youness Alaoui]

Then I suppose once they arrive at the conference registration booth
to get their lanyard, they'll be told hat they haven't paid yet and
that they can pay now in cash (and credit cards?). Not that
complicated :)

On Thu, Jun 1, 2017 at 3:39 PM, Zoran Stojsavljevic
<zoran.stojsavlje...@gmail.com> wrote:
> Good. Two reasons here:
> [1] The email delivery is not reliable (very seldom reason, 0.1%).
> [2] The list of attendees are not filled correctly, so for double checking
> Coreboot email list is used. ;-)
>
> What if somebody (who applied) does NOT belong to Coreboot list? ;-)
>
> Zoran
>
> On Thu, Jun 1, 2017 at 9:31 PM, Youness Alaoui
> <kakar...@kakaroto.homelinux.net> wrote:
>>
>> If you registered for the conference, and didn't receive the invoice
>> to pay the conference attendance fees, then let Martin know that you
>> didn't receive the invoice. If you received it, then pay it and that's
>> it.
>>
>> On Thu, Jun 1, 2017 at 2:35 PM, Zoran Stojsavljevic
>> <zoran.stojsavlje...@gmail.com> wrote:
>> >> If you are planning on attending and have not received these emails,
>> >> please let me know immediately so we can get you accounted for.
>> >
>> > Not sure if I understood logic behind this email... What are other
>> > (parallel) means of communications here??? So, let say, I did not get
>> > the
>> > email with the important notification, so I should let somebody know for
>> > something I do not know??? Based upon what else??? Hm Brm!
>> > ;-)
>> >
>> > Zoran
>> >
>> > On Thu, Jun 1, 2017 at 7:44 PM, Martin Roth <gauml...@gmail.com> wrote:
>> >>
>> >> Everyone who is attending the Denver conference should have gotten an
>> >> invoice from the Software Freedom Conservancy, and an email about the
>> >> conference from me.
>> >>
>> >> If you are planning on attending and have not received these emails,
>> >> please let me know immediately so we can get you accounted for.
>> >>
>> >> Thanks.
>> >> Martin
>> >>
>> >> --
>> >> coreboot mailing list: coreboot@coreboot.org
>> >> https://mail.coreboot.org/mailman/listinfo/coreboot
>> >
>> >
>> >
>> > --
>> > coreboot mailing list: coreboot@coreboot.org
>> > https://mail.coreboot.org/mailman/listinfo/coreboot
>
>
>
> --
> coreboot mailing list: coreboot@coreboot.org
> https://mail.coreboot.org/mailman/listinfo/coreboot

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

Re: [coreboot] Denver conference

[Youness Alaoui]

If you registered for the conference, and didn't receive the invoice
to pay the conference attendance fees, then let Martin know that you
didn't receive the invoice. If you received it, then pay it and that's
it.

On Thu, Jun 1, 2017 at 2:35 PM, Zoran Stojsavljevic
 wrote:
>> If you are planning on attending and have not received these emails,
>> please let me know immediately so we can get you accounted for.
>
> Not sure if I understood logic behind this email... What are other
> (parallel) means of communications here??? So, let say, I did not get the
> email with the important notification, so I should let somebody know for
> something I do not know??? Based upon what else??? Hm Brm! ;-)
>
> Zoran
>
> On Thu, Jun 1, 2017 at 7:44 PM, Martin Roth  wrote:
>>
>> Everyone who is attending the Denver conference should have gotten an
>> invoice from the Software Freedom Conservancy, and an email about the
>> conference from me.
>>
>> If you are planning on attending and have not received these emails,
>> please let me know immediately so we can get you accounted for.
>>
>> Thanks.
>> Martin
>>
>> --
>> coreboot mailing list: coreboot@coreboot.org
>> https://mail.coreboot.org/mailman/listinfo/coreboot
>
>
>
> --
> coreboot mailing list: coreboot@coreboot.org
> https://mail.coreboot.org/mailman/listinfo/coreboot

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

Re: [coreboot] GPIO PADRSTCFG conflict in datasheet

[Youness Alaoui]

Hi,

I just found this file here :
https://github.com/IntelFsp/FSP/blob/Skylake/SkylakeFspBinPkg/Include/GpioConfig.h
It defines the reset values for GPIO in this enum :
typedef enum {
GpioResetDefault = 0x0, ///< Leave value of pad reset unmodified
GpioResetPwrGood = 0x1, ///< GPP: RSMRST; GPD: DSW_PWROK; (PadRstCfg =
00b = "Powergood")
GpioResetDeep = 0x3, ///< Deep GPIO Reset (PadRstCfg = 01b = "Deep GPIO Reset")
GpioResetNormal = 0x5, ///< GPIO Reset (PadRstCfg = 10b = "GPIO Reset" )
GpioResetResume = 0x7 ///< GPP: Reserved; GPD: RSMRST; (PadRstCfg =
11b = "Resume Reset" )
} GPIO_RESET_CONFIG;

We can see it specifically says that 00b is "GPP: RSMRST; GPD:
DSW_PWROK" and 11b is "GPP: Reserved; GPD: RSMRST". So I'm leaning
towards the datasheet not having a typo, but rather they just have
different values for RSMRST depending on whether it's GPP or GPD, so I
vote for changing the define in coreboot so it stops being confusing
for those who want to use RSMRST.

I'll send a patch shortly to do it as I suggested in my previous
email, unless someone else has a better idea.

Thanks,
Youness.


On Thu, May 18, 2017 at 2:56 PM, Youness Alaoui
<kakar...@kakaroto.homelinux.net> wrote:
> Hi,
>
> I'm working on a skylake port and I've noticed something with the PADRSTCFG
> field of the GPIO Pad configuration. If you look at the 100-series datasheet
> volume 2
> (https://www-ssl.intel.com/content/www/us/en/chipsets/100-series-chipset-datasheet-vol-2.html).
> The Pad configuration DW0 for GPP_A, GPP_B, GPP_C, etc.. (page 1179, 1249)
> up to GPP_I (page 1319) has bits 31:30 (PADRSTCFG) defined like this :
> 00 = RSMRST#
> 01 = Host deep reset.
> 10 = PLTRST#
> 11 = Reserved
>
> But the Pad configuration DW0 for GPD pads (page 1296) has it defined like
> this :
> 00 = DSW_PWROK
> 01 = Host deep reset.
> 10 = PLTRST#
> 11 = RSMRST#
>
> The problem here is that while the DEEP and PLTRST values are the same, the
> RSMRST value is 0 for GPP gpio pads, and 3 for GPD gpio pads. In the skylake
> and apollolake gpio_defs.h file, it is defined like this (with different
> naming for apollolake but same values) :
> #define  PADRSTCFG_DSW_PWROK 0
> #define  PADRSTCFG_DEEP 1
> #define  PADRSTCFG_PLTRST 2
> #define  PADRSTCFG_RSMRST 3
>
> These defines are only valid for GPD pads, if someone was to use a RSMRST
> reset config on a GPP pad, they would be setting the pad to a 'reserved'
> configuration, which could have unexpected behavior.
> There are two possibilities here, either the datasheet is wrong (and PWROK
> should be 3 so the RSMRST value is consistent for both GPP and GPD), or the
> datasheet is correct, and in both cases, the value in coreboot is wrong.
>
> If someone from Intel is reading this list, or if someone here knows someone
> inside Intel who could confirm whether or not the datasheet has an error,
> that would be great.
> In the meantime, I would maybe suggest to change the defines to  :
> #define PADRSTCFG_GPD_RSMRST3
> #define PADRSTCFG_GPP_RSMRST0
>
> This would affect both skylake and apollolake, and note that the only
> skylake+ boards that use RSMRST seem to be the kblrvp in the rvp7 variant
> which sets it for GPP_A12 and GPP_E3 (which means those two gpios have the
> wrong setting due to the wrong define).
>
> What do you think ?
>
> Thanks,
> Youness.

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

Re: [coreboot] VGA rom doesn't work

[Youness Alaoui]

Congratulations on getting the ME working again.
Your VGA device is 8086,1616, so that's what you need to set. The
8086,0406 is probably just the default one in coreboot, but you still
have to configure it.
In 'make menuconfig', go to Devices menu and set the "VGA Device ID"
to "8086,1616", then recompile, and it will work.
I had the exact same issue . Search for "VGA" in this blog post to
read about it (I didn't say much about it other than what I just said)
: https://puri.sm/posts/librem-13-coreboot-report-february-3rd-2017/

Good luck,
Youness.

On Wed, May 24, 2017 at 7:50 PM, Alejandro Flores  wrote:
> Now that my ME problem is solved I turn to another problem.
>
> The video bios does not seem to function. During seabios boot screen no
> video is displayed. Only when grub auto loads does the video start.
>
> When I use cbfstool auron_yuna.bin print
> it shows pci8086,0406.rom at offset 0x7004c0
>
> However when I check lspci -n it shows an address of 8086:1616 for pci
> device 00.02.0 VGA compatible controller.
>
> Which of these should I use for coreboot VGA device PCI ID?
>
> --
> coreboot mailing list: coreboot@coreboot.org
> https://mail.coreboot.org/mailman/listinfo/coreboot

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

[coreboot] GPIO PADRSTCFG conflict in datasheet

[Youness Alaoui]

Hi,

I'm working on a skylake port and I've noticed something with the PADRSTCFG
field of the GPIO Pad configuration. If you look at the 100-series
datasheet volume 2 (
https://www-ssl.intel.com/content/www/us/en/chipsets/100-series-chipset-datasheet-vol-2.html).
The Pad configuration DW0 for GPP_A, GPP_B, GPP_C, etc.. (page 1179, 1249)
up to GPP_I (page 1319) has bits 31:30 (PADRSTCFG) defined like this :
00 = RSMRST#
01 = Host deep reset.
10 = PLTRST#
11 = Reserved

But the Pad configuration DW0 for GPD pads (page 1296) has it defined like
this :
00 = DSW_PWROK
01 = Host deep reset.
10 = PLTRST#
11 = RSMRST#

The problem here is that while the DEEP and PLTRST values are the same, the
RSMRST value is 0 for GPP gpio pads, and 3 for GPD gpio pads. In the
skylake and apollolake gpio_defs.h file, it is defined like this (with
different naming for apollolake but same values) :
#define  PADRSTCFG_DSW_PWROK 0
#define  PADRSTCFG_DEEP 1
#define  PADRSTCFG_PLTRST 2
#define  PADRSTCFG_RSMRST 3

These defines are only valid for GPD pads, if someone was to use a RSMRST
reset config on a GPP pad, they would be setting the pad to a 'reserved'
configuration, which could have unexpected behavior.
There are two possibilities here, either the datasheet is wrong (and PWROK
should be 3 so the RSMRST value is consistent for both GPP and GPD), or the
datasheet is correct, and in both cases, the value in coreboot is wrong.

If someone from Intel is reading this list, or if someone here knows
someone inside Intel who could confirm whether or not the datasheet has an
error, that would be great.
In the meantime, I would maybe suggest to change the defines to  :
#define PADRSTCFG_GPD_RSMRST3
#define PADRSTCFG_GPP_RSMRST0

This would affect both skylake and apollolake, and note that the only
skylake+ boards that use RSMRST seem to be the kblrvp in the rvp7 variant
which sets it for GPP_A12 and GPP_E3 (which means those two gpios have the
wrong setting due to the wrong define).

What do you think ?

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

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

[Youness Alaoui]

Thanks Peter, well said! I enjoyed that little graphic too :)
@Taiidan, I hadn't thought of PAVP, but the idea is to remove/neutralize
the ME entirely, not to intercept its messages.  If we take control of the
ME, we'll probably just call 'halt' to make sure that core is disabled. I
don't see how that affects the DMCA.
Either way, the DMCA exception is still there for our purposes, even if
that wasn't what we were doing.
As for your FX-2 idea, I already explained my thoughts on that.

@Nico, Thanks for a civil and interesting response, I'll reply inline to
your comments below, but a disclaimer, the things I'm saying below are my
own opinions and interpretations on things, and a lot of it is based on
things I've heard. The accuracy of what I heard, which is often a second
hand account of events, may not be 100%, so keep that in mind.

On Wed, May 3, 2017 at 3:45 PM, Nico Huber <nic...@gmx.de> wrote:

> On 03.05.2017 01:39, Youness Alaoui wrote:
> > to answer Nico's other post:
> > I'm quite surprised and disappointed by your answer. You have every right
> > to say that you are disappointed or distrusting Purism due to past
> actions,
> > but I find it harsh for you to be repeatedly saying "fraud" and "scammed"
> > when that is not the case at all. I think Ron has responded quite well to
> > that and said exactly what I wanted to say, there is a difference between
> > being naive and underestimating the task, vs actively "trying to scam
> > people". If they were scamming people, they wouldn't have shipped any
> > product and they wouldn't have reimbursed those who changed their mind or
> > were unsatisfied with what they got, and actually, I wouldn't even have
> > been contracted in the first place.
>
> Finally! I was hoping for some statement like this. I didn't know about
> any reimbursement taking place. See, what was publicly visible was some
> drawing of customers away from free firmware supporting vendors. Amend-
> ments were not publicly visible, FWIW. OTOH, the way you wrote it im-
> plies that only those who complained got a refund, or was the reimburse-
> ment an explicit offer?
>

Yes, there were reimbursements. How the reimbursements have taken place, I
don't know, but I know that some got refunds, some got upgrades,
downgrades, sidegrades, etc.. depending on what the customer wanted. I know
that Purism has been struggling for a bit (one of the reasons most of the
employees are volunteers) as it was lacking funds (hence the recent
kickfurther for the v2 stock). Customers who had the highest requirements
and expectations for the touchpad requested reimbursements and got them.
The original campaign promised a great touchpad experience, unfortunately
the touchpads of the first batches of laptops (before the one currently
being made) did have limitations. While those touchpads do work, they're
not the ultimate user experience, and Purism hasn't had the time and
resources to work on fixing that driver (I was originally going to reverse
engineer the BYD driver, but instead I was thrown into working on
coreboot).
I don't have any other details on how it happened, it it was an explicit
offer, if there are conditions, etc.. If you're curious, you can drop in
#purism and ask your questions, I'm sure there are people more
knowledgeable than me that can answer you.


> > Attributing to malice what was the result of honest mistakes, while you
> > know how complex this is both on the software and hardware side, is why
> > your tone was disappointing. Careless name-calling leads to people
> getting
> > hurt and flame wars and all that.
>
> Carelessly promising free software (that is impossible to deliver) with
> the name of free projects on it... I think that was a huge offense to
> many developers. Don't you think that hurt people too? So don't tell me
> I started this.
>
>

I never said you started anything, and yes, using some FOSS project's
reputation to boost your own by association when there really wasn't any
contribution is cause for anger and disappointment, I never said otherwise
either. The only thing that I said is that there's a difference between
being naive and making unintentional mistakes versus being a scammer and
intentionally misleading people. Eventually people have to forgive past
mistakes, especially if they were unintentional and efforts are made to
move things in the right direction (which it is now afaik). I agree with
you though that past mistakes have to be owned up by those who made them,
and apologies should be made. You (and everyone else) doesn't owe Purism
anything, so you don't have to accept their excuses either, but it's just
better when everyone is on good terms I think.
Like I told you in my first email, you have every right to be disappointed
and mistrusting of Purism due to their past mis

Re: [coreboot] Will we maintain Skylake/FSP1.1?

[Youness Alaoui]

I thought FSP 1.1 was for skylake and FSP 2.0 for Kabylake, I didn't
realize 2.0 would be compatible with skylake too. Does this mean a skylake
port could use fsp 1.1 or 2.0 ? In that case, is the 2.0 version better
maintained, more stable, easier to integrate, etc.. or are both 1.1 and 2.0
implementations equivalent at this point?
I also don't see the 2.0 release in https://github.com/IntelFsp/FSP/ so I
assume getting my hands on it would mean grabbing it from somewhere else

Thanks,
Youness.

On Tue, May 9, 2017 at 11:19 AM, Aaron Durbin  wrote:

> On Tue, May 9, 2017 at 10:14 AM, Nico Huber 
> wrote:
> > Hi,
> >
> > I was walking through the Skylake FSP1.1 support in coreboot and asked
> > myself if it is worth to clean it up and maintain the code? given that
> > the upcoming release of Kabylake FSP should be able to supersede it (I
> > presume it is?). Are there any plans yet to drop it once the next FSP
> > is released? (when will that be anyway?)
>
> I wanted to get rid of it, but Intel claimed they had customers using it
> still.
>
> >
> > Btw. does anybody feel like a maintainer for soc/intel/skylake/?
>
> Personally feel? Or want?
>
> >
> > In it's current state it's very hard to use from a mainboard porter's
> > point of view. Many of the selectable Kconfig settings are useless
> > (either don't compile or don't run) for FSP1.1, and there's a `struct
> > pei_data` [1] that seems to be a remnant of compatibility for a dif-
> > ferent blob ;)
>
> That's just an old remnant of passing data around. It could be removed
> as you annotated isolating those pieces to different structs and/or
> variables for passing data around. The name is obviously not
> applicable w.r.t. its current use.
>
> >
> > Best regards,
> > Nico
> >
> > PS. Microcode updates are also missing in the upstream blobs repo. Is
> > that a licensing problem? If I try to download them from Intel, it
> > asks me to click to accept that I'll prevent further distribution.
> > I could prepare a patch to add them but somebody else would have
> > to sign it off.
> >
> > [1] https://review.coreboot.org/#/c/19638/
> >
>
-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

[coreboot] PCIe Role-based error reporting

[Youness Alaoui]

Hi,

I'm looking at the src/device/pciexp_device.c file trying to understand
what it does and I've noticed this in pciexp_enable_aspm :
/* Enable ASPM role based error reporting. */
devcap = pci_read_config32(endp, endp_cap + PCI_EXP_DEVCAP);
devcap |= PCI_EXP_DEVCAP_RBER;
pci_write_config32(endp, endp_cap + PCI_EXP_DEVCAP, devcap);

This looks like it tries to write a bit to 1 to enable Role-based
error-reporting in the DEVCAP (offset 0x04) in the PCIe capability, but
according to the spec (looking at page 612 of the spec version 3.0 that I
found here  :
http://composter.com.ua/documents/PCI_Express_Base_Specification_Revision_3.0.pdf),
that structure is read-only (it's the device capabilities register, not the
device control register).
Is that an error ?
I tracked that code (moved, then moved again) all the way to this change
from 2011 : https://review.coreboot.org/#/c/735/ but for some reason git
blame can't find the file in commits before that.

That code is probably harmless since it's a Read-only field anyways, but
I'm wondering if the code that should be there shouldn't instead be
enabling the bits 0:3 in the device control register to enable the error
reporting. Also, I don't see how this actually relates to ASPM (it only
gets called if ASPM is enabled).

Does anyone know if I'm on the right track in my interpretation or if I
misunderstood the spec or what that code is meant to do ?

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

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

[Youness Alaoui]

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

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

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

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

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


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

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

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

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

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

[Youness Alaoui]

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

> On 05/01/2017 06:44 PM, ron minnich wrote:
>
> On Mon, May 1, 2017 at 1:17 PM Rene Shuster 
>> wrote:
>>
>> Yes Puri.sm has been debunked.
>>>
>>> I disagree. I've seen the systems. From what I can see, Puri.sm has made
>> a
>> good faith effort to go as far possible *with modern x86 chipsets* toward
>> getting rid of the blobs. They can't get to 100%, but they're trying to
>> get
>> as close as possible.
>>
>> ron
>>
> Name one thing that they have done themselves?
>
> https://www.reddit.com/r/linux/comments/3anjgm/on_the_librem
> _laptop_purism_doesnt_believe_in/ (yeah its leah but shes right about the
> coreboot community being corrupted)
>
> Everything they "do" is someone elses code, and their "coreboot" has zero
> actual init code it is entirely blobbed.
>
> Their marketing is the only thing that is good.
>
>
> --
> coreboot mailing list: coreboot@coreboot.org
> https://mail.coreboot.org/mailman/listinfo/coreboot
>

Without entering into a flamewar, you're asking "name one thing that they
have done themselves" and I will answer that.
Full disclaimer: I am working for Purism, and I have been a paid contractor
working since last December (part time initially, full time since March) on
bringing coreboot and the ME-disablement effort to the Librem line of
laptops (more precisely Librem 13 v1, and now working on the Librem 13 v2
hardware which is set to be released/shipped next month).

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

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

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

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

For actual ME-related work that wasn't done by someone else, I will point
you to this file :
https://github.com/kakaroto/purism-playground/blob/master/me_re/romp.c
That is a full C re-implementation of the ROMP module (the smallest of the
two modules that me_cleaner does not remove).
This is the RAPI header it uses :
https://github.com/kakaroto/purism-playground/blob/master/me_re/rapi.h
That code is a C reimplementation with every instruction accounted for. It
has not been compiled (it serves more as a proof of concept/pseudocode,
although it should probably compile), and it's not meant to generate a
binary-compatible file (that could be a long term goal to generate binary
compatible images from C source with official intel-provided images).
Note that I have done the entire Assembly->C conversion myself, but I do
want to give credit to Igor Skochinsky for his help (which saved me
weeks/months of work) as he shared his notes of his ME reverse engineering
efforts (memory 

Re: [coreboot] Intel ME The Way of the Static Analysis

[Youness Alaoui]

Thanks for the links.
This is the article that I had seen :
http://blog.ptsecurity.com/2017/04/intel-me-way-of-static-analysis.html


On Tue, Apr 25, 2017 at 10:38 AM, Shawn  wrote:

> slide:
> https://www.troopers.de/downloads/troopers17/TR17_ME11_Static.pdf
>
> video:
> https://www.youtube.com/watch?v=2_aokrfcoUk
>
> --
> coreboot mailing list: coreboot@coreboot.org
> https://mail.coreboot.org/mailman/listinfo/coreboot
>
-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] [VERY IMPORTANT] Announcement regarding Apollo Lake Coreboot building

[Youness Alaoui]

Zoran,

The blog post is not meant to be documentation, it's just a progress report
and a *blog post* about the experience and I'm sure it's much less
confusing than your emails have been so far.
in menuconfig, in the Chipset section, there's "Add Intel descriptor.bin
file" (which is what you had enabled, causing the build to fail) and under
it, there is "Path and filename of the descriptor.bin file", you set it
there.
You'll also probably need to extract and include the ME region as well, and
clone the blobs repository for the microcode updates to be generated from
tree.
Apart from that, I suggest you be careful with what you're doing to avoid
bricking your device, learn what you can about the process, read
documentation and even read the code if you need to. Randomly thinking that
there's a "very important announcement" because you didn't understand how
to compile coreboot (and then refusing to give your config and telling
developers to look into this 'bug' without giving any more information) is
not really the way to incite people to help you.

Good luck
Youness.

On Thu, Feb 23, 2017 at 10:29 AM, Zoran Stojsavljevic <
zoran.stojsavlje...@gmail.com> wrote:

> Hello Youness (and others),
>
> Here, I need to apologize to all Coreboot recipients. Since it was a
> while, I did peak into that. But... It is NOT You(ness). You got my
> attention, and, since you blog is very confusing (lack of  some systematic
> knowledge) about INTEL BSP Technology.
>
> I really admire your effort. And just because of that I (after some 6+
> hours of investigation) I'll try to strengthen out your logs, which are, I
> should say, puzzled, scrambled all over place. Pieces of Truth are there,
> and you got on the right path. Although... Labyrinth (unsorted kludges and
> facts) for most of folks.
>
> *I did NOT expect that ... will make out of this Rocket Science.* And
> yes, they did make it??? Why, that is the question? ;-)
>
> I got it. Not quite up to ground level (I need to understand more about
> make menuconfig setup). But in order to make (example) 8MB Coreboot, you
> need to take the TRUE APL-I BIOS and to apply IFD tool, in order to extract
> first 4K (4096) File Descriptor. And SBIOS part as well. Not sure how many
> parts should be extracted?!
>
> Here is what GOOGLE designers posted for Emerald Lake 2, in 3rdparty:
>
> [user@localhost emeraldlake2]$ ls -al
> total 2120
> drwxrwxr-x. 2 user user4096 Feb 18 01:57 .
> drwxrwxr-x. 3 user user4096 Feb 18 01:57 ..
> -rw-rw-r--. 1 user user   4096 Feb 18 01:57 descriptor.bin
> -rw-rw-r--. 1 user user   2093056 Feb 18 01:57 me.bin
> -rw-rw-r--. 1 user user   65536 Feb 18 01:57 snm_2120.dat
> [user@localhost emeraldlake2]$ pwd
> /home/intel/projects/coreboot/coreboot/3rdparty/blobs/mainbo
> ard/intel/emeraldlake2
> [user@localhost emeraldlake2]$
>
> And, for descriptor.bin, there is the following:
>
> [image: Inline image 1]
>
> This (location 0x0010) I have checked with many BIOSes found on the
> open net, . Most, but I did not find any instance of Apollo Lake, to build
> proper Coreboot.com.
>
> So, I need to extract at least SBIOS and descriptor.bin from real (UEFI)
> BIOS, and put, where?
>
> And then, to add to the Coreboot image. Using make menuconfig. Where and
> how?
>
> (Courtesy Aaron Durbin): http://elinux.org/Minnowboard:MinnowMaxCoreboot#
> TXE_and_SPI_descriptor
>
> Thank you all,
> Zoran
>
> On Thu, Feb 23, 2017 at 12:30 AM, Youness Alaoui <
> kakar...@kakaroto.homelinux.net> wrote:
>
>> Zoran, read this : https://puri.sm/posts/librem
>> -13-coreboot-report-january-12-2017/
>> It might help you understand what that IFD and 0x5aa5f00f is (little
>> endian makes it 0x0FF0A55A)
>> I had the same confusion when I started, and when I figured things out, I
>> wrote that blog post that explained the process.
>>
>>
>> On Wed, Feb 22, 2017 at 11:51 AM, Zoran Stojsavljevic <
>> zoran.stojsavlje...@gmail.com> wrote:
>>
>>> So, the final word here: In building of INTEL skus' Coreboot INTEL FIT
>>> tool (under NDA) is A MUST/mandatory, and INTEL is the road block if you
>>> are not working with them (having the NDA signed with them)?
>>>
>>> What about the concept of an Open Source??? ;-)
>>>
>>> I am at this point very confused... Really, I am. I did NOT find
>>> anywhere in any document that for Coreboot building INTEL FIT is
>>> mandatory???
>>>
>>> Thank you,
>>> Zoran
>>>
>>> On Wed, Feb 22, 2017 at 5:40 PM, Aaron Durbin <adur...@google.com>
>>> wrote:
>>>
>>>> On Wed, Feb 22, 2017 at 10:18 AM, Zoran Sto

Re: [coreboot] [VERY IMPORTANT] Announcement regarding Apollo Lake Coreboot building

[Youness Alaoui]

Zoran, read this :
https://puri.sm/posts/librem-13-coreboot-report-january-12-2017/
It might help you understand what that IFD and 0x5aa5f00f is (little endian
makes it 0x0FF0A55A)
I had the same confusion when I started, and when I figured things out, I
wrote that blog post that explained the process.


On Wed, Feb 22, 2017 at 11:51 AM, Zoran Stojsavljevic <
zoran.stojsavlje...@gmail.com> wrote:

> So, the final word here: In building of INTEL skus' Coreboot INTEL FIT
> tool (under NDA) is A MUST/mandatory, and INTEL is the road block if you
> are not working with them (having the NDA signed with them)?
>
> What about the concept of an Open Source??? ;-)
>
> I am at this point very confused... Really, I am. I did NOT find anywhere
> in any document that for Coreboot building INTEL FIT is mandatory???
>
> Thank you,
> Zoran
>
> On Wed, Feb 22, 2017 at 5:40 PM, Aaron Durbin  wrote:
>
>> On Wed, Feb 22, 2017 at 10:18 AM, Zoran Stojsavljevic
>>  wrote:
>> > Aaron,
>> >
>> > Not that I am trying to be pest/bad guy. Please, believe me on this.
>> Just
>> > about the simple logic, which SHOULD NOT be deniable!
>> >
>> > I did what I know about Coreboot, hands on, from 3.3 years ago. Then, I
>> > built the VERY first Emerald Lake 2 (CCG CRB) -> Cougar Canyon 2 CRB as
>> > payload SeaBIOS, and WIN 8.0 32bit. I was really amazed. Then.
>> >
>> > And I read much more these days, and a bit emailed with Martin
>> (forth/back),
>> > so Martin can give me a jump start. And then I read more. And more. And
>> for
>> > 5 full days I was doing this exercise (with lot of pain).
>> >
>> > So, I'll quote you:
>> >
>> >> That file is the FSP blob. Nothing more. As Nico pointed out that is
>> >> something completely different from the flash descriptor. The flash
>> >> descriptor can be obtained from the original released BIOS or you have
>> >> to generate it using Intel's FIT tool.
>> >
>> > Please, guide me through this process. Or point to some documents about
>> this
>> > process I can read about?
>>
>> IIRC, FIT is provided by Intel to its customers under NDA. You'll have
>> to contact your Intel rep for that. It's quite the barrier to entry
>> for using these devices, but that's a policy decision from Intel.
>>
>> Or you can take a previously released bios for this board and do
>> similar as the instructions on the Minnow Max page:
>> http://elinux.org/Minnowboard:MinnowMaxCoreboot#TXE_and_SPI_descriptor
>>
>> Note, TXE/CSE on apollolake does not have its own region in the flash.
>> It's in something intel calls IFWI and has its own new format that
>> lives in the "BIOS" region. There's a tool (util/cbfstool/ifwitool.c)
>> which takes an existing image with the IFWI and makes it work with
>> coreboot's implementation/support for apollolake.
>>
>> >
>> > Thank you,
>> > Zoran
>> >
>> > On Wed, Feb 22, 2017 at 5:05 PM, Aaron Durbin 
>> wrote:
>> >>
>> >> On Wed, Feb 22, 2017 at 10:01 AM, Zoran Stojsavljevic
>> >>  wrote:
>> >> > I can admit my errors:
>> >> >
>> >> > This is what I have:
>> >> >
>> >> > user@localhost FspBin]$ pwd
>> >> >
>> >> > /home/user/projects/coreboot/coreboot/APL-I_FSP/ApolloLakeFs
>> pBinPkg/FspBin
>> >> > [user@localhost FspBin]$ ls -al
>> >> > total 672
>> >> > drwxr-xr-x. 2 user user   4096 Feb 11 12:19 .
>> >> > drwxr-xr-x. 6 user user   4096 Feb 11 12:19 ..
>> >> > -rw-r--r--. 1 user user 136832 Feb 11 12:19 ApolloLakeFsp.bsf
>> >> > -rw-r--r--. 1 user user 540672 Feb 11 12:19 ApolloLakeFsp.fd
>> >> > [user@localhost FspBin]$
>> >> >
>> >> > I use one in RED.
>> >> >
>> >> > Need the clarification. Please, do it for me.
>> >>
>> >> That file is the FSP blob. Nothing more. As Nico pointed out that is
>> >> something completely different from the flash descriptor. The flash
>> >> descriptor can be obtained from the original released BIOS or you have
>> >> to generate it using Intel's FIT tool.
>> >>
>> >> >
>> >> > Zoran
>> >> >
>> >> > On Wed, Feb 22, 2017 at 4:56 PM, Nico Huber 
>> >> > wrote:
>> >> >>
>> >> >> On 22.02.2017 08:12, Zoran Stojsavljevic wrote:
>> >> >> > Hello to community,
>> >> >> >
>> >> >> > I finally, after 3 days of additional very hard struggle, found
>> out
>> >> >> > why
>> >> >> > I
>> >> >> > have (while I am in the last stage of building CBFS) nonsense
>> while
>> >> >> > building APL-I Coreboot coreboot.rom?!
>> >> >> >
>> >> >> > Please, read carefully this announcement.
>> >> >> >
>> >> >> > For last three days I came to hard stop because of this failure:
>> >> >> >
>> >> >> > Just quick look into the final failure (all passed, but last
>> stage -
>> >> >> > IFD
>> >> >> > failed):
>> >> >> >
>> >> >> > Compile IFDTOOL
>> >> >> > HOSTCC util/ifdfake/ifdfake
>> >> >> > DD Adding Intel Firmware Descriptor
>> >> >> > IFDTOOLUnlocking Management Engine
>> >> >> > File build/coreboot.pre is 8388608 bytes
>> >> >> >