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
The following two patches add a menu item to the TPM 2.0 menu that allows
a user to activate and deactivate the PCR banks the attached TPM 2.0
supports.
This operation has to be done while in the firmware.
Stefan
v2->v3:
- Activate the selection of activate PCR banks right from the menu
- Undo some other changes, such as #define in src/utils.h
v1->v2:
- Refactor existing function for looking up the buffer size a hash needs
to use a table instead; we extend the table then in patch 2
Stefan Berger (2):
tcgbios: Use table to convert hash to buffer size
tcgbios: Implement TPM 2.0 menu item to activate and deactivate PCR
banks
src/std/tcg.h | 17 ++++
src/tcgbios.c | 264 +++++++++++++++++++++++++++++++++++++++++++++++---
2 files changed, 268 insertions(+), 13 deletions(-)
--
2.17.2
Specifically added support for 16 and 32bpp files, in addition to 24bpp.
The function bmp_show() in bmp.c has had the hardcoded check for 24bpp replaced with a general
bpp check that uses a % to check for remainder, and returns 1 if the remainder is >0.
The previous method for adjusting the BMP data (raw_data_format_adjust_24bpp) relied
on a preset 3*bytes_per_line_src, this has been changed and the multiplication is now performed
in the function's arguments. This change still allows someone else to reuse the same function for
1/2/4bpp support if necessary. The file util.h has been modified to reflect this decision.
The changes to raw_data_format_adjust() is based on an
abandoned patch by Gert Menke (submitted March 14, 2017),
credit to them for that change and the addition of *bpp to bmp_get_info().
Any feedback? I would appreciate it.
Signed-off-by: Joseph S. Pacheco-Corwin <hammersamatom(a)gmail.com>
---
src/bmp.c | 19 +++++++++----------
src/bootsplash.c | 17 +++++++++++++----
src/util.h | 2 +-
3 files changed, 23 insertions(+), 15 deletions(-)
diff --git a/src/bmp.c b/src/bmp.c
index 96a2b3f..fecc295 100644
--- a/src/bmp.c
+++ b/src/bmp.c
@@ -56,10 +56,9 @@ typedef struct tagRGBQUAD {
* arrange horizontal pixel data, add extra space in the dest buffer
* for every line
*/
-static void raw_data_format_adjust_24bpp(u8 *src, u8 *dest, int width,
- int height, int bytes_per_line_dest)
+static void raw_data_format_adjust(u8 *src, u8 *dest, int width,
+ int height, int bytes_per_line_src, int bytes_per_line_dest)
{
- int bytes_per_line_src = 3 * width;
int i;
for (i = 0 ; i < height ; i++) {
memcpy(dest + i * bytes_per_line_dest,
@@ -95,22 +94,22 @@ int bmp_decode(struct bmp_decdata *bmp, unsigned char *data, int data_size)
}
/* get bmp properties */
-void bmp_get_size(struct bmp_decdata *bmp, int *width, int *height)
+void bmp_get_info(struct bmp_decdata *bmp, int *width, int *height, int *bpp)
{
*width = bmp->width;
*height = bmp->height;
+ *bpp = bmp->bpp;
}
/* flush flat picture data to *pc */
-int bmp_show(struct bmp_decdata *bmp, unsigned char *pic, int width
- , int height, int depth, int bytes_per_line_dest)
+int bmp_show(struct bmp_decdata *bmp, unsigned char *pic, int width,
+ int height, int depth, int bytes_per_line_dest)
{
if (bmp->datap == pic)
return 0;
- /* now only support 24bpp bmp file */
- if ((depth == 24) && (bmp->bpp == 24)) {
- raw_data_format_adjust_24bpp(bmp->datap, pic, width, height,
- bytes_per_line_dest);
+ if ((depth == bmp->bpp) && (bmp->bpp%8 == 0)) {
+ raw_data_format_adjust(bmp->datap, pic, width, height,
+ (bmp->bpp/8)*width, bytes_per_line_dest);
return 0;
}
return 1;
diff --git a/src/bootsplash.c b/src/bootsplash.c
index 165c98d..401c348 100644
--- a/src/bootsplash.c
+++ b/src/bootsplash.c
@@ -172,10 +172,13 @@ enable_bootsplash(void)
dprintf(1, "bmp_decode failed with return code %d...\n", ret);
goto done;
}
- bmp_get_size(bmp, &width, &height);
- bpp_require = 24;
+ bmp_get_info(bmp, &width, &height, &bpp_require);
}
- /* jpeg would use 16 or 24 bpp video mode, BMP use 24bpp mode only */
+
+ /* jpeg would use 16 or 24 bpp video mode, BMP uses 8/16/24/32 bpp mode.
+ * 8bpp for BMP has corrupted colors, and lower than 8bpp fails to display
+ * or results in a loop.
+ */
// Try to find a graphics mode with the corresponding dimensions.
int videomode = find_videomode(vesa_info, mode_info, width, height,
@@ -192,7 +195,13 @@ enable_bootsplash(void)
dprintf(3, "bytes per scanline: %d\n", mode_info->bytes_per_scanline);
dprintf(3, "bits per pixel: %d\n", depth);
- // Allocate space for image and decompress it.
+ // Allocate space for image and decompress it.
+ /*
+ * Has a weird issue with low bpp image files, imagesize is not
+ * consistent. Example: 8bpp images are correct, being essentially
+ * multiplied/divided by 1, but if you use 4bpp images, width is divided by
+ * 8, when it should be divided by 2.
+ */
int imagesize = height * mode_info->bytes_per_scanline;
picture = malloc_tmphigh(imagesize);
if (!picture) {
diff --git a/src/util.h b/src/util.h
index 6dd080f..9c06850 100644
--- a/src/util.h
+++ b/src/util.h
@@ -12,7 +12,7 @@ void handle_1553(struct bregs *regs);
// bmp.c
struct bmp_decdata *bmp_alloc(void);
int bmp_decode(struct bmp_decdata *bmp, unsigned char *data, int data_size);
-void bmp_get_size(struct bmp_decdata *bmp, int *width, int *height);
+void bmp_get_info(struct bmp_decdata *bmp, int *width, int *height, int *bpp);
int bmp_show(struct bmp_decdata *bmp, unsigned char *pic, int width
, int height, int depth, int bytes_per_line_dest);
--
2.20.1
The following two patches add a menu item to the TPM 2.0 menu that allows
a user to activate and deactivate the PCR banks the attached TPM 2.0
supports.
This operation has to be done while in the firmware.
Stefan
v1->v2:
- Refactor existing function for looking up the buffer size a hash needs
to use a table instead; we extend the table then in patch 2
Stefan Berger (2):
tcgbios: Use table to convert hash to buffer size
tcgbios: Implement TPM 2.0 menu item to activate and deactivate PCR
banks
src/std/tcg.h | 18 ++++
src/tcgbios.c | 270 +++++++++++++++++++++++++++++++++++++++++++++++---
src/util.h | 2 +
3 files changed, 275 insertions(+), 15 deletions(-)
--
2.17.2
Hi Ivan,
On 03.04.2018 20:03, Ivan Ivanov wrote:
> I have noticed that both coreboot and seabios are using the very old
> versions of LZMA SDK.
True. I introduced the lzma code in coreboot (back when it was called
LinuxBIOS) when we were working on OLPC XO-1 support.
> If we will upgrade our LZMA libraries from the
> outdated-by-12-years 4.42 to the current version 18.04 , speed and
> compression ratio should improve and maybe a few bugs will be fixed.
Do you have any numbers for this? An improved compression ratio and
improved speed would be nice indeed, but how does the size of the
decompression code change? If the decompression code grows more than the
size reduction from better compression, it would be a net loss. A
significantly reduced decompression speed would also be a problem.
Decompression speed would have to be measured both for stream
decompression (i.e. the decompressor gets the compressed data in
single-byte or multibyte chunks) as well as full-size decompression
(i.e. the decompressor can access all compressed data at once). We also
have to make sure that stream decompression still works after the change.
> Do you think it should be done, or you are OK with using such an
> outdated version?
A size benefit for the resulting image is a good reason to switch.
Regards,
Carl-Daniel
FYI, the SeaBIOS mailing list backend was recently updated (upgrade to
Mailman3). Service should not be impacted, but if anyone does
experience an issue then please let me know.
Cheers,
-Kevin
