PCR 8736 - SAS: Kernel may attempt to write to virtual address 0x0
Summary: SAS: Kernel may attempt to write to virtual address 0x0
Status: NEW
Alias: None
Product: Kernel
Classification: Deos
Component: Kernel (show other PCRs)
Version: mainline
Hardware: All Deos
: By Cert
: Limitation
Target Milestone: 7.6.2
Assignee: .Kernel
URL:
Whiteboard:
Depends on: 8734
Blocks:
  Show dependency treegraph
 
Reported: 2013-11-07 15:54 MST by rroffelsen
Modified: 2025-09-30 15:16 MST (History)
0 users

See Also:
Impact Assessment: ---
Organization: ---
rroffelsen: Requirements-
rroffelsen: Code-
rroffelsen: TestCases-
rroffelsen: TestProcedures-
rroffelsen: Other?


Attachments

Note You need to log in before you can comment on or make changes to this PCR.
Description rroffelsen 2013-11-07 15:54:15 MST
+++ This PCR was initially created as a clone of PCR #8734 +++

If the PAL calls frameSynchronizationLost() or raisePowerTransient()
while some thread other than idle is running, or some thread successfully calls
warmStartKernel() (note: This can only happen when debugServicesHonored is true), the kernel will attempt to write to virtual address
0x0 every time idle is subsequently preempted.  If virtual address 0x0
is mapped kernel accessible the write will succeed and the kernel will
continue executing without impact to the kernel. If virtual address
0x0 is not mapped kernel accessible the kernel will page fault and
halt execution.

Whether virtual address zero is mapped or not is specified at
hyperstart time and cannot subsequently change.

Note that virtual address zero is mapped kernel accessible on all PPC
platforms but not necessarily for x86.  Furthermore when virtual
address 0x0 is mapped it will be identity mapped to physical address
0x0. As long as physical address 0x0 is not used by BOOT, PAL, or an
application (e.g., via a platform resource) this limitation will have
no negative effect.

Cause:
frameSynchronizationLost() and Scheduler::shutdown() insert a kernel mode exception handler to perform the desired operation then use Scheduler::switchToIdle() to invoke the handler. Scheduler::switchToIdle() sets Idle as the current running thread but fails to remove Idle's preemption node from the runnable list so when the kernel mode exception handler calls Scheduler::scheduleAnyThread() it results in a call to addAtBeginning() to put Idle's preemption node on the runnable list (which it is already on). This is a violation of a precondition on addAtBeginning(). Idle is the only thread ever on the runnable list at it's priority so the violation of the precondition only impacts Idle's preemption node. This results in Idle's preemption node pointing at itself and when it is removed for the runnable list (i.e. Idle is context switched in) the runnable list's next pointer at Idle's priority winds up pointing to NULL instead of itself (as designed). When Idle is preempted (by a system tick or platform interrupt) and added back to the runnable list the list's next pointer will be used as if it was a valid address to write to and Idle's preemption node winds up pointing at itself again. At this point the cycle repeats every time Idle is scheduled and preempted.
Comment 1 deosbugs.ccb 2013-11-14 13:11:11 MST
CCB visited this PCR on 2013-11-14.
Comment 2 deosbugs.ccb 2014-05-20 10:16:35 MST
CCB 2 visited this PCR on 2014-05-20
Comment 3 Stephen P. Smith 2016-08-05 14:43:28 MST
The SAS has not been updated for this PCR.
Comment 4 deosbugs.ccb 2017-02-01 09:38:02 MST
CCB visited this PCR on 2017-02-01-59501
Comment 5 deosbugs.ccb 2017-10-30 12:22:03 MST
CCB visited this PCR on 2017-10-30-67574
Comment 6 deosbugs.ccb 2020-01-15 14:49:20 MST
CCB visited this PCR on 2020-01-15-78324
Comment 7 rroffelsen 2025-09-30 15:16:27 MST
Committed SVNRevision 100540.  Applies to PCR 16766, PCR 8736, PCR 8004.

- Update the SAS and SCI for Limitation 16760.
- Update the SAS and SCI for Limitation 8734
- Fix the command used to check if an executable, shared library, or dll modifies the DS register