11.0.0-33: Difference between revisions

Line 30: Line 30:


====ARM11-kernel====
====ARM11-kernel====
3 new functions used for validation with memory management were added(kernelpanic() on failure). 57 functions were updated, at least 48 of these are the actual functions used for handling SVCs.
57 functions were updated, at least 48 of these are the actual functions used for handling SVCs. The  lone function updated with v10.4 was updated with this version again.


The same lone function updated with v10.4 was updated with this version again.
3 new functions used for validation with memory management were added (kernelpanic() on failure). This is a new security feature for the kernel heaps. By adding a MAC to the kernel heap [[Memory_Management#MemoryBlockHeader|memchunkhdr]] they can detect when it is modified by an outside DMA device.


Those new functions use XOR + rotation(besides the checks which were already done in previous versions).
The function which initializes a memalloc heap had a major update (used for FCRAM memregions and the SlabHeap container). It is unknown precisely what this does, but presumably it generates a random MAC key based on svcGetSystemTick.


The function which initializes a memalloc heap(FCRAM memregions + the container which the SlabHeap is under), had a major update. This uses XOR + rotation code, and it also uses svcGetSystemTick.
The MAC itself is custom based on xor-rot-sub, and is calculated as follows (pseudo-code):


The svcGetSystemTick + XOR/rotation code mentioned above is a new security feature for the kernel heaps(see above). This is intended to stop non-arm11kernel from modifying kernel heap [[Memory_Management#MemoryBlockHeader|memchunkhdrs]]. However, it's unknown how much the svcGetSystemTick() output really varies if anything(?) for each hard-boot during initialization of the heaps.
u32* crypto_state = (u32*) r4; // Safe kernel memory.
u32* data_ptr = (u32*) lr; // Unsafe FCRAM pointer.
 
r0 = crypto_state[16/4] // Load "key".
r1 = crypto_state[20/4]
r2 = crypto_state[28/4]
r3 = crypto_state[24/4]
for(size_t i=0; i<2; i++) {
    for(size_t j=0; j<5; j++) {
        r0 -= data_ptr[j] + (r1 >>> 3)
        r1 -= (r3 >>> (r2 & 0xf + 3)) ^ (r2 >>> (r0 & 0xf + 13))
        r3 -= (r2 >>> r0) * r1
        r2 -= (r0 >>> r1) * r3
    }
}
   
// Verify MAC.
if(data_ptr[5] != (r0 ^ r1)) {
    kernel_panic()
}
 
However, it's unknown how much the svcGetSystemTick() output really varies if anything(?) for each hard-boot during initialization of the heaps.


6 memory management functions were updated to use the above new functions, these func-calls replaced the validation code previously used in these functions in some cases. These were also updated for the above heap security implementation. One function had a validation func-call added where previously there wasn't any validation done in the beginning of the function for previous versions.
6 memory management functions were updated to use the above new functions, these func-calls replaced the validation code previously used in these functions in some cases. These were also updated for the above heap security implementation. One function had a validation func-call added where previously there wasn't any validation done in the beginning of the function for previous versions.