Ever since I have worked at Sun I've had a list of “usual
suspects” when systems crash. Those drivers that when you got
bizarre memory corruption or the system would watchdog reset or fail
in other ways that you did not expect were always present, lurking,
staring at you with a “accuse me if you dare” look on
their face. Invariably disabling the driver would make the problem
disappear but proving it was that driver took days, weeks, sometimes
the proof never quite came. You know the drivers, fddi will be
burned into my brain as having such a driver.
Many of those drivers turned out to be third party products that
just had not taken the DDI/DKI interface to heart or feel that using
memory after freeing it is just fine. How we love kmem_flags.
However I digress.
Today's problem is due two things;
A third party application adding a bogus entry to
The kernel not range checking the values in
The result is often, but not always, a system that won't boot.
What is worse is that if the system does boot then applying a patch
to it can change it into a system that does not boot.
So as a small step to prevent this I have filed this bug:
System call numbers in /etc/name_to_sysnmum should be range checked.
The fix is trivial, the pain relieved enormous. The webrev is here
if anyone wants to review it: