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
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.drwho8(a)gmail.com
"This signature fought the Time Wars, time and again."
you can be as much biased as you want, and you can express that here. I
have no trouble with that. What I don't like is your choice of words.
For instance with "Undoubtedly, Intel ME is a backdoor," you imply to
know everybody's opinion on the matter. Because I don't think you are
the creator himself, this draws a big WTF? into my brain.
You can say "In my opinion, Intel ME is a backdoor, ..." but you can't
say it's undoubted. I don't only doubt that, IMHO, it is a frontdoor.
You also claim that things are well studied which are not. A replay of
a proprietary program might be open-source technically, but it doesn't
mean that anybody has a clue how it works.
So please, if you want to express your *personal* opinion or "knowledge"
please always state so. And don't make it look like the general under-
standing (especially not when experts disagree).
As far as I am concerned, this is expected behavior.
The longer first boot time is due to the RAM training process, which is
needed because the MRC cache (training data) is empty. Once it has been
cached, if the RAM configuration does not change on subsequent boots, the
MRC cache is reused, which is faster than retraining. If you dump a flash
image, then rewrite it, the end result is that the flash contents have not
changed. This implies the MRC cache remains unchanged as well. Since the
RAM configuration did not change, the MRC cache is still valid thus it is
Regarding the extraction of said data, I believe it could be done, but I
would not recommend it. Since this data is specific for a system,
generating it anew sounds more reasonable than reusing it.
> This Email may contain confidential or privileged information for the
intended recipient (s). If you are not the intended recipient, please do
not use or disseminate the information, notify the sender and delete it
from your system.
This footer makes absolutely no sense when you address a mailing list.
be surprised if you get less answers because of it.
For a security boundary, the question is "what can an OS potentially
do", not "what do we expect it to do".
Modification of the APIC_ID register is model specific, but prohibited
by the x2APIC spec. I presume that the SMM entry straps disambiguate by
the initial APIC ID, which is fixed, but I don't know for sure.
Since sending this email, I've come to the conclusion that deriving the
stack from the entry strap is probably a safer option than trying to
use/parse/modify the APIC.
As for x2APIC, any system with >254 cpus needs x2APIC (and Interrupt
Remapping) for the OS to be able to perform symmetric interrupt
handling, but OSes will turn it on if available, because it has a better
programming model (no waiting on status bits), and is easier to virtualise.
On 28/08/18 19:37, Lance Zhao wrote:
> Without x2apic mode, APIC_ID register will not be moved by OS. Those
> address normally had been tagged as reserved and will not be touched.
> I believe that x2apic will apply for processors number more than 255,
> so majority cases in coreboot didn't touch that area yet.
> On Tue, Aug 28, 2018 at 7:50 AM Andrew Cooper
> <andrew.cooper3(a)citrix.com <mailto:firstname.lastname@example.org>> wrote:
> While looking at some code, I noticed that twice (once in asm, and
> later in C), the SMM handler assumes that 0xfee00020 is the APIC_ID
> reigster in the xAPIC MMIO window.
> This isn't true if the OS has moved the MMIO window, or switched to
> x2apic mode (on supporting hardware).
> As a result, it looks like its rather easy to feed a kernel-controlled
> value into Coreboot's idea of its Local APIC id, which can either
> be the
> same on all cores (reuse of the same stack) or wildly out of range
> (albeit, at least bounded to 255).
> To fix, I'd expect Coreboot to read MSR_APIC_BASE, and either cope
> x2apic mode (which is surely easier than switching APIC mode, as
> got to cycle through off to switch back to xAPIC mode), or
> save/remap/restore the APIC MMIO window.
> Without paging, you can't address an APIC MMIO window above the 4G
> Is this something you care about?
> coreboot mailing list: coreboot(a)coreboot.org
While looking at some code, I noticed that twice (once in asm, and again
later in C), the SMM handler assumes that 0xfee00020 is the APIC_ID
reigster in the xAPIC MMIO window.
This isn't true if the OS has moved the MMIO window, or switched to
x2apic mode (on supporting hardware).
As a result, it looks like its rather easy to feed a kernel-controlled
value into Coreboot's idea of its Local APIC id, which can either be the
same on all cores (reuse of the same stack) or wildly out of range
(albeit, at least bounded to 255).
To fix, I'd expect Coreboot to read MSR_APIC_BASE, and either cope with
x2apic mode (which is surely easier than switching APIC mode, as you've
got to cycle through off to switch back to xAPIC mode), or
save/remap/restore the APIC MMIO window.
Without paging, you can't address an APIC MMIO window above the 4G boundary.
Is this something you care about?
> I doubt those guys have the skill to do so but for those who do - you'd
> spend tens of thousands in order to have a port for an old machine that
> still is stuck with ME and hardware init done entirely by binary blobs.
It is not about the skill or money involved in the process, it is about the
*possibility* of even running coreboot on said machine, which is most
> I would save your money and instead buy an ivy/sandybridge thinkpad (can
> nerf the ME - but not disable which is impossible)
AFAIK, you can still run me_cleaner on a Broadwell laptop. I don't think the
ME is the main reason to get a XX20/XX30 Thinkpad over newer models.
> microcode - is optional
I assume you refer to microcode *updates*, not the microcode that is
hard-coded inside the CPU. Still, I fail to understand why there is so much
worry about microcode updates, as if they were going to open a backdoor
of some sorts. To me, the only gain of not updating the microcode is in the
number of bugs.
I do understand temporarily delaying the updates of known unstable
microcode versions while awaiting for a fix, though.
> as far as I know its impossible to completely replace ME, only to trim
> its' firmware as much as possible and hope for the best that it
> doesn't have some undocumented "backdoor restore" mechanism that could
> restore the original uncut blob under some conditions. Undoubtedly,
> Intel ME is a backdoor, e.g. because it contains some antitheft
> features which could be used to control your computer remotely: shut
> it down, wipe or retrieve data from it, etc
This makes me feel I should recall what Nico told you earlier:
"please don't spread FUD on this list."
please don't spread FUD on this list.
On 28.08.2018 09:54, Mike Banon wrote:
> And even if there weren't any problem with Intel Boot Guard, its not
> that easy to add a support for new board (impossible to do it over
> weekends, especially for the newcomers).
The T450s would probably benefit a lot from the existing support for
ThinkPads. But Broadwell really isn't a weekend port (Sandy or Ivy
Bridge would be for a ThinkPad) because we have few Broadwell ports
and an ugly blob situation.
Anyway, chances are close to 100% that the T450s has BootGuard in
> If I were you I would have
> sold these T450S and bought some machine already supported by
> coreboot. It could be one of those Intel Thinkpads (although you'll
> have to spend time cleaning Intel ME)
You don't *have to* spend time cleaning the ME, you *can* spend time
with it. It is actually unknown if that lowers or highers security,
so there is really no reason to advice to do it (unless you need more
flash space for fancy stuff).
> or maybe Lenovo G505S quadcore
> AMD laptop which doesn't have any Intel ME / AMD PSP backdoors in its'
> CPU at all - so no need to clean anything.
The G505s requires a lot of other blobs, IIRC: xHCI (optional), AtomBIOS
for GFX (which even runs in the OS on the host CPU), maybe more I don't
remember. I don't see how that is better (you seemed to want to sell
that by only stating absence of blobs, ignoring those it has instead).
And even if there weren't any problem with Intel Boot Guard, its not
that easy to add a support for new board (impossible to do it over
weekends, especially for the newcomers). If I were you I would have
sold these T450S and bought some machine already supported by
coreboot. It could be one of those Intel Thinkpads (although you'll
have to spend time cleaning Intel ME) or maybe Lenovo G505S quadcore
AMD laptop which doesn't have any Intel ME / AMD PSP backdoors in its'
CPU at all - so no need to clean anything. More information here -
On Tue, Aug 28, 2018 at 2:07 AM Th3Fanbus . <th3fanbus(a)gmail.com> wrote:
> Hello Brian,
> As far as I am concerned, Haswell or newer ThinkPads ship with Intel Boot Guard enabled in Verified Mode. This prevents coreboot from running on them. I assume this is the case on your machine as well, thus I advise you to check before proceeding, to avoid wasting time.
> Best regards,
> Angel Pons
> On Tue, Aug 28, 2018, 00:48 Brian Herman <bherman.aconspart(a)gmail.com> wrote:
>> im sorry i should really read the documentation first i want to create the support for a t450s ill do that this weekend
>> Sent from my iPhone
>> > On Aug 27, 2018, at 8:34 AM, Mike Banon <mikebdp2(a)gmail.com> wrote:
>> > Sorry but T450S is not supported by coreboot.
>> > Here is a list of laptops that ARE supported:
>> > https://www.coreboot.org/Supported_Motherboards/old
>> > On Mon, Aug 27, 2018 at 4:23 AM Brian Herman
>> > <bherman.aconspart(a)gmail.com> wrote:
>> >> I am in contact with a person with the means to reprogram a T450S.
>> >> https://www.allservice.ro/forum/viewtopic.php?t=1311
>> >> What would I have to do to make coreboot work?
>> >> I think I would have to have two laptops or at least motherboards right?
>> >> --
>> >> coreboot mailing list: coreboot(a)coreboot.org
>> >> https://mail.coreboot.org/mailman/listinfo/coreboot
>> coreboot mailing list: coreboot(a)coreboot.org