SeaBIOS

seabios@seabios.org

5 participants
3802 discussions

Re: [SeaBIOS] Running privilege code on hidden O.S.
by Fred . 08 Jun '13

08 Jun '13

Sounds like a rootkit. On Thu, Jun 6, 2013 at 9:35 PM, Jerry Backer <bataille16(a)gmail.com> wrote: > Hi, > > The idea is to run some security and packet inspection codes on the hidden > core. > There is a typo on the title, it should be 'Running privilege code on > hidden core'. > > Thanks, > > > On Thu, Jun 6, 2013 at 3:04 PM, Fred . <eldmannen(a)gmail.com> wrote: > >> I am curious as to why you would want to do such a thing... >> >> >> On Thu, Jun 6, 2013 at 6:52 PM, Jerry Backer <bataille16(a)gmail.com>wrote: >> >>> Hello, >>> >>> I am using seaBIOS with QEMU and am attempting to hide a processor core >>> (on an smp system) from the O.S. and then load a dedicated code on that >>> core before boot. I have managed to hide one of the cores by decreasing >>> CountCPUs (within smp.c) after running the ap core code, hence the BIOS >>> load info for 1 less core on the mp table. >>> >>> However, I have not been able to figure out how to load the privileged >>> code. My intuition was to load it when the hidden core enters protected >>> mode before running kernel code. But I don't see where in the code the >>> cores go into protected mode during boot. >>> >>> Can anyone give me some insight on how to proceed? >>> >>> Thanks, >>> >>> -- >>> Jerry >>> >>> _______________________________________________ >>> SeaBIOS mailing list >>> SeaBIOS(a)seabios.org >>> http://www.seabios.org/mailman/listinfo/seabios >>> >>> >> > > > -- > Jerry Backer >

1 0

Re: [SeaBIOS] Running privilege code on hidden O.S.
by Jerry Backer 06 Jun '13

06 Jun '13

Hi, The idea is to run some security and packet inspection codes on the hidden core. There is a typo on the title, it should be 'Running privilege code on hidden core'. Thanks, On Thu, Jun 6, 2013 at 3:04 PM, Fred . <eldmannen(a)gmail.com> wrote: > I am curious as to why you would want to do such a thing... > > > On Thu, Jun 6, 2013 at 6:52 PM, Jerry Backer <bataille16(a)gmail.com> wrote: > >> Hello, >> >> I am using seaBIOS with QEMU and am attempting to hide a processor core >> (on an smp system) from the O.S. and then load a dedicated code on that >> core before boot. I have managed to hide one of the cores by decreasing >> CountCPUs (within smp.c) after running the ap core code, hence the BIOS >> load info for 1 less core on the mp table. >> >> However, I have not been able to figure out how to load the privileged >> code. My intuition was to load it when the hidden core enters protected >> mode before running kernel code. But I don't see where in the code the >> cores go into protected mode during boot. >> >> Can anyone give me some insight on how to proceed? >> >> Thanks, >> >> -- >> Jerry >> >> _______________________________________________ >> SeaBIOS mailing list >> SeaBIOS(a)seabios.org >> http://www.seabios.org/mailman/listinfo/seabios >> >> > -- Jerry Backer

1 0

Re: [SeaBIOS] Running privilege code on hidden O.S.
by Fred . 06 Jun '13

06 Jun '13

I am curious as to why you would want to do such a thing... On Thu, Jun 6, 2013 at 6:52 PM, Jerry Backer <bataille16(a)gmail.com> wrote: > Hello, > > I am using seaBIOS with QEMU and am attempting to hide a processor core > (on an smp system) from the O.S. and then load a dedicated code on that > core before boot. I have managed to hide one of the cores by decreasing > CountCPUs (within smp.c) after running the ap core code, hence the BIOS > load info for 1 less core on the mp table. > > However, I have not been able to figure out how to load the privileged > code. My intuition was to load it when the hidden core enters protected > mode before running kernel code. But I don't see where in the code the > cores go into protected mode during boot. > > Can anyone give me some insight on how to proceed? > > Thanks, > > -- > Jerry > > _______________________________________________ > SeaBIOS mailing list > SeaBIOS(a)seabios.org > http://www.seabios.org/mailman/listinfo/seabios > >

1 0

Running privilege code on hidden O.S.
by Jerry Backer 06 Jun '13

06 Jun '13

Hello, I am using seaBIOS with QEMU and am attempting to hide a processor core (on an smp system) from the O.S. and then load a dedicated code on that core before boot. I have managed to hide one of the cores by decreasing CountCPUs (within smp.c) after running the ap core code, hence the BIOS load info for 1 less core on the mp table. However, I have not been able to figure out how to load the privileged code. My intuition was to load it when the hidden core enters protected mode before running kernel code. But I don't see where in the code the cores go into protected mode during boot. Can anyone give me some insight on how to proceed? Thanks, -- Jerry

1 0

[PATCH RFC v2 1/2] ec: add ASL for ACPI Embedded Controller
by liguang 06 Jun '13

06 Jun '13

Signed-off-by: liguang <lig.fnst(a)cn.fujitsu.com> --- src/acpi-dsdt-isa.dsl | 26 ++++++++++++++++++++++++++ 1 files changed, 26 insertions(+), 0 deletions(-) diff --git a/src/acpi-dsdt-isa.dsl b/src/acpi-dsdt-isa.dsl index 23761db..2b9c3a0 100644 --- a/src/acpi-dsdt-isa.dsl +++ b/src/acpi-dsdt-isa.dsl @@ -99,4 +99,30 @@ Scope(\_SB.PCI0.ISA) { IRQNoFlags() { 3 } }) } + + Device (EC0) { + Name(_HID, EISAID ("PNP0C09")) + Name(_UID, 1) + + Method(_CRS, 0) { + Name(BFFR, ResourceTemplate() { + IO(Decode16, 0x62, 0x62, 0, 1) // ACPI DATA IN/OUT + IO(Decode16, 0x66, 0x66, 0, 1) // CMD/STS + }) + Return(BFFR) + } + + OperationRegion(ECFD, EmbeddedControl, 0, 0xFF) + Field(ECFD, ByteAcc, Lock, Preserve) { + Offset(1), + CPUS, 8, // 1, CPU plug/unplug status map + CPUN, 8, // 2, CPU index + } + + Name(_GPE, 3) + + Method(_Q01) { + } + } + } -- 1.7.2.5

1 1

Re: [SeaBIOS] [PATCH] Seabios: allow mapping of multiple PCI option ROMs to one
by Dave Frodin 05 Jun '13

05 Jun '13

Kevin, Attached is the new option rom mapping patch. I was hunting around for an existing SeaBIOS ftn that would convert ascii strings to a binary value (i.e. sscanf) but couldn't find one. If there's already one in the code I can replace the text_to_binary() with it. I tested this on a AMD family14 platform. The vendev-map file I added to CBFS looks like this... 10029803-10029802 10029804-10029802 10029805-10029802 10029806-10029802 10029807-10029802 10029808-10029802 10029809-10029802 Each line ends with a NEWLINE character (0x0A). On my test platform the actual graphics ID of the part is 10029804. The vgabios gets added to CBFS with the name "pci1002,9802.rom". Thanks, Dave

1 0

[PATCH v3] config: allow DEBUG_IO for !QEMU
by Gerd Hoffmann 05 Jun '13

05 Jun '13

Allow selecting DEBUG_IO for non-qemu configurations, which is useful when running coreboot+seabios on qemu. [ v2: QEMU_HARDWARE is even better as DEBUG_IO default value ] [ v3: make QEMU_HARDWARE usage consistent with other config options, fix spellings in commit message ] Signed-off-by: Gerd Hoffmann <kraxel(a)redhat.com> --- src/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/Kconfig b/src/Kconfig index 3c80132..5882d11 100644 --- a/src/Kconfig +++ b/src/Kconfig @@ -425,7 +425,7 @@ menu "Debugging" Base port for serial - generally 0x3f8, 0x2f8, 0x3e8, or 0x2e8. config DEBUG_IO - depends on QEMU && DEBUG_LEVEL != 0 + depends on QEMU_HARDWARE && DEBUG_LEVEL != 0 bool "Special IO port debugging" default y help -- 1.7.9.7

4 10

Re: [SeaBIOS] [Qemu-devel] [PATCH RFC 00/13] qemu: generate acpi tables for the guest
by Anthony Liguori 04 Jun '13

04 Jun '13

Jordan Justen <jljusten(a)gmail.com> writes: > On Tue, May 14, 2013 at 6:34 AM, Anthony Liguori <anthony(a)codemonkey.ws> wrote: >> "Michael S. Tsirkin" <mst(a)redhat.com> writes: >> >>> On Mon, May 13, 2013 at 03:38:51PM -0500, Anthony Liguori wrote: >>>> I don't think it's a good idea to move BIOS functionality in QEMU. >>> >>> Just to clarify: generating ACPI tables is not BIOS >>> functionality. It ended up in seabios for historical >>> reasons. >>> >>> A normal scenario for ACPI tables is that they are written >>> in ASL and compiled with IASL. >> >> I wouldn't call this the normal scenario. Some tables are static but >> more tables are dynamic than you'd think. If you're a firmware engineer >> and you have to support dozens of platforms, it's much easier to make >> the tables dynamic than attempt to maintain dozens of ASL descriptions. > > Anthony is right. Firmware for "real" systems contains the tables as > binary aml output from the asl compiler, but also goes through > extensive hoops to tweak the ACPI information. > > On the other hand, "real firmware" doesn't have the luxury of being > able to just download the ACPI tables like fw-cfg might be able to > offer. > > I'm a little concerned that firmware might find a desire to still > customize the tables, and thus the fw-cfg solution might be too > restricting. It does seem to work out okay for other VMM projects > though. (It does seem to be working for Xen in OVMF. But, I'm not > certain how well it is working, since I don't have a Xen setup.) > > I mentioned in the other thread that perhaps QEMU could also consider > making the ACPI code available under some 'appropriate' license, which > would allow firmware writers to leverage the code directly if desired. > Perhaps a dual/multi license situation for the relevant files? Would the OVMF developers participate in a GPL version of OVMF that live outside of the EDK2 tree? I think the only solution to the licensing problem is a GPL-friendly UEFI build... Regards, Anthony Liguori > > But, if the fw-cfg route works, then it seems the easiest option for > firmware writers. > > -Jordan

2 1

[PATCH RFC 00/13] qemu: generate acpi tables for the guest
by Michael S. Tsirkin 04 Jun '13

04 Jun '13

This patchset moves all generation of ACPI tables from guest BIOS to the hypervisor. Although ACPI tables come from a system BIOS on real hw, it makes sense that the ACPI tables are coupled with the virtual machine, since they have to abstract the x86 machine to the OS's. Several future developments that this will enable: - make it easier to use alternative firmware: any firmware can just load the ACPI tables from QEMU. case in point OVMF. - make it easier to add more chipsets without bumping into fw_cfg boundaries. - describe a complex configuration e.g. a bridged PCI topology to enable acpi hotplug of devices behind a PCI bridge, or for multi-root topology. If you look at the actual code: i386: imports ACPI table generation code from seabios you will see that it's more complex than it needs to be, with lots of low level casts and similar tricks. There's also a bit of duplication where we already declare similar acpi structures in qemu. This is the result of code being a direct port from seabios. Laszlo's patch (build ACPI MADT (APIC) for fw_cfg) shows how this will be cleaned up by follow-up work. I think it's best to do it in this order: port code directly, and apply cleanups and reduce duplication that results, on top. This way it's much easier to see that we don't introduce regressions. In particular, for a simple VM with piix, I booted a guest on qemu with and without the change, and verified that ACPI tables are unchanged except for trivial pointer address changes. Such binary compatibility makes it easier to be confident that this change won't break things. So the idea is Laszlo's patchset (patches 2-7) will be rebased on top of this patchset, this way we'll get small cleanup changes, where each step is easy to verify as not changing anything from Guest POV. One issue this patchset creates is cross-version migration. Specifically migration to qemu 1.5 will not work if it happens while bios is accessing fw_cfg when we migrate. This is a general problem of the fw_cfg implementation, I plan to extend fw_cfg implementation to address this. I plan to test q35 and numa setups before I submit this for inclusion, in a similar way. git trees, for those interested in testing this: git://git.kernel.org/pub/scm/virt/kvm/mst/qemu.git acpi git://git.kernel.org/pub/scm/virt/kvm/mst/seabios.git acpi bios patchset will be posted tomorrow (need to clean up the commit log a bit). Laszlo Ersek (1): refer to FWCfgState explicitly Michael S. Tsirkin (12): apic: rename apic specific bitopts hw/i386/pc.c: move IO_APIC_DEFAULT_ADDRESS to include/hw/i386/apic.h fw_cfg: move typedef to qemu/typedefs.h i386: add ACPI table files from seabios acpi: add rules to compile ASL source acpi: pre-compiled ASL files range: add Range structure i386: add bios linker/loader i386: generate pc guest info pc: pass PCI hole ranges to Guests i386: ACPI table generation code from seabios pc: reuse guest info for legacy fw cfg configure | 9 +- hw/acpi/ich9.c | 7 +- hw/acpi/piix4.c | 44 +- hw/core/loader.c | 2 +- hw/i386/Makefile.objs | 27 + hw/i386/acpi-build.c | 685 ++++ hw/i386/acpi-dsdt-cpu-hotplug.dsl | 93 + hw/i386/acpi-dsdt-dbug.dsl | 41 + hw/i386/acpi-dsdt-hpet.dsl | 51 + hw/i386/acpi-dsdt-isa.dsl | 117 + hw/i386/acpi-dsdt-pci-crs.dsl | 105 + hw/i386/acpi-dsdt.dsl | 343 ++ hw/i386/acpi-dsdt.hex.generated | 4409 ++++++++++++++++++++ hw/i386/bios-linker-loader.c | 155 + hw/i386/multiboot.c | 2 +- hw/i386/multiboot.h | 4 +- hw/i386/pc.c | 159 +- hw/i386/pc_piix.c | 28 +- hw/i386/pc_q35.c | 14 +- hw/i386/q35-acpi-dsdt.dsl | 452 +++ hw/i386/q35-acpi-dsdt.hex.generated | 7346 ++++++++++++++++++++++++++++++++++ hw/i386/ssdt-misc.dsl | 73 + hw/i386/ssdt-misc.hex.generated | 190 + hw/i386/ssdt-pcihp.dsl | 51 + hw/i386/ssdt-pcihp.hex.generated | 108 + hw/i386/ssdt-proc.dsl | 63 + hw/i386/ssdt-proc.hex.generated | 134 + hw/intc/apic.c | 42 +- hw/isa/lpc_ich9.c | 11 +- hw/mips/mips_malta.c | 2 +- hw/pci-host/q35.c | 5 + hw/sparc/sun4m.c | 6 +- hw/sparc64/sun4u.c | 2 +- include/hw/acpi/ich9.h | 2 +- include/hw/i386/acpi-build.h | 9 + include/hw/i386/apic.h | 2 + include/hw/i386/bios-linker-loader.h | 26 + include/hw/i386/ich9.h | 3 +- include/hw/i386/pc.h | 67 +- include/hw/loader.h | 3 +- include/hw/nvram/fw_cfg.h | 2 +- include/hw/pci-host/q35.h | 2 + include/qemu/range.h | 22 + include/qemu/typedefs.h | 2 + scripts/acpi_extract.py | 362 ++ scripts/acpi_extract_preprocess.py | 52 + scripts/update-acpi.sh | 4 + 47 files changed, 15248 insertions(+), 90 deletions(-) create mode 100644 hw/i386/acpi-build.c create mode 100644 hw/i386/acpi-dsdt-cpu-hotplug.dsl create mode 100644 hw/i386/acpi-dsdt-dbug.dsl create mode 100644 hw/i386/acpi-dsdt-hpet.dsl create mode 100644 hw/i386/acpi-dsdt-isa.dsl create mode 100644 hw/i386/acpi-dsdt-pci-crs.dsl create mode 100644 hw/i386/acpi-dsdt.dsl create mode 100644 hw/i386/acpi-dsdt.hex.generated create mode 100644 hw/i386/bios-linker-loader.c create mode 100644 hw/i386/q35-acpi-dsdt.dsl create mode 100644 hw/i386/q35-acpi-dsdt.hex.generated create mode 100644 hw/i386/ssdt-misc.dsl create mode 100644 hw/i386/ssdt-misc.hex.generated create mode 100644 hw/i386/ssdt-pcihp.dsl create mode 100644 hw/i386/ssdt-pcihp.hex.generated create mode 100644 hw/i386/ssdt-proc.dsl create mode 100644 hw/i386/ssdt-proc.hex.generated create mode 100644 include/hw/i386/acpi-build.h create mode 100644 include/hw/i386/bios-linker-loader.h create mode 100755 scripts/acpi_extract.py create mode 100755 scripts/acpi_extract_preprocess.py create mode 100644 scripts/update-acpi.sh -- MST

6 26

[PATCH 1/2] config: allow DEBUG_IO for !QEMU
by Gerd Hoffmann 03 Jun '13

03 Jun '13

Make DEBUG_IO depend on QEMU_HARDWARE instead of QEMU, so it can be enabled for seabios builds running indirectly (coreboot, csm) on qemu. Add runtime check for PF_QEMU to debug port console to make sure we don't poke on random ports on physical hardware. Signed-off-by: Gerd Hoffmann <kraxel(a)redhat.com> --- src/Kconfig | 2 +- src/output.c | 3 ++- 2 files changed, 3 insertions(+), 2 deletions(-) diff --git a/src/Kconfig b/src/Kconfig index 3c80132..5882d11 100644 --- a/src/Kconfig +++ b/src/Kconfig @@ -425,7 +425,7 @@ menu "Debugging" Base port for serial - generally 0x3f8, 0x2f8, 0x3e8, or 0x2e8. config DEBUG_IO - depends on QEMU && DEBUG_LEVEL != 0 + depends on QEMU_HARDWARE && DEBUG_LEVEL != 0 bool "Special IO port debugging" default y help diff --git a/src/output.c b/src/output.c index 79c3ada..100481b 100644 --- a/src/output.c +++ b/src/output.c @@ -11,6 +11,7 @@ #include "bregs.h" // struct bregs #include "config.h" // CONFIG_* #include "biosvar.h" // GET_GLOBAL +#include "paravirt.h" // PlatformRunningOn struct putcinfo { void (*func)(struct putcinfo *info, char c); @@ -77,7 +78,7 @@ putc_debug(struct putcinfo *action, char c) { if (! CONFIG_DEBUG_LEVEL) return; - if (CONFIG_DEBUG_IO) + if (CONFIG_DEBUG_IO && (PlatformRunningOn & PF_QEMU)) // Send character to debug port. outb(c, GET_GLOBAL(DebugOutputPort)); if (c == '\n') -- 1.7.9.7

2 1

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

SeaBIOS