SDK/Bugs
< SDK
Jump to navigation
Jump to search
For exploitable bugs, see Wii system flaws#Wii SDK.
| Library | Description |
|---|---|
| Unknown | A function called flushAndInvalidateRange, called before OSInit in an app's main, seems to try to align the base address to a multiple of 16; the appropriate way to do this would be to AND it with 0xFFFFFFF0. However, it instead ANDs the base address with 0xFFFFFFF1.
|
| OS | OSDisableInterrupts is placed between two labels (__RAS_OSDisableInterrupts_begin and __RAS_OSDisableInterrupts_end) that are used to atomize the function, as a bad MSR could be saved if MSR changes from an interrupt between reading and updating it. However, OSEnableInterrupts contains no such protection; this is not a problem in the common case of enabling interrupts from when they are disabled, but it does cause issues if it is called with interrupts already enabled.
Unlike with |
| OS | When a function needs to execute in atomic mode, it calls OSDisableInterrupts, saves the return value, and calls OSRestoreInterrupts when it is finished; the kernel treats OSDisableInterrupts specially in order to prevent MSR from changing between when it is loaded and when it is saved with the interrupt flag off. This is done by checking if the current PC is between __RAS_OSDisableInterrupts_begin (which points to the same place as OSDisableInterrupts) and __RAS_OSDisableInterrupts_end (which points to the BLR in OSDisableInterrupts), bumping the PC back to __RAS_OSDisableInterrupts_begin if it is. However, no such check exists in OSRestoreInterrupts, despite the fact that it will actively disable interrupts using its own copy of the OSDisableInterrupts code if it is passed false.
|
| OS | In the code that saves GQRs, GQR0 is never saved. It is clear that it was supposed to be saved, as a result of its inclusion in OSDumpContext, but this makes GQR0 unreliable unless the code is executing in atomic mode, since the active thread switches on every external interrupt.
|