| History log of /src/tests/kernel/arch/hppa |
| Revision | Date | Author | Comments |
| 1.2 | 21-Apr-2025 |
riastradh | t_signal_and_sp: Fix threadsp test to actually test the thread sp.
Copypasta error had it testing alignment of signalsp instead, and
since it was always null, that always passed. Mark it xfail on mips
now as originally expected.
While here, deal with some other issues:
- Test was failing on riscv for me because I haven't updated this
`current' VM in a while so it didn't have the fix for 57721
(pthread_attr_setstack incorrectly adjusts address as if for guard
page). Don't mark it xfail.
- Fix amd64 threadspfunc.S to adjust rsp like in all the other amd64
stubs so it's congruent to 0 mod 16, not congruent to 8 mod 16.
- Fix hppa contextspfunc.S to use separate registers for separate
purposes at the same time, instead of expecting addil to preserve
%r1 AND yield a result we use later in %r1.
PR kern/59327: user stack pointer is not aligned properly
|
| 1.1 | 21-Apr-2025 |
riastradh | t_signal_and_sp: Test makecontext and pthread_create stack alignment.
PR kern/59327: user stack pointer is not aligned properly
|
| 1.2 | 28-Feb-2025 |
riastradh | t_execregs: Test some more registers on hppa.
Looks like we're missing zeroing of floating-point registers too, as
well as the carry/borrow and divide step correction bits in the
semi-secret PSW register.
Unfortunately, while investigating this, I discovered that qemu's
hppa implementation doesn't implement fpu traps even if the fpu is
disabled (relevant bits of CR 10 `CCR', Coprocessor Control Register,
are cleared), which breaks fpu switching on NetBSD. So I can't test
properly this myself. We should maybe just change NetBSD from lazy
fpu switching to eager fpu switching anyway to thwart Spectre-class
attacks if there's any hppa hardware out there that does speculative
execution.
PR kern/59084: exec/spawn leaks register content
|
| 1.1 | 27-Feb-2025 |
riastradh | Test whether exec/spawn will zero registers.
Currently implemented only for a handful of architectures; should
extend this to all the others, and extend as appropriate if we find
more register content is worth testing (like maybe vector registers,
but they are managed differently anyway and less likely to leak).
VAX test contributed (and tested) by Kalvis Duckmanton, with some
tweaks by me; the others written and tested by me. IA64 skipped,
even though I suspect it _would_ leak if the kernel code ran as is,
because I have no way to test it.
PR kern/59084: exec/spawn leaks register content
|
| 1.2 | 28-Feb-2025 |
riastradh | t_execregs: Test some more registers on hppa.
Looks like we're missing zeroing of floating-point registers too, as
well as the carry/borrow and divide step correction bits in the
semi-secret PSW register.
Unfortunately, while investigating this, I discovered that qemu's
hppa implementation doesn't implement fpu traps even if the fpu is
disabled (relevant bits of CR 10 `CCR', Coprocessor Control Register,
are cleared), which breaks fpu switching on NetBSD. So I can't test
properly this myself. We should maybe just change NetBSD from lazy
fpu switching to eager fpu switching anyway to thwart Spectre-class
attacks if there's any hppa hardware out there that does speculative
execution.
PR kern/59084: exec/spawn leaks register content
|
| 1.1 | 27-Feb-2025 |
riastradh | Test whether exec/spawn will zero registers.
Currently implemented only for a handful of architectures; should
extend this to all the others, and extend as appropriate if we find
more register content is worth testing (like maybe vector registers,
but they are managed differently anyway and less likely to leak).
VAX test contributed (and tested) by Kalvis Duckmanton, with some
tweaks by me; the others written and tested by me. IA64 skipped,
even though I suspect it _would_ leak if the kernel code ran as is,
because I have no way to test it.
PR kern/59084: exec/spawn leaks register content
|
| 1.1 | 20-Apr-2025 |
riastradh | t_signal_and_sp: Add hppa support.
Fortunately, hppa -- which uses monster 64-byte(!) stack alignment --
looks good already.
PR kern/59327: user stack pointer is not aligned properly
|
| 1.2 | 28-Feb-2025 |
riastradh | t_execregs: Test some more registers on hppa.
Looks like we're missing zeroing of floating-point registers too, as
well as the carry/borrow and divide step correction bits in the
semi-secret PSW register.
Unfortunately, while investigating this, I discovered that qemu's
hppa implementation doesn't implement fpu traps even if the fpu is
disabled (relevant bits of CR 10 `CCR', Coprocessor Control Register,
are cleared), which breaks fpu switching on NetBSD. So I can't test
properly this myself. We should maybe just change NetBSD from lazy
fpu switching to eager fpu switching anyway to thwart Spectre-class
attacks if there's any hppa hardware out there that does speculative
execution.
PR kern/59084: exec/spawn leaks register content
|
| 1.1 | 27-Feb-2025 |
riastradh | Test whether exec/spawn will zero registers.
Currently implemented only for a handful of architectures; should
extend this to all the others, and extend as appropriate if we find
more register content is worth testing (like maybe vector registers,
but they are managed differently anyway and less likely to leak).
VAX test contributed (and tested) by Kalvis Duckmanton, with some
tweaks by me; the others written and tested by me. IA64 skipped,
even though I suspect it _would_ leak if the kernel code ran as is,
because I have no way to test it.
PR kern/59084: exec/spawn leaks register content
|
| 1.1 | 20-Apr-2025 |
riastradh | t_signal_and_sp: Add hppa support.
Fortunately, hppa -- which uses monster 64-byte(!) stack alignment --
looks good already.
PR kern/59327: user stack pointer is not aligned properly
|
| 1.1 | 20-Apr-2025 |
riastradh | t_signal_and_sp: Add hppa support.
Fortunately, hppa -- which uses monster 64-byte(!) stack alignment --
looks good already.
PR kern/59327: user stack pointer is not aligned properly
|
| 1.1 | 21-Apr-2025 |
riastradh | t_signal_and_sp: Test makecontext and pthread_create stack alignment.
PR kern/59327: user stack pointer is not aligned properly
|
