> On Feb 21, 2025, at 2:28 PM, ben via cctalk <cctalk@classiccmp.org> wrote:
>
> On 2025-02-21 11:55 a.m., John via cctalk wrote:
>> On Fri, 21 Feb 2025 12:00:07 -0600
>> Paul Koning <paulkon...@comcast.net> wrote:
>>>> What is the problem with ISRs running in a user stack? The ISR
>>>> runs, exits, the stack is cut back, and net effect on the user's
>>>> stack is zero.
>>>
>>> A stack access fault in user mode kills the process, in kernel mode
>>> (certainly in an ISR) it kills the whole system. You can't leave the
>>> integrity of the OS at the mercy of the application having a valid
>>> stack.
>> Additionally, the ISR could leave potentially sensitive information in
>> user memory, depending on exactly how the stack and memory protection
>> are implemented. Consider an architecture where the stack pointer is a
>> normal address register (as on the -11, the 68k, etc.) and protection
>> is on a per-page basis with no bounds checking (i.e. there's no special
>> address space for the stack, just a particular chunk mapped into normal
>> user memory.) It'd be trivial for a user program to sit and "scrape"
>> the stack for stray bits left by passing ISRs - say, waiting to see if
>> the UART service routine happens to jot down something that looks like
>> an admin password coming off one of the terminals.
>
> There is really no safe password system.
> Mind you it might take 30 years to break it
> and the OS is no longer around.
My favorite example of security holes in strange places is the paper describing
how to recover the RSA private key used by crypto inside of a smartphone, by
listening to the sounds made by the electronics while it's doing the
computation. Adi Shamir was a co-author as I recall -- he's the S in RSA and
one of the world's top cryptographers.
paul
