1. Field of the Invention
The present invention relates to the field of micro-processors and more specifically to multitask circuits capable of executing, at least from the user's viewpoint, several programs simultaneously. In practice, a single instruction of a program is processed at each time by a central processing unit (CPU) but several programs or program sections are stored in a RAM by the CPU which transfers lines of the program to be executed to a cache memory assigned thereto.
2. Discussion of the Related Art
FIG. 1 is a schematic block diagram of an example of a simplified architecture of the type to which the present invention applies. A CPU 1 equipped with a cache memory 2 (CACHE) is connected to one or several buses 3 of communication (data, addresses, control signals) with peripheral elements. Among the peripheral elements, a RAM 4 intended to contain the data (operands) of the programs being processed as well as the code lines of these programs (at least by blocks) is connected to bus 3. In practice, the programs contained in memory 4 generally originate from a mass storage 5 (MMEN), for example, a hard disk. This mass storage contains the programs likely to be executed by the CPU as well as the data saved when these programs are not being executed. Of course, several mass storages (CDROM, floppy disk, etc.) may be connected to bus 3.
To execute several different applications or programs temporarily stored in memory 4, CPU 1 must have a table of correspondence between so-called virtual addresses of the program, which are independent from its storage location, and so-called physical addresses corresponding to the physical addresses in the memory, for example memory 4, where the different program lines are stored. This correspondence table is generally stored in buffers and is generally designated as a TLB (Translation Look Aside Buffer).
FIG. 2 schematically and functionally illustrates a correspondence table 10 and the exchanges between the cache memory or register containing this table and the different elements using it.
On the side of CPU 1, each time an instruction of a program stored in RAM 4 must be executed, this instruction is called by using virtual address VirtAD of this instruction corresponding to the address contained in the program. This virtual address is converted by table 10 into a physical address PhysAD where this instruction is located in RAM 4. RAM 4 then provides the corresponding instruction over the bus (3, FIG. 1) to the CPU.
If table 10 does not contain the correspondence between the two addresses, the CPU or, more specifically, a calculation program (block 11, CALC) of its exploitation system calculates a new correspondence line between the virtual address and the physical address, and writes it into correspondence table 10.
Each time an application contained in RAM 4 must be executed by the CPU, the exploitation system takes over and uses its internal structures to calculate the correspondence table for the involved program.
FIG. 3 illustrates the fact that two different applications APPL1 and APPL2 stored in RAM 4 at different physical addresses (PhysAD(k) to PhysAD(m) for the first program and PhysAD(n) to PhysAD(p) for the second program) share identical virtual addresses (VirtAD(1), VirtAD(2), VirtAD(i), etc). Each time a program comes to the foreground, that is, is executed by CPU 1 (possibly after transfer into cache memory 2), its correspondence table 10 is used to convert its virtual addresses into physical addresses in memory 4.
For security reasons in the program execution, it is important for two identical virtual addresses of two different applications not to point to the same physical address in memory 4. Indeed, this enables protecting the program code, as well as the application data, from one another. For example, if critical data (secret quantity, secret result, etc.) of a first application are located at a physical address between addresses k and m in memory 4 while they are assigned a virtual address i, absolutely no other application must be able to access the corresponding physical address by reusing virtual address i. In an architecture of the type in FIG. 2, the correspondence table must be reset each time it is switched from one application to another. This imposes recalculating the correspondence table each time an application switches to a foreground execution, that is, one of its instructions must be executed by the CPU.
An obvious disadvantage is that this takes time.
FIG. 4 schematically illustrates the architecture of a conventional solution avoiding recalculation of the correspondence table each time an application comes to the foreground. This solution uses an additional field of correspondence table 10 which contains, for each line, an identifier ASID of the application in addition to the virtual and physical addresses. This enables, in principle, avoiding association of an application with a physical address corresponding to another application.
To implement this solution, the circuit uses a register 20 (ASIDREG) containing the identifier of the current application. This register is a state register of CPU 1.
This solution has the advantage, as compared to that of FIG. 2, of not requiring resetting or emptying the correspondence table each time the foreground task is changed.
A disadvantage however remains that it is the exploitation system that assigns identifiers ASID to the different applications when an application is loaded into the RAM for execution. The area of RAM 4 assigned to a suspended (background) application accordingly becomes more vulnerable to possible attacks. Indeed, from the moment that the correspondence table is not integrally recalculated when the application comes to the foreground, it is possible to replace the RAM with an emulator, or to modify the signals on bus 3, to modify an operation code of a background application and insert a pirate instruction (of virus or “Trojan horse” type) therein. Then, when the modified application comes back to the foreground, it can then have access to the physical addresses which have remained present in the correspondence table upon former execution of the modified application (ie., before it has been modified).
This vulnerability of a background application is increased by the fact that it is not necessary to be synchronous with the CPU to modify the lines of this memory.
A similar problem is posed for mass storage 5 when the program is not integrally loaded into RAM 4 and its execution requires data line calls in mass storage 5.
USPTO Backgrounds
USPTO Backgrounds