GR20180200176U - Delay masking action for memory access requests - Google Patents

Abstract

An apparatus comprises control circuitry to control access to a memory implemented using a memory technology providing variable access latency. The control circuitry has request handling circuitry to identify an execution context switch comprising a transition from servicing memory access requests associated with a first execution context to servicing memory access requests associated with a second execution context. At least when the execution context switch meets a predetermined condition, a delay masking action is triggered to control subsequent memory access requests associated with the second execution context, for which the required data is already stored in the memory, to be serviced with a response delay which is independent of which addresses were accessed by the memory-access requests associated with the first execution context. This can help guard against attacks which aim to exploit variation in response latency to gain insight into the addresses accessed by a victim execution context.

Description

MASK DELAY FUNCTION FOR REQUESTS

MEMORY ACCESS

BACKGROUND

Technical field

The present technique relates to the field of data processing. More specifically, it relates to accessing a memory that is implemented using a memory technology that provides variable access latency.

Technical background

Certain types of memory technologies used in data processing systems may provide a variable access latency. Therefore, sometimes memory access requests can be served with higher latency than other times. More specifically, with some forms of memory technologies the access latency may depend not only on whether the required data is already stored in memory, but even in cases where the required data is stored in memory, there may be a variance in the access latency depending on which specific memory location stores the required data and/or depending on the previous access addresses.

SUMMARY

At least some examples provide an arrangement comprising: a control circuit for controlling access to a memory implemented using a memory technology that provides variable access latency, the control circuit comprising: an interface circuit for receiving access requests in memory to be serviced by memory and providing responses to memory access requests serviced by memory, and a request management circuit for: determining an execution context switch that includes a transition from servicing memory access requests associated with a first execution context in servicing memory access requests associated with a second execution context and at least when the execution context switch satisfies a predetermined condition, triggering a function to control subsequent memory access requests associated with the second context execution frames, for which the required data is already stored in memory, to be served with a response delay that is independent of the addresses accessed by the memory access requests associated with the first execution frame, with said response delay to include a delay between the receipt of the memory access request by said interface circuit and the provision of a response to the memory access request by said interface circuit.

At least some examples provide a method for controlling access to a memory implemented using a memory technology that provides a variable access latency, the method comprising: receiving memory access requests for service from the memory and providing responses to memory access requests served by the memory, determining an execution context switch that includes a transition from serving memory access requests associated with a first execution context to serving memory access requests associated with a second context execution frame and at least when the execution frame switching satisfies a predetermined condition, triggering a masking delay function to control subsequent memory access requests associated with the second execution frame, for which the required data is already stored in memory, to service with a response delay that is independent of the addresses accessed by the memory access requests associated with the first execution frame, said response delay comprising a delay between the receipt of the memory access request by the due to an interface circuit and the provision of a response to the memory access request by said interface circuit.

Further aspects, features and advantages of the present technique will become apparent from the following description of the examples, which should be read in conjunction with the accompanying drawings.

BRIEF DESCRIPTION OF THE DRAWINGS

Figure 1 schematically illustrates an example of a data processing system including at least one memory device,

Figure 2 illustrates an example of a memory arrangement implemented using dynamic random access memory (DRAM), Figure 3 illustrates an example of an attack to gain access to secret information associated with a victim execution context with based on the analysis of the variation of the latency of access to a memory,

Figure 4 shows an example of a control circuit having a request handling circuit for determining execution frame switches and triggering a delay masking reaction in response to an execution frame switch that satisfies a predetermined condition,

Figure 5 shows an example of creating an execution context ID associated with memory access requests,

Figure 6 shows an example of using a frameswitch separation indicator as an indication of the existence of an execution frameswitch,

Figure 7 illustrates an example of delaying a request or a response to a memory access request to mask an actual response delay associated with the memory access,

Figure 8 shows an example of tagging cache entries with the execution frame ID so that a downstream component can determine which frame is associated with asynchronous write requests, and

Figure 9 is a flow chart showing a method of determining whether to perform a masking delay operation.

DESCRIPTION OF EXAMPLES

A data processing arrangement may have security mechanisms to ensure that certain secret information is accessible to certain execution frameworks running on the data processing system without being accessible by other execution frameworks. For example, an execution context may be associated with a given privilege level, and some data may only be accessible to a context that has a certain privilege level or higher. For example, memory protection techniques can be used to enforce the desired memory access rights.

However, it has been recognized that the variable access latency provided by some forms of memory technologies can be exploited by attackers to bypass certain security protections provided to limit access to certain sensitive information. For example, the attacker's runtime and a victim's runtime that has access to sensitive information inaccessible to the attacker can each allocate data to a given memory. If the victim frame accesses its data first, and then after an execution frame switch to the attacker frame, the attacker frame accesses its data, then with some memory technologies the latency to respond to memory access requests issued from the attacker's frame may depend on the addresses accessed by the victim frame before execution frame switching. This may make it possible to infer information about the operation of the victim frame, which could leak some side-channel information about the secret information.

One approach to countering such attacks could be to use a constant latency policy in which any memory access request for which the required data is already stored in a given memory is served with a response delay equal to some predefined constant latency time. However, this can be detrimental to performance since often the fixed latency should be the latency operator provided by the memory device and thus this can unreasonably require a large number of requests to be delayed to slow down the performance of the processing system.

The device described below provides a control circuit for controlling access to a memory implemented using a memory technology that provides variable access latency. For example the control circuit could be a part of an interface or a memory controller. The control circuit has an interface circuit for receiving memory access requests to be serviced by the memory and providing responses to memory access requests that have been serviced by the memory. The control circuit also has a request management circuit for determining an execution context switch which includes a transition from servicing memory access requests associated with a first execution context to servicing memory access requests associated with a second execution context. At least when the execution frame switch satisfies a predetermined condition, the request handling circuitry triggers a latency masking function to control subsequent memory access requests associated with the second execution frame, for which the required data is already stored in memory, to serving with a response delay which is independent of the access addresses from the memory access request associated with the first execution context. Here the response delay refers to a delay between the receipt of the memory access request by the interface circuit and the provision of a response to the memory access request by the interface circuit.

By providing a control circuit capable of determining when a transition occurs from servicing memory access requests associated with a first execution context to servicing memory access requests associated with a second execution context, this means that it is not necessary triggering the delay masking function on each memory access request. Instead the delay masking function can be triggered at least when the execution frame switching satisfies a predetermined condition. This can help reduce the performance overhead of dealing with the types of security attacks discussed above that exploit variable memory access latency. By triggering a latency masking function in response to an execution frame switch that satisfies the predefined condition, this means that the latency associated with responding to memory access requests after the execution frame switch does not depend on the addresses accessed by memory access request associated with the first execution context. Therefore if the second execution frame is an attacker frame and the first execution frame is a victim frame, the attacker is not able to learn information about the addresses accessed by the victim frame from analyzing the access delays in memory from the attacker's context.

In some examples, at least when the execution frame switch satisfies the predetermined condition, the response management circuit may ensure that at least one subsequent memory access request associated with the second execution frame, for which the required data is already stored in memory, served with a fixed response delay. For example with a memory that includes multiple storage units (eg arrays) accessed in parallel, the at least one subsequent memory access request handled with a fixed response delay could include at least one first memory access request to each unit storage which is served after execution frame switching. Note that the first memory access request served after the execution frame switch may be the first memory access request for which a memory response is provided, which may not necessarily be the first memory access request received from memory after execution frame switching. Some memories may implement a quality of service policy that makes it possible to service requests out of order relative to the order in which they were received. So sometimes the first memory access request served after the execution frame switch could actually be the second or third request received after the execution frame switch, for example.

By ensuring that at least the first memory access served by a given storage unit after a frame switch is handled with a fixed response delay, this can make it more difficult for an attacker to obtain information about the addresses accessed immediately before the frame switch by a different execution context. In some cases, more than one subsequent memory access request to each storage unit could be handled with a fixed response delay. For example, in some cases to improve security the fixed response delay may be imposed for a certain period after the frame switch with the size of the period being defined according to the level of security required for a given implementation.

In other examples, the response delay imposed after execution frameswitching may not be required to be constant, but could be some random value that does not depend on any pattern of addresses accessed prior to frameswitching. As long as the response delay is not correlated with the addresses accessed before the first execution frame then this is sufficient to prevent the attacker from being able to obtain information about the operation of the victim frame by analyzing the access timings.

In some embodiments, after the execution frame switch, the request management circuit may control the servicing of at least one subsequent memory access request associated with the second execution frame for which the required data is already stored in memory, with a variable response delay to depend on the variable access latency provided by the memory. Therefore, it is not necessary to impose a fixed or random latency on all requests. For example, the delay masking function may affect one or more subsequent requests in an initial period after the frame switch, but then the delay masking function could be removed (or some subsequent requests may not be affected by the delay masking function); when it is no longer necessary to ensure that the response delay for subsequent requests is completely independent of the previous access addresses. This recognizes that the risk of information leakage may be highest immediately after a context switch, but thereafter the risk may decrease as more requests are served from the new context, because the greater the number of requests served in the new context, the more likely it is that response timings depend on the activity of the new frame rather than the activity of the previous frame.

For example, the at least one subsequent memory access request (for which the response delay may be variable and proportional to the variable access latency provided by the memory), may be a memory access request to a group of one or more memory locations that were already accessed by another memory access request served after the execution frame switch. In some memory formats, the variable memory access latency may be such that the access latency is less when the memory access request accesses a memory location in a first state than when the memory access request accesses a memory location in a second state, wherein an access to a memory location in the second state triggers a transition of a corresponding group of one or more memory locations from the second state to the first state.

For example, some memory technologies may require that a group of memory locations be opened, activated, or cached before any memory location in that group can be read/written. If a memory location to be accessed is not currently in an open/activated/cached memory location group, then the group containing that memory location may need to be opened/activated/cached (i.e. a transition from the second state to the first state), while if another group is already open/enabled/cached then that other group may need to be closed/disabled or cached instead (which could require retroactive writes to the underlying memory storage table), i.e. a transition from the first state to the second state. The group of memory locations that transitions between the first/second state as an entire unit may correspond to a page of a DRAM structure, a row of a memory array, or a group of two or more rows, for example.

Another example of a variable response latency memory technology may be a memory that uses a physical read head that moves over a storage medium, e.g. a turntable drive. In this case, the distance the head must travel (and thus the latency) to reach the desired position depends on the position of the previous read request and the current read request. Thus, metal disks (spinning disks) may essentially correspond to arrays of a DRAM, and the current position of the read/write head may essentially correspond to an “open” set of positions as discussed herein for DRAM. The “first state” could be a state when the distance the head needs to cover to the desired position from its current position is less than a certain threshold value, while the “second state” could be a state when the distance between the current position and the desired position is greater than the threshold value.

For accesses to a pool of one or more memory locations that have already been accessed at least once since the execution frame switch, the risk of timing side-channel attacks can be relatively low because the already served request to the same pool from the second execution frame would force the memory request pool to the first state (open/enabled/cached) regardless of whether or not the same pool had previously been accessed in the first execution frame prior to the execution frame switch. Therefore, allowing the response delay to be variable depending on the actual memory-imposed delay for requests associated with the second execution context that focus on a group of locations that have already been accessed by another memory access request in the second execution context that has been served after execution context switching, this can improve performance without exposing the second execution context to the risk of attack by the first execution context.

The request handler can detect execution frame switches in a number of ways. In one example, the request management circuit may detect an execution frame switch that satisfies the predetermined condition when a frame switch split indication is detected in a stream of memory access requests from the interface circuit. For example the processing element or the interface responsible for creating or forwarding/routing the memory access request could show additional separation indications when the processing element has switched from executing one execution frame to switching another execution frame , so that the memory-related control circuitry can detect the point at which subsequent memory access requests relate to a different execution context. Therefore when a separator is included in the stream of memory access requests this can be interpreted as a frame switch by the request handling circuit so that the delay masking function can then be excited and ensure that at least one subsequent request is served with a response delay of which is independent of the addresses of previous accesses.

In some cases, the frameswitch separation indication could be generated automatically by hardware in a processing element or a memory system component (e.g., an interface) based on an execution frameswitch detection in the processing element, such as based on interrupts that trigger a frame change or frame identifiers associated with the processing element's current architectural state. In other examples, the frame switch split indication could be generated in response to a software trigger, such as a split generation command included in software executing in the processing element of the data processing device. Therefore, a programmer or software editor can increase the security of a program code by including split statements that trigger the creation of the frameswitch split flag so that the programmer or editor can ensure that a subsequent part of the program will not be able to obtains information about the operation of an older part of the program that precedes the create split command. Other examples may support hardware- and software-generated partitions.

Another approach may be to detect execution frame switching based on execution frame identifiers associated with at least a subset of memory access requests received by the interface circuit. For example, the device may have at least one processing element for issuing the memory access request received from the interface circuit, and a given processing element may generate the execution context identifier associated with a given memory access request. For example a processing element could assign to its memory access request the identifier of the currently running execution context that caused the memory access request to be made. It is not necessary to assign each memory access request the execution context ID. For example on some systems the processing component could provide the execution context ID only when there is an execution context switch and when memory access requests are received which do not specify an execution context ID then they may be assumed to be related to the same execution context as the most recently received memory access requests that specify an execution context ID. Alternatively, in a system that has multiple processing elements then to distinguish between requests made by multiple processing elements (which could be mixed), it may be preferable for each memory access request to specify the execution context identifier of the corresponding frame switch that generated the request. Therefore, the exact way execution context identifiers are assigned to requests can vary from implementation to implementation.

Each execution context may generally be a portion of the software workload running on the data processing device. For example an execution context could refer to a certain process or group of processes executed by a processing element or a virtual machine executed by a given processing element or subpart within a process, application or virtual machine for example. Some processes could be divided into sections corresponding to separate execution contexts (eg different tabs of an internet browser might be protected from each other for security purposes by assigning different execution context identifiers to each tab). Alternatively, in some cases several different processes that are not considered to be vulnerable to attacks from each other could be grouped into a single execution context identified by a single execution context ID value. In other examples, execution context may refer to a group of one or more processes that operate under a certain security mode or at a given exception level or privilege level (e.g., different processes running at the same privilege level or with the same security mode could be perceived as the same execution context). Also, in some cases the software running on a given processing element could itself provide indications of the parts of the software workload being run which should be considered as separate execution contexts and therefore in some cases identifiers may be used determined by software to distinguish between different execution contexts. Also, the particular processing component of a multiprocessing component system executing the frame could form part of the execution frame identifier, so that the exact same software process when executed on different hardware processing components of the multiprocessing system could be considered as different frames execution frame for the control circuit to determine whether to apply the delay masking function after a frame switch to or from the corresponding execution frame.

Accordingly, a given processing element may generate the execution context identifier associated with a given memory access request based on at least one of the following:

a process identifier or address space identifier associated with a process running on the processing element;

a virtual machine identifier associated with a virtual machine running on the processing element,

a processing element identifier associated with the given processing element;

a security mode identifier identifying a current security mode of the given processing element;

an exception level identifier that identifies a current exception level of the given processing element, and

a software-defined identifier provided by the software running on the processing element.

Note that the “execution context switch” detected by the control circuitry refers to the point at which there is a transition between memory access requests handled by one execution context and memory access requests associated with a different execution context. The time at which the control circuit determines the execution frame switch in the stream of processed memory access requests may differ from the time at which the corresponding processing element actually switched the executed execution frame instructions (e.g., the control may not see the execution frame switch for some time after the corresponding switch in the processing element).

In some example implementations, the selection of the order in which to service memory access requests received by the interface circuit may be independent of the execution context associated with each request. For example, some examples could simply select requests to service in the same order in which they are received. Other examples could be more sophisticated and allow requests to be reordered so that requests targeting the same group of memory locations in memory can be grouped together to reduce the latency of those accesses targeting the same group. In any case, the circuitry that chooses the order in which requests are served may also have to respect other constraints, such as data dependencies between successive requests to the same address (which may have to be served in the same order as which are received) and possibly other requirements such as whether the requests are related to array-type memory (for which reordering requests compared to the order in which they were received may not be allowed even for requests that do not have a data dependency). Thus there may be a number of criteria for selecting the order in which received requests are served. If execution context is not included in this option then it is possible that the sequence of requests passed to memory will contain a number of individual requests each of which is associated with a different execution context, so that there are frequent execution context switches whenever there is a request from a different context immediately following a request from a previous context. This may be simpler to implement within the control circuit, however it may result in frequent triggering of the delay masking function which could have a negative impact on performance.

Accordingly, in some examples the request handling circuitry may be arranged to group together memory access requests associated with the same execution context as a group of requests to be serviced sequentially by memory. The request management circuit may trigger the delay masking function when switching from a group of memory access requests associated with the first execution frame to a group of memory access requests associated with the second execution frame at least when the switch from the first frame execution in the second execution frame satisfies the predefined condition. Therefore, instead of simply passively observing when there is an execution context switch between a memory access request associated with an execution context and a request associated with another context, in some cases the request management circuitry can actively control when such an execution frame switching so execution frame switching is determined when the request management circuit decides to switch from serving a group of requests associated with the first execution frame to a group of requests associated with the second execution frame. This can improve performance by reducing how often the delay masking function is triggered.

In approaches that group memory access requests from the same context together, however, a number of other criteria may be applied to determine the order in which the requests are serviced, such as data dependencies, sort constraints, layout type memory, etc. Therefore , in some cases the request handler circuit may be limited in terms of the number of requests that can be grouped together by a given execution context. However in general grouping together requests from the same execution context when possible can help improve performance.

In some implementations the request management circuit could simply trigger the delay masking function after any execution frame switch, regardless of whether the execution frame switch satisfies the predetermined condition. While it is possible that some execution context transitions are not vulnerable to the type of security attack discussed above, this approach may prioritize security over performance. Even if the delay masking function is excited for each execution frame switch, some forms of the delay masking function can only be applied to a certain number of requests after the execution frame switch so that some performance can be saved by preventing extra delays from being added to each request after the switch framework.

However, in other examples the request handling circuit may omit triggering the delay masking function when the execution frame switch does not satisfy the predetermined condition. Therefore, the request handling circuit can judge whether the particular switching of execution frames causes a security vulnerability risk. For example, in one example the predetermined condition may be whether the second execution context is a context that is prohibited from accessing at least some data that is accessible by the first execution context. For example this could be determined based on the privilege levels associated with the first and second execution contexts respectively. In some cases the default condition may be that the second execution context is a less privileged execution context than the first execution context, so that an attacker with a lower privilege level cannot obtain information about the addresses accessed by a most privileged context, which if the addressing scheme accessed by the most privileged first execution context depended on some portions of secret information could allow some portions of the secret to be deduced by the attacker. Other systems may also have some security mechanisms in place to prevent access from a more privileged context to data that can be accessed from a less privileged context (e.g. in data center applications, it may be desirable to perform various of virtual machines on the same physical platform for exclusive access to some secret data that cannot be accessed by the supervisor operated by the cloud platform provider). Accordingly, if such mechanisms are provided then it may be considered that the predetermined condition should also be satisfied when the second execution context is a more privileged process than the first execution context. In some cases the predefined condition may include that the second execution context is a context associated with a different privilege level than the first execution context (so that delay masking can be bypassed for transitions between contexts at the same privilege level).

In other examples, instead of being based on privilege level, some systems may have secure and non-secure modes where running a context in an insecure mode does not access data accessible in secure mode. Therefore in some cases the predetermined condition may include a second execution frame which is a frame associated with the non-secure domain while the first execution frame is associated with the secure domain so that the delay masking function is triggered by a switch from a secure context to a less secure context, but not be triggered when a transition in the opposite direction occurs since it may not be considered important to prevent a secure process from obtaining information about addresses accessed by an insecure process.

In other examples, the predetermined condition could be whether the first execution frame is a frame from a predetermined subset of execution frames. For example, specific frames can be specified as needing protection, and any frame outside the list of protected frames could be considered as not needing the protections provided by the delay masking function. For example, some critical execution frames may be specified as requiring the extra security protection, and therefore when the request handler traces an execution frame from one of these critical execution frames to another frame then it may apply delay masking, but otherwise the delay masking function could be omitted to improve performance.

Delay masking can be implemented in a number of different ways. In general the delay masking function can be any function which ensures that subsequent memory access requests associated with the second execution frame after the frame switch, for which the required data is already stored in memory, are served with a delay response which is independent of the addresses accessed by requests associated with a first execution frame prior to execution frame switching. The technique discussed above can be applied to various memory arrangements in a data processing system, including both main memory and cache memory. For main memory that is not acting as a cache, then any request that targets an address mapped to that memory will have the required data already stored in memory, so there is no chance that the memory access request will require data that is not already stored in main memory. On the other hand, for a cache access requests may meet a cache hit or a cache miss depending on whether the required data has already been allocated in the cache, which may depend on the previous access addresses. In cases where the memory is a cache and memory access requests fail the cache so that the required data is not already stored in memory, then even if the delay masking operation is performed, the response delay may still depend on the addresses which were accessed before the frame switch, since a cache miss may require the data to be served from a further cache or from main memory, and the time required to service this line fill request may vary depending on extent to which the data has already been stored in the further caches within the memory system. Known techniques, such as discarding caches in response to an execution frame switch or slicing the cache into areas reserved for specific execution frames, can be used to counter attacks aimed at exploiting the timing variation caused by the different layers of the cache that may have data allocated to it.

In contrast, the latency masking function discussed here is intended to address the variation in latency associated with memory access requests for which the required data is already stored in memory, i.e., requests to a non-cache memory device for which memory occupancy does not depend on previous accesses (i.e. no eviction as in caches and allocation of data in memory based on recent addressing schemes) or requests that hit a memory used as a cache (instead of requests which result in a cache miss).

In a memory using a technology which has memory locations in a first state or a second state as discussed above, where there is a lower access latency when a request to block is made in the first state than when the memory access request makes accessing a group in the second state, the delay masking function could in some cases include checking the memory for transition of each group currently in the first state from the first state to the second state. For example, the delay masking operation could include closing or disabling one or more pages or rows of memory locations, or clearing a cached group of locations and writing it back to the storage array. This means that after the execution frame switch that satisfies the predetermined condition, the next request served after the execution frame switch is served with a latency corresponding to the second state.

For example, with a DRAM-based memory, the latency corresponding to the second state could correspond to the delay associated with accessing a closed row within a DRAM array where no row is already open at that time. Therefore, in some cases the fixed delay applied for at least some memory access requests after the frame switch may correspond to the closed array access delay of the DRAM. When the delay masking function involves triggering the closing of pages of memory locations as discussed above, then this can mean that the first access served on each array after the frame switch can have a constant delay (second state latency) corresponding to the closed condition array, but then subsequent served requests associated with the second execution context that access the same page as an earlier served request associated with the second execution context could still be served with the page-open delay (first-state latency ) if they access the same page as another request served by the execution context switch. Therefore, although paging memory locations (or transitioning from the first to the second state) may be sufficient to ensure that the response latency of all subsequent requests of the second execution frame is independent of the address scheme being accessed from the first execution frame, this does not require servicing each subsequent request of the second execution frame with a fixed delay (since requests can be handled faster when accessing an already open page of memory locations), to improve performance.

Alternatively, the delay masking function could include delaying one or both of the following: (i) a memory access request served after the execution frame switch or (d) a response to the memory access request served after execution frame switching, keeping the request or response in a delay buffer for some time to mask an actual access latency provided by the memory while servicing the at least one memory access request. In some approaches this could save power because the operation of closing or disabling pages of memory locations may require pre-charging the signal lines within the memory structure which translates into additional power consumption. Instead of actually closing in-memory locations, open/enabled pages resulting from access plans in the first execution context could be kept open during the switch to memory access request management associated with the second execution context, but a delay buffer can be used to simulate a delay as if the pages were closed/disabled so that even if a request from the second execution framework targets the same page accessed by the first execution framework, the second execution framework cannot determine from the response latency that the first execution context accessed the same page of the memory structure.

In some examples, during a delay period when the memory access request or response is delayed in the delay buffer, the request manager may control the memory to service at least one other request that targets the same page in memory as the delayed one memory access request. For example, the other request could be another memory access request (a read or write request), an asynchronous write request that triggers an asynchronous write from an in-memory cache, or a refresh operation to refresh the contents of memory in a type of memory that requires periodic refresh to maintain its state. This approach can allow the request handler to use the delay period (when a given request or response is delayed to simulate memory being slower than it is actually serving the request) to service another request in the meantime so that it does not it is necessary to wait until the end of the simulated delay before servicing this other request. This can improve performance.

A given memory array can serve several types of requests, such as read requests that request data to be read from memory and write requests that request data to be written to memory. In general, read and write requests can be requests that are triggered directly by software running on a processing element or by a hardware element such as a prefetcher that prefetches data from memory based on the observed activity of a given execution context running on the processing element. Such requests can be relatively simple to associate with specific execution contexts, for example the processing component that originated the read or write request could tag the requests with the ID of the execution context currently running.

However, another type of request that may need to be serviced by memory may be a write asynchronous request which is a request to write data asynchronously from a cache to memory. In this context, the memory could be a further-level cache into which data is written from a cache closer to the processing element, or it could be main memory that replaces the backup storage space in one or more cache levels memory. With asynchronous write requests, the timing at which the asynchronous write request is issued can be decoupled from the time at which the data was written to the cache by a processing element under the control of a given execution context. Therefore, at the time the rollback request is issued it may be more difficult to determine the execution context associated with the rollback request. For example, the timing at which an asynchronous write request is issued may depend on the time the corresponding data is evicted from the cache, which may depend on the subsequent access plans of the addresses that have nothing to do with the execution context. which actually wrote the data in the first place. In some implementations, it may be considered that since the timing at which asynchronous write requests are issued actually depends on the cache control policy adopted, which may be relatively difficult for an attacker to influence, then the risk of information being obtained by an attacker to run a victim process, based on the memory access latency experienced for asynchronous write requests or for subsequent requests after the asynchronous write request, may be relatively low. Accordingly, in some implementations the request handling circuitry may not attempt to determine specific execution contexts associated with asynchronous write requests.

However, in other systems with a higher security requirement it may also be desirable to counter potential side-channel attacks that exploit the variation in the timing of a memory access burst associated with an attacker process following a write asynchronous request associated with data which were originally registered by a victim process. A number of options are available to counter such attacks.

In a first example, the request handling circuitry may determine that write-ahead requests that request the asynchronous write of cached data from an in-memory cache are associated with a dedicated write-ahead execution context, independent of the execution context which actually caused the cached data to be allocated to the cache. Therefore, all asynchronous write requests can simply be assumed to be associated with their own specific execution context so that asynchronous write requests can be grouped together in a similar way to requests from other execution contexts as discussed above. When there is a switch from handling a pool of asynchronous write requests to handling requests from a real (non-asynchronous write) execution context, the circuit manager circuit may identify it as an execution context switch that satisfies the predefined condition and therefore may trigger performing the delay masking function. By grouping asynchronous write requests together, this can reduce the frequency with which there are switches between handling a asynchronous write request and handling a memory access request associated with a real execution context, which can reduce vulnerability to side channel attacks.

Another approach might be that each individual asynchronous write request is essentially treated as its own execution context, so that each transition from servicing a given asynchronous write request to servicing another request (e.g. a different asynchronous write request or a non-synchronous write memory access) is treated as an execution frame switch. Accordingly, the request management circuitry could ensure that after a given write-ahead request is serviced, delay masking may be performed so that a subsequent memory access request or a subsequent memory-served write-ahead request, for which the required data is already stored in memory, be served with a response delay regardless of the address specified by the given write-back request. For example, the page or pool of the memory structure accessed by the asynchronous write request could transition to the second state (eg, closed or disabled) before servicing the next request after the asynchronous write request, so that it is possible to ensure that even if the write-back request was associated with a victim process of interest to an attacker, the attacker's subsequent memory access request cannot be used to obtain information about the write-back address.

A third option might be for the cache that stores the cached data to store a pointer to the execution context ID along with the cached data itself, so that when the cache makes a write-back request for the asynchronously writing a predefined group of cached data into memory, the asynchronous write request may be tagged with the execution context ID associated with that group of cached data. With this approach, the request handler can determine the actual execution context associated with the cached data and group it together with requests from the same execution context if necessary. In other words, with this approach the request handler can treat asynchronous write requests in the same way as discussed above for normal memory access requests, using an execution frame identifier specified by the request to identify frame switches . Although this approach may increase the storage capacity required in the cache, it may reduce the risk of information leakage through address plan information accessed by asynchronous write requests.

The technique discussed above can be applied to a range of memory technologies, such as DRAM, non-volatile RAM (NVRAM) such as flash memory or a spinning disk memory, or another form of memory technology that uses a hardware read head that moves onto the storage medium. It is particularly useful in forms of memory technologies where, to access a given memory location, the corresponding page, row, or group of rows of the memory structure is read into a buffer, and then the reads and writes to that page, row, or group of rows they can be served by the cache faster than a request that requires a different non-cached area of memory. DRAM and NVRAM are examples of this, but it will be appreciated that other forms of technology could have similar variable latency depending on the current cached/uncached state of the access memory location.

Figure 1 schematically illustrates an example of a data processing system 2 with a number of processing elements 4, such as processor cores, central processing units (CPU), graphics processing units (GPU) or any other device capable of issuing data access requests from memory. At least some of the processing elements 4 may have at least one cache 6 for caching data from the memory system for faster access by the processing element 4. An interface 8 may be provided to manage coherence between the respective caches memories 6 of the processing elements 4 and also the routing of the requests for the data reads and writes to the main memory. A number of memory devices may be provided within the memory system such as a DRAM unit 10 and a non-volatile (NV) RAM 12. It will be appreciated that these are just some of the types of memory that may be provided. Each memory array 10, 12 has a memory controller 14 associated with it to manage access to that memory array. The interface 8 may have a control circuit 16 to control the routing of memory access requests to the memory controllers 14 and other slave devices not shown in Figure 1. In some cases the interface 8 may include a system cache 18 which is shared by the processing elements 4 and caches some data from the main memory 10, 12 for faster access by the processing elements 4 than if they had to be fetched from the main memory. Any known coherency protocol may be used by interface 8 to manage coherency between the various caches. It will be appreciated that Figure 1 is just one example of one possible implementation of a data processing system and that many variations of this arrangement may be possible.

Figure 2 shows an example of a memory structure for the DRAM unit 10. Multiple arrays 20 of a DRAM integrated circuit 10 can be accessed independently and thus requests to different arrays can be serviced simultaneously. This is called banklevel parallelism. Arrays 20 are examples of storage units that can be accessed in parallel. Each array 20 has a row buffer 22. Each array 20 is organized into rows and columns, while the data of a DRAM array can only be accessed from the row buffer of array 22, which serves as a buffer for the last memory row access to this array.

Subsequent accesses to the same row can be served by accessing row cache 22 (row cache hit), which reduces latency compared to accessing DRAM cells in other rows. This is referred to as the row cache location. DRAM access therefore has variable latency depending on whether:

1. desired row is open, ie row cache success: low access latency, example 18+ ns

2. array is closed/pre-charged (no row open at that time): medium access latency, example 32+ ns

3. a different row is open on the same array as the desired row (also known as array contention): high access latency, example 42+ ns.

Although Figure 2 shows an example for a DRAM memory unit 10 and other types of memory may similarly have multiple parallel storage units 20 that can be accessed in parallel, each having a cache 22 for temporarily storing at least one row or “page” of the memory structure so that access to a given memory location has a lower latency when the memory location is in a first state (stored in page buffer 22) than if the memory location is in a second state (not cached page 22). It should be noted that the term "page" in the context of DRAM or another memory unit refers to the unit of the memory storage array that can be placed in the buffer 22 rows at a time. This differs from operating system (OS) “pages” which refer to the size of the memory address unit (resolution) for which address translation, memory allocation, or memory protection is managed.

The mapping of a physical address to a DRAM or other memory modules, although usually undocumented, is not a secret, and should not be trusted for security. Mapping can be recovered by metrics and generative reasoning, and there are freely available tools to help with this.

Variable latency depending on the current state of the accessed memory location and the freely accessible or guessable mapping of physical addresses in DRAM can cause some problems. The memory unit 10, 12 and the memory controller 14 may be shared resources at the system level. As with any resource shared by sensitive and potentially untrusted code (eg, Javascript in an Internet browser), care must be taken to avoid side channels. Array conflicts expose different timings and can be used as a timing side channel. Detecting open rows on a page can be used as another side channel.

For example, as shown in Figure 3, the timing side channel can leak certain address accesses allowing a malicious user to spy on another user who is just doing his job. First the spy discovers the vulnerable addresses of the victim process. The spy can then map data that is also on the same DRAM page as the vulnerable data and infer whether the vulnerable address was accessed. For example, the attack could include the following steps:

• two processes allocate data to the same DRAM page, even though they belong to different OS pages (victim address B1 and spy address A1)

• The spy (attacker) process reads A2 (or some other row of the array other than A1 )

• The spy process allows the victim process to perform some task.

• The spy process then reads A1 and measures the response latency for the memory access request:

o In the event of a series success, then it is inferred that the victim has accessed B1

o In the event of a row failure, then it is inferred that the victim did not access B1.

By repeating such attacks, the spy can then infer information about the address plans accessed by the victim, which could be used to leak information about sensitive data, or obtain information about the operation of the victim process that could be used to inform other types of attacks.

Another example of an attack that would not require the OS to assign victim and spy data to physically consecutive addresses could be as follows:

(1) The attacker initializes the array buffer by accessing A1 (or some other address An which corresponds to array X), (2) the attacker allows the victim to execute,

(3) The attacker probes the array cache by accessing A1 or An again to understand whether the victim accessed the same array, thus inferring some information about the victim through the access location.

Figure 4 illustrates an example of a control circuit 14, 16 for controlling access to a memory, which is capable of triggering a delay masking function to mask possible timing channel information that could otherwise be produced by an attacker. . The control circuit could be the memory controller 14 for a particular memory unit or it could be a control logic 16 within an interface 8 for example. The memory controlled by the control circuit could be a dedicated main memory unit such as DRAM 10 or NVRAM 12 or a cache memory 6, 18. Although cache memories have traditionally been implemented using SRAM (static random access memory or static random access memory), for which the access latency is usually the same for each physical storage location of the storage array, as the cache capacity increases, so does the interest in using DRAM for caches, so a similar problem arises and in the DRAM attack discussed above.

The control circuit has an interface 30 for receiving memory access requests from upstream components and providing responses to these requests to the upstream components once the request is serviced by memory 10, 12. Although not shown in Figure 4, the control circuitry may also have a downstream interface for transmitting a selected request for service from the memory and receiving the corresponding response from the memory.

Received requests are assigned to one of a number of queues, for example a read queue 32 and a write queue 34, while requests are selected from the respective queues 32, 34 by a request selector 36 under the control of the request management circuit 38. The circuit request management 38 may apply a number of criteria governing when particular requests may be selected and may control the order in which requests are selected. For example, request management circuitry 38 may consider factors such as data dependencies between requests (ie, whether they specify the same address), other sorting constraints imposed by the type of memory area accessed by the request, or by other parameters or sort identifiers specified by the request, and may also consider the efficiency with which various requests can be grouped together to ensure more efficient memory access, e.g. requests targeting the same page in DRAM 10 or NVRAM 12 could be grouped together so that they can be handled more quickly as a group compared to the case where these requests were intermingled with other requests on different pages.

However, in addition to such factors the request manager 38 may also consider the execution context to which the various requests are associated. Figures 5 and 6 show two different ways in which the request handling circuit 38 may be capable of determining the context associated with a request. As shown in Figure 5, in some cases one of the processing elements may include a circuit 40 for implementing a frame identifier generation function to generate an execution frame identifier 42 for inclusion with memory access requests generated by the processing element 4. For example the frame identifier generation operation 40 may be an operation of one or more different identifiers associated with the currently running frame being processed by the processing element 4 or based on properties of the processing element 4 itself or the parameters determined by the software running on the processing element. For example, execution context identifier 42 may result from one or more identifiers including any combination of:

A process identifier (or ASID address space identifier) 44 associated with a process or software application running on the processing element.

• A virtual machine identifier (VIMD) 46 associated with a virtual machine or operating system under which the application or process is running.

A processing element identifier (PEID) 48 that identifies the specific processing element 4 that is generating the request.

• A secure/non-secure mode (S/NS) indicator 50 indicating whether the processing element 4 that generated the request was operating in secure mode or in non-secure mode.

• An indication 52 of the current exception level (EL) or privilege level at which the processing element was operating when it created the request.

• A software identifier A 54 which may be arbitrarily determined by software running on the processing element regardless of the current operating state of the processing element, for example the software-defined identifier 54 could be a value written to the element's register processing by the software.

It will be appreciated that it may not be necessary to consider all of these identifiers in the framework identifier generation function 40, but in general by generating an identifier as a function of one or more of these properties then the execution framework identifier 42 may characterize the implementation of a software workload to the processor to distinguish it from other workloads. Attaching the execution frame identifier 42 to memory access requests may enable the control circuit 14, 16 to determine which frame a given request is associated with.

As shown in Figure 4, requests pending in the read queue 32 or the write queue 34 can be assigned the corresponding execution context identifiers so that the request management circuit 38 can identify a number of "virtual" queues 56 with each associated with a given context. It will be appreciated that each virtual queue 56 need not necessarily be physically partitioned within the read or write queues 32, 34 but could simply correspond to those entries of the respective queues associated with a given frame. Sharing a physical queue structure between multiple frames can make it easier to trace the order of requests and address dependencies than if requests were placed on physically separate queues for each frame. However, request manager 38 may implement virtual queues by attempting to group requests from the same context to be served sequentially by memory 10, 12, 18, to reduce the number of switches between handling memory access requests that related to one context and in handling requests related to another context.

As shown in Figure 6, another way to determine when an execution frame switch occurs between memory-managed memory access requests may be to use a frame switch break flag 60 which may be included in a stream of memory access requests to mark the point at which post-split requests are associated with a different execution context than pre-split requests. For example the frame switch allocation 60 could be a memory request which identifies a specific identifier code indicating that this is an allocation request rather than an actual serviceable memory read or write request. Alternatively instead of providing a specific request corresponding to split 60, the last request associated with the older execution context or the first request associated with the new execution context could be placed with a marker indicating that this request also acts as separation. Splits may be generated under hardware control within the processing element 4 when a frame switch is detected in the software running on the processing element or could be triggered under software control so that the software has the explicit ability to request the insertion of a frame switch split in the stream of memory requests and to signal to the control circuit 14, 16 that requests received subsequently will relate to a different context.

Regardless of how the frame switch is signaled to the request manager 38, when the request management circuitry determines that a frame switch is occurring, and therefore there is a transition from handling memory access requests associated with an execution frame to access requests to memory to another execution context, then the request handler may issue a signal 62 to trigger a delay masking function. The delay masking operation could be performed within the control circuitry 14, 16 itself or by another component of the memory system such as in the memory controller 14 or the actual storage device 10, 12, depending on the type of delay masking operation being performed. In one example, the latency masking operation could be that each open or active page within the DRAM or NVRAM structure is closed or disabled, with each open page being written from the row buffer 22 asynchronously so that after the latency masking operation the next request memory accesses to each array 20 will target a locked page so that the access latency associated with accessing that locked page is independent of the addresses that were accessed before the latency masking operation was performed. This can be used to ensure that any incoming frame cannot acquire access address plan information from an older frame.

Alternatively, as shown in Figure 7 another way of implementing delay masking may be to provide a delay buffer 68 to add an additional delay either to the request before it is sent to memory, or to the response to a memory request received from memory. before it is returned to the upstream component that issued the request. Although Figure 7 shows delays in both the request channel and the response channel it will be appreciated that only one of them may be required. In systems where memory cannot serve requests in a different order than the order in which they were received, delaying the request may be acceptable. However, in a memory that supports out-of-order service of requests, it may be preferable to delay the response to provide a more efficient guarantee of masking delay for the first serviced request(s). after a frame switch. A selection circuit (e.g., a judge) 70 may be provided for selecting whether or not the delay is applied based on the delay masking function drive signal 62 provided by the request handling circuit 38. Accordingly, an additional delay for simulating a page as closed when it is actually open, or simulating an array conflict when in actuality the desired row is open or no row is open in the required array. Such simulated delays can be useful for obfuscating results that might be explored by an attacker based on side-channel timing. During the delay of a given request or a given response, another request to the same open page could be served in the meantime, for example another read or write request, a post-write request, or a refresh request to refresh the contents of memory which can be useful for some forms of memory such as DRAM which requires periodic refresh to maintain its state.

It is not necessary to apply the delay masking function to every single frame switch. Instead the delay masking function could be motivated with a secure adaptive policy to enable hierarchical activation of the function based on the exception level of the corresponding execution frame or based on whether the incoming or outgoing frame satisfies certain properties. For example the latency masking function could be triggered by a frame switch from a more privileged process to a less privileged process or vice versa but it might not need to be triggered by a frame switch between processes running at the same privilege level for example. In some examples, only frame transitions from a first frame executing a minimum or a higher privilege threshold level could trigger the delay masking function.

As shown in Figure 8, one form of memory access request that may be received by interface 30 in control circuitry 14, 16 may be a cache asynchronous write request 80 that is generated by a cache (e.g., cache memory L1 , the cache memory L2 or some other subsequent cache memory 6 within the processing element 4 itself or the system cache 18 within the interface 8), for retroactively writing data previously written to the cache, to the cache next-level memory 18 or in main memory 10, 12. In the approach shown in Figure 8, each cache location 82 may (in addition to the data itself 84 and any tag information 86) identify the execution frame identifier 88 associated with the corresponding data, which can be derived from the processing element 4 using the frame ID generation function 40 as shown in Figure 5 during allocation time of cached data 84 to cache 6, 18. Accordingly, when the cache controller determines that some data is to be evicted from the cache and written back to memory, the write back request 80 may be appended with the identifier execution frame 88 which is read from the corresponding victim cache location so that the request manager 38 can then match it with a corresponding one of the execution frames 56 to control whether a latency masking function should be triggered by a transition from an asynchronous write request to a memory access request associated with a different context to the one that originally allocated the data to the cache.

Alternatively, as shown in Figure 4 the write queue 34 can distinguish the asynchronous write from other types of memory access requests so that the asynchronous write requests can be grouped together as their own dedicated 56-W asynchronous write frame. Therefore, asynchronous writes can be grouped together as their own special context, while there is a transition from handling asynchronous write requests (regardless of which context is actually associated with asynchronous write data) to handling non-asynchronous write requests related to a particular execution frame, then the delay masking function can be excited and prevent an attacker from obtaining side-channel information based on the previous access addressing scheme used by the frame that originally allocated the data to the cache prior to the asynchronous excitation write from the cache controller.

A third approach could be to treat each individual asynchronous write request as its own separate context so that for any asynchronous write requests served by memory, the delay masking function is fired before the immediately following memory access request to protect against possible side-channel information leaks from the rollback request so that the context associated with the subsequent request cannot obtain rollback address information that could otherwise be exploited by attackers to gain information about its operation framework that originally allocated the data to the cache.

Figure 9 is a flow diagram showing a method of controlling memory access using control circuitry 14, 16. In step 100 request handling circuitry 38 determines whether an execution frame switch has been identified which satisfies a predetermined condition. In some implementations an execution context switch may be determined to have occurred at the time the request manager determines that memory should be switched from handling requests associated with one context to handling requests associated with another context. Whether the frame switch satisfies the predefined condition may depend on properties of the frame which could be derived from the corresponding execution frame identifiers, such as the exception level. Alternatively the request handling circuit 38 could maintain a list of certain execution frames for which additional security is required, while the execution frame switching could be determined to satisfy the predetermined condition if the first execution frame (from which the access requests were handled memory before frame switching) is on the list of frames that require extra security.

If the execution frame switching does not satisfy the predetermined condition, then in step 102 the control circuit 14, 16 triggers the execution of the delay masking function so that the response delay associated with subsequent requests whose required data is stored in the relevant memory 10, 12, 18 to be independent of the addresses accessed prior to frame switching. For example the delay masking function could be the extra delay imposed by the delay buffer 68 or it could be an instruction to close or open pages within a given memory so that the next request to each block of memory will suffer a fixed delay which corresponds to the delay when no open page is kept at that moment in the row cache 22.

On the other hand, if the execution frame switching does not satisfy the predetermined condition then at step 104 the delay masking operation is omitted, in which case the response delay for subsequent requests that target data already stored in memory may depend on the previous addresses accessed by the first execution frame before the frame switch.

In the present application, the words "configured for..." are used to mean that an element of a device has a configuration capable of performing the specified function. In this context, a "configuration" means a device or way of interfacing hardware or software. For example, the device may have dedicated hardware that provides the specified function, or a processor or other processing device may be programmed to perform The words “configured for” do not imply that the element of the arrangement must be changed in some way to provide the specified function.

Although illustrative embodiments of the invention have been described herein in detail with reference to the accompanying drawings, it should be understood that the invention is not limited to these precise embodiments and that various changes and modifications may be made therein by those skilled in the art without departing from object and spirit of the invention as defined by the appended claims.

Claims (20)

CLAIMS: 1. An arrangement that includes: a control circuit for controlling access to a memory implemented using a memory technology that provides variable access latency, the control circuit comprising: an interface circuit for receiving memory access requests to be served by the memory and providing responses to memory access requests served by the memory, and a request management circuit for: determining an execution context switch that includes a transition from servicing memory access requests associated with a first execution context to serving memory access requests associated with a second execution context, and at least when the execution frame switch satisfies a predetermined condition, triggering a delay masking function to control subsequent memory access requests associated with the second execution frame, for which the required data is already stored in memory, to be serviced with a a response delay which is independent of the addresses accessed by the memory access requests associated with the first execution frame, said response delay including a delay between receipt of the memory access request by said circuit interface and providing a response to the memory access request from said interface circuit. 2. The arrangement according to claim 1, wherein at least when the execution frame switch satisfies the predetermined condition, the response management circuit is configured to ensure that at least one subsequent memory access request associated with the second execution frame, for the which the required data is already stored in memory, is served with a fixed response delay. 3. The arrangement according to claim 2, wherein the memory includes a plurality of storage units accessible in parallel, and said at least one subsequent memory access request includes at least one first memory access request to each storage unit served after the switch execution framework. 4. The arrangement according to claim 1, wherein after the execution frame switch, the request management circuit is configured to control the servicing of at least one of said subsequent memory access requests associated with the second execution frame, for which the required data is already stored in memory, with a variable response delay dependent on the variable access latency provided by the memory. 5. The arrangement according to claim 4, wherein said variable memory access latency comprises a shorter access latency when the memory access request accesses a memory location in a first state than when the memory access request accesses a memory location in a second state, wherein an access to a memory location in the second state triggers a transition of a corresponding group of one or more memory locations from the second state to the first state, and said at least one of said subsequent memory access requests includes a memory access request to a group of one or more memory locations that have already been accessed by another memory access request served by the execution frame switch. 6. The apparatus according to claim 1, wherein the request management circuit is configured to detect an execution frame switch that satisfies said predetermined condition when a frame switch split indication is detected in a stream of memory access requests received from the interconnection circuit. 7. The device according to claim 1, wherein the request management circuit is configured to detect said execution frame switching based on the execution frame identifiers associated with at least a subset of the memory access requests received by the interface circuit . 8. The device according to claim 7, comprising at least one processing element for issuing memory access requests received from the interface circuit, wherein a given processing element is configured to generate the execution frame identifier associated with a given memory access request based on at least one of the following: a process identifier or address space identifier associated with a process running on the processing element; a virtual machine identifier associated with a virtual machine running on the processing element, a processing element identifier associated with the given processing element; a security mode identifier identifying a current security mode of the given processing element; an exception level identifier that identifies a current exception level of the given processing element, and a software-defined identifier provided by the software running on the processing element. 9. The arrangement according to claim 1, wherein the request management circuit is configured to group memory access requests associated with the same execution context together as a group of requests to be serviced sequentially by memory and to determine context switching execution time when switching from a pool of memory access requests associated with the first execution context to a pool of memory access requests associated with the second execution context. 10. The apparatus according to claim 1, wherein when the execution frame switching does not satisfy said predetermined condition, the request management circuit is configured to omit triggering said delay masking function. 11. The arrangement according to claim 1, wherein said predetermined condition includes the second execution frame which is a frame whose access is prohibited to at least some data which is accessible in the first execution frame. 12. The arrangement according to claim 1, wherein said predetermined condition includes the first execution frame which is a frame from a predetermined subset of execution frames. 13. The arrangement according to claim 1, wherein said variable memory access latency comprises a shorter access latency when the memory access request accesses a memory location in a first state than when the memory access request accesses a memory location in a second state, wherein an access to a memory location in the second state triggers a transition of a corresponding group of one or more memory locations from the second state to the first state, and said delay masking operation includes controlling the memory to transition at least a group of one or more memory locations from the first state to the second state. 14. The arrangement according to claim 1, wherein said delay masking function comprises delaying a memory access request served after execution frame switching or a response to the memory access request served after execution frame switching to a latency buffer to mask an actual access latency provided by the memory when servicing said at least one memory access request. 15. The arrangement according to claim 14, wherein during a delay period of the memory access request or response to the delay buffer, the request manager is configured to control the memory to service at least one other request that targets a same page in memory as the delayed memory access request. 16. The arrangement according to claim 1, wherein the request management circuit is configured to determine that asynchronous write requests, which request the asynchronous write of caches to the memory, are associated with a dedicated asynchronous write execution context regardless of the execution context that caused the cached data to be allocated, and in response to an execution context switch involving a transition from servicing asynchronous write requests associated with the dedicated asynchronous write execution context to servicing memory access requests associated with another execution context, the request management circuitry is configured to perform the due to delay masking operation. 17. The arrangement according to claim 1, wherein after servicing a given asynchronous write request requesting the asynchronous write of cached data from an in-memory cache, the request handling circuitry is configured to perform said delay masking operation so that a subsequent memory access request or a subsequent memory-served asynchronous write request, for which the required data is already stored in memory, is served with a response delay independent of the address specified by the given request retroactive registration. 18. The apparatus according to claim 1, comprising a cache configured to cache data relative to an execution frame identifier of an execution frame corresponding to the cached data and generating a post-write request for asynchronously writing a predetermined group of cached data into memory, the asynchronous write request specifying the execution context identifier associated with the predetermined group of cached data, and the request management circuit is configured to determine the execution frame switch based on the execution frame identifier associated with the asynchronous write request. 19. The device according to claim 1, wherein said memory comprises DRAM. 20. A method for controlling access to a memory implemented using a memory technology that provides variable access latency, comprising: t^-getting-memory-access-parts for -serving from memory and providing responses to memory access requests served by memory, The implementation of the implementation of the program includes the implementation of memory access requests related to a first step in the execution of service requests for memory access. IG and/or second frame execution. and "at least when execution frame switching is performed with yeni-siintheki. triggering a delay masking function to control memory access requests related to which the required data is already-stored -a response delay which is not accessed by the requests for the first execution frame, with ev due to each delay between the receipt of the request and the provision of a request from the rv end with the second execution frame, i.o. written in-memory service with depending on the addresses at which ^-memory access related to the denial of response to include a — memory access from said in the request for access to the information