Check whenever pnp roms attempt to redirect int19, and in case it does
log a message and undo the redirect.
A pnp rom should not need this, we have BEVs and BCVs for that.
Nevertheless there are roms in the wild which are redirecting int19.
At least some BIOS implementations for physical hardware have a config
option in the setup to allow/disallow int19 redirections, so just not
allowing this seems to be the way to deal with this situation.
Buglink: https://bugzilla.redhat.com//show_bug.cgi?id=1642135
Signed-off-by: Gerd Hoffmann <kraxel(a)redhat.com>
---
src/optionroms.c | 29 +++++++++++++++++++++++++++++
1 file changed, 29 insertions(+)
diff --git a/src/optionroms.c b/src/optionroms.c
index fc992f649f..e90900b790 100644
--- a/src/optionroms.c
+++ b/src/optionroms.c
@@ -8,6 +8,7 @@
#include "bregs.h" // struct bregs
#include "config.h" // CONFIG_*
#include "farptr.h" // FLATPTR_TO_SEG
+#include "biosvar.h" // GET_IVT
#include "hw/pci.h" // pci_config_readl
#include "hw/pcidevice.h" // foreachpci
#include "hw/pci_ids.h" // PCI_CLASS_DISPLAY_VGA
@@ -308,6 +309,24 @@ fail:
return NULL;
}
+static int boot_irq_captured(void)
+{
+ struct segoff_s current, seabios;
+
+ current = GET_IVT(0x19);
+ seabios = FUNC16(entry_19_official);
+ return ((current.seg != seabios.seg) ||
+ (current.offset != current.offset));
+}
+
+static void boot_irq_restore(void)
+{
+ struct segoff_s seabios;
+
+ seabios = FUNC16(entry_19_official);
+ SET_IVT(0x19, seabios);
+}
+
// Attempt to map and initialize the option rom on a given PCI device.
static void
init_pcirom(struct pci_device *pci, int isvga, u64 *sources)
@@ -327,8 +346,18 @@ init_pcirom(struct pci_device *pci, int isvga, u64 *sources)
if (! rom)
// No ROM present.
return;
+ int irq_was_captured = boot_irq_captured();
+ struct pnp_data *pnp = get_pnp_rom(rom);
setRomSource(sources, rom, RS_PCIROM | (u32)pci);
init_optionrom(rom, pci->bdf, isvga);
+ if (boot_irq_captured() && !irq_was_captured &&
+ !file && !isvga && pnp) {
+ // This PCI rom is misbehaving - recapture the boot irqs
+ char *desc = MAKE_FLATPTR(FLATPTR_TO_SEG(rom), pnp->productname);
+ dprintf(1, "PnP optionrom \"%s\" (bdf %pP) captured int19, restoring\n",
+ desc, pci);
+ boot_irq_restore();
+ }
}
--
2.9.3
Check whenever pnp roms attempt to redirect int19, and in case it does
log a message and undo the redirect.
A pnp rom should not need this, we have BEVs and BCVs for that.
Nevertheless there are roms in the wild which are redirecting int19.
At least some BIOS implementations for physical hardware have a config
option in the setup to allow/disallow int19 redirections, so just not
allowing this seems to be the way to deal with this situation.
Buglink: https://bugzilla.redhat.com//show_bug.cgi?id=1642135
Signed-off-by: Gerd Hoffmann <kraxel(a)redhat.com>
---
src/optionroms.c | 18 +++++++++++++++++-
1 file changed, 17 insertions(+), 1 deletion(-)
diff --git a/src/optionroms.c b/src/optionroms.c
index fc992f649f..4ec5504ca9 100644
--- a/src/optionroms.c
+++ b/src/optionroms.c
@@ -8,6 +8,7 @@
#include "bregs.h" // struct bregs
#include "config.h" // CONFIG_*
#include "farptr.h" // FLATPTR_TO_SEG
+#include "biosvar.h" // GET_IVT
#include "hw/pci.h" // pci_config_readl
#include "hw/pcidevice.h" // foreachpci
#include "hw/pci_ids.h" // PCI_CLASS_DISPLAY_VGA
@@ -136,9 +137,24 @@ init_optionrom(struct rom_header *rom, u16 bdf, int isvga)
tpm_option_rom(newrom, rom->size * 512);
- if (isvga || get_pnp_rom(newrom))
+ struct pnp_data *pnp = get_pnp_rom(newrom);
+ if (isvga || pnp) {
+ struct segoff_s old19, new19;
// Only init vga and PnP roms here.
+ old19 = GET_IVT(0x19);
callrom(newrom, bdf);
+ new19 = GET_IVT(0x19);
+ if (old19.seg != new19.seg ||
+ old19.offset != new19.offset) {
+ dprintf(1, "WARNING! rom tried to hijack int19 "
+ "(vec %04x:%04x, pnp %s, bev %s, bvc %s)\n",
+ new19.seg, new19.offset,
+ pnp ? "yes" : "no",
+ pnp && pnp->bev ? "yes" : "no",
+ pnp && pnp->bcv ? "yes" : "no");
+ SET_IVT(0x19, old19);
+ }
+ }
return rom_confirm(newrom->size * 512);
}
--
2.9.3
According to SMBIOS Specification, section 6.1.3 Text Strings:
"Text strings associated with a given SMBIOS structure are returned in
the dmiStructBuffer, appended directly after the formatted portion of the
structure. This method of returning string information eliminates the
need for application software to deal with pointers embedded in the
SMBIOS structure. Each string is terminated with a null (00h) BYTE and
the set of strings is terminated with an additional null (00h) BYTE”
Furthermore:
"If the formatted portion of the structure contains string-reference
fields and all the string fields are set to 0 (no string references),
the formatted section of the structure is followed by two null (00h)
BYTES"
From the above it can be seen that any SMBIOS type which contains string
references should end with an additional zero byte.
This is currently handled in all SMBIOS types which use
load_str_field_with_default() besides type0.
Therefore, add the missing zero byte to SMBIOS Type 0.
Running QEMU with:
-machine pc-i440fx-2.0 (for legacy smbios)
-smbios type=0,vendor=,version=,date= (for zero str_index)
Will cause SMBIOS type0 entry to overrun type1 entry.
Reviewed-by: Ross Philipson <ross.philipson(a)oracle.com>
Reviewed-By: Liran Alon <liran.alon(a)oracle.com>
Signed-off-by: Sam Eiderman <shmuel.eiderman(a)oracle.com>
---
src/fw/smbios.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/src/fw/smbios.c b/src/fw/smbios.c
index f3b5ad9d..62a563b2 100644
--- a/src/fw/smbios.c
+++ b/src/fw/smbios.c
@@ -205,6 +205,10 @@ smbios_init_type_0(void *start)
*end = 0;
end++;
+ if (!str_index) {
+ *end = 0;
+ end++;
+ }
return end;
}
--
2.13.3
When I kexec either Xen or Linux in real mode, from either Xen or
Linux, it fails.
The last thing I see looks like SeaBIOS trying to use SMM for call32:
----------------
IN:
0x00000000000f70ec: mov %eax,%esi
0x00000000000f70ef: mov $0xb5,%eax
0x00000000000f70f5: mov $0x1234,%ecx
0x00000000000f70fb: mov $0xef3dc,%ebx
0x00000000000f7101: out %al,$0xb2
0x00000000000f7103: pause
----------------
IN:
0x00000000000ef3db: hlt
This happens when the real mode boot code calls INT 13h to read from
the disk. It seems to happen with virtio and SATA disks.
This is with the Ubuntu-packaged 1.10.2-1ubuntu1 SeaBIOS. Switching to
an IDE disk, or booting with 'edd=skipmbr', makes Xen work and Linux
get a little further before it dies anyway.
Hi,
I'm working on stuffing a bootable Linux distro into coreboot. In QEMU I
already succeded by using coreboot's built-in kernel loading mechanism, but
that's without SeaBIOS.
I'd love to have it as a SeaBIOS payload so I can also boot other things,
but I guess I'd have to create a custom-sized floppy image for this or
figure out how to create an ELF payload out of a Linux kernel (I'm open to
either, but I wasn't able to find any documentation on the ELF method).
The guy who put Win 3.1 in coreboot attempted the floppy method, but
according to his article he did not find success with this method due to
unknown and complex issues in the floppy-side logic of SeaBIOS.
So, I'm making the question explicit: What would it take to support
custom-sized floppy images? In particular, I'm thinking of a 16MB device...
Alternatively, would it be possible to create an ELF file out of a Linux
kernel+initrd / bootable image?
Cheers,
Rafael
Dear Gerd Hoffman,
If my advanced_bootmenu new patch ( [*] link below ) is not
upstream-able ( for what reasons? ), I will be happy if your
alternative solution gets merged - at least because it is better than
what's currently in SeaBIOS master. However, I just tested your
patches and noticed some issues which did not exist at my original
version [*] - https://mail.coreboot.org/hyperkitty/list/seabios@seabios.org/thread/CKWL...
. I hope that you could review my feedback and address at least some
of them :
1) It is not possible to choose the boot entry by a single key press
of a fullsize keyboard. We have so many keyboard keys, why are we
limited to 1234567890 ? Seems inefficient. The alternative way, which
I followed, is to continue with qwertyuiop etc. - to utilize 4 rows of
keyboard keys - and make a single key press selection possible.
2) If there are >10 menu entries and you accidentally press '0'
instead of '1', there is no way to backspace/delete this wrong
character. Although, if there is an ability to remove the wrong
characters, then a confirmation of a correct input (e.g. by pressing
the Enter key) is also needed - to confirm that your last character
wasn't wrong. I implemented this mini console interface in my version
- but only for a numpad; for keyboard it wasn't needed because it is a
single key boot there.
3) If there are >20 menu entries, the first menu entries may not fit
on a screen. (That's why I had to add 2 pages support.) Perhaps you
think it's unlikely that anyone would need >20 menu entries: however,
if you are a floppy-based OS developer who is debugging something that
could be reproduced only at bare metal (so no QEMU) - you may want to
add a lot of different versions of your floppy to your coreboot build
- to reduce the amount of BIOS chip reflashes and just for your
convenience. I stopped at 35 max simply because ran out of keyboard
letter keys (could have gone double-letter but wanted to preserve a
single key boot).
4) Although a few USB numpads do have an Escape key (e.g. Motospeed
K23), the majority of them do not - so it is impossible for them to
open a boot menu by pressing Escape - simply because no such key.
(That's why I added "/" character to the menukeys - every USB numpad
has this key.) Also, in your patch version it's not possible to access
TPM from a numpad because no t or m keys on it - so I had to add '-'
character to the menukeys.
To summarize, perhaps the only advantage of your current patch version
is that it is 3 times smaller, so 3 times more likely to be merged.
However it doesn't necessarily mean that my original patch is
inefficient or bloated: I optimized it as best as I could, and quite
sure that if you'd have tried to implement the features mentioned
above - as well as some others I may have forgot to mention - then
your patch linecount would've jumped too.
P.S. If there are any issues with my patch, which have persuaded you
to create your own version (aside from the size issue) - I am open to
suggestions and could try to address them when I will have enough free
time.
Best regards,
Mike Banon
Dear SeaBIOS folks,
It was announced already on the coreboot mailing list [1], so some might
already know this.
redsPL got SeaBIOS and a Win 3.1 (floppy disk) (with coreboot) booting [2].
> Because the standard coreboot payload with SeaBIOS only occupies only
> about 1MB out of the full 8 on the ROM, I thought about embedding a
> full OS on the remaining 7 megs. It turns out that SeaBIOS has
> partial support for booting from flash - it sets up a virtual floppy
> drive with your floppy of choice loaded from floppyimg/<name>.lzma,
> but this gives us at best 2.88MB (standard ED floppy disk size,
> exactly 2x as large as a popular 1.44M), and I wanted more.
I guess it should be reproducible in QEMU too.
Kind regards,
Paul
[1]: https://mail.coreboot.org/hyperkitty/list/coreboot@coreboot.org/thread/2Q...
[2]: https://sakamoto.pl/weblog/07-windows-3-flash-edition/
