New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 982 link

Starred by 2 users

Issue metadata

Status: Fixed
Last visit > 30 days ago
Closed: Jan 2017

Sign in to add a comment

Samsung: RKP information disclosure via s2-remapping physical ranges

Reported by, Nov 2 2016

Issue description

As part of Samsung KNOX, Samsung phones include a security hypervisor called RKP (Real-time Kernel Protection), running in EL2. This hypervisor is meant to ensure that the HLOS kernel running in EL1 remains protected from exploits and aims to prevent privilege escalation attacks by "shielding" certain data structures within the hypervisor.

In order to protect the information processed and stored within RKP (i.e., RKP's heap and stack or the current control-flow protection key), the physical ranges in which RKP and "physmap" are located are unmapped from the stage 2 translation table upon initialization of RKP. This prevents an attacker in EL1 from accessing any of these memory regions, as such an attempt would trigger an s2 translation fault.

However, RKP provides commands which can be used in order to re-map regions in the stage 2 translation table. Most of these commands correctly perform a validation on the given address range using "physmap". However, the "rkp_set_init_page_ro" command (command code 0x51) can be used to mark a region as read-only in stage 2, and performs no such validation. Here is the approximate pseudo-code for this command:

__int64 rkp_set_init_page_ro(unsigned args* args_buffer)
  unsigned long page_pa = rkp_get_pa(args_buffer->arg0);
  if ( page_pa < rkp_get_pa(text) || page_pa >= rkp_get_pa(etext) )
    if ( !rkp_s2_page_change_permission(page_pa, 128LL, 0, 0) )// RO, XN
      return rkp_debug_log("Cred: Unable to set permission for init cred", 0LL, 0LL, 0LL);
    rkp_debug_log("Good init CRED is within RO range", 0LL, 0LL, 0LL);
  rkp_debug_log("init cred page", 0LL, 0LL, 0LL);
  return rkp_set_pgt_bitmap(page_pa, 0);

The "rkp_s2_page_change_permission" function makes sure the given page is mapped in stage 2 (and if it isn't, it re-maps it). The arguments passed in by "rkp_set_init_page_ro" in this specific case mark the page as read-only and non-executable.

Regardless, the physical address ranges for RKP are already present in the stage 1 translation table:

  [424] 0x0b5000000-0x0b5200000 [PXN: 1, UXN: 1, AP: 0]
  [425] 0x0b5200000-0x0b5400000 [PXN: 1, UXN: 1, AP: 0]
  [426] 0x0b5400000-0x0b5600000 [PXN: 1, UXN: 1, AP: 0]
  [427] 0x0b5600000-0x0b5800000 [PXN: 1, UXN: 1, AP: 0]
  [428] 0x0b5800000-0x0b5a00000 [PXN: 1, UXN: 1, AP: 0]

This means an attacker can simply invoke the "rkp_set_init_page_ro" command to s2-map any wanted page, and will subsequently be able to directly read from that page, even if it resides within RKP's physical address range.

I've verified this issue on an SM-G935F device, build version "XXS1APG3". The RKP version present on the device is "RKP4.2_CL7572479".

This bug is subject to a 90 day disclosure deadline. If 90 days elapse
without a broadly available patch, then the bug report will automatically
become visible to the public.
Proof of concept for the RKP stage 2 remapping issue.

This PoC s2-remaps RKP's physical address range and reads from it in EL1.
6.2 KB Download
Labels: -Restrict-View-Commit SVE-2016-7897
Status: Fixed (was: New)
Fixed in January SMR, verification pending.
Verified fix on G935F, XXU1DQAO.

The patch prevents calling the "rkp_set_init_page_ro" command more than once. As this command is called early during the kernel's initialisation, this reduces the window for attack. However, the rest of the code remains unchanged.
Summary: Samsung: RKP information disclosure via s2-remapping physical ranges (was: Android: RKP information disclosure via s2-remapping physical ranges)

Sign in to add a comment