[coreboot] Microcode updates for slightly older intel CPU's re: meltdown/spectre

[Mike Banon]

Hi Nico,

>
> you seem to be misinformed about the G505s. There is no
> open-source gfx init for AMD (not in firmware, not in the OS),
> so within your requirements it's not usable as a laptop
>

I've had a small discussion with bridgman from AMD (at Phoronix forums)
and he told me that VBIOS needed by G505S - aka "gfx init for AMD" -
- is "effectively open source" - a byte code which is possible to parse
with [AtomDis] open source interpreter

Only problem is that the last update of AtomDis was at 2011 - so, while it
should be able to parse 100% of G505S integrated / discrete GPUs AtomBIOSes
(because these GPUs were developed before 2011 if I am correct)
maybe AtomDis couldn't parse everything for the modern AMD GPUs

Me:

" @bridgman why you don't just open source the complete source code of
VBIOS, to let the open source community improve it and fix some bugs?
With the help of flashrom open source project, anyone is able to
reflash their VBIOS through In-System-Programming. We just don't have
the original source code of VBIOS, and the creation of open source
VBIOS from scratch is like reinventing the wheel - a huge wheel, which
is way too much for unpaid work

Just share the complete source code of VBIOS and let the open source
community fix the bugs for you for free! A win-win solution. Why not
do it? For the bystanders like me, it gives an impression that either
1) VBIOS source code is a horrible quality, too ashamed to release it
to public 2) VBIOS contains some hidden backdoors, hence the need for
secrecy 3) AMD is not that friendly to open source community, if
instead of sharing what you already got, you want the people to start
reinventing the wheel and waste countless of unpaid work hours on it "

brigman:

" It is effectively open source. The data tables are all documented in
atombios.h. They are just data structures. The command table
parameters are all documented in atombios.h (also just data
structures). The command tables are all written in byte code to begin
with. The source to the interpreter is open source so you can dump
command tables and see exactly what they are doing. You can even write
your own command tables in byte code or edit exiting ones if you
wanted to. Those are the only things the driver uses from the vbios.
The whole point of the data and command tables is to encapsulate board
specific configuration details on the actual board itself so that the
driver doesn't need explicit knowledge about every board configuration
out there.

To summarize:

1. We use an interpreter in VBIOS in order to (a) fit a lot of
functionality into a small ROM, (b) give us a degree of CPU
independence. My understanding is that this is pretty common practice;
either way it's not likely to change unless OEMs buying AMD chips are
willing to spend more $$ on the ROM for our hardware than for
competitors hardware AND we are willing to go back to having different
BIOS code for each of the different CPUs our chips are used with.

2. As agd5f said, the VBIOS source code is bytecode similar to what
you get out of the disassembler, although the disassembler output is
formatted more neatly. It's not like there is a single master copy of
VBIOS source written in C that could be "opened once" - every HW
vendor tweaks their BIOS images before production and AFAIK those
changes are not ours to publish.

Relatively more of the changes are in data tables than in command
tables but both get changed and so we need to use both in the driver
if we want driver functionality to correctly match the HW config.
There are literally thousands of different HW subsystems, each with
their own VBIOS image and hence each with their own slightly different
source code... and the associated HW differences DO generally need to
be considered when the driver runs.

3. A couple of people have started projects to replace VBIOS with a
fully open solution, but my impression is that they all run into the
same issues:

- initial implementation is straightforward but ongoing maintenance is
a big and boring effort nobody wants to own
- you lose CPU independence unless you are willing to maintain AND
TEST a lot more different VBIOS builds
- without an interpreter the resulting implementation won't fit in the
on-card ROM unless you cut back functionality

We make enough information for an open source BIOS replacement
available as part of the open source driver effort (data table &
command table headers, bytecode interpreter, open source drivers using
the tables) although I don't think we support VBIOS re-flashing in
general. It is easy to get the same result by over-riding tables in
the driver code, however, and I believe there is an existing quirk
mechanism.

4. Over time I think you will see a trend away from using AtomBIOS
calls simply because ROM size limits the amount of complexity that can
be supported in ROM-resident tables while HW complexity is continuing
to grow as quickly as ever.

My understanding is that DAL/DC makes somewhat less use of AtomBIOS
calls but it also replaces a relatively painless sharing model
(drivers for all OSes/platforms make the same AtomBIOS calls for the
fiddly HW-specific bits) with a much-harder-to-sell sharing model
(drivers for all OSes/platforms share native driver code for the
fiddly HW-specific bits).

I understand that this seems unnecessary (and maybe even
counter-productive) if you believe that modesetting is trivial, but I
don't know how to reconcile your views on modesetting with the views
of developers working on the code at different vendors. Once we figure
out how to close that gap the rest of the discussion should become
easier. "

Best regards,
Mike Banon

On Thu, Jan 11, 2018 at 1:05 PM, Nico Huber <nico.h at gmx.de> wrote:
> Hi Taiidan,
>
> On 11.01.2018 03:55, Taiidan at gmx.com wrote:
>> I am curious of any intel insiders know if there will be microcode
>> updates released for older intel CPU's (ex: sandy/ivybridge) and failing
>> that, what can be done in regards to securing them from meltdown/spectre.
>>
>> I believe this is a relevant coreboot topic considering how many
>> coreboot boards have these and older CPU's....without a fix there will
>> be only one coreboot compatible laptop with open source hardware
>> initiation that is remotely secure (lenovo g505s as has a pre-PSP AMD
>> CPU) and theoretically owner controllable
>
> you seem to be misinformed about the G505s. There is no open-source gfx
> init for AMD (not in firmware, not in the OS), so within your require-
> ments it's not usable as a laptop.
>
>> (as the previous C2D/C2Q's
>> such as the X200 are now permanently insecure without intervention from
>> intel apparently)
>
> It depends on the software you run. Please read more about Meltdown and
> Spectre. When you understood it, you can still start to worry.
>
>>
>> At this point even a massive performance loss is better than having to
>> throw out so much now-useless hardware.
>
> Yes? and that can be accomplished without microcode updates, AFAIK.
>
> Nico
>
> --
> coreboot mailing list: coreboot at coreboot.org
> https://mail.coreboot.org/mailman/listinfo/coreboot