Here's what I know about PSP:
> I'm utterly ignorant of the PSP -- is this thing like the Intel ME, and
how scared should we be of it?
The PSP is an actual processor that takes control when reset is released.
The x86 does not start fetching code until the PSP is satisfied that BIOS
meets whatever constraints have been programmed into the PSP firmware.
There are TPM-like characteristics but I don't know any specifics.
The PSP is capable of "locking" additional processor features that could
be exploited to take over a system.
> My hope is that it ... deactivates itself silently.
For the coreboot implementation, it runs, decides that the x86 code is not
its concern, and the x86 starts fetching code. From that point on, I
think the PSP is transparent to the x86.
> After glancing thru [the PSP presentation], it looks more like they are
> grafting the security model of ARM-based SoCs onto x86 where a masked
> ROM loads the next stage.
A masked processor and associated firmware (the PSP) validate the first
"stage" of x86 code. What comprises the first stage is arbitrary and gets
signed with an AMD private key. Your first stage could be bootblock,
bootblock plus romstage, something more involved, or something less
involved. You need a legal arrangement with AMD to get your first stage
signed. For coreboot, none of the x86 code is signed.
> So we can kiss goodbye coreboot on AMD platforms in the future?.. How
That isn't true for the first processor with PSP. Coreboot support for
"Steppe Eagle" is already posted to Gerrit. Steppe Eagle is the AMD
Embedded variant of Mullins. The Olive Hill+ platform demonstrates
building a coreboot ROM without requiring that AMD sign any part of the
coreboot code. I expect to have the final version of support posted by
the end of the week. Give me some +2's and we could have PSP support
available next week! ;-)
> Does this thing ... exist in any AMD CPUs buyable today?
The processors are released as AMD Beema (A6-6310, A4-6210,
E2-6110,E1-6010), AMD Mullins (A10 micro-6700T, A4 micro-6400T, E1
Micro-6200T), and AMD Steppe Eagle processors. AMD has developed
reference boards similar to what was developed for AMD Kabini SoCs. I
have not seen any retail "bare-bones" motherboards, but maybe there are
low-end notebooks and desktops that use Mullins/Beema (perhaps Acer Aspire
Has anybody tested reset signal (PMU_RESETBUTTON_B) on Rangeley/Avoton? The
board seems to shut down after asserting the signal (pushing the reset
button). I turn on an LED in early_mainboard_romstage_entry(). The LED was
not on indicating the function was not executed. Below is what printed out
on console after reset:
coreboot-0f49404 Tue Aug 26 15:28:40 EDT 2014 starting...
Setting up static southbridge registers... done.
Disabling Watchdog timer... done.
Starting the Intel FSP (early_init)
Configure Default UPD Data
find_current_mrc_cache_local: No valid fast boot cache found.
FSP MRC cache not present.
For cold boot, it will continue to spit out boot messages.
-- Wen Wang
On 26.08.2014 17:53, Charles Devereaux wrote:
> My understanding is that the OS does the call that correctly, but that
> coreboot ASL tables only expect one argument.
Please provide a refrence when doing such bold claims. LED method is not
specified in ACPI, so assuming that it takes any particular arguments is
wrong from OS side.
Dear Charles, dear David,
Am Montag, den 25.08.2014, 11:21 -0600 schrieb David Hubbard:
> I'm focusing in on this error message first:
> ACPI Warning: For \_SB_.PCI0.LPCB.EC__.LED_: Excess arguments - needs 1,
> found 2
> Can you take a look at the .asl files in your coreboot build? I believe you
> will find something like "Method (LED, 2, NotSerialized)" which means the
> LED method wants 2 arguments. Then look for calls to "LED ()" and if you
> find one only passing 1 argument, that is the problem.
I also noticed that message and quickly looked through the coreboot ASL
files, but could not find anything calling that message. Looking at the
Linux kernel sources I was also unable to find a call site. But I’d say
the OS call this method incorrectly.
<TROLL> So we can kiss goodbye coreboot on AMD platforms in the future?.. How sad! :-/ </TROLL>
Does this thing "Platform Security Processor" exist in any AMD CPUs buyable today (Q3 2014) or it will begin to be implemented later?
Thank you for this information!
----- Mail d'origine -----
De: ron minnich <rminnich(a)gmail.com>
À: David Hendricks <dhendrix(a)google.com>
Cc: Coreboot <coreboot(a)coreboot.org>
Envoyé: Mon, 25 Aug 2014 22:33:25 +0200 (CEST)
Objet: Re: [coreboot] AMD PSP
On Mon, Aug 25, 2014 at 1:24 PM, David Hendricks <dhendrix(a)google.com> wrote:
> After glancing thru this PSP (Platitude Spewing Presentation), it looks more
> like they are grafting the security model of ARM-based SoCs onto x86 where a
> masked ROM loads the next stage.
> A couple kind of nice things they mention:
> - "Isolated on-chip ROM and SRAM" - So this may be somewhat more constrained
> than the multi-megabyte blobs for MEs?
> - "Secure Boot does not require the system ROM image to be signed"
> Not so nice: "Access to system memory / resources". Ugh.
well, we all know how well that's worked fro the ME.
so, another insecure x86 platform. Great.
coreboot mailing list: coreboot(a)coreboot.org
Am Montag, den 25.08.2014, 15:24 -0700 schrieb ron minnich:
> On Mon, Aug 25, 2014 at 3:21 PM, Paul Menzel wrote:
> > Another approach would be to do it like the Chromium OS folks do it on
> > the Google Chromebooks. In normal mode they do not initalize the graphic
> > device (just place the Video BIOS/VGA Option ROM for VBT information),
> > so you cannot see GRUB, and let just Linux initialize the graphics. Then
> > they have a developer mode and only in this mode coreboot does graphics
> > initialization.
> That's actually slower than having coreboot do native graphics init.
> That's why we did the coreboot graphics work in the first place.
Sorry for getting that wrong and thank you for the clarification. Could
you please elaborate about the difference between normal and developer
mode regarding graphics setup?
Am Sonntag, den 24.08.2014, 23:25 -0400 schrieb Charles Devereaux:
> I'm still trying to improve boot time.
nice. Thank you for keeping us in the loop.
> After some further optimizations (previous results : 2.2s for the kernel,
> 0.6s for the daemons),
1. So what are your coreboot numbers? (Also what `.config` and what
payload (with `.config`) do you use?)
2. What hardware do you use? Especially what SSD?
3. Do you use the default Linux kernel shipped with Debian?
4. Which Debian release do you use?
5. Which init system do you use?
> I believe it should be possible to get a command line in less than 2
> seconds, since most of the time is spend re-initializing the video
> chip (almost a full second) while there are some features to prevent
> just that.
That sounds indeed possible. How do you measure the timings?
> It seems that coreboot is spending some time initializing the video chip
> for grub, then linux spends some time again - even when grub option "set
> gfxpayload=keep" is set (which should prevent that) and when coreboot is
> compiled with CONFIG_FRAMEBUFFER_KEEP_VESA_MODE
> in kernel 3.10.45 :
> [ 0.291014] [drm] GMBUS [i915 gmbus panel] timed out, falling back to bit banging on pin 3
> [ 0.321926] [drm] initialized overlay support
> [ 0.384013] [drm] GMBUS [i915 gmbus vga] timed out, falling back to bit banging on pin 2
> [ 0.570068] fbcon: inteldrmfb (fb0) is primary device
> [ 1.230010] Console: switching to colour frame buffer device 128x48
> [ 1.258981] i915 0000:00:02.0: fb0: inteldrmfb frame buffer device
> [ 1.258984] i915 0000:00:02.0: registered panic notifier
> [ 1.258992] [drm] Initialized i915 1.6.0 20080730 for 0000:00:02.0 on minor 0
> I'm currently trying a recent kernel since some i915 patches have been
> backported (cf http://blog.ffwll.ch/2014/04/neat-drmi915-stuff-for-315.html),
> introducing the i915.fastboot option to do just that, but it does not help.
> I must be doing something terribly wrong, but I just don't realize what
> Has anyone succeeded in keeping the vesa mode?
Sorry, I have not played with this. But I think the way to go is to
contact the Linux Intel graphics folks. Best is to submit a bug report.
Let’s hope to get that fixed for Debian Jessie, which is going to be
frozen in November .
Another approach would be to do it like the Chromium OS folks do it on
the Google Chromebooks. In normal mode they do not initalize the graphic
device (just place the Video BIOS/VGA Option ROM for VBT information),
so you cannot see GRUB, and let just Linux initialize the graphics. Then
they have a developer mode and only in this mode coreboot does graphics
As these are smart people and they probably did a lot of testing, that
might be the only viable solution if you want to have quick boot times.
Though I have no idea why they did not go the `gfxpayload=keep` route.
-----BEGIN PGP SIGNED MESSAGE-----
On 25/08/14 04:25, Charles Devereaux wrote:
> I'm still trying to improve boot time.
> After some further optimizations (previous results : 2.2s for the
> kernel, 0.6s for the daemons), I believe it should be possible to
> get a command line in less than 2 seconds, since most of the time
> is spend re-initializing the video chip (almost a full second)
> while there are some features to prevent just that.
> It seems that coreboot is spending some time initializing the video
> chip for grub, then linux spends some time again - even when grub
> option "set gfxpayload=keep" is set (which should prevent that) and
> when coreboot is compiled with CONFIG_FRAMEBUFFER_KEEP_VESA_MODE
> in kernel 3.10.45 : [ 0.291014] [drm] GMBUS [i915 gmbus panel]
> timed out, falling back to bit ban ging on pin 3 [ 0.321926]
> [drm] initialized overlay support [ 0.384013] [drm] GMBUS [i915
> gmbus vga] timed out, falling back to bit bangi ng on pin 2 [
> 0.570068] fbcon: inteldrmfb (fb0) is primary device [ 1.230010]
> Console: switching to colour frame buffer device 128x48 [
> 1.258981] i915 0000:00:02.0: fb0: inteldrmfb frame buffer device [
> 1.258984] i915 0000:00:02.0: registered panic notifier [
> 1.258992] [drm] Initialized i915 1.6.0 20080730 for 0000:00:02.0
> on minor 0
> I'm currently trying a recent kernel since some i915 patches have
> been backported (cf
> introducing the i915.fastboot option to do just that, but it does
> not help.
> I must be doing something terribly wrong, but I just don't realize
> what exactly.
> Has anyone succeeded in keeping the vesa mode?
Do you get those same errors in 3.10.45 when booting factory bios or
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
-----END PGP SIGNATURE-----
On 25.08.2014 23:28, ron minnich wrote:
> A friend asks me how to disable the usb stack in his bios. I have no
> clue, anyone?
Doesn't sound like end goal. But I'd go through setup menu to see if
something fits his *end* goal (disabling usb stack sounds like means to
goal, not the goal itself).