GB2579614A

GB2579614A - Page table isolation method

Info

Publication number: GB2579614A
Application number: GB1819922.4A
Authority: GB
Inventors: Deprez Olivier; Hänel Lukas
Original assignee: Trustonic Ltd
Current assignee: Trustonic Ltd
Priority date: 2018-12-06
Filing date: 2018-12-06
Publication date: 2020-07-01
Anticipated expiration: 2038-12-06
Also published as: GB201819922D0; GB2579614B

Abstract

A page table isolation method comprising selecting, using a first pointer, a shadow kernel page table which itself references a shadow page 510, mapping the shadow page in a virtual address space and associating the shadow page with a global indicator. Selecting, using a second pointer, a first application page table from a number of such tables, the table being associated with a first address space identifier and referencing one or more application pages 540, 550 and mapping the application pages in the virtual address space and associating them with the address space identifier. Responsive to a request to transition from user to kernel mode, the first pointer may be changed to point towards a kernel page table referencing both the shadow kernel page and one or more kernel pages, and mapping the kernel pages in the virtual address space with a unique kernel address space identifier. When transitioning from kernel to user mode, the first pointer may be pointed back to the shadow kernel page table and the kernel pages may be unmapped from the virtual address space. The shadow kernel page may be trampoline code which manages the transition between user and kernel mode. An iteration on KAISER.

Description

Intellectual Property Office Application No. GB1819922.4 RTM Date:1 May 2019 The following terms are registered trade marks and should be read as such wherever they occur in this document: Intel ARM Intellectual Property Office is an operating name of the Patent Office www.gov.uk /ipo

PAGE TABLE ISOLATION METHOD

FIELD AND BACKGROUND

[0001] The present techniques relate to the field of computing devices. More particularly, they relate to enabling a computing device to perform page table isolation.

[0002] Increasingly, computing devices are being used to access services which may involve handling of potentially sensitive information, such as mobile banking, access to health care services or handling of employment details. Also, with the increasing development of embedded-system and Internet of Things (loT) devices, it is becoming more common for systems such as heating, air-conditioning or street lighting to be controlled based on information provided by computing devices which may provide sensor information such as temperature data or proximity information indicating whether a user is present, for example. In these scenarios, it can be important to ensure security in such devices. An important aspect of providing the security can be through the strict isolation of access to the kernel memory by user applications.

[0003] Traditionally kernel and user pages are both mapped in the same virtual address space for performance reasons. The isolation can be made by a Memory Management Unit hardware feature called the privilege bit which prevents direct access to the kernel pages by a user application. However, there has recently been discovered a practical side-channel cache timing attack known as CVE-2017-5754 "Meltdown" Variant 3 which allows a user application to break the isolation and access kernel pages mapped in the same virtual address space.

[0004] Meltdown works to bypass the privilege bit by exploiting a CPU race condition between certain memory accesses and privilege checking which allows for data to be written to a cache as part of an operation prior to the privilege check being performed (and failed). Subsequently accesses to the cache can be timed by which the outcome of the failed operation, and hence contents of the kernel page, can be inferred.

[00os] Kernel page table isolation techniques such as KAISER can be provided which protect against Meltdown and various other side-channel attacks by ensuring that kernel pages are not mapped in the virtual address space when the computing device is a user mode though the use two sets of page tables, one for use when a given process (application) is executing in a user mode and one for use when the given process is executing in a kernel mode. These corresponding page tables for each process are associated with a first address space identifier for the "user mode" version and a second address space identifier for the "kernel mode" version.

[0006] As identified by the present inventors, while such techniques can provide kernel page table isolation they do so at the expense of an increased consumption of address space identifiers and increased memory consumption through the storage of near-duplicate page tables. As identified by the present inventors, in small computing devices such as sensors, actuators or other embedded-system or loT devices, the available system resources (including number of application identifiers and memory) can be constrained which renders the above-described isolation technique infeasible due to the increase resource consumption within the limited capabilities of such devices.

[0007] At least certain embodiments of the present disclosure address one of more of these problems as set out above.

SUMMARY

[0008] Particular aspects and embodiments are set out in the appended claims.

[0009] Viewed from one perspective, there can be provided a page table isolation method for a computing device, the method comprising: selecting using a first pointer a shadow kernel page table, wherein the shadow kernel page table references a shadow kernel page; mapping the shadow kernel page in a virtual address space and associating the shadow kernel page with a global indicator; selecting using a second pointer a first application page table from a plurality of application page tables, the first application page table associated with a first address space identifier, wherein the first application page table references one or more first application pages; mapping the one or more first application pages in the virtual address space and associating the one or more first application pages with the first address space identifier.

[0010] Through the use of two pointers, "kernel" and "application" page tables can be separately selected. In general, for example when the computing device is in a user mode, only a shadow kernel page needs to be mapped in the virtual address space (i.e. as opposed to the "full" kernel). The shadow kernel page table does not need to contain sensitive assets and need only include a minimal subset of the kernel pages which allow for the full kernel to be called and mapped into the virtual address space upon transition from a user mode to a kernel mode (e.g. in response to system call or other exception). Thereby all other (sensitive) parts of the kernel are protected from Meltdown and other similar attacks.

[0011] The shadow kernel page is marked with a global indicator such that it can always be accessed irrespective of what address space identifier is currently set. In addition, through the use of a global indicator, the shadow kernel page does not need to be unmapped or flushed from a Translation Lookaside Buffer (TLB) when the computing device transitions between a user mode and a kernel mode or when the active application (process) is switched. Examples of suitable address space identifiers include Intel's PCID (Process-Context Identifier) and ARM's ASID (Address Space Identifier).

[0012] In some examples, the computing device is in a user mode and responsive to a request to transition from a user mode to a kernel mode, the method comprises: repositioning the first pointer to select a kernel page table, wherein the kernel page table references the shadow kernel page and one or more kernel pages; mapping the one or more kernel pages in the virtual address space with a unique kernel address space identifier. Thereby, the application pointer may be left in place with no need to unmap the application pages or invalidate cached virtual memory to physical memory translations upon transition from a user mode to a kernel mode.

[0013] This is in contrast to prior KAISER approaches which, by using two separate address space identifiers for each application (i.e. one associated with a user mode and one associated with a kernel mode), require a replacement mapping of application pages with the alternate address space identifier and reconstruction of caches using the alternate address space identifier upon the transition between user and kernel modes. The present approach uses a unique kernel address space identifier for the "full" kernel pages which is the same for all applications.

[0014] Accordingly, only a single additional address space identifier (i.e. the unique kernel address space identifier) is used to provide the page table isolation functionality. This is in contrast to KAISER approaches that require one additional address space identifier per application. Furthermore, the approach identified by the present inventors requires minimal extra memory as only a single additional page table needs to be stored instead of the two times the number of page tables required in the KAISER approach. Thus, the computing device can provide for page table isolation, and transition from a user mode to a kernel mode, with a low consumption of computing resources.

[0015] In some examples, responsive to a request to transition from the kernel mode to the user mode, the method comprises: repositioning the first pointer to select the shadow kernel page table; unmapping the one or more kernel pages in the virtual address space. Thereby, as with the transition from a user mode to a kernel mode, only the pointer associated with the (shadow) kernel need be moved and the application pointer may be left in place with no need unmap the application pages or invalidate cached virtual memory to physical memory translations. Thus, the computing device can transition from a kernel mode to a user mode with low computational overheads.

[0016] In some examples, the shadow kernel page table and the kernel page table are contiguous in physical memory, and wherein when the computing device transitions between the kernel mode and user mode the first pointer is repositioned by adding or subtracting the size of the current page table pointed to by the first pointer. Thereby, there is no need to separately store / retain the location of the other of the shadow kernel page table and the kernel page table (i.e. it can be computed in real-time). In some examples the kernel (first) pointer is a processor register and the transition between the kernel mode and user mode can be efficiently performed by move system to register and move register to system operations.

[0017] In some examples, the shadow kernel page is a trampoline page which comprises code which, at least in part, manages transitions between the kernel mode and user mode. The code acts to provide an efficient mechanism to manage the translation from a user mode to kernel mode. In some examples, the code is sufficient to manage the transition without the need for extra code to be stored elsewhere. In some examples, the trampoline page comprises trampoline code and a vector table. The vector table can act to capture user mode executions and trigger the trampoline code to manage the transition.

[0018] In some examples, responsive to a request to switch from the first application page table to a second application page table, the method comprises: selecting using the second pointer the second application page table from the plurality of application page tables, the second application page table associated with a second address space identifier, wherein the second application page table references one or more second application pages; mapping the one or more second application pages in the virtual address space and associating the one or more second application pages with the second address space identifier. Thereby, an efficient mechanism is provided to switch active applications which can be performed when the computing device is either in a user mode or in a kernel mode.

[0019] In some examples, the computing device comprises a translation lookaside buffer which stores recent translations, in association with an address space identifier and/or global indicator, between the virtual address space and physical memory. Thereby, by including a translation lookaside buffer recent translations of virtual to physical memory can be cached thus speeding up further instances of the same translations (e.g. since the translation can be looked up in the cache and does not need to be looked up in comparatively slow main computing device memory).

[0020] In some examples, when the computing device attempts to access an application page while the computing device is in the kernel mode, the computing device will invalidate any translation in the translation lookaside buffer which has the virtual address of the application page being accessed and which is associated with the unique kernel address space identifier prior to the application page being accessed. If, for example, a virtual address "A" associated with a first application was accessed and cached in the TLB while the computing device was running in a kernel mode the virtual address would be tagged with the unique kernel address space identifier as this would be the active address space. Then if, for example, the computing device was switched to a second application and a new request for virtual address "A" was made in kernel mode, the previously cached location in the TLB for virtual address "A" would be erroneous.

[0021] The above-described invalidation process overcomes this by invalidating pages in the TLB associated with the unique kernel address space identifier prior to the access of the application page thus avoiding the risk of using an erroneous physical address. It is to be noted that the invalidation is done in a targeted manner only as and when there is a risk of an erroneous match rather than, for example, always flushing the TLB on transition between the user and kernel mode, thus avoiding unnecessary overheads.

[0022] In some examples, when the computing device is in the kernel mode the computing device is prevented from accessing application pages. Thereby, the risk of an erroneous match in a virtual to physical memory cache for an application page is avoided.

[0023] In some examples, the shadow kernel page and/or the one or more kernel pages are marked as privileged in the virtual address space, and the one or more first application pages and/or the one or more second application pages are marked as non-privileged in the virtual address space. Thereby, by marking the (shadow) kernel pages as privileged (e.g. with a privilege bit) a further layer of security is provided as unprivileged processes (e.g. user application) will not be able to directly read the pages. Furthermore, when a side-channel such as Meltdown is used to read the shadow kernel page the above techniques prevent the "full" kernel from being read in such a manner as it is not mapped in the user mode.

[0024] In some examples, the shadow kernel page table references a code page marked as executable in the virtual address space, the kernel page table references a code page marked as executable in the virtual address space and a data page marked as non-executable in the virtual address space and the application page table(s) references a code page marked as executable in the virtual address space and a data page marked as non-executable in the virtual address space. Thereby, "Data Execution Prevention" is provided further enhancing security by preventing pages which are not meant to contain executable code (e.g. executable code being maliciously hidden as data pages) from being executed.

[0025] In some examples, the computing device comprises an operating system and wherein a kernel of the operating system which utilises the virtual address space is a microkernel. Thereby, limited capability devices (e.g. embedded-system or loT devices) which only run a microkernel can efficiently use their limited resources such as their small number of available address space identifiers and memory. Furthermore, by their nature, microkernels only access application address spaces in very limited circumstances hence further reducing any potential benefits of having two separate address space identifiers associated with each application as in the KAISER techniques.

[0026] In some examples, the computing device comprises a processor which supports execution in both a normal world and secure world and wherein the kernel associated with the kernel page table(s) and the applications associated with the application page table(s) are operating in the secure world. The provision of both normal and secure worlds can further enhance security by providing a further layers of separation between a kernel or a trusted application executing in a secure world and an application running in a normal world. Where, as here, both the kernel and application are executing in the secure world the secure world application can benefit from enhanced security from normal world applications while not compromising the security of the kernel through the above-described techniques for isolating the kernel and application page tables.

[0027] Viewed from one perspective, there can be provided a computer program for controlling an apparatus to perform any of the above-described methods. In some examples, the computer program is stored on a computer-readable medium.

[0028] Viewed from one perspective, there can be provided an apparatus comprising: processing circuitry to perform data processing; and memory circuitry storing a computer program for controlling the processing circuitry to perform any of the above-described methods.

[0029] Other aspects will also become apparent upon review of the present disclosure, in particular upon review of the Brief Description of the Drawings, Detailed Description and Claims sections.

BRIEF DESCRIPTION OF THE DRAWINGS

[0030] Examples of the disclosure will now be described, by way of example only, with reference to the accompanying drawings in which: [0031] Figure 1: Schematically illustrates an example method according to teachings of the disclosure for enabling a computing device to perform page table isolation.

[0032] Figure 2: Schematically illustrates an example method according to teachings of the disclosure for enabling a computing device to transition from a user mode to a kernel mode.

[0033] Figure 3: Schematically illustrates an example method according to teachings of the disclosure for enabling a computing device to transition from a kernel mode to a user mode.

[0034] Figure 4: Schematically illustrates an example method according to teachings of the disclosure for enabling a computing device to transition from a first application page table to a second application page table.

[0035] Figure 5: Schematically illustrates example contents of a virtual address space in A: kernel mode and B: user mode according to teachings of the disclosure.

[0036] Figure 6: Schematically illustrates an example of a computing device which can be

used to implement teachings of the disclosure.

[0037] While the disclosure is susceptible to various modifications and alternative forms, specific example approaches are shown by way of example in the drawings and are herein described in detail. It should be understood however that the drawings and detailed description attached hereto are not intended to limit the disclosure to the particular form disclosed but rather the disclosure is to cover all modifications, equivalents and alternatives falling within the spirit and scope of the claimed invention.

[0038] It will be recognised that the features of the above-described examples of the disclosure can conveniently and interchangeably be used in any suitable combination.

DETAILED DESCRIPTION

[0039] Figure 1 shows a schematic illustration of an example method 100 according to teachings of the disclosure for enabling a computing device to perform page table isolation.

[0040] At step 5110, a shadow kernel page table is selected using a first pointer. The shadow kernel page table references a shadow kernel page (e.g. a minimal subset of the kernel that allows for the full kernel to be called and mapped into the virtual address space). It is explicitly contemplated that in some examples the selected page table is merely a top level of a hierarchy of page tables. The method then continues on to step 5120.

[0041] At step 5120, the shadow kernel page is mapped into a virtual address space. The shadow kernel page is associated with a global indicator, for example, by a memory management unit (MMU) of the computing device. In some examples, the global indicator indicates that the shadow kernel page can be accessed irrespective of what address space identifier(s) is currently active. In some examples, the global indicator is a global bit. The method then continues on to step 5130.

[0042] At step 5130, a first application page table is selected from a plurality of application page tables using a second pointer. Again it is explicitly contemplated that in some examples the selected page table is merely a top level of a hierarchy of page tables. Each application page table is, in general, associated with a specific user application/process. The first application page table is associated with a first address space identifier and references one or more first application pages. The method then continues on to step 5140.

[0043] At step 5140, the one or more first application pages are mapped into the virtual address space. The one or more first application pages are associated with a first address space identifier, for example, by a memory management unit (MMU) of the computing device.

[0044] It will be appreciated that the depicted order of steps 5110, 5120, 5130 and 5140 is merely an example order and that these steps can be performed in any other suitable order. As one example, steps 5130, 5140 can be performed prior to steps 5110, 5120. As another example, step 5110 can be performed as the first step followed by 5130 followed by steps 5120 and 5140 in either order.

[0045] Figure 2 schematically illustrates an example method 200 according to teachings of the disclosure for enabling a computing device to transition from a user mode to a kernel mode in response to a request to transition the computing device from a user mode to a kernel mode.

[0046] It is to be appreciated that, in some examples, subsequent to the method 100 depicted in figure 1 that the computing device would be in a user mode and that method 200 would directly follow on. The method begins at 5210 with the computing device receiving a request to transition into the kernel mode. The method then continues to step 5220.

[0047] At step 5220, the first pointer is now repositioned to select a kernel page table. The kernel page table references both the shadow kernel page and one or more kernel pages. From one perspective the kernel page table can be viewed as referencing the "full" kernel. The method then continues to step 5230.

[0048] At step 5230, the one or more kernel pages are mapped into the virtual address space.

It is to be noted that the shadow kernel page need not be mapped at this stage as it is already mapped into the virtual address space. In some examples, prior to the one or more kernel pages being mapped into the virtual address space an MMU selects a unique kernel address space identifier. The one or more kernel pages are associated, for example by the MMU, with the unique kernel address space identifier. The unique kernel address space identifier is "unique" in the sense that the same unique kernel address space identifier is used whatever application page table is selected by the second pointer (e.g. it is the same whatever application/process is active). It is to be noted that, as discussed above, the shadow kernel page is not associated with unique kernel address space identifier and instead is associated with a global indicator.

[0049] Figure 3 schematically illustrates an example method 300 according to teachings of the disclosure for enabling a computing device to transition from a kernel mode to a user mode in response to a request to transition the computing device from a user mode to a kernel mode. The method begins at 910 with the computing device receiving a request to transition into a user mode. The method then continues to step S320.

[0050] It is to be appreciated that, in some examples, the method 300 follows on from the method 200 depicted in figure 2, for example, after the computing device has completed the procedure for which the kernel mode was called.

[0051] At step 5320, the first pointer is repositioned to select the shadow kernel page table.

The method then continues to step 5330.

[0052] At step 5330, the one or more kernel pages are unmapped from the virtual address space i.e. so these pages are not available to the computing device when operating in a user mode and hence not available to the user application/process. In some examples, prior to the one or more kernel pages being unmapped from the virtual address space an MMU selects a user address space identifier. It is to be noted that the shadow kernel page need not be mapped as it has already been mapped in the virtual address space. In addition, the shadow kernel page is not unmapped when the one or more kernel pages are unmapped as the shadow kernel page is used to allow for the "full" kernel to be called and hence is kept in the virtual address space.

[0053] In some examples, the shadow kernel page table and the kernel page table are contiguous in physical memory. As such, when the computing device transitions between the kernel mode and user mode, for example as described in either or methods 200 or 300 above, the first pointer can be repositioned by adding or subtracting the size of the current page table (i.e. either the shadow kernel page table or the kernel page table) pointed to by the first pointer.

[0054] In some examples, the shadow kernel page is a trampoline page which comprises code which, at least in part, manages transitions between the kernel mode and user mode. In some examples, the code is sufficient to manage the transition without the need for extra code to be stored elsewhere. In some examples, the trampoline page comprises trampoline code and a vector table. The vector table can act to capture user mode exceptions and trigger the trampoline code to manage the transition.

[0055] Figure 4 schematically illustrates an example method 400 according to teachings of the disclosure for enabling a computing device to transition from a first application page table to a second application page table.

[0056] It is to be appreciated that, in some examples, the method 400 can follow on from any of methods 100, 200, 300 described above. In some examples, the transition from a first application page table to a second application page table can be associated with a transition from the first application being the active application to the second application being the active application.

[0057] At step 5410, the second application page table from the plurality of application page tables is selected using the second pointer. The second application page table is associated with a second address space identifier and references one or more second application pages. The method then continues to step 5420.

[0058] At step 5420, the one or more second application pages tables are mapped in the virtual address space. The one or more second application pages are associated in the virtual address space with the second address space identifier, for example, by an MMU of the computing device. In the present examples there is no requirement to unmap the previously mapped one or more first application pages as these have been separately associated with the first address space identifier and hence there is no ambiguity between pages "belonging" to the first and second applications. In some examples, the first application pages may be unmapped when the second application pages are mapped, for example, to enhance security between the applications by ensuring that each other's pages are not available when the other application is active. In other examples, the first application pages may be unmapped on demand, for example, when virtual address space (e.g. in a cache) is required.

[0059] Figures 5A, 5B schematically illustrates the contents of two example virtual address spaces 500A, 500B. The virtual address spaces 500A, 5005 depicted are in some examples maintained by a MMU.

[0060] Figure 5A schematically illustrates an example virtual address space SODA when the computing device is in kernel mode. The depicted virtual address space includes a shadow kernel page 510, kernel data 520, kernel code 530, application data 540 and application code 550.

[0061] The shadow kernel page 510 is marked as a global page (i.e. can be accessed whatever address space identifier is currently active).

[0062] As set out above, in some examples, the shadow kernel page is a trampoline page which comprises code which, at least in part, manages transitions between the kernel mode and user mode. The trampoline page may include trampoline code and a vector table, where the vector table can act to capture user mode executions and trigger the trampoline code to manage the transition. In some examples, the code is sufficient to manage the transition without the need for extra code to be stored elsewhere.

[0063] The kernel data 520 and kernel code 530 are associated with the unique kernel address space identifier (e.g. translations in respect of the kernel data 520 and kernel code 530 can be marked with the unique kernel address space identifier in a translation lookaside buffer). These pages are non-global (i.e. can only be accessed when the unique kernel address space identifier is currently active). In some examples, non-global status is implicit by translations having an associated address space identifier. In other examples, non-global status is explicitly indicated through the inclusion of a specific non-global flag. It will be appreciated that the kernel data 520 may include a plurality of kernel data/bss/heap pages and that the kernel code 530 may comprise a plurality of kernel code pages.

[0064] The application data 540 and application code 550 are associated with the application address space identifier associated with the application/process that these pages belong to (e.g. translations in respect of the application data 540 and application code 550 can be marked with the application address space identifier in a translation lookaside buffer). It will be appreciated that the application data 540 may include a plurality of application data/bss/heap pages and that the application code 550 may comprise a plurality of application code pages. It will also be appreciated that since the kernel and application pages are associated with different address space identifiers there is, in general, no requirement to explicitly invalidate application page translations stored in any translation lookaside buffer upon transition between user and kernel modes.

[0065] While the above described virtual address space 500A has been depicted in a particular order it will be appreciated that any of shadow kernel page 510, kernel data 520, kernel code 530, application data 540 and application code 550 can be in a different order. Furthermore, while an unspecified "gap" (which may be empty or contain other pages) has been depicted between kernel code 530 and application data 540 it will be appreciated that this "gap" may not be present or that other "gaps" may be present between others of the contents of virtual address space 500A. It is also explicitly contemplated that the various contents need not be stored as single blocks in the virtual address space. For example, one or more pages of kernel data 520 may be present before kernel code 530 and one or more pages of kernel data 520 may be present after kernel code 530. In some examples, the shadow kernel page 510 is placed at or towards the top of the virtual address space 500A with application data/code 540, 550 placed at or towards the bottom of the virtual address space 500A. In other examples, the shadow kernel page 510 is placed at or towards the bottom of the virtual address space 500A with application data/code 540, 550 placed at or towards the top of the virtual address space 500A [0066] Figure 5B schematically illustrates an example virtual address space 500B when the computing device is in user mode. The depicted virtual address space includes the shadow kernel page 510 the application data 540 and the application code 550 but does not include either the kernel data 520 or the kernel code 530.

[0067] It will be appreciated, that like numbered elements depicted in virtual address space 5008 are substantially similar to those depicted in virtual address space 500A. As mentioned, the virtual address space 500B does not include either kernel data 520 or the kernel code 530. Accordingly, when the computing device is in a user mode (i.e. when an application's page table is active) the kernel data 520 or the kernel code 530 is not mapped and hence is protected from access by user applications/processes.

[0068] In some examples, various pages in the virtual address spaces 500A, 5008 are marked either as executable or non-executable to ensure Data Execution Prevention (DEP). Pages marked as non-executable are prevented from being executed in contrast to pages marked as executable for which execution is permitted. DEP can be used to protect against certain attacks, such as certain buffer overflow exploits, where pages marked as "data" contain malicious executable code.

[0069] In the present examples, the shadow kernel page 510, kernel code 530 and application code 550 are marked as executable. Further, the kernel data 520 and the application data are marked as non-executable.

[0070] Figure 6 schematically illustrates an example of a computing device 600 which can be used to implement teachings of the disclosure. The device includes processing circuitry 610, a memory management unit 620 and memory 630, and optionally may include a communications interface 640 and one or more user input/output devices 650. It will be appreciated, that the components are communicatively connected to each other, for example, using one or more buses.

[0071] The processing circuitry 610 performs data processing in response to program instructions. The memory management unit (MMU) 620 manages memory and caching operations on behalf of the processing circuitry 610. The MMU 620 handles the translation of virtual memory address to physical memory address.

[0072] In some examples, the computing device 600 includes a translation lookaside buffer (TLB) which stores recent translations, in association with an address space identifier and/or global indicator, between the virtual address space and physical memory. In some examples, the TLB may be implemented as part of a memory management unit (MMU) 620. In other examples, the TLB may be a separate component of computing device 600.

[0073] In some examples, when the computing device 600 attempts to access an application page while the computing device 600 is in the kernel mode, the computing device 600 will invalidate any translation in the translation lookaside buffer which has the virtual address of the application page being accessed and which is associated with the unique kernel address space identifier prior to the application page being accessed. For example, if a virtual address "A" associated with a first application was accessed and cached in the TLB while the computing device 600 was running in a kernel mode the virtual address would be tagged with the unique kernel address space identifier as this would be the active address space. Then if, for example, the computing device was switched to a second application and a new request for virtual address "A" was made in kernel mode, the previously cached location in the TLB for virtual address "A" would be erroneous. The above-described invalidation process avoids this issue by invalidating pages in the TLB associated with the unique kernel address space identifier prior to the access of the application page thus avoiding the risk of retrieving an erroneous physical address corresponding to the application page. In other examples, this problem of potentially erroneous lookups being made to the TLB is avoided by the computing device 600, when it is in the kernel mode, being prevented from accessing application pages [0074] The memory circuitry 630 stores data and instructions for processing by the processing circuitry 610. The memory circuitry 630 may include both a non-volatile region(s) (e.g. for long-term data and instruction storage) and a volatile region(s) (e.g. for temporarily storing data and instructions for short-term access). The memory circuitry 630 may have a secure region which is protected by hardware mechanisms (e.g. using memory protection units or security mechanisms providing a trusted execution environment) or by software mechanisms (e.g. encryption), so that data stored in a secure region is inaccessible to software not executing within a trusted environment.

[0075] The device 600 may optionally have a communications interface 640 for communicating with external devices. For example communications interface 640 could use any of a range of different communication protocols, such as Ethernet, WiFi®, Bluetooth'Y, ZigBee®, etc. [0076] The device 600 may optionally have one or more user input/output devices 650.

Examples of user input devices which could be used include a button, a keyboard, a mouse, a microphone, touch screen, a stylus or any other suitable user input device. Examples of user output devices which could be used include an LED, a screen, a speaker, a haptic feedback device, a printer or any other suitable user output device.

[0077] It will be appreciated that while each of the processing circuitry 610, the memory management unit 620, the memory circuitry 630, the communications interface 640 and the one or more user input/output devices 650 have been depicted as separate elements one or more of these elements could be combined as single physical entities. As one example, the MMU 620 may be implemented together with the processing circuitry 510 as part of a CPU. In another example, the MMU 620 may be integrated with, at least a part of, memory circuitry 630 as a single component.

[0078] In some examples, the computing device 600 includes an operating system and wherein a kernel of the operating system which utilises the virtual address space is a microkernel. A microkernel is a near-minimum size kernel which, in some examples, rarely requires access to user application data when running (i.e. in kernel mode).

[0079] In some examples, the processing circuitry 610 (e.g. a processor) supports execution in both a "normal world" and "secure world". Both the normal and secure worlds can execute user applications/processes, however, the secure world is typically reserved for the kernel and trusted applications. Typically, applications/processes running in the normal world face additional restrictions on execution of software operations or access to particular hardware components. In some examples, the normal world and secure world is implemented through separate dedicated circuitry in the processing circuitry 610. In some examples, only the secure world has access to a secure region of memory circuitry 630. Such features are supported, for example, by ARM TrustZone® Trusted Execution Environment.

[0080] The methods discussed above may be performed under control of a computer program executing on a device. Hence a computer program may comprise instructions for controlling a device to perform any of the methods discussed above. The program can be stored on a computer-readable medium. A computer-readable medium may include non-transitory type media such as physical storage media including storage discs and solid state devices. A computer readable medium may also or alternatively include transient media such as carrier signals and transmission media. A computer-readable storage medium is defined herein as a non-transitory memory device. A memory device includes memory space within a single physical storage device or memory space spread across multiple physical storage devices.

[0081] In the present application, the words "configured to..." are used to mean that an element of an apparatus has a configuration able to carry out the defined operation. In this context, a "configuration" means an arrangement or manner of interconnection of hardware or software. For example, the apparatus may have dedicated hardware which provides the defined operation, or a processor or other processing device may be programmed to perform the function. "Configured to" does not imply that the apparatus element needs to be changed in any way in order to provide the defined operation.

[0082] Although illustrative teachings of the disclosure have been described in detail herein with reference to the accompanying drawings, it is to be understood that the invention is not limited to those precise teachings, and that various changes and modifications can be effected therein by one skilled in the art without departing from the scope and spirit of the invention as defined by the appended claims.

Claims

CLAIMS: 1. A page table isolation method for a computing device, the method comprising: selecting using a first pointer a shadow kernel page table, wherein the shadow kernel page table references a shadow kernel page; mapping the shadow kernel page in a virtual address space and associating the shadow kernel page with a global indicator; selecting using a second pointer a first application page table from a plurality of application page tables, the first application page table associated with a first address space identifier, wherein the first application page table references one or more first application pages; mapping the one or more first application pages in the virtual address space and associating the one or more first application pages with the first address space identifier.
2. The page table isolation method of claim 1, wherein the computing device is in a user mode and responsive to a request to transition from the user mode to a kernel mode, the method comprises: repositioning the first pointer to select a kernel page table, wherein the kernel page table references the shadow kernel page and one or more kernel pages; mapping the one or more kernel pages in the virtual address space with a unique kernel address space identifier.
3. The page table isolation method of claim 2, wherein responsive to a request to transition from the kernel mode to the user mode, the method comprises: repositioning the first pointer to select the shadow kernel page table; unmapping the one or more kernel pages in the virtual address space.
4. The page table isolation method of claim 2 or claim 3, wherein the shadow kernel page table and the kernel page table are contiguous in physical memory, and wherein when the computing device transitions between the kernel mode and user mode the first pointer is repositioned by adding or subtracting the size of the current page table pointed to by the first pointer.
S. The page table isolation method of any preceding claim, wherein the shadow kernel page is a trampoline page which comprises code which, at least in part, manages transitions between the kernel mode and user mode.
6. The page table isolation method of any preceding claim, wherein responsive to a request to switch from the first application page table to a second application page table, the method comprises: selecting using the second pointer the second application page table from the plurality of application page tables, the second application page table associated with a second address space identifier, wherein the second application page table references one or more second application pages; mapping the one or more second application pages in the virtual address space and associating the one or more second application pages with the second address space identifier.
7. The page table isolation method of any preceding claim, wherein the computing device comprises a translation lookaside buffer which stores recent translations, in association with an address space identifier and/or global indicator, between the virtual address space and physical memory.
8. The page table isolation method of claim 7, wherein when the computing device attempts to access an application page while the computing device is in the kernel mode, the computing device will invalidate any translation in the translation lookaside buffer which has the virtual address of the application page being accessed and which is associated with the unique kernel address space identifier prior to the application page being accessed.
9. The page table isolation method of any of claims 1 to 7, wherein when the computing device is in the kernel mode the computing device is prevented from accessing application pages.
10. The page table isolation method of any preceding claim, wherein the shadow kernel page and/or the one or more kernel pages are marked as privileged in the virtual address space, and the one or more first application pages and/or the one or more second application pages are marked as non-privileged in the virtual address space.
11. The page table isolation method of any preceding claim, wherein the shadow kernel page table references a code page marked as executable in the virtual address space, the kernel page table references a code page marked as executable in the virtual address space and a data page marked as non-executable in the virtual address space and the application page table(s) references a code page marked as executable in the virtual address space and a data page marked as non-executable in the virtual address space.
12. The page table isolation method of any preceding claim, wherein the computing device comprises an operating system and wherein a kernel of the operating system which utilises the virtual address space is a microkernel.
13. The page table isolation method of any preceding claim, wherein the computing device comprises a processor which supports execution in both a normal world and secure world and wherein the kernel associated with the kernel page table(s) and the applications associated with the application page table(s) are operating in the secure world.
14. A computer program for controlling an apparatus to perform the method of any of claims 1 to 13.
15. A computer-readable medium storing the computer program of claim 14.
16. An apparatus comprising: processing circuitry to perform data processing; and memory circuitry storing a computer program for controlling the processing circuitry to perform the method of any of claims 1 to 13.