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.