21 Feb
2025
21 Feb
'25
10:55 a.m.
On Fri, 21 Feb 2025 12:00:07 -0600
Paul Koning <paulkoning(a)comcast.net> wrote:
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.
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. 
21 Feb
21 Feb
11:28 a.m.
New subject: Classic computers with more than one stack pointer, but not FORTH machines.
On 2025-02-21 11:55 a.m., John via cctalk wrote:
On Fri, 21 Feb 2025 12:00:07 -0600
Paul Koning <paulkoning(a)comcast.net> wrote:
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.
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. 
1:06 p.m.
New subject: Classic computers with more than one stack pointer, but not FORTH machines.
On Feb 21, 2025, at 2:28 PM, ben via cctalk
<cctalk(a)classiccmp.org> wrote:
On 2025-02-21 11:55 a.m., John via cctalk wrote:
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
On Fri, 21 Feb 2025 12:00:07 -0600
Paul Koning <paulkoning(a)comcast.net> wrote:
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. 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. 
1:09 p.m.
New subject: Classic computers with more than one stack pointer, but not FORTH machines.
That’s a side channel attack.
If there ever was one.
Was there ever a proof of concept made of that theory ?
Sent from my iPhone
On Feb 21, 2025, at 13:06, Paul Koning via cctalk
<cctalk(a)classiccmp.org> wrote:
the
2:43 p.m.
New subject: Classic computers with more than one stack pointer, but not FORTH machines.
On 2025-02-21 2:09 p.m., Wayne S via cctalk wrote:
That’s a side channel attack.
If there ever was one.
Was there ever a proof of concept made of that theory ?
Only when the BLACK helicopters show up.
1
days inactive
1
days old
4 comments
4 participants
participants (4)
-
ben -
John -
Paul Koning -
Wayne S