'Exception C000009D - Privileged Instruction' - why only on some systems?

[Andi B.]

I get this exception on my T42p but not my T60 nor on my desktop. I know it is triggered
by IN from serial port register but I don't understand why it only traps on the T42.

The same on all systems -
PROTECTONLY=NO
IOPL=YES

The T42p is the only system without ACPI.PSD. But I do not understand why this should make
a difference.

Following code triggers the exception (icc3.65) -

while ( !(__inpb(0x3F8 + 5) & 0x20) );
__outpb(0x3F8, *s);


Below is the start of the .trp file if it helps.

Regards, Andreas


______________________________________________________________________

Exception Report - created 2019/02/02 14:20:14
______________________________________________________________________

wlanstat build: Dec 16 2018 17:18:15

OS2/eCS Version: 2.45
# of Processors: 1
Physical Memory: 1534 mb
Virt Addr Limit: 1536 mb
Exceptq Version: 7.11.3-shl (Jul 5 2016)

______________________________________________________________________

Exception C000009D - Privileged Instruction
______________________________________________________________________

Process: E:\_WORK\XWLAN\TRUNK\DEBUG\WLANSTAT.EXE (12/16/2018 17:29:14 1,009,644)
PID: 11E (286)
TID: 01 (1)
Priority: 200

Filename: E:\_WORK\XWLAN\TRUNK\DEBUG\GENMAC.DIM (12/16/2018 17:29:13 321,749)
Address: 005B:16B057A9 (0002:000057A9)

______________________________________________________________________

Failing Instruction
______________________________________________________________________

16B057A7 ADD [EAX], AL (0000)
16B057A9 >IN AL, DX (ec)
16B057AA MOVZX EAX, AL (0fb6c0)
16B057AD TEST AL, 0x20 (a8 20)
16B057AF JNZ 0x16b057be (75 0d)

______________________________________________________________________

Registers
______________________________________________________________________

EAX : 16D2018C EBX : 00000000 ECX : 16D215FC EDX : 000003FD
ESI : 1C9EED2C EDI : 1C9F07D0
ESP : 000D4C28 EBP : 000D4C34 EIP : 16B057A9 EFLG : 00212202
CS : 005B CSLIM: FFFFFFFF SS : 0053 SSLIM: FFFFFFFF

EAX : read/write memory at 0007:0000018C in GENMAC
EBX : not a valid address
ECX : read/write memory at 0007:000015FC in GENMAC
EDX : not a valid address
ESI : read/write memory allocated by PMMERGE
EDI : read/write memory allocated by PMMERGE

______________________________________________________________________

Stack Info for Thread 01
______________________________________________________________________

Size Base ESP Max Top
00010000 000D7140 -> 000D4C28 -> 000D3140 -> 000C7140

______________________________________________________________________

Call Stack
______________________________________________________________________

EBP Address Module Obj:Offset Nearest Public Symbol
-------- --------- -------- ------------- -----------------------
Trap -> 16B057A9 GENMAC 0002:000057A9 WpaCliTerminate - 1C74 0002:0000741D (wpacli)

000D4C34 16B07457 GENMAC 0002:00007457 WpaCliTerminate + 3A 0002:0000741D (wpacli)

[Lars Erdmann]

In order to execute the in/out/ins/outs/cli/sti instructions:
The old W4 kernel requires the code segment to be an IOPL segment in
order to execute these instructions. Since IOPL segments are limited
to 16-bit segments, that also means that you need to thunk to 16-bit
code. Additionally, you need to define a callgate to transition from
32-bit ring3 to 16-bit ring2.

The SMP and UNI kernels have no such requirement. They will trap and the
trap will be handled by the kernel which will allow to execute these
instructions. There is a reason for that but I forgot what that was.

I therefore believe that your problem is that you are using these 2
different kernels. It has nothing to do with ACPI.PSD.

If you want to write compatible code, you need to go via an 16-bit IOPL
segment as that still works ok with the SMP/UNI kernel.


Lars

Post by Andi B.
I get this exception on my T42p but not my T60 nor on my desktop. I know
it is triggered by IN from serial port register but I don't understand
why it only traps on the T42.
The same on all systems -
PROTECTONLY=NO
IOPL=YES
The T42p is the only system without ACPI.PSD. But I do not understand
why this should make a difference.
Following code triggers the exception (icc3.65) -
while ( !(__inpb(0x3F8 + 5) & 0x20) );
__outpb(0x3F8, *s);
Below is the start of the .trp file if it helps.
Regards, Andreas

[Dave Yeo]

Post by Lars Erdmann
I therefore believe that your problem is that you are using these 2
different kernels. It has nothing to do with ACPI.PSD.

In a round about way it does. If ArcaOS installs with APM support
instead of ACPI, it will install the W4 kernel and the T42 works much
better with APM.

Dave

[Andi B.]

Post by Lars Erdmann
I therefore believe that your problem is that you are using these 2
different kernels. It has nothing to do with ACPI.PSD.

In a round about way it does. If ArcaOS installs with APM support instead of ACPI, it will
install the W4 kernel and the T42 works much better with APM.
Dave

Thanks both of you. Last night during two REM phases the kernel difference came up to my
mind too ;-) But I still wondering why the SMP kernel behaves different here. Does that
expose some security/stability issues with SMP kernels compared to the W4?

And yes the T42p works well with APM. Even hibernate works. Slow but it works (except the
USB mouse attached to the docking station IIRC).

Andreas

[Lars Erdmann]

Post by Andi B.

Post by Dave Yeo

Post by Lars Erdmann
I therefore believe that your problem is that you are using these 2
different kernels. It has nothing to do with ACPI.PSD.

In a round about way it does. If ArcaOS installs with APM support
instead of ACPI, it will
install the W4 kernel and the T42 works much better with APM.
Dave

Thanks both of you. Last night during two REM phases the kernel
difference came up to my mind too ;-) But I still wondering why the SMP
kernel behaves different here. Does that expose some security/stability
issues with SMP kernels compared to the W4?

I think now I remember. It has something to do with the CLI and STI
instructions.
For the SMP kernel (but NOT the W4 kernel), there is something called
IPIs (interprocessor interrupts). These are used to synchronize multiple
CPUs.
For example, they are needed when you want to hand over execution of a
thread from one CPU to another.
Now, there is a CLI spinlock. Every processor that wants to issue a CLI
needs to acquire this spinlock. This spinlock is needed by the kernel to
keep track of if an IPI can be issued or not because if CLI is issued on
a CPU it cannot receive an IPI (after all, an IPI is a normal interrupt
source like a HW interrupt).
So how can the OS ensure that the CLI spinlock is acquired if a
processor issues a CLI (from an application) ?
Solution: it needs to trap this instruction. In the OS exception
handler, it can then ensure that on a CLI the OS will acquire the CLI
spinlock.
Likewise, the STI instruction will then release the CLI spinlock.

Unfortunately, the set of IN/INS/OUT/OUTS/CLI/STI are all trapped if the
CPL (current privilege level) has a higher number than the IOPL.
But according to the trap address the kernel will be able to find out
what instruction caused the trap. And then it will allow IN/INS/OUT/OUTS
to execute normally while it will do the special processing for CLI and STI.

When you look at the W4 kernel and the SMP kernel you will realize that
the IOPL flag will be set to 2 for the W4 kernel and to 0 for the SMP
kernel. And that's why regardless if you have an IOPL segment for your
IN and OUT instructions or not, the kernel will trap in any case on an
SMP kernel (and do the aforementioned). On the W4 kernel, if you run the
IN and OUT instructions from an IOPL segment, the CPL will be 2 and
therefore it will be <= IOPL and therefore it will NOT trap.


And yes, it is a security flaw in the SMP kernel because as you
realized, you can execute IN and OUT from a normal application on the
SMP kernel without going through any special fuzz.
I don't know why the kernel does not prevent IN and OUT from being
executed in the exception handler. It would have been possible to
prevent that. Maybe IBM forgot :-)


Lars

[Lars Erdmann]

Post by Dave Yeo

Post by Lars Erdmann
I therefore believe that your problem is that you are using these 2
different kernels. It has nothing to do with ACPI.PSD.

In a round about way it does. If ArcaOS installs with APM support
instead of ACPI, it will install the W4 kernel and the T42 works much
better with APM.
Dave

ACPI.PSD is the symptom, not the cause.