Hi everyone.
I'm currently working on coreboot but I stumbled on a strange SeaBIOS behaviour. After executing a payload and returning control to the caller SeaBIOS crashes.
The problem is currently solved by rebooting before the payload returns but doing so also makes chaining multiple payloads impossible so I'm trying to look into a solution.
I tried to increment the debug level to 8 to get more information and the attached log is what I got. I also attached a build of coreboot with this problem if someone wants to try it in QEMU.
I'm not terribly knowledgeable about SeaBIOS so I'm a bit lost.
Could anyone point me where the problem could be originating from?
Thanks in advance,
Antonello Dettori
On Tue, Aug 02, 2016 at 03:37:44PM +0200, Antonello Dettori wrote:
Hi everyone.
I'm currently working on coreboot but I stumbled on a strange SeaBIOS behaviour. After executing a payload and returning control to the caller SeaBIOS crashes.
The problem is currently solved by rebooting before the payload returns but doing so also makes chaining multiple payloads impossible so I'm trying to look into a solution.
The SeaBIOS payload support was not designed to robustly handle returns from a payload. It will crash if the payload alters the GDT, overwrite the stack, or otherwise messes up the SeaBIOS state. As far as I know, payloads in general aren't designed to handle returns to their caller.
I tried to increment the debug level to 8 to get more information and the attached log is what I got.
That log isn't from SeaBIOS. It's unclear what hardware you have. In general, a serial port is the most robust way of obtaining a log. See also: http://www.seabios.org/Debugging
-Kevin
On 02/08/16 16:39, Kevin O'Connor wrote:
On Tue, Aug 02, 2016 at 03:37:44PM +0200, Antonello Dettori wrote:
Hi everyone.
I'm currently working on coreboot but I stumbled on a strange SeaBIOS behaviour. After executing a payload and returning control to the caller SeaBIOS crashes.
The problem is currently solved by rebooting before the payload returns but doing so also makes chaining multiple payloads impossible so I'm trying to look into a solution.
The SeaBIOS payload support was not designed to robustly handle returns from a payload. It will crash if the payload alters the GDT, overwrite the stack, or otherwise messes up the SeaBIOS state. As far as I know, payloads in general aren't designed to handle returns to their caller.
Some payloads can handle returns to the previous caller/payload. Would it be possible in theory to re-design the payload support so as to make it work (i.e. restoring the SeaBIOS state after returning)? Are there any reasons why it would be unfeasible?
I tried to increment the debug level to 8 to get more information and the attached log is what I got.
That log isn't from SeaBIOS. It's unclear what hardware you have. In general, a serial port is the most robust way of obtaining a log. See also: http://www.seabios.org/Debugging
-Kevin
I run the image on QEMU, didn't realise that SeaBIOS probably doesn't support QEMU debug port output. I'll try on a hardware target later.
On Tue, Aug 02, 2016 at 04:53:16PM +0200, Antonello Dettori wrote:
On 02/08/16 16:39, Kevin O'Connor wrote:
On Tue, Aug 02, 2016 at 03:37:44PM +0200, Antonello Dettori wrote:
Hi everyone.
I'm currently working on coreboot but I stumbled on a strange SeaBIOS behaviour. After executing a payload and returning control to the caller SeaBIOS crashes.
The problem is currently solved by rebooting before the payload returns but doing so also makes chaining multiple payloads impossible so I'm trying to look into a solution.
The SeaBIOS payload support was not designed to robustly handle returns from a payload. It will crash if the payload alters the GDT, overwrite the stack, or otherwise messes up the SeaBIOS state. As far as I know, payloads in general aren't designed to handle returns to their caller.
Some payloads can handle returns to the previous caller/payload. Would it be possible in theory to re-design the payload support so as to make it work (i.e. restoring the SeaBIOS state after returning)? Are there any reasons why it would be unfeasible?
Depends on what the payload is altering. Which payload is it?
I tried to increment the debug level to 8 to get more information and the attached log is what I got.
That log isn't from SeaBIOS. It's unclear what hardware you have. In general, a serial port is the most robust way of obtaining a log. See also: http://www.seabios.org/Debugging
-Kevin
I run the image on QEMU, didn't realise that SeaBIOS probably doesn't support QEMU debug port output. I'll try on a hardware target later.
SeaBIOS can support the qemu debug port, but it's probably easier to compile seabios with serial support and instruct qemu to write the serial log to a file: -serial file:foo.txt
-Kevin
On 02/08/16 17:02, Kevin O'Connor wrote:
On Tue, Aug 02, 2016 at 04:53:16PM +0200, Antonello Dettori wrote:
On 02/08/16 16:39, Kevin O'Connor wrote:
On Tue, Aug 02, 2016 at 03:37:44PM +0200, Antonello Dettori wrote:
Hi everyone.
I'm currently working on coreboot but I stumbled on a strange SeaBIOS behaviour. After executing a payload and returning control to the caller SeaBIOS crashes.
The problem is currently solved by rebooting before the payload returns but doing so also makes chaining multiple payloads impossible so I'm trying to look into a solution.
The SeaBIOS payload support was not designed to robustly handle returns from a payload. It will crash if the payload alters the GDT, overwrite the stack, or otherwise messes up the SeaBIOS state. As far as I know, payloads in general aren't designed to handle returns to their caller.
Some payloads can handle returns to the previous caller/payload. Would it be possible in theory to re-design the payload support so as to make it work (i.e. restoring the SeaBIOS state after returning)? Are there any reasons why it would be unfeasible?
Depends on what the payload is altering. Which payload is it?
The payload that I'm trying is coreinfo (I removed the reboot and halt() section in order to be able to return and chain).
I tried to increment the debug level to 8 to get more information and the attached log is what I got.
That log isn't from SeaBIOS. It's unclear what hardware you have. In general, a serial port is the most robust way of obtaining a log. See also: http://www.seabios.org/Debugging
-Kevin
I run the image on QEMU, didn't realise that SeaBIOS probably doesn't support QEMU debug port output. I'll try on a hardware target later.
SeaBIOS can support the qemu debug port, but it's probably easier to compile seabios with serial support and instruct qemu to write the serial log to a file: -serial file:foo.txt
-Kevin
Oh, didn't think about that. Attached the full log.
-
Antonello Dettori -
Kevin O'Connor