daw@sun.com (Doug Ward) (12/23/88)
There seems to be confusion about how L1-A works. Once the system is booted, the L1-A sequence is recognized in the kernel. The kernel then calls a routine in the PROM monitor to abort. Actually, that's the same routine that the kernel calls as the lasty thing it does during a halt. At the cost of making system administration marginally harder, you can disable L1-A in the kernel. Then the only window of vulnerability will be while the PROMS are in control and while boot is in control. For 4.0, look at: zs_async.c: zsa_xsint() -- this has code to detect breaks for terminal consoles and for unplugging the keyboard. kbd.c: kbdinput() -- L1-A is caught here. The part of the code you're interested in is the sequence of events leading up to "montrap(*romp->v_abortent);". The setup is pretty much the same in 3.x. Personally, I think people who want UNIX machines without consoles and people who want to power cycle hung machines instead of the "L1-A, g0" sequence crazy, but I understand why the abort key is such a pain to Universities. -daw
bickel@nprdc.arpa (Steven Bickel) (01/04/89)
daw@sun.com (Doug Ward) writes: >There seems to be confusion about how L1-A works. Once the system is >booted, the L1-A sequence is recognized in the kernel. The kernel then >calls a routine in the PROM monitor to abort. Actually, that's the same >routine that the kernel calls as the lasty thing it does during a halt. An interesting side note for L1-a is that you can restart all processing where it left off by typing c. It takes some courage because it may not come back complete (disk io interrupts may corrupt files) but in the several time I have tried it my machine was back to normal after a screen refresh. Steve Bickel Steve Bickel bickel@nprdc.arpa Systems Engineering Assoc. (619) 553-9306 Naval Personel R & D Center.
gww@sun.com (Gary Winiger) (01/07/89)
There has recently been discussion of bypassing operating system security by using the PROM monitor. Various solutions have been proposed such as disabling L1-A in the kernel and fixing the PROM monitor. As of version 2.8 of the PROM monitor, three security modes are provided: 1) Non-secure mode provides complete access to the PROM commands as is the case in earlier PROM monitors. 2) Command secure mode requires the entry of a password to access commands other than Boot and Continue with no parameters. This permits ``normal'' operation of powering up, booting, crashing and rebooting. 3) Fully secure mode requires the entry of a password to access all commands other than Continue with no parameters. This effectively locks the workstation if it is power cycled, or crashed. If the workstation is in the fully secure mode and the password is forgotten, the workstation can't be booted and the CPU board must be serviced as a failed board. When it's available, the 2.8 PROM will be shipped in all new workstations. When a workstation starts its boot sequence, it displays the PROM revision level. Gary..
weaverj@eecae.ee.msu.edu (Jeff Weaver) (04/26/89)
In a previous posting, someone (I'm not sure who) noted a way to disable L1-a by just returning from the 'montrap' routine. I have a different way that diables the jump into monitor from the kbdinput() routine. This seems to disable other keyboard jumps into the monitor from programs such as kadb. It's very important to disallow L1-a because a person with knowledge of UNIX internal's can abort a running system, change kernel accreditation structeres, and then *continue* UNIX. The fix (SunOs 3.5, but I expect it is simmilar for others) is to change the instruction at 'kbdinput+0x21e' to a NOP. % adb -k -w /vmunix /dev/mem (system vm map info printed out, etc) kbdinput+0x21e/w 0x4e71 (for running kernel) kbdinput+0x21e?w 0x4e71 (for kernel image) montrap/w 0x4e75 montrap?w 0x4e75 $q Watchdog Reset is still serviceable, but with proper security on UNIX re-entry, this can be minimized (as the continuation of UNIX from a watchdog reset is difficult at best). jeff Jeffrey Weaver, System Programmer, ERDL Phone: (517) 355-3769 260 Engineering Bldg. Michigan State University weaverj@eecae.ee.msu.edu ...uunet!frith!eecae!weaverj