[coreboot] Assigning PCI resources clobbers console with io-mapped / memory-mapped UART

[Jay Talbott]

We ran into an issue where we were not getting a full coreboot log on
Denverton with the Harcuvar CRB, where it just abruptly stops the serial
console output during the assignment of the PCI resources.

 

Root Device assign_resources, bus 0 link: 0

DOMAIN:  assign_resources, bus 0 link: 0

PCI: 00:09.0 1c <- [0x00 - 0x00fffe] size 0x gran 0x0c
bus 01 io

PCI: 00:09.0 24 <- [0x00dfff - 0x00dffe] size 0x gran 0x14
bus 01 prefmem

PCI: 00:09.0 20 <- [0x00dfff - 0x00dffe] size 0x gran 0x14
bus 01 mem

PCI: 00:09.0 10 <- [0x00df70 - 0x00df71] size 0x0002 gran 0x11
mem64

PCI: 00:0e.0 1c <- [0x00 - 0x00fffe] size 0x gran 0x0c
bus 02 io

PCI: 00:0e.0 24 <- [0x00dfff - 0x00dffe] size 0x gran 0x14
bus 02 prefmem

PCI: 00:0e.0 20 <- [0x00dfff - 0x00dffe] size 0x gran 0x14
bus 02 mem

PCI: 00:0e.0 10 <- [0x00df72 - 0x00df73] size 0x0002 gran 0x11
mem64

PCI: 00:10.0 1c <- [0x00 - 0x00fffe] size 0x gran 0x0c
bus 03 io

PCI: 00:10.0 24 <- [0x00dc00 - 0x00ddff] size 0x0200 gran 0x14
bus 03 prefmem

PCI: 00:10.0 20 <- [0x00de00 - 0x00de8f] size 0x0090 gran 0x14
bus 03 mem

PCI: 00:10.0 10 <- [0x00df74 - 0x00df75] size 0x0002 gran 0x11
mem64

PCI: 00:10.0 assign_resources, bus 3 link: 0

PCI: 03:00.0 1c <- [0x00 - 0x00fffe] size 0x gran 0x0c
bus 04 io

PCI: 03:00.0 24 <- [0x00dc00 - 0x00ddff] size 0x0200 gran 0x14
bus 04 prefmem

PCI: 03:00.0 20 <- [0x00de00 - 0x00de8f] size 0x0090 gran 0x14
bus 04 mem

PCI: 03:00.0 assign_resources, bus 4 link: 0

PCI: 04:00.0 10 <- [0x00dc00 - 0x00ddff] size 0x0200 gran 0x19
prefmem

PCI: 04:00.0 14 <- [0x00de82 - 0x00de823fff] size 0x4000 gran 0x0e
mem

PCI: 04:00.0 18 <- [0x00de00 - 0x00de7f] size 0x0080 gran 0x17
mem

PCI: 04:00.0 30 <- [0x00de80 - 0x00de81] size 0x0002 gran 0x11
romem

PCI: 03:00.0 assign_resources, bus 4 link: 0

PCI: 00:10.0 assign_resources, bus 3 link: 0

PCI: 00:12.0 10 <- [0x00df77b000 - 0x00df77b3ff] size 0x0400 gran 0x0a
mem64

PCI: 00:14.0 10 <- [0x00df774000 - 0x00df775fff] size 0x2000 gran 0x0d
mem

PCI: 00:14.0 14 <- [0x00df77c000 - 0x00df77c0ff] size 0x0100 gran 0x08
mem

PCI: 00:14.0 18 <- [0x001c40 - 0x001c47] size 0x0008 gran 0x03
io

PCI: 00:14.0 1c <- [0x001c60 - 0x001c63] size 0x0004 gran 0x02
io

PCI: 00:14.0 20 <- [0x001c00 - 0x001c1f] size 0x0020 gran 0x05
io

PCI: 00:14.0 24 <- [0x00df77a000 - 0x00df77a7ff] size 0x0800 gran 0x0b
mem

PCI: 00:15.0 10 <- [0x00df76 - 0x00df76] size 0x0001 gran 0x10
mem64

PCI: 00:16.0 1c <- [0x00 - 0x00fffe] size 0x gran 0x0c
bus 05 io

PCI: 00:16.0 24 <- [0x00dea0 - 0x00deef] size 0x0050 gran 0x14
bus 05 prefmem

PCI: 00:16.0 20 <- [0x00df50 - 0x00df5f] size 0x0010 gran 0x14
bus 05 mem

PCI: 00:16.0 assign_resources, bus 5 link: 0

PCI: 05:00.0 10 <- [0x00dea0 - 0x00debf] size 0x0020 gran 0x15
prefmem64

PCI: 05:00.0 20 <- [0x00dee0 - 0x00dee03fff] size 0x4000 gran 0x0e
prefmem64

PCI: 05:00.0 30 <- [0x00df50 - 0x00df57] size 0x0008 gran 0x13
romem

PCI: 05:00.1 10 <- [0x00dec0 - 0x00dedf] size 0x0020 gran 0x15
prefmem64

PCI: 05:00.1 20 <- [0x00dee04000 - 0x00dee07fff] size 0x4000 gran 0x0e
prefmem64

PCI: 05:00.1 30 <- [0x00df58 - 0x00df5f] size 0x0008 gran 0x13
romem

PCI: 00:16.0 assign_resources, bus 5 link: 0

PCI: 00:17.0 1c <- [0x00 - 0x00fffe] size 0x gran 0x0c
bus 06 io

PCI: 00:17.0 24 <- [0x00df00 - 0x00df4f] size 0x0050 gran 0x14
bus 06 prefmem

PCI: 00:17.0 20 <- [0x00df60 - 0x00df6f] size 0x0010 gran 0x14
bus 06 mem

PCI: 00:17.0 assign_resources, bus 6 link: 0

PCI: 06:00.0 10 <- [0x00df00 - 0x00df1f] size 0x0020 gran 0x15
prefmem64

PCI: 06:00.0 20 <- [0x00df40 - 0x00df403fff] size 0x4000 gran 0x0e
prefmem64

PCI: 06:00.0 30 <- [0x00df60 - 0x00df67] size 0x0008 gran 0x13
romem

PCI: 06:00.1 10 <- [0x00df20 - 0x00df3f] size 0x0020 gran 0x15
prefmem64

PCI: 06:00.1 20 <- [0x00df404000 - 0x00df407fff] size 0x4000 gran 0x0e
prefmem64

PCI: 06:00.1 30 <- [0x00df68 - 0x00df6f] size 0x0008 gran 0x13
romem

PCI: 00:17.0 assign_resources, bus 6 link: 0

PCI: 00:18.0 10 <- [0x00df776000 - 0x00df776fff] size 0x1000 gran 0x0c
mem64

 

The boot continues, there's just no more console output from coreboot past
this point. The payload launches fine after coreboot is finished. If we use
a Linux kernel payload, it still successfully sends all of its kernel
console output to the serial console beginning immediately after where the
coreboot console output stopped.

 

The last device that has its resources assigned that is displayed in the log
is D24, F0 (PCI 00:18.0). 

Re: [coreboot] shrdw question

[ron minnich]

On Thu, Mar 29, 2018 at 3:16 PM Nico Huber  wrote:

> On 29.03.2018 23:58, ron minnich wrote:
> > believe it or not that code runs on coreboot simulator, hardware, and
> qemu,
>
> What is `coreboot simulator`?
>
>
>
the 8086 one in yabel.

So here's what I think is going on.

you're doing a shrdw with a 64-bit number in ebx,eax, target is %ax.

In one intel architecture manual, it says, on 8086, that shifts of 16 bits
or greater will happen, with the result of 0. On 386 and later,  according
to some docs, "if the count is greater than the operand size, the result is
undefined." According to another intel ref manual, if the shift count is
greater than the operand size, the instruction is not executed.

Other docs say only the lower 5 bits of the count are used.

qemu, yabel, and real hardware don't really agree on the result.

No big deal, I thought people would find it amusing.

It only came up because I ported the yabel x86 simulator to Go, and I'm
doing verification with the qemu verification tests, and this is one small
difference that has come up.

For the record, with
eax=12345678
ebx=
cl=0x10
qemu believes the right answer for shrdw is
eax=1234

i.e. ax gets bx.
which surprised me.
ron
-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] shrdw question

[Nico Huber]

On 29.03.2018 23:58, ron minnich wrote:
> believe it or not that code runs on coreboot simulator, hardware, and qemu,

What is `coreboot simulator`?

> and gets a different answer on each.

Same binary and same processor (e.g. 32-bit protected) mode?

Without knowing what your assembler translated it to, anything seems
possible.

Nico

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

Re: [coreboot] shrdw question

[ron minnich]

believe it or not that code runs on coreboot simulator, hardware, and qemu,
and gets a different answer on each.



On Thu, Mar 29, 2018 at 12:54 PM Nico Huber  wrote:

> On 29.03.2018 20:25, ron minnich wrote:
> > I have the following code:
> >
> > movl $0x12345678, %eax
> > movl $0x, %ebx
> > movb $0x10, %cl
> > shrdw %ebx, %eax
>
> If I had to assemble it, I would have refuse it... *w with 32-bit
> registers? how should that work?
>
> Though, after reading a little about AT, I found this:
>
>   "In AT syntax, the size of memory operands is determined from
>the last character of the opcode name." [1]
>
> Memory operands, heh, no memory operands here... but the GNU as
> manual talks about operands in general and that it may infer the
> suffix from register operands, hmmm, no word about what happens
> if register operands don't match the suffix.
>
> I've also tried to find a quote about the third operand. Is it
> %cl implicitly? I would think so, but is it written anywhere?
> Could also be implicitly $0, ok that would never make sense.
>
> > quiz: what's the value of %ax after this instruction?
>
> I guess it depends on the assembler you use. non-zero?
>
> TIL, you can't shift by 32 bits this way.
>
> Nico
>
> [1]
>
> https://web.archive.org/web/20131003180256/http://www.ibm.com/developerworks/linux/library/l-gas-nasm/index.html
>
-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] shrdw question

[Andriy Gapon]

On 29/03/2018 21:25, ron minnich wrote:
> I have the following code:
> 
> movl $0x12345678, %eax
> movl $0x, %ebx
> movb $0x10, %cl
> shrdw %ebx, %eax
> 
> quiz: what's the value of %ax after this instruction?

Given 'w', correct notation for the last instruction should be
shrdw %bx, %ax
?

I believe that the original value of %ax would be shifted out and replaced with
the value of %bx.  So, 0x.  Same as %bx.

-- 
Andriy Gapon

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

Re: [coreboot] shrdw question

[Nico Huber]

On 29.03.2018 20:25, ron minnich wrote:
> I have the following code:
> 
> movl $0x12345678, %eax
> movl $0x, %ebx
> movb $0x10, %cl
> shrdw %ebx, %eax

If I had to assemble it, I would have refuse it... *w with 32-bit
registers? how should that work?

Though, after reading a little about AT, I found this:

  "In AT syntax, the size of memory operands is determined from
   the last character of the opcode name." [1]

Memory operands, heh, no memory operands here... but the GNU as
manual talks about operands in general and that it may infer the
suffix from register operands, hmmm, no word about what happens
if register operands don't match the suffix.

I've also tried to find a quote about the third operand. Is it
%cl implicitly? I would think so, but is it written anywhere?
Could also be implicitly $0, ok that would never make sense.

> quiz: what's the value of %ax after this instruction?

I guess it depends on the assembler you use. non-zero?

TIL, you can't shift by 32 bits this way.

Nico

[1]
https://web.archive.org/web/20131003180256/http://www.ibm.com/developerworks/linux/library/l-gas-nasm/index.html

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

Re: [coreboot] When does AMD release the fam15 spectre microcode updates?

[taii...@gmx.com]

On 02/18/2018 07:03 AM, Rudolf Marek wrote:
> Hi,
Thanks for the detailed reply :]
> What do you want to protect?
I just looked at the AMD page saw they said they would be releasing
updates and I figured I should have them even though there is no
description of as to what they actually will do.
>  If you want to protect the kernel, retpolines are OK on AMD.
> And you don't need any microcode update. Your CPU needs to have SMEP, 
> otherwise
> you would need to clear RSB on CPL change (the paper on mentined page says 
> that you need to do that
> always, but at least on Ryzen, the attack using RSB is not working (we tried 
> that out, maybe it works
> only on some circumstances).
>
> If you want to protect userspace, the RSB will be clear by IBPB (which you 
> would need if you don't have userspace compiled
> with retpolines). I don't know if intel clears RSB on IBPB... probably not
>
> To sum it up on AMD:
>
> kernel:
> retpolines, RSB clear on CPL change on CPU without SMEP (see above)
>
> userspace:
> retpolines, RSB clear on context switch necessary or IBPB (needs microcode 
> update).
>
> Plus make sure you enable "LFENCE is dispatch serializing" - perhaps coreboot 
> can do that :) it is simple
> MSR write on fam 10h 12h+ the fam 11h and 0fh dont have this MSR but LFENCE 
> is dispatch serilizing.
Hmm do you have more info links about this?
> Besides that, you don't need any microcode update.
>
> Plus of course there is a spectre variant 1, which is more difficult to 
> mitigate, basically you need to check all the software
> and look for any pattern like array_x[array_z[untrusted_index] * any 
> transformation].
>
> The first access would leak just address (ASLR defated), second will leak 
> data.
> The variant 1 works on user/user attack and as well as user/kernel.
>
> As far I know there are no automated tools to check for this.


0xDF372A17.asc
Description: application/pgp-keys
-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

[coreboot] shrdw question

[ron minnich]

I have the following code:

movl $0x12345678, %eax
movl $0x, %ebx
movb $0x10, %cl
shrdw %ebx, %eax

quiz: what's the value of %ax after this instruction?
-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Missing ACPI ASL code for Denverton GPIO controller

[Julien Viard de Galbert]

Hi Sumo,

It was more to get some motivation to clean some of the code.

The branch is here: https://review.coreboot.org/c/coreboot/+/25446 


I’ve really not looked on GPIO on ACPI (cause I don’t need it) but I really 
think it should be a better base for your work.
So if you can test in on your board, please report your results and help 
reviewing the code ;-)

Best Regards,

Julien

> Le 28 mars 2018 à 14:10, Sumo  a écrit :
> 
> Hi Julien,
> 
> Yes, I'm interested. But no need to hurry up, do it in your own time. ;)
> 
> Thanks,
> Sumo
> 
> 2018-03-27 6:54 GMT-03:00 Julien Viard de Galbert  >:
> 
> 
>> Le 26 mars 2018 à 21:24, Sumo > > a écrit :
>> 
>> Hi all,
> 
> Hi Sumo,
> 
>> 
>> We have a kernel patch which adds pinctrl/GPIO support for Intel Denverton 
>> SoC (https://patchwork.kernel.org/patch/9879473/ 
>> ) to make possible to access 
>> the GPIO from user space (via sysfs, i.e. /sys/kernel/debug/pinctrl/), 
>> however this patch is expects a "INTC3000" GPIO controller definition in the 
>> ACPI tables.
>> I want to add/implement the INTC3000 in the ASL code, but since I don´t want 
>> to reinvent the wheel I´m asking if such ASL code is already available 
>> somewhere (at least in the Intel Pine Lake CRB there´s no such reference to 
>> INTC3000 in the ACPI tables).
>> 
> 
> I have a set of patches that still need some work 
> (https://review.coreboot.org/c/coreboot/+/24928 
> ) that enable some shared 
> code for GPIO; following I also have more patches to use the ACPI code from 
> common block too (not published yet). I didn’t check but probably apollolake 
> or cannonlake has the ACPI code for GPIO (using common block).
> If you are interested I can probably work on adding the ACPI implementation 
> to Gerrit sooner.
> 
> Best Regards,
> 
> Julien
> 
>> Thanks,
>> Sumo
>> -- 
>> coreboot mailing list: coreboot@coreboot.org 
>> https://mail.coreboot.org/mailman/listinfo/coreboot 
>> 
> --
> Julien Viard de Galbert - jviarddegalb...@online.net 
> 
> Online / Scaleway
> Looking for an amazing job? Join us NOW ! https://careers.scaleway.com/ 
> 
> 
> 
> 
> 
> 
> -- 
> coreboot mailing list: coreboot@coreboot.org
> https://mail.coreboot.org/mailman/listinfo/coreboot

--
Julien Viard de Galbert - jviarddegalb...@online.net
Online / Scaleway
Looking for an amazing job? Join us NOW ! https://careers.scaleway.com/




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