Re: [coreboot] RFC: Changing CBMEM console to run as a persistent ring-buffer

Re: [coreboot] RFC: Changing CBMEM console to run as a persistent ring-buffer

[Paul Menzel]

[-- Attachment #1: Type: text/plain, Size: 1369 bytes --]

[For the GRUB folks, this is about coreboot commit d67c6876 (Turn CBMEM
console into a ring buffer that can persist across reboots) [1].
Julius’ message can be find in the coreboot list archive [2].]


Dear Julius,


Am Montag, den 10.04.2017, 15:50 -0700 schrieb Julius Werner:

[…]

> The change may also cause some hiccups if you're using a newer version of
> coreboot with an older version of cbmem (or SeaBIOS or whatever else reads
> the console): it will not crash and it will still print the whole log, but
> if the log has rolled over (into "ring buffer mode") it will print lines
> out of order. This is unfortunately the best I can do with the way current
> readers are implemented. I'm of course also updating the code for cbmem so
> as soon as you deploy the new version it will be able to display buffers
> from both old and new coreboot versions correctly. (I'll send patches to
> align SeaBIOS and the Linux memconsole driver in the same manner as soon as
> the coreboot patch is approved.)

Could you please also check, if GRUB’s CBMEM console driver, and the
the command cbmemc to display it need any updates?


Thanks,

Paul


PS: Where can I get your S/MIME certificate, used to sign your email?


[1] https://review.coreboot.org/18301
[2] https://mail.coreboot.org/pipermail/coreboot/2017-April/083950.html

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: [coreboot] RFC: Changing CBMEM console to run as a persistent ring-buffer

[Julius Werner]

[-- Attachment #1: Type: text/plain, Size: 673 bytes --]

[-seabios for the GRUB part of the thread]


> Could you please also check, if GRUB’s CBMEM console driver, and the
> the command cbmemc to display it need any updates?
>

Thanks, I wasn't aware that GRUB also had a driver for this. I'm happy to
write a patch for it, but unfortunately I'm having some trouble testing it.
I managed to build it after some effort, but I don't have hardware that
supports it. Maybe you (or Vladimir?) could double-check that it works?


> PS: Where can I get your S/MIME certificate, used to sign your email?
>

Sorry, that wasn't supposed to be there... I accidentally sent the first
mail in here from the wrong account.

[-- Attachment #2: Type: text/html, Size: 1075 bytes --]

Re: [coreboot] RFC: Changing CBMEM console to run as a persistent ring-buffer

[Vladimir 'phcoder' Serbinenko]

[-- Attachment #1: Type: text/plain, Size: 414 bytes --]

I'm very concerned with compatibility. You can't guarantee that coreboot
and payload match. And in case of mismatch you get a memory corruption that
is very hard to trace. Can we please change signature of cbmem entry?

You mentioned having trouble building GRUB. Can you detail those?
What do you mean by not having hardware supported by grub-coreboot?
Grub-coreboot should work on all coreboot-supported boards.

[-- Attachment #2: Type: text/html, Size: 470 bytes --]

Re: [coreboot] RFC: Changing CBMEM console to run as a persistent ring-buffer

[Julius Werner]

[-- Attachment #1: Type: text/plain, Size: 1813 bytes --]

>
> I'm very concerned with compatibility. You can't guarantee that coreboot
> and payload match. And in case of mismatch you get a memory corruption that
> is very hard to trace. Can we please change signature of cbmem entry?


I would rather allow older implementations to continue working as best as
possible. Changing the signature would mean that an old payload (or 'cbmem'
command line tool, etc.) couldn't interoperate at all with the console. The
changes I made are as backwards-compatible as possible: in many cases (e.g.
before the console rolled over once) the old payload will continue working
just fine. If the console did roll over, the old payload can no longer
append lines and may print existing contents out of order. It will never
access invalid memory, though. (You may have been worried about bit 31 I'm
setting in the "cursor" field, but all existing implementations were
already required to check (cursor < size) before trusting the cursor to be
accessible since the old console would continue counting characters even
after the buffer filled up.)


> You mentioned having trouble building GRUB. Can you detail those?
> What do you mean by not having hardware supported by grub-coreboot?
> Grub-coreboot should work on all coreboot-supported boards.
>

I am able to build it, I just had to figure out how and install some
dependencies. But I tried booting it on an HP Chromebook 14 2013 (falco)
and it doesn't seem to recognize my keyboard and will reboot a few seconds
after displaying the GRUB console. (Most of the devices I have are ARM
unfortunately, which I'm assuming it doesn't support since all the coreboot
code is in i386 directories? And even if it did, it probably wouldn't have
a keyboard driver for them either. I assume there's no way to make it run
over the UART instead?)

[-- Attachment #2: Type: text/html, Size: 2272 bytes --]

Re: [coreboot] RFC: Changing CBMEM console to run as a persistent ring-buffer

[Vladimir 'phcoder' Serbinenko]

[-- Attachment #1: Type: text/plain, Size: 2274 bytes --]

On Tue, Apr 25, 2017, 20:15 Julius Werner <jwerner@chromium.org> wrote:

> I'm very concerned with compatibility. You can't guarantee that coreboot
>> and payload match. And in case of mismatch you get a memory corruption that
>> is very hard to trace. Can we please change signature of cbmem entry?
>
>
> I would rather allow older implementations to continue working as best as
> possible. Changing the signature would mean that an old payload (or 'cbmem'
> command line tool, etc.) couldn't interoperate at all with the console. The
> changes I made are as backwards-compatible as possible: in many cases (e.g.
> before the console rolled over once) the old payload will continue working
> just fine. If the console did roll over, the old payload can no longer
> append lines and may print existing contents out of order. It will never
> access invalid memory, though. (You may have been worried about bit 31 I'm
> setting in the "cursor" field, but all existing implementations were
> already required to check (cursor < size) before trusting the cursor to be
> accessible since the old console would continue counting characters even
> after the buffer filled up.)
>
Did you check that all implementations use unsigned?

>
>
>> You mentioned having trouble building GRUB. Can you detail those?
>> What do you mean by not having hardware supported by grub-coreboot?
>> Grub-coreboot should work on all coreboot-supported boards.
>>
>
> I am able to build it, I just had to figure out how and install some
> dependencies. But I tried booting it on an HP Chromebook 14 2013 (falco)
> and it doesn't seem to recognize my keyboard
>
Is it PS2 or USB? Is at_keyboard included in the payload?

> and will reboot a few seconds after displaying the GRUB console. (Most of
> the devices I have are ARM unfortunately, which I'm assuming it doesn't
> support since all the coreboot code is in i386 directories?
>
Arm is in separate branch due to freeze.

>  even if it did, it probably wouldn't have a keyboard driver for them
> either. I assume there's no way to make it run over the UART instead?)
>
terminal_input serial_com0
terminal_output serial_com0
In etc/grub.cfg

Possibly the problem is that some module hangs. Can you try minimal GRUB
without non-essential modules?

>

[-- Attachment #2: Type: text/html, Size: 3918 bytes --]

Re: [coreboot] RFC: Changing CBMEM console to run as a persistent ring-buffer

[Julius Werner]

[-- Attachment #1: Type: text/plain, Size: 1289 bytes --]

>
> Did you check that all implementations use unsigned?
>

Yes, all the ones that I'm now aware of used unsigned, 32-bit.


> I am able to build it, I just had to figure out how and install some
>> dependencies. But I tried booting it on an HP Chromebook 14 2013 (falco)
>> and it doesn't seem to recognize my keyboard
>>
> Is it PS2 or USB? Is at_keyboard included in the payload?
>

It's a matrixed laptop keyboard. I believe the embedded controller does
8042 emulation, but I'm not sure honestly. I'm an ARM guy and this was the
one old x86 machine I have lying around. I can try USB if I get it to not
crash long enough to type something.

 even if it did, it probably wouldn't have a keyboard driver for them
>> either. I assume there's no way to make it run over the UART instead?)
>>
> terminal_input serial_com0
> terminal_output serial_com0
> In etc/grub.cfg
>

I don't think I have an etc/grub.cfg... is there a way to compile that in
instead?


> Possibly the problem is that some module hangs. Can you try minimal GRUB
> without non-essential modules?
>
>>
How do I do that? Is there some configure flag?

For reference, I did:

./autogen.sh
./configure --with-platform=coreboot
make
make default_payload.elf
<cbfstool default_payload.elf into my coreboot image and flash it>

[-- Attachment #2: Type: text/html, Size: 2867 bytes --]

Re: [coreboot] RFC: Changing CBMEM console to run as a persistent ring-buffer

[Julius Werner]

[-- Attachment #1: Type: text/plain, Size: 1546 bytes --]

Managed to get it working with serial input now. Found a few issues with my
patch. Will send a new, tested version out.

On Tue, Apr 25, 2017 at 11:48 AM, Julius Werner <jwerner@chromium.org>
wrote:

> Did you check that all implementations use unsigned?
>>
>
> Yes, all the ones that I'm now aware of used unsigned, 32-bit.
>
>
>> I am able to build it, I just had to figure out how and install some
>>> dependencies. But I tried booting it on an HP Chromebook 14 2013 (falco)
>>> and it doesn't seem to recognize my keyboard
>>>
>> Is it PS2 or USB? Is at_keyboard included in the payload?
>>
>
> It's a matrixed laptop keyboard. I believe the embedded controller does
> 8042 emulation, but I'm not sure honestly. I'm an ARM guy and this was the
> one old x86 machine I have lying around. I can try USB if I get it to not
> crash long enough to type something.
>
>  even if it did, it probably wouldn't have a keyboard driver for them
>>> either. I assume there's no way to make it run over the UART instead?)
>>>
>> terminal_input serial_com0
>> terminal_output serial_com0
>> In etc/grub.cfg
>>
>
> I don't think I have an etc/grub.cfg... is there a way to compile that in
> instead?
>
>
>> Possibly the problem is that some module hangs. Can you try minimal GRUB
>> without non-essential modules?
>>
>>>
> How do I do that? Is there some configure flag?
>
> For reference, I did:
>
> ./autogen.sh
> ./configure --with-platform=coreboot
> make
> make default_payload.elf
> <cbfstool default_payload.elf into my coreboot image and flash it>
>

[-- Attachment #2: Type: text/html, Size: 3563 bytes --]