Hi,
Antti wrote:
Korona wrote:
SMM is independent of long mode.
Unfortunately, this is questionable.
I'd really like to know the answer to this specific question: are the "PS/2 emulation" bugs waken up only if a CPU executing in long mode tries to read/write ports 0x60 or 0x64 which triggers the SMI handlers (but are interrupts involved in this scenario too)?
For "PS/2 emulation for USB devices" I'd assume firmware may need to try to figure out which instruction caused the SMI (e.g. was it "in al,dx" or "in ax,dx" or ...?) so that it can emulate that instruction. This could involve doing a manual page table walk to find the instruction in physical memory, which implies that firmware's SMM code would need to support all the different paging modes and all of their features (large pages, "no-execute", ...); including things like "instruction split across page boundary" and including emulating page faults (e.g. "insb" writing to a not-present page).
Antti wrote:
There is a huge difference. I'm really worried about the "passive" state after entering long mode, i.e. a state in which "traditional" BIOS firmware is not in control (but obviously SMM still is) and the operating system / initialization code itself has not done anything yet.
Are you accessing the PS/2 chip's IO ports while in this passive state?
Antti wrote:
I'd understand the following scenario: emulation enabled, long mode, port read/write, and crash. If just being in long mode doing nothing crashes the computer... oh well.
Excluding "PS/2 emulation for USB devices" and "suspend/resume"; for everything else that SMM is used for (power management, ECC "scrubbing" in some computers, etc) the firmware's SMM code has no reason to care what the OS is doing (or which mode the CPU was in, etc).
Note that long mode was introduced in about 2000 (and I guess there may be "teething problems" in firmware involving "PS/2 emulation" and long mode for computers created at/near the introduction of long mode); and ACPI was introduced in about 1999 (and there are "teething problems" in firmware involving ACPI for computers created at/near the introduction of ACPI); and these time-frames are close enough to overlap (e.g. computers from around 2000 where firmware has problems with both long mode and ACPI). If an OS supports older 32-bit CPUs (e.g. and has a 32-bit kernel, etc) it should be relatively easy to force the OS to use 32-bit (e.g. using automated blacklist/whitelist approach and/or heuristics, and/or a manual user setting); and if the OS doesn't support older 32-bit CPUs then 64-bit computers from around 2000 are only slightly newer than computers the OS developer has already decided are too old to care about and it probably wouldn't matter much if the OS developer didn't support a few more old computers.
I should also mention that I'm relatively sceptical of some of the problems Linux sees - often it's too hard to know if they're just working around symptoms of Linux doing something incredibly silly (e.g. not disabling "PS/2 emulation" in USB controllers before starting PS/2 drivers). For this reason I'd be tempted to ignore some of the problems Linux seems to have with firmware (until/unless I have similar problems with my OS).
Cheers,
Brendan