JP2009543234A - System for protecting sensitive data from user code within a register window architecture - Google Patents

Abstract

An excellent system is provided for protecting supervisor mode data from user code within a register window architecture of a processor.
A system is provided for protecting supervisor mode data from user code within a register window architecture of a processor. When transitioning from supervisor mode to user mode, this system sets at least one invalid window bit in the invalid window mask of the architecture in addition to the invalid window bit set for a window with an invalid window mask reserved. To do. That additional bit is set for the transition window between the supervisor data window and the user data window.
[Selection] Figure 5

Description

  The present invention relates to an electronic device having an embedded computer system. The present invention was developed primarily to improve security and protect computer systems from malicious unauthorized use of software while still providing flexibility downstream of the device manufacturer's software design.

これらの出願及び特許の開示を、参照により本明細書に組み込む。 [Cross-reference of related applications]
Various methods, systems and devices relating to the present invention are disclosed in the following US patents / US patent applications filed by the assignee or assignee of the present invention.

The disclosures of these applications and patents are incorporated herein by reference.

  Currently, electronic devices with embedded computer systems are part of everyday life. Examples of such devices include automatic teller machines (ATMs), mobile phones, printers, copiers, handheld calculators, microwave ovens, televisions, DVD players, washing machines, handheld game machines, and the like. is there. In general, embedded computer systems are characterized by providing functions that are not themselves computers.

  In general, embedded systems include special purpose hardware and a processor (CPU) that supports a real-time operating system (RTOS). This system is programmed with special purpose software adapted to meet the requirements for a particular system. Typically, software written for embedded systems is called “firmware”. Because electronic devices are expected to operate continuously for many years without error, firmware is usually developed and tested more strictly than software for computers.

  In addition to the obvious operational advantages of an embedded computer system, there are many advantages offered with respect to the manufacture and sale of various product lines. As new products are put on the market, it is often desirable to release different versions of each product with a price that is commensurate with that particular version. For example, a first product can have function X and a second product can have functions X, Y, and Z.

  In terms of manufacturing, it is expensive to provide a production line dedicated to the first product and another production line dedicated to the second product. It is cheaper to produce a single product type that includes the necessary hardware to support functions X, Y, and Z within all products. In this case, the various product lines can be differentiated by their embedded firmware. Compared to hardware, firmware provides a cheaper way to differentiate between various products. In addition, the firmware allows users to upgrade their devices without buying new devices. For example, to provide an upgrade, authorized Internet downloads can be used via a personal computer, thereby enabling functions Y and Z within a product that initially had only function X.

  However, a problem unique to embedded firmware is that it is susceptible to malicious attacks from hackers or intentional pirates who carry out unauthorized firmware upgrades. For example, unauthorized firmware upgrades may be freely distributed over the Internet, and users can upgrade their devices for free.

我々の以前の出願において説明したように、プリンタプラットフォーム内のＱＡチップは、安全な環境で数々の機能を実行する。印刷カートリッジ内のＱＡチップは、許可された方法でのみプリンタの操作を許可するように使用されうる。例えば、プリンタＡは１分あたり１０ページを印刷するよう許可され、プリンタＢは１分あたり３０ページを印刷するよう許可されうる。それぞれのプリンタ内のハードウェアは同一だが、ＱＡチップがそれぞれのプリンタを差別化することができる。更に、ＱＡチップがそれぞれのプリンタのデータを安全で認証された方法で格納するので、信頼できる供給源によってしかアップグレード又は置き換えできない。したがって、ＱＡチップは無許可のユーザからの攻撃に対する保護を提供する。 One way to avoid this problem is through an authentication chip in the device, rather than through the firmware itself to provide an upgrade. The use of an authentication chip (“QA chip”) in a printer environment is described in our earlier application described below, the contents of which are incorporated herein by reference.

As explained in our previous application, the QA chip in the printer platform performs a number of functions in a secure environment. The QA chip in the print cartridge can be used to allow operation of the printer only in an authorized manner. For example, printer A can be authorized to print 10 pages per minute and printer B can be authorized to print 30 pages per minute. Although the hardware in each printer is the same, the QA chip can differentiate each printer. Furthermore, since the QA chip stores the data for each printer in a secure and authenticated manner, it can only be upgraded or replaced by a reliable source. Thus, the QA chip provides protection against attacks from unauthorized users.

  The QA chip mounted on the ink cartridge ensures that the ink contained in the cartridge is from a specific source or of a specific quality, so that illegal ink that damages the print head cannot be used reliably. Can be used to guarantee. Similarly, the same QA chip determines the amount of “virtual ink” remaining in the cartridge, determined with reference to the initial amount of ink in the cartridge and the number of dots printed using that ink. Can be used for dynamic storage in that memory. The amount of “virtual ink” provides a security mechanism for the printer and prevents unauthorized refilling of the ink cartridge. That is, if the firmware in the printer communicates with the QA chip of the ink cartridge before printing and the amount of “virtual ink” is insufficient, the printer does not print. In this way, the quality of the ink can be assured and the risk of damaging the print head using low quality ink with improper replenishment is minimized.

  QA chips provide an excellent means for preventing unauthorized use of electronic devices. However, the security of the QA chip depends on the firmware in the embedded system that communicates with the chip. It is conceivable that the most daring hacker can change the firmware and disable communication with the QA chip in the device. In this case, the security provided by the QA chip is compromised. In the above example, the ink cartridge can be illegally replenished regardless of the presence of the QA chip on the ink cartridge.

  It may seem unlikely that such a bold attack will be made against an embedded computer system. However, in the printer market, sales of refill fraudulent inks are becoming a multi-million dollar industry, providing considerable incentives to malicious attacks against any security system built into the printer. From the printer manufacturer's point of view, using low-quality ink in the printer can result in poor print quality, shorten the life of the printhead, and immeasurable damage to the reputation and reputation in the printer market.

  Accordingly, it is desirable to provide an electronic device having an embedded computer system that has improved security from malicious attacks.

  It is further desirable to provide an electronic device that can have the flexibility to perform firmware upgrades or even install an alternative core RTOS downstream of the device manufacturer.

  It is further desirable to provide a simple method for upgrading firmware in a PictBridge printer.

US Patent Application No. 11/014769 (filed December 12, 2004)

  In a first aspect, an electronic device comprising an embedded computer system is provided, the device comprising a processor that supports a real time operating system (RTOS), the processor supporting a user mode and a supervisor mode, the computer system However, only the part of the code that directly controls the essential hardware in the device is programmed to run in supervisor mode.

  As used herein, “essential hardware” is used to mean hardware components that are essential for a device to perform important functions. For example, in the case of a printer, the essential hardware can include a drive circuit to operate a nozzle actuator in the print head, but an LCD display is not essential for the printer to print, so on the printer LCD display is not included.

  As used herein, the term “code portion” is used to mean any portion of code that performs a particular function. The code portion may be part of a thread or process.

  Processors that support user mode and supervisor mode are well known in the computer field. Code running in supervisor mode can only be accessed by a privileged person, such as the person who originally wrote the code. On the other hand, code executing in user mode can be accessed and modified by anyone regardless of privileges.

  An example of a processor that supports user mode and supervisor mode is the SPARC ™ processor. Such processors are designed to protect the core (or kernel) of the operating system from potentially buggy applications running on the computer. If the core of the operating system is running in supervisor mode, the operating system can continue to run even if a particular application running in user mode crashes. This ensures that other applications running in user mode can continue to run on the operating system. By protecting the core of the operating system in this way, the risk of crashing the entire computer with buggy applications is minimized. That is, there is a separation between the application and the core of the operating system.

  In the present invention, a processor that supports user mode and supervisor mode is used in a manner different from conventional use in non-embedded computer systems. The embedded computer system of the present invention is programmed so that only the code portion that directly controls the essential hardware in the device is executed in supervisor mode and the remaining code portion is executed in user mode.

  The main advantage of running certain code portions (which control the required hardware in the device) in supervisor mode is that these code portions cannot be modified once finalized by the device manufacturer. Thus, the manufacturer or licensee has ultimate control over how the device can be operated.

  For example, the printer manufacturer can program the printer to print only 10 pages per minute in the code portion that directly controls the print head and paper feed mechanism. Because this code part is protected in supervisor mode, it is impossible for hackers to modify the code and upgrade their printers.

  Optionally, the computer system is programmed such that portions of code that do not directly control the required hardware in the device are executed in user mode. Optionally, the core of RTOS is executed in user mode. There are two advantages to programming an embedded computer system in this way. First, the amount of code in supervisor mode is kept to a minimum, minimizing the risk of bugs present in this immutable code. Next, by running the RTOS and non-essential applications in user mode, the authorized printer manufacturer or distributor, or the downstream department of the original printer manufacturer, specializes in their requirements on the operating system of their choice. There is an opportunity to develop customized firmware. For example, an approved printer manufacturer may want to change the LCD display format and program it using the preferred operating system. In accordance with the present invention, authorized printer manufacturers have the flexibility to do this without compromising the security of the QA system in the device.

  Optionally, the computer system is programmed so that code portions that directly control the required hardware can be called from applications running in user mode via traps that identify the code portions. Allows multiple code portions, each directly controlling individual required hardware, to be called independently from an application running in user mode via individual traps that identify individual code portions be able to.

  The advantage of being able to call a specific code portion from the user mode is that it gives more flexibility to program a specific sequence of operations into the device. User mode applications may be programmed by authorized device manufacturers, or even available through upgrades that can be downloaded from the Internet. For example, a printer user may want to have a default option to print “5000 pages, full color”. Since the print job application programmed in the embedded system runs in user mode, the user can upgrade his firmware to have this default option.

  Optionally, the code portion that directly controls the required hardware communicates with at least one authentication chip in the device prior to operation of the hardware. The authentication chip (or “QA chip”) permits the operation. For example, the code portion may ask the QA chip for the printing speed allowed for the printer. The QA chip returns this information (eg, 10 pages per minute) to the computer system and can start printing at the permitted printing speed. In this way, operations authorized by the device can be safely controlled via the QA chip without being threatened by a malicious attack on the firmware in the device.

  Optionally, an initial authentication chip is associated with the consumable component of the device. Examples of consumable components in electronic devices include ink cartridges, toner, paper, batteries, and the like. The initial authentication chip can include static and / or dynamic data regarding the consumable component. For example, static data can relate to the source of consumable components, batch number, quality (eg, ink color), initial quantity, and the like. The dynamic data can relate to the current amount of consumable components (eg, ink level) or quality (eg, temperature).

  An electronic device may require several consumable components. Thus, the apparatus can comprise a plurality of initial authentication chips, each associated with an individual consumable component.

  Optionally, the electronic device is a printer and the consumable component is an ink cartridge having a respective first authentication chip. The authentication chip on the ink cartridge prints only when a predetermined type of ink cartridge is loaded into the printer, as determined via certain conditions, eg, (i) the associated authentication chip, and / or (Ii) can be used to allow printing only if a predetermined amount of ink remains in the ink cartridge, as determined via the associated authentication chip, is satisfied . As mentioned above, these authentication mechanisms provide a guarantee to the printer manufacturer regarding the quality of the ink used in the printer, thereby preserving the manufacturer's reputation in the printer market.

  Optionally, the second authentication chip is located within the body of the device that is not associated with the consumable component. For example, the second authentication chip can be mounted in or on the print engine of the printer. The second authentication chip can be used to allow certain operations of the device, such as printing at a predetermined speed.

In a second aspect, a system for upgrading firmware in a PictBridge printer is provided, the system comprising:
A PictBridge printer having an embedded computer system;
A memory stick for communicating with the embedded computer system, the memory stick including a firmware upgrade for the embedded computer system.

  In a third aspect, a memory stick is provided that includes a firmware upgrade for an embedded computer system of a PictBridge printer.

In a fourth aspect, a system for upgrading firmware in a PictBridge printer is provided, the system comprising:
A PictBridge printer having an embedded computer system;
A digital camera for communicating with the embedded computer system, the camera including a firmware upgrade for the embedded computer system.

  In a fifth aspect, a digital camera is provided that includes a firmware upgrade for a pictobridge printer embedded computer system.

  PictBridge is an industry open standard for direct printing from the Camera & Imaging Products Association (CIPA). PictBridge makes it possible to print video directly from a digital camera with a printer without connecting the camera to a computer. By using a single USB cable to connect a PictBridge-compatible printer to a PictBridge-compatible camera, users can easily control print settings using their own camera without using a personal computer. High quality photos can be obtained. The main advantage of PictBridge printing is that it is simple for the user and especially for users where complex photo application software can be a barrier.

  PictBridge relies on communication between the embedded computer system in the camera and the printer. These embedded computer systems effectively replace personal computer photographic applications and further simplify operation for the user.

  Sometimes it may be necessary to upgrade the firmware in the PictBridge printer. For example, additional printing options may be required, and firmware may need to be upgraded to be compatible with new Pictobridge compatible cameras on sale.

  In conventional digital camera systems, software upgrades for personal computer photo applications are provided via download from the Internet or CD. However, many PictBridge printer users may not have a computer in the first place. The complexity of upgrading a Pictbridge printer by downloading new software from the Internet to your personal computer and connecting the Pictbridge printer to your personal computer can be a significant barrier for users who own computers High nature. After all, PictBridge users are generally attracted to this system because of its simplicity and because it does not require a personal computer.

  The main advantage of the present invention is simplicity for the user. No computer skills are required to insert the memory stick into the USB port of the PictBridge printer. Thus, printer firmware upgrades can be performed with confidence by anyone without the risk or fear of inaccurately upgrading the printer.

  As used herein, the term “memory stick” is used to mean any portable non-volatile digital memory device.

  The memory stick or camera can communicate with the embedded computer system via a standard USB connector.

  Optionally, the memory stick or camera is configured to automatically download the firmware upgrade to the printer when it detects that the printer does not yet have an upgrade.

  Optionally, the portable non-volatile digital memory device is a memory stick.

  Cameras may be sold with firmware upgrades already programmed into memory. Alternatively, the camera can receive a firmware upgrade from an external source. For example, a memory stick can be used to download a firmware upgrade to the camera so that the camera can upgrade the printer the next time it is connected.

  In a sixth aspect, a system is provided for protecting supervisor mode data from user code within a register window architecture of a processor, such as the processor of the first aspect, when the system transitions from supervisor mode to user mode. In addition to an invalid window bit set for an invalid window mask reserved window, setting at least one invalid window bit in the invalid window mask of the architecture, the additional bits comprising supervisor data Set for the transition window between the window and the user data window.

  The position of the additional invalid window bits within the invalid window mask is maintained independent of window overflow and underflow in the transition window.

  Separate supervisor mode and user mode stacks may be provided, and the separate supervisor mode and user mode stacks are stored separately in memory accessible only to supervisor mode and in memory accessible to user mode, respectively. Is done.

  The current stack pointer can be switched between the supervisor stack and the user stack each time a transition from user mode to supervisor mode and from supervisor mode to user mode occurs.

  Optionally, information about the transition window is recorded in the supervisor stack upon window overflow and underflow in the transition window.

  Optionally, the window stack is stored in memory accessible only to supervisor mode, and information about the transition window is recorded in the window stack upon window overflow and underflow in the transition window.

  Optionally, non-transition window information is recorded in the window stack upon window overflow and underflow in non-transition windows.

  Optionally, each register window is assigned a unique numeric label that starts at zero and increases monotonically with each save. The record of the current label assigned to the reserved window is held in the local register of the reserved window, and the record is updated when window overflow and underflow occur in the reserved window. The label can be calculated based on the current window pointer.

  Optionally, on window overflow and underflow in a reserved window, the label is used to index at least the record of the reserved window's stack pointer in the window stack.

  Optionally, the label is used to index the stack pointer record of each window in the window stack upon window overflow and underflow in each window.

  When transitioning from supervisor code to user code, the calling function moves the current window pointer to the user window located behind the transition window and contains at least the supervisor code data from the current window to the reserved window. A save can be issued to overwrite the register.

  The calling function can overwrite registers in all windows from the current window to the reserved window, or in all registers of the processor that contain supervisor code data. Registers in the transition window can be overwritten upon window overflow and underflow in the transition window.

  When transitioning from user code to supervisor code, the window underflow trap routine can issue a restore to move the current window pointer to the supervisor window before the transition window.

1 is a perspective view of a printer having an embedded computer system. FIG. FIG. 2 illustrates the interrelationship between various components of an embedded computer system and printer hardware. FIG. 2 illustrates a register window architecture implemented by a processor of an embedded computer system. It is a figure which shows the mode switch between supervisor mode and user mode. FIG. 6 illustrates a mode switch between supervisor mode and user mode using a transition window.

Hereinafter, specific embodiments of the present invention will be described in detail with reference to the drawings.
Embedded System with User Mode and Supervisor Mode FIG. 1 shows a printer 2 embodying the present invention. The media supply tray 3 supports and supplies the media 8 to be printed by a print engine (hidden in the printer casing). Printed sheets of media 8 are sent from the print engine and collected in the media output tray 4. The user interface 5 is an LCD touch screen that allows the user to control the operation of the printer 2. The printer 2 includes an embedded computer system (not shown) that controls the entire operation of the printer.

  Referring to FIG. 2, the embedded computer system 10 and the interrelationship between the embedded computer system 10 and the printer hardware and other external components are schematically shown. The embedded computer system 10 includes a processor 11 that supports a user mode and a supervisor mode. The processor 11 executes the code portion 12 that controls the essential printing hardware 13 only in the supervisor mode. The essential printing hardware 13 can include a drive circuit for operating the nozzle operating device, a motor for driving the supply mechanism, and the like. All other code, including the core RTOS 14, is executed in user mode.

  The application 15 running in the user mode indirectly controls the printer operation via a trap that calls the code portion 12. In this way, the integrity of the code portion 12 is protected while still allowing some flexibility in how exactly the printer is operated.

  The code portion 12 is in communication with a print engine QA chip 16a and one or more ink cartridge QA chips 16b in the printer. Before any operation of the required printing hardware 13, the code portion 12 communicates with the QA chips 16a and 16b to request permission for that operation.

  The print engine QA chip 16a is programmed with an allowed printing speed (eg, 30 pages per minute). This information is returned to the code portion 12 and the required printing hardware 13 is operated according to the permitted printing speed.

  The ink cartridge QA chip 16b is programmed with information about ink including the remaining amount of ink. For example, if the ink cartridge QA chip 16b returns information that no ink remains in the cartridge, the code portion 12 is not permitted to operate the essential printing hardware 13 and printing is stopped.

  Since code portions 12 are executed only in supervisor mode, it is impossible for an unauthorized person to modify these code portions, thus changing the operation of essential printing hardware 13 or the QA chip. It is impossible to override the security provided by 16a and 16b.

  On the other hand, the code portion 17 that controls the non-essential hardware 18 such as the LCD display 5 is executed in the user mode. The code portion 17, along with the core RTOS 14, can be modified without any authorization privileges to provide flexibility in the operation of non-essential hardware and even flexibility in selecting the desired operating system.

  When the embedded system 10 is arranged as described above, all printer upgrades and ink refills can be reliably controlled via the QA chips 16a and 16b. The print engine QA chip 16a can receive the print speed upgrade 19 via an authorized Internet download or memory stick. Similarly, the ink refill QA chip 20 can communicate with the ink cartridge QA chip 16b during the permitted ink refill, so that the ink cartridge QA chip 16b has been refilled from a reliable source. The permitted ink replenishment operation is described in detail in Japanese Patent Application Laid-Open No. H10-228707, the contents of which are incorporated herein by reference.

Firmware Upgrade As noted above, most of the firmware in the embedded system 10 for the printer 2 can be modified or upgraded without compromising the security of authorized printer operation. Some firmware upgrades can be performed by the user.

  Referring to FIG. 2, the firmware upgrade can be performed by the memory stick 30 or the camera 31. The memory stick 30 or camera 31 includes a firmware upgrade in its memory and automatically downloads the upgrade to the embedded system 10 when it detects that the embedded system requires an upgrade.

  In the case of the memory stick 30, the user simply plugs the memory stick into the USB port of the PictBridge printer.

  In the case of the camera 31, the user simply connects the camera normally to the PictBridge printer via the USB port of the PictBridge printer. If the camera is purchased with the upgrade in memory, the user may not even be aware that a firmware upgrade has occurred. Alternatively, the memory stick 30 can be used to download firmware upgrades into the memory of the camera, and the camera 31 upgrades the firmware in the embedded system 10 the next time it is connected to the printer 2. Can be used for.

Invalid window mask configuration for user code and supervisor code Further security is provided by protecting all supervisor code from user code. This eliminates the possibility of user code reading confidential data and allowing the computer system to execute arbitrary code in supervisor mode, allowing unauthorized access to and modification of printer operating hardware and software. The

  The processor 11 implements a register window architecture for manipulating data. For example, the processor is a LEON CPU that implements the SPARC ™ architecture. Within processor 11, user code can access integer unit working registers ("r" registers), multiplication and division registers (Y registers), program counters (PC and nPC), and hardware watchpoints. Therefore, these registers must not hold sensitive data in either direction transition between supervisor mode and user mode.

  The print engine's “r” register has 8 global 32-bit registers and 8 sets of registers with 16 32-bit registers in each set. The register set is arranged so that the processor 11 has a window for viewing 24 of the registers. The current window being viewed is determined by a pointer to that window, such as CWP (Current Window Pointer). It should be understood that the above numbers of registers and register sets are exemplary only, and different numbers of registers and register sets may be used. For example, the SPARC ™ architecture can have as many as 2 to 32 register sets.

  If there are only 8 windows, function calls and traps beyond this depth will cause the register window to overflow, which is handled by using an invalid window mask and a combination of overflow and underflow traps. For example, the invalid window mask may be WIM (Windows Invalid Mask) used in the SPARC ™ architecture. Overflow and underflow handlers are used to give the illusion of an infinite number of register windows.

  Traditionally, the invalid window mask contains one bit per window, and overflow and underflow traps are generated when an instruction is issued to move to a new window with a bit set, designating the new window as invalid.

  For example, when a save instruction is issued to move the current window from window N to window (N-1), the processor first checks the invalid window mask bit (N-1). If the bit is set, the window is invalid, so the processor does not change the window and generates a window overflow trap. Similarly, when a restore instruction is issued to move the current window from window N to window (N + 1), the processor first checks the invalid window mask bit (N + 1). If the bit is set, the window is invalid, so the processor does not change the window and generates a window underflow trap.

  When a trap such as an interrupt occurs, the mask is ignored. Therefore, the window is rotated, and when a trap occurs, one window is reserved as invalid to ensure that the used register is not overwritten. Is normal. Thus, conventionally, the invalid window mask has a value of 1 bit set indicating the end of available windows, ie, seven in this embodiment, and reserves one window for trapping.

  For example, if an overflow trap is taken as a result of a save instruction that rotates the current window to a reserved window, the trap handler saves the oldest window in memory and rotates the invalid mask to the current point of the saved window. Thereby freeing a previously reserved window for use. For example, if an underflow trap is taken as a result of a restore instruction that rotates the current window to a reserved window, the reverse occurs.

  Each register set has 16 registers, with 8 “internal” registers and 8 “local” registers. However, since the window sees 24 registers, the remaining registers are 8 "external" registers. Thus, as the window cycles through the set, processor 11 sees some registers from the neighboring set. This is illustrated in FIG. 3, where the “external” register corresponds to the next lower window “internal” register. Thus, a given window can modify the “external” register of the next higher window and the “inner” register of the next lower window, even on overflow and underflow.

  Thus, unless appropriate action is taken, the user mode window can read and modify some of the data in nearby windows including the supervisor mode window. User code may cycle through the register window and even read and modify values. This is illustrated in FIG. 4, where the switch from supervisor mode to user mode is shown. As shown, the supervisor code used windows 7 and 6 before calling the user code, but the user code issues multiple instructions to move back and read / modify supervisor data There is nothing to stop.

  In some cases, this means that if the supervisor code registers are stored in user-accessible memory, the user code can easily overwrite those values to adjust the values that the supervisor code sees when the registers are restored. Or, even if the supervisor code register is stored in memory accessible only by the supervisor, the user code modifies the value of the “external” register, and in some cases tricks the code into misregistering the register It may lead to an example such as restoring.

  In this embodiment, by providing a system in which these potential security threats to supervisor code, and thus sensitive data, are implemented by a processor 11 that configures an invalid window mask for setting at least one additional bit. Minimize. This shows an invalid window behind a conventional reserved window that causes additional overflow and underflow traps to be generated at the transition between supervisor mode and user mode.

  To facilitate these additional traps, separate stacks are used for supervisor code data and user code data. When a transition occurs, the current stack pointer, eg,% o6, is switched between the supervisor stack and the user stack. The supervisor stack is stored in a memory accessible only by the supervisor mode, and the user stack is stored in a memory accessible by the user mode or accessible only by the user mode.

  Setting the extra bit provides a transition window between the supervisor window and the user window to ensure that sensitive data stored in the supervisor register is not accessible by the user code. This is illustrated in FIG. 5, in which the supervisor code has moved down two additional windows before calling the user code, indicating the intermediate window as invalid in the invalid window mask. This window presents a barrier in transition, because if the user code issues multiple instructions to move backward through the window, it will generate a trap if it hits an invalid window in window 5.

  The position of the transition window (s) is maintained when overflow and underflow occur. This can be done by storing information about the transition window in the supervisor stack when the trap occurs, or this same information in a separate window stack that is maintained in memory accessible only to supervisor mode. Is done by. In this way, information about the transition window is not stored in the invalid window mask or in the register of the transition window itself. Therefore, this information cannot be accessed by user code, thereby protecting the supervisor code data stored in the “external” or “internal” registers of the transition window.

  The possibility of overflow every time the supervisor mode is entered is checked to prevent supervisor stack overflow, thereby preventing overwriting of other supervisor code data. Such an overflow may occur as a result of the user installing a function that is called by a trap that issues the same trap, so in some cases a large nesting or longer time than a tick period to execute It causes such a function to be called on a timer tick, thereby causing continuous interrupt nesting.

  For example, if the reserved window is rotated at the top of the supervisor window because the calling function and user code issue a trap to call the supervisor code, further protection of the supervisor code data is required. Configure all “internal” and “local” registers in the new reserved window so that the trap will overwrite with 0 (eg,% g0) after saving the registers to memory for the previous state Thus, this protection is achieved by configuring the trap to overwrite all used register windows before returning for later state.

  With respect to overwriting all used register windows, a common piece of code returned from the trap may be used, where the code is reserved from the current window (and includes the current window) ( Overwrite all register windows (but do not include reserved windows) until already overwritten). Alternatively, code can be used that overrides the number of windows known to be used or known to contain supervisor code data.

  Since the user code invokes supervisor mode via a trap, the associated trap routine is configured to store the return address from the trap. If the SPARC ™ architecture is employed, the trap routine can also store a previous processor state register (PSR). This is done in the “local” register of the new register window allocated for the trap routine. For this reason, there are never two adjacent transition windows, ie each transition window is preceded by at least one supervisor window, ie the window used to hold the return address from the trap. .

  An exemplary system that maintains a stack of overflow and transition windows, running either in hardware or firmware, will be described in connection with a processor 11 employing the SPARC ™ architecture (similar systems under It is also applicable to flows).

  1. Each thread has an associated stack for storing information about the transition window.

2. Whenever the supervisor code wants to call user code, it issues a call instruction to the function (callUserFunction) and takes the following arguments:
(I) The address of the function to be called is in% o0:
(Ii) The current user (not supervisor) stack pointer is in% o1, and the caller must be prepared to pass the correct user stack pointer:
The interrupt routine now calls the user function and the trap routine uses a user stack pointer that reads from the current thread context, or a separate dedicated user stack for interrupts is used. In the latter case, context switch calls are disabled during these calls because context switching between threads is not possible when sharing a common stack;
A non-interrupt trap routine now calls a user function, which uses the user stack pointer read from the current thread context.

(Iii) From% o2 to% o5, up to four parameters are passed to the user function. % O6 contains the current frame pointer (on the supervisor stack), and the current frame pointer must be maintained because it is where the previous supervisor window is saved if an overflow occurs. Therefore, callUserFunction is constructed as follows:
Issue a save and move CWP to the transition window. This also means that the function argument% i7 of the transition window is in the "internal" register, containing the address of the calling instruction that called the callUserFunction (because the calling instruction placed there);
Copy the “internal” register containing the arguments to the “external” register containing the function to be called and the user stack pointer;
Mark the current window (which is a transition window) as invalid in WIM;
Save the% y and global registers in the “local” and “internal” registers in this transition window;
Issue another save, eg "Save% i1, -104,% o6", move the current window behind the transition window, meaning that the above copied argument is now in the "internal"register;
Overwrite all windows from the current window to a reserved window (already overwritten) (but not including a reserved window). However, when overwriting the current window, the “internal” registers used for the arguments are not overwritten;
Protect any old supervisor data, overwrite% y registers and global registers;
Switch to user mode;
Copy the requested user function arguments from% i2 to% i5 to% o0 to% o3;
Call user functions;
After the user function returns, copy the current window's% o0 to% i0, which is the return value from the user function and is currently in% o0 of the transition window;
Since we copied% o0, we issue a restore, which means that we hit the invalid bit set in WIM for the transition window, which means that the underflow trap routine takes over. The code after the restore instruction should not be executed because the restore should have caused a trap. If the code is to be executed, the user code means that all save instructions do not match the restore instruction. This is due to bugs or malicious attacks. Thus, the processor 11 stops until the reset or code is branched again to the restore instruction and continuously expands the register window until an expected trap is encountered.

3. The window overflow trap routine determines whether the window to be saved in memory is already indicated as invalid in the WIM:
• If it is not marked invalid, it means a normal window. Therefore, the trap routine saves the window register as normal in memory and, after checking for stack overflow (as described above), places a "normal" record on the window stack. This record need only be a single flag indicating that this is a "normal" record:
If it is shown as invalid, it means a transition window. In this case, the trap routine need not save any registers in memory. However, the trap routine puts a “transition” record on the window stack. This record must contain:
A flag indicating that this is a "transition"record; and
Transition window frame pointer, ie,% i6, the return address from callUserFunction read from% i7 of the transition window, and the values of the% y and global registers stored in the transition window. The% i6,% i7,% y, and global registers must be saved on the window stack because they are not necessarily maintained in the transition window after it is saved. After making these saves, the transition window registers must be overwritten (as described above).

4). The window underflow trap routine does the following:
Check the WIM to see if multiple bits are set. If multiple bits are set, it means that the window just met is a transition window. This is because the reserved window is always the first invalid window in the downward direction, so encountering a different invalid window in the upward direction can only mean that the window is a transition window. In this case, the trap routine is configured to do the following:
Indicate the transition window as valid in WIM;
Copy% o0 of the transition window to% i0, which is the return value from the user function;
Restore the% y and global registers from the local register in the transition window;
• Move the current window pointer to the window prior to the transition window. If this hits another invalid window, the window must be a reserved window, as described above, since a continuous transition window is not possible. In this case, the invalid window is restored from memory and the associated normal record is taken from the window stack;
Jump to the supervisor code that originally called callUserFunction and its address is available via% o7 of the current window (in this case, the transition window is not overwritten by overflow, ie% i7 of the transition window) .

If the WIM has only one bit set, it is the reserved window that has been hit and the trap must retrieve the record from the window stack. The record should indicate whether the window to be restored is a transition window. If it is not a transition window, the trap routine simply restores the window from memory, adjusts the CWP, and shuffles the reserved window bits appropriately in the WIM. For transition windows, the trap routine is configured to do the following:
Restore% i6 and% i7 of the transition window, and% y and global registers from the transition record taken from the stack;
Copy% o0 of the transition window to% i0, which is the return value from the user function;
Move the current window pointer to the window prior to the transition window and shuffle the reserved window bits appropriately in the WIM. This moves the CWP to the supervisor window before the transition window, meaning that the value written in the “internal” register above is now in the “external” register. Note that this window should still be in memory at this point; this window needs to be restored;
Retrieve the next record from the window stack, which is a “normal” record corresponding to the saved supervisor window;
Restore the saved supervisor window, restoring the “internal” and “local” registers. Values in the "external" register (such as the return value from above) are not overwritten;
Jump to the supervisor code that originally called the callUserFunction and its address is available via% o7 of the restored supervisor window.

  In the example above, the window stack is used to record the flags associated with the type of window being stored, namely the “transition” record for transition windows and the “normal” record for non-transition windows. The In this way, the position of the transition window is maintained through overflow and underflow, and no confidential data is accessible to the user code as a result of the transition between supervisor mode and user mode. This is further ensured by overwriting all register windows before returning from the trap.

  Alternatively or additionally, the% o6 value is stored on the register overflow so that each used register window is labeled and used for the corresponding restoration. In this way, when overflow and underflow occur, the% o6 value is inspected and confirmed to determine whether the register window belongs to user mode or supervisor mode.

  For example, the label is assigned as a unique numeric label for every possible register window for the thread of execution, starting from zero and increasing monotonically with each save and / or function. Labels are used in the same way as the flag records described above by attaching a label location record when overflow and underflow occur.

  That is, a record of the current label assigned to the reserved window and the window number of the reserved window can be attached. This is updated each time the overflow and underflow routines shift the reserved window, overflow increases the label and underflow decreases the label.

  For example, the window label secured at the time of thread initialization is set to 8, and the window number is set to 0. This record can be kept in some thread-specific supervisor RAM, or it can be held in the “local” register of a reserved window (user code is not accessible). In this case, underflow and overflow traps shift values as they shift the reserved window. Next, the label (L) of the current window is L = reserved window label − ((CWP−reserved window number); (N−1) and the bitwise AND operation, N is the register window number) Can be calculated as

Labels can also be used to access additional states for each register window during overflow and underflow events. Additional states include a saved stack pointer, eg,% o6, for windows and window modes. The mode can identify whether the window is running in supervisor mode, and can further identify whether the window is running with interrupts and mode changes. Like the flag record described above, this provides a record as to whether the register window belongs to user mode or supervisor mode. In this case, the label for the current window is L = next label to be saved + ((CWP + next label to be saved) ^N−1 ; (N−1) and bitwise AND operation, N is a register Where the "next label to save" variable contains a label for the next register window to overflow, and assists in the orderly processing of overflow and underflow.

  Additional state information is accessed by indexing the stack pointer and mode records in the window stack when overflow and underflow occur as part of the label record. This can be done only for reserved windows or for all register windows, as described above. In this way, restoration beyond the transition between user mode and supervisor mode is identified and can be handled in a different way than restoring what remains in the user mode, for example in the manner described above. Therefore, the supervisor mode confidential data is protected from user code access.

  Of course, it will be understood that the invention has been described by way of example only and modifications of detail may be made within the scope of the invention as defined by the appended claims.

Claims (20)

A system for protecting supervisor mode data from user code within a register window architecture of a processor, comprising:
When transitioning from supervisor mode to user mode, at least one invalid window bit is additionally set in the invalid window mask of the architecture in addition to the invalid window bit set for a window with an invalid window mask reserved. It is characterized by
The additionally set bit is set for a transition window between a supervisor data window and a user data window.   The system of claim 1, wherein the register window architecture of the processor is a SPARC ™ register window architecture.   The system of claim 1, wherein the processor is incorporated in a print engine for a printer.   The system of claim 1, wherein the position of additional invalid window bits in the invalid window mask is maintained independent of window overflow and underflow in the transition window.   The system of claim 1, further comprising a supervisor mode stack and a user mode stack separately.   6. The system of claim 5, wherein the supervisor mode stack is stored in memory accessible only by supervisor mode, and the user mode stack is stored in memory accessible by user mode. Each time a transition from user mode to supervisor mode occurs, the current stack pointer is switched to the supervisor stack,
Each time a transition from supervisor mode to user mode occurs, the current stack pointer is switched to the user stack.
The system according to claim 6.   The system of claim 6, wherein information about the transition window is recorded in the supervisor stack upon window overflow and underflow in the transition window. The system further comprises a window stack stored in memory accessible only to the supervisor mode,
The system of claim 6, wherein information about the transition window is recorded in the window stack upon window overflow and underflow in the transition window.   The system of claim 9, wherein information about non-transition windows is recorded in the window stack upon window overflow and underflow in the non-transition windows.   7. The system of claim 6, wherein each register window is assigned a unique numeric label that starts at zero and increases monotonically with each save.   A record of the current label assigned to the reserved window is held in a local register of the reserved window, and the record is updated when window overflow and underflow occur in the reserved window; The system of claim 11.   Further comprising a window stack stored in a memory accessible only by the supervisor mode, wherein the label is at least of the reserved window in the window stack upon window overflow and underflow in the reserved window. The system of claim 11, wherein the system is used to index the stack pointer records.   14. The system of claim 13, wherein the label is used to index a record of the stack pointer for each window in the window stack upon window overflow and underflow in each window.   The system of claim 11, wherein the label is calculated based on a current window pointer.   When transitioning from supervisor code to user code, the calling function issues a save to move the current window pointer to the user window located behind the transition window, and at least the reserved from the current window. The system of claim 1, overwriting the register in the window containing supervisor code data up to the window.   The system of claim 16, wherein the call function overwrites the register in all windows from the current window to the reserved window.   The system of claim 17, wherein the call function overwrites all registers of the processor that contain supervisor code data.   The system of claim 1, wherein the register in the transition window is overwritten upon window overflow and underflow in the transition window.   The system of claim 1, wherein when transitioning from user code to supervisor code, a window underflow trap routine issues a restore to move the current window pointer to the supervisor window prior to the transition window.

Images