SeaBIOS

seabios@seabios.org

4 participants
3801 discussions

[CCE 3944-6] Option to disable booting from USB devices
by Fred . 22 Aug '12

22 Aug '12

CCE 3944-6 http://nvd.nist.gov/scap/content/stylesheet/scap-rhel5-document.htm "An attacker with physical access could try to boot the system from a USB flash drive and then access any data on the system’s hard drive, circumventing the normal operating system’s access controls. To prevent this, configure the BIOS to disallow booting from USB drives. Also configure the BIOS or firmware password as described in Section 2.3.5.1 to prevent unauthorized configuration changes."

1 0

Re: [SeaBIOS] Data exchange between coreboot - seabios - option rom
by Kevin O'Connor 22 Aug '12

22 Aug '12

On Tue, Aug 21, 2012 at 04:57:56PM +0200, Christian Gmeiner wrote: > 2012/8/21 Christian Gmeiner <christian.gmeiner(a)gmail.com>: > > Hi all, > > > > my vacation is over and I need to look in some stuff deeper to finally > > get the combination coreboot/seabios fully working. The only missing part > > aside from a lot of testing is the video bios stuff. Here I am working on > > a patch series to extend seabios vga option rom to support flat panels. > > > > I would like to to use EPI (http://www.epi-standard.org/) for the description > > of the panels. Due EOL changes my target hardware supports different > > kind of flat panels (with different timings). I can detect what panel is used > > with the help of an i2c eeprom. So the normal CBFS will be extended by > > n EPI raw files. And here the troubles begins :) > > > > 1) Can I add symbolic links during runtime > > > > It would be fine if somewhere during the boot (coreboot or seabios) I > > can readout > > the needed bytes from the eeprom, decide which EPI file to use and create > > something line a symlink to the choosen one. > > > > panel.epi -> 640_480_panel_name.epi I don't know of anyway to do this. The effort to implement this would probably be large. > As I found out this can be done via nvram. So coreboot set the filename of the > EPI file to use and seabios/... etc can simply use it. Using CMOS for passing temporary variables around is quite ugly. I'd recommend against it. > > 2) Can I load a CBFS file in the option rom? > > > > The idea is to load the EPI raw file and provide it via VBE (vbe_104f15) BIOS > > call. So the geode lx option rom can read out the timing informations via VBE > > and setup the video mode. It's possible. However, the vgabios currently runs in 16bit mode. Getting the existing CBFS code to run in 16bit mode would be a pain. Probably better to convert the vgabios init phase to jump into 32bit mode. However, that is a bit of work. > It could also be possible to store the EPI data at a defined memory > area where the > option rom can simply check for existing identifiers and checksum. I'd recommend against that - magic areas of memory have been quite troublesome in the past. > Any hints are really welcome. I'm not sure I fully understand your requirements. Will the board truly have different flat screens hooked up to it? One can't simply compile the EPI info into the BIOS? Also, if you have to interrogate the display via i2c, can you simply fully generate the EPI info in the vgabios at runtime? -Kevin

2 1

Re: [SeaBIOS] Data exchange between coreboot - seabios - option rom
by Christian Gmeiner 21 Aug '12

21 Aug '12

2012/8/21 Christian Gmeiner <christian.gmeiner(a)gmail.com>: > Hi all, > > my vacation is over and I need to look in some stuff deeper to finally > get the combination coreboot/seabios fully working. The only missing part > aside from a lot of testing is the video bios stuff. Here I am working on > a patch series to extend seabios vga option rom to support flat panels. > > I would like to to use EPI (http://www.epi-standard.org/) for the description > of the panels. Due EOL changes my target hardware supports different > kind of flat panels (with different timings). I can detect what panel is used > with the help of an i2c eeprom. So the normal CBFS will be extended by > n EPI raw files. And here the troubles begins :) > > 1) Can I add symbolic links during runtime > > It would be fine if somewhere during the boot (coreboot or seabios) I > can readout > the needed bytes from the eeprom, decide which EPI file to use and create > something line a symlink to the choosen one. > > panel.epi -> 640_480_panel_name.epi > As I found out this can be done via nvram. So coreboot set the filename of the EPI file to use and seabios/... etc can simply use it. > 2) Can I load a CBFS file in the option rom? > > The idea is to load the EPI raw file and provide it via VBE (vbe_104f15) BIOS > call. So the geode lx option rom can read out the timing informations via VBE > and setup the video mode. > It could also be possible to store the EPI data at a defined memory area where the option rom can simply check for existing identifiers and checksum. Any hints are really welcome. --- Christian Gmeiner, MSc

1 0

Data exchange between coreboot - seabios - option rom
by Christian Gmeiner 21 Aug '12

21 Aug '12

Hi all, my vacation is over and I need to look in some stuff deeper to finally get the combination coreboot/seabios fully working. The only missing part aside from a lot of testing is the video bios stuff. Here I am working on a patch series to extend seabios vga option rom to support flat panels. I would like to to use EPI (http://www.epi-standard.org/) for the description of the panels. Due EOL changes my target hardware supports different kind of flat panels (with different timings). I can detect what panel is used with the help of an i2c eeprom. So the normal CBFS will be extended by n EPI raw files. And here the troubles begins :) 1) Can I add symbolic links during runtime It would be fine if somewhere during the boot (coreboot or seabios) I can readout the needed bytes from the eeprom, decide which EPI file to use and create something line a symlink to the choosen one. panel.epi -> 640_480_panel_name.epi 2) Can I load a CBFS file in the option rom? The idea is to load the EPI raw file and provide it via VBE (vbe_104f15) BIOS call. So the geode lx option rom can read out the timing informations via VBE and setup the video mode. The result should be something like this: http://www.youtube.com/watch?v=83CDqJMblkw greets --- Christian Gmeiner, MSc

1 0

Big real mode use in ipxe
by Avi Kivity 19 Aug '12

19 Aug '12

ipxe contains the following snippet: /* Copy ROM to image source PMM block */ pushw %es xorw %ax, %ax movw %ax, %es movl %esi, %edi xorl %esi, %esi movzbl romheader_size, %ecx shll $9, %ecx addr32 rep movsb /* PMM presence implies flat real mode */ Which copies an image to %edi, with %edi >= 0x10000. This is in accordance with the PMM spec: "3.2.4 Accessing Extended Memory This section specifies how clients should access extended memory blocks allocated by the PMM. When control is passed to an option ROM from a BIOS that supports PMM, the processor will be in big real mode, and Gate A20 will be disabled (segment wrap turned off). This allows access to extended memory blocks using real mode addressing. In big real mode, access to memory above 1MB can be accomplished by using a 32-bit extended index register (EDI, etc.) and setting the segment register to 0000h. The following code example assumes that the pmmAllocate function was just called to allocate a block of extended memory, and DX:AX returned the 32-bit buffer address. ; Assume here that DX:AX contains the 32-bit address of our allocated buffer. ; Clear the DS segment register. push 0000h pop ds ; Put the DX:AX 32-bit buffer address into EDI. mov di, dx ; Get the upper word. shl edi, 16 ; Shift it to upper EDI. mov di, ax ; Get the lower word. ; Example: clear the first four bytes of the extended memory buffer. mov [edi], 00000000h ; DS:EDI is used as the memory pointer. In a similar way, the other segment registers and 32-bit index registers can be used for extended memory accessing." So far so good. But the Intel SDM says (20.1.1): "The IA-32 processors beginning with the Intel386 processor can generate 32-bit offsets using an address override prefix; however, in real-address mode, the value of a 32-bit offset may not exceed FFFFH without causing an exception. For full compatibility with Intel 286 real-address mode, pseudo-protection faults (interrupt 12 or 13) occur if a 32-bit offset is generated outside the range 0 through FFFFH." Which is exactly what happens here. My understanding of big real mode is that to achieve a segment limit != 0xffff, you must go into 32-bit protected mode, load a segment with a larger limit, and return into real mode without touching the segment. The next load of the segment will reset the limit to 0xffff. Due to bugs in both qemu tcg and kvm, limit checks are not enforced in real mode, but once this bugs are fixed, the code above will break. The PMM spec also has this to say (1.3): "Big Real Mode Big Real Mode is a modified version of the processor’s real mode with the segment limits changed from 1MB to 4GB. Big real mode allows the BIOS or an Option ROM to read and write extended memory without the overhead of protected mode. The BIOS puts the processor in big real mode during POST to allow simplified access to extended memory. The processor will be in big real mode while the PMM Services are callable." This is more in line with the Intel spec, and means that the modification to %es must be avoided (and that seabios needs changes to either work in big real mode, or to put the processor back into big real mode after returning from a PMM service. The whole thing is very unfortunate, as kvm is very slow while in big real mode, on certain processors. -- error compiling committee.c: too many arguments to function

3 5

Re: [SeaBIOS] WinXP 32 installation failure with new SeaBIOS in QEMU
by Avi Kivity 19 Aug '12

19 Aug '12

On 08/19/2012 12:27 PM, Avi Kivity wrote: > On 08/17/2012 08:53 AM, Gerd Hoffmann wrote: >> Hi, >> >>> It might be instruction emulator bug in KVM. >>> Attached is the trace. >> >> qemu-2047 [000] d..2 261.999076: kvm_entry: vcpu 0 >> qemu-2047 [000] ...1 261.999077: kvm_emulate_insn: >> f0000:6201:fb (real) >> qemu-2047 [000] d..2 261.999078: kvm_entry: vcpu 0 >> ##### CPU 3 buffer started #### >> qemu-2047 [003] ...1 411.367592: kvm_emulate_insn: >> 20000:26c:cb (prot16) >> qemu-2047 [003] ...1 411.367593: kvm_inj_exception: #GP >> (0x844) >> qemu-2047 [003] d..2 411.367594: kvm_entry: vcpu 0 >> >> This looks suspious. vcpu migration issue? Or just something missing >> in the trace? >> > > Looks like tracing with a too-small buffer size. I generally trace using > > trace-cmd record -e kvm -b 100000 > > and with fingers crossed. > > The RET FAR instruction failure (which trace-cmd report decodes) is > probably not the original failure. In fact it is, we mis-emulated stack operations when SS.B=0 but the address size was 32-bits, and there are bits set in the top 16 bits of ESP. Why ESP has bits set in the top 16 bits is another question. Is seabios polluting those bits? -- error compiling committee.c: too many arguments to function

2 2

The cbfs header for a payloads dest addr is a u64, use ntohll instead of ntohl
by Dave Frodin 15 Aug '12

15 Aug '12

All, I found an issue with seabios when it is attempting to download and execute a payload that has been added to a coreboot rom image img/ directory. The cbfs header has a destination address of "u64 load_addr". The code that reads the destination address out of the header is using ntohl which only works on u32, so the address that the cbfstool puts in the header, 0x00000000000100000 gets converted to 0x00000000. I couldn't find where there was 64 bit version of the ntohl ftn/macro so I copied one out of coreboot. Feel free to change where/how the ntohll gets implemented. Thanks, Dave Frodin P.S. Thanks to whomever came up with the img/payload method of adding payloads. It's slick. diff --git a/src/coreboot.c b/src/coreboot.c index e116a14..4efec9c 100644 --- a/src/coreboot.c +++ b/src/coreboot.c @@ -470,6 +470,17 @@ struct cbfs_payload { struct cbfs_payload_segment segments[1]; }; +#define ntohll(x) \ + ((u64)( \ + (((u64)(x) & (u64)0x00000000000000ffULL) << 56) | \ + (((u64)(x) & (u64)0x000000000000ff00ULL) << 40) | \ + (((u64)(x) & (u64)0x0000000000ff0000ULL) << 24) | \ + (((u64)(x) & (u64)0x00000000ff000000ULL) << 8) | \ + (((u64)(x) & (u64)0x000000ff00000000ULL) >> 8) | \ + (((u64)(x) & (u64)0x0000ff0000000000ULL) >> 24) | \ + (((u64)(x) & (u64)0x00ff000000000000ULL) >> 40) | \ + (((u64)(x) & (u64)0xff00000000000000ULL) >> 56) )) + void cbfs_run_payload(struct cbfs_file *file) { @@ -480,7 +491,7 @@ cbfs_run_payload(struct cbfs_file *file) struct cbfs_payload_segment *seg = pay->segments; for (;;) { void *src = (void*)pay + ntohl(seg->offset); - void *dest = (void*)ntohl((u32)seg->load_addr); + void *dest = (void*)ntohll((u64)seg->load_addr); u32 src_len = ntohl(seg->len); u32 dest_len = ntohl(seg->mem_len); switch (seg->type) {

3 5

[PULL 0/1] update qemu seabios / seabios release?
by Gerd Hoffmann 14 Aug '12

14 Aug '12

Hi, This pull updates seabios in qemu to the latest bits from seabios master, so the upcoming 1.2 qemu release gets all the new shiny stuff added recently. I'd like to have a new seabios release for inclusion into qemu 1.2 which is planned for September 1st. So how about this plan: - merge seabios snapshot now (this pull req), so it gets testing in the qemu testing & release candidates phase - put seabios into bugfixing freeze too (now or in a few days), fix any issues poping up in testing. - roll out seabios release by end of august, so it can be included into qemu 1.2 Anthony? Kevin? Fine are you ok with this? qemu release schedule is here: http://wiki.qemu.org/Planning/1.2 cheers, Gerd Gerd Hoffmann (1): update seabios to latest master pc-bios/bios.bin | Bin 131072 -> 131072 bytes roms/seabios | 2 +- 2 files changed, 1 insertions(+), 1 deletions(-) The following changes since commit 0b8db8fe15d17a529a5ea90614c11e9f031dfee8: slirp: fix build on mingw32 (2012-08-06 19:31:55 -0500) are available in the git repository at: git://git.kraxel.org/qemu seabios-5a02306 Gerd Hoffmann (1): update seabios to latest master pc-bios/bios.bin | Bin 131072 -> 131072 bytes roms/seabios | 2 +- 2 files changed, 1 insertions(+), 1 deletions(-)

3 5

[PATCH v2 0/2] Add IPMI SMBIOS/ACPI support
by minyard＠acm.org 14 Aug '12

14 Aug '12

I went ahead and kept the structure passing because I've added ACPI support. After thinking about it a while, I think if you have to pass anything to SMBIOS (like "IPMI is present") you might as well pass the whole structure, and making things fixed in the BIOS that can change in the hardware doesn't seem like a good idea. Note that the acpi-element code might make building the SSDT table a little cleaner, if that is interesting.

4 13

[PATCH] add acpi pmtimer support
by Gerd Hoffmann 14 Aug '12

14 Aug '12

This patch makes seabios use the acpi pmtimer instead of tsc for timekeeping. The pmtimer has a fixed frequency and doesn't need calibration, thus it doesn't suffer from calibration errors due to a loaded host machine. Signed-off-by: Gerd Hoffmann <kraxel(a)redhat.com> --- src/clock.c | 29 +++++++++++++++++++++++++++++ src/pciinit.c | 5 +++++ src/util.h | 1 + 3 files changed, 35 insertions(+), 0 deletions(-) diff --git a/src/clock.c b/src/clock.c index 69e9f17..59f269b 100644 --- a/src/clock.c +++ b/src/clock.c @@ -129,11 +129,40 @@ emulate_tsc(void) return ret; } +u16 pmtimer_ioport VAR16VISIBLE; +u32 pmtimer_wraps VARLOW; +u32 pmtimer_last VARLOW; + +void pmtimer_init(u16 ioport, u32 khz) +{ + dprintf(1, "Using pmtimer, ioport 0x%x, freq %d kHz\n", ioport, khz); + SET_GLOBAL(pmtimer_ioport, ioport); + SET_GLOBAL(cpu_khz, khz); +} + +static u64 pmtimer_get(void) +{ + u16 ioport = GET_GLOBAL(pmtimer_ioport); + u32 wraps = GET_LOW(pmtimer_wraps); + u32 pmtimer = inl(ioport); + + if (pmtimer < GET_LOW(pmtimer_last)) { + wraps++; + SET_LOW(pmtimer_wraps, wraps); + } + SET_LOW(pmtimer_last, pmtimer); + + dprintf(9, "pmtimer: %u:%u\n", wraps, pmtimer); + return (u64)wraps << 24 | pmtimer; +} + static u64 get_tsc(void) { if (unlikely(GET_GLOBAL(no_tsc))) return emulate_tsc(); + if (GET_GLOBAL(pmtimer_ioport)) + return pmtimer_get(); return rdtscll(); } diff --git a/src/pciinit.c b/src/pciinit.c index 68f302a..31115ee 100644 --- a/src/pciinit.c +++ b/src/pciinit.c @@ -180,6 +180,9 @@ static const struct pci_device_id pci_class_tbl[] = { PCI_DEVICE_END, }; +/* PM Timer ticks per second (HZ) */ +#define PM_TIMER_FREQUENCY 3579545 + /* PIIX4 Power Management device (for ACPI) */ static void piix4_pm_init(struct pci_device *pci, void *arg) { @@ -191,6 +194,8 @@ static void piix4_pm_init(struct pci_device *pci, void *arg) pci_config_writeb(bdf, 0x80, 0x01); /* enable PM io space */ pci_config_writel(bdf, 0x90, PORT_SMB_BASE | 1); pci_config_writeb(bdf, 0xd2, 0x09); /* enable SMBus io space */ + + pmtimer_init(PORT_ACPI_PM_BASE + 0x08, PM_TIMER_FREQUENCY / 1000); } static const struct pci_device_id pci_device_tbl[] = { diff --git a/src/util.h b/src/util.h index 89e928c..1603a57 100644 --- a/src/util.h +++ b/src/util.h @@ -312,6 +312,7 @@ void lpt_setup(void); // clock.c #define PIT_TICK_RATE 1193180 // Underlying HZ of PIT #define PIT_TICK_INTERVAL 65536 // Default interval for 18.2Hz timer +void pmtimer_init(u16 ioport, u32 khz); int check_tsc(u64 end); void timer_setup(void); void ndelay(u32 count); -- 1.7.1

3 2

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

SeaBIOS