WO2013110736A1 - Speichercontroller zur bereitstellung mehrerer definierter bereiche eines massenspeichermediums als unabhängige massenspeicher an einen master-betriebssystem - kern zur exklusiven bereitstellung an virutelle maschinen - Google Patents

Speichercontroller zur bereitstellung mehrerer definierter bereiche eines massenspeichermediums als unabhängige massenspeicher an einen master-betriebssystem - kern zur exklusiven bereitstellung an virutelle maschinen Download PDF

Info

Publication number
WO2013110736A1
WO2013110736A1 PCT/EP2013/051390 EP2013051390W WO2013110736A1 WO 2013110736 A1 WO2013110736 A1 WO 2013110736A1 EP 2013051390 W EP2013051390 W EP 2013051390W WO 2013110736 A1 WO2013110736 A1 WO 2013110736A1
Authority
WO
WIPO (PCT)
Prior art keywords
operating system
mass storage
storage medium
flsh
computer system
Prior art date
Application number
PCT/EP2013/051390
Other languages
English (en)
French (fr)
Inventor
Bernd Becker
Thorsten Finke
Original Assignee
Continental Automotive Gmbh
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Continental Automotive Gmbh filed Critical Continental Automotive Gmbh
Priority to US14/372,415 priority Critical patent/US10055361B2/en
Priority to CN201380006822.4A priority patent/CN104081349B/zh
Priority to EP13702764.5A priority patent/EP2807558B1/de
Publication of WO2013110736A1 publication Critical patent/WO2013110736A1/de

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F12/00—Accessing, addressing or allocating within memory systems or architectures
    • G06F12/14—Protection against unauthorised use of memory or access to memory
    • G06F12/1416—Protection against unauthorised use of memory or access to memory by checking the object accessibility, e.g. type of access defined by the memory independently of subject rights
    • G06F12/145—Protection against unauthorised use of memory or access to memory by checking the object accessibility, e.g. type of access defined by the memory independently of subject rights the protection being virtual, e.g. for virtual blocks or segments before a translation mechanism
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F12/00—Accessing, addressing or allocating within memory systems or architectures
    • G06F12/02—Addressing or allocation; Relocation
    • G06F12/0223—User address space allocation, e.g. contiguous or non contiguous base addressing
    • G06F12/023—Free address space management
    • G06F12/0238—Memory management in non-volatile memory, e.g. resistive RAM or ferroelectric memory
    • G06F12/0246—Memory management in non-volatile memory, e.g. resistive RAM or ferroelectric memory in block erasable memory, e.g. flash memory
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F12/00—Accessing, addressing or allocating within memory systems or architectures
    • G06F12/14—Protection against unauthorised use of memory or access to memory
    • G06F12/1458—Protection against unauthorised use of memory or access to memory by checking the subject access rights
    • G06F12/1466—Key-lock mechanism
    • G06F12/1475—Key-lock mechanism in a virtual system, e.g. with translation means
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F12/00—Accessing, addressing or allocating within memory systems or architectures
    • G06F12/14—Protection against unauthorised use of memory or access to memory
    • G06F12/1458—Protection against unauthorised use of memory or access to memory by checking the subject access rights
    • G06F12/1491—Protection against unauthorised use of memory or access to memory by checking the subject access rights in a hierarchical protection system, e.g. privilege levels, memory rings
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45533—Hypervisors; Virtual machine monitors
    • G06F9/45558—Hypervisor-specific management and integration aspects
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45533—Hypervisors; Virtual machine monitors
    • G06F9/45558—Hypervisor-specific management and integration aspects
    • G06F2009/45579—I/O management, e.g. providing access to device drivers or storage
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2212/00—Indexing scheme relating to accessing, addressing or allocation within memory systems or architectures
    • G06F2212/15—Use in a specific computing environment
    • G06F2212/152—Virtualized environment, e.g. logically partitioned system
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2212/00—Indexing scheme relating to accessing, addressing or allocation within memory systems or architectures
    • G06F2212/72—Details relating to flash memory management
    • G06F2212/7211—Wear leveling

Definitions

  • the invention relates to a computer system which can be used for example in a motor vehicle or as an embedded system.
  • One task to be solved is to specify an improved concept for the security of virtualized operating systems.
  • the proposed concept is based on the idea of providing a computer system with a special memory controller for a nonvolatile mass storage medium, which accesses defined areas of the mas Sensory storage medium each as an independent mass storage enabled, so that in each case at least one of the independent mass storage for each virtualized operating system is made available.
  • the memory controller is preferably realized as a hardware component which is independent of a processor of the computer system on which the virtualized operating systems run. Thus, it can be ensured that the virtualized operating systems can only access the mass memories assigned to them.
  • a computing system includes at least one processor and a memory controller for a nonvolatile mass storage medium.
  • the computer system is set up to execute on the processor a master operating system core and a first and at least one second operating system kernel under the control of the master operating system kernel.
  • the memory controller is configured to provide regions of a mass storage medium that are defined for the master operating system core, that is to say, a first and at least one second mass memory that are independent of each other, and an image of the first and the at least one second mass memory to be defined Control areas of the mass storage medium.
  • the master operating system core is set up to allow the first and the at least one second operating system kernel exclusive access to at least one of the provided mass storages.
  • the mass storage medium is for example a so-called
  • Flash memory such as a multimedia card, MMC, or a secure digital memory card, SD card, or the like.
  • the nonvolatile mass storage medium is a NAND memory, a NOR memory or a managed NAND memory, which in each case can be soldered firmly to the board of the computer system.
  • the mass storage medium may also be a hard disk or Solid State Drive (SSD).
  • SSD Solid State Drive
  • the mass storage medium is encompassed by the computer system and, for example, permanently integrated in the computer system.
  • the memory controller thus provides the master operating system core with a plurality of mass storages which, under the control of the master operating system kernel, are made available as respective mass storages for the first and the at least one second operating system kernel. This allows a protected access to the defined areas of the mass storage medium.
  • the memory controller has a mapping table that has stored a mapping rule for each provided mass memory on the associated defined areas of the mass storage medium.
  • the operating system cores can use the mass storage provided in each case like a conventional mass storage device, with conversion or mapping of the access requirements of the operating system cores taking place using the mapping table or the mapping rules.
  • the defined areas of the mass storage medium are formed by partitions on the mass storage medium, wherein the stored mapping instructions include information about a position and size of the partitions.
  • the memory controller comprises a master controller configured to control hardware access to the defined areas.
  • the master controller is set up, for example, to check a respective access authorization to the defined areas.
  • mapping rules also include information about a hardware identification number of the respective mass memories. This hardware identification number can be used, for example, by the operating system cores or their drivers for controlling the mass storage devices.
  • the memory controller has a first and at least one second virtual controller, each providing one of the mass memories and each having a register which is mapped into a memory area of the master operating system kernel.
  • each operating system kernel controlled by the master operating system kernel can be provided with at least one virtual controller, which can be directly controlled within the address range of the operating system kernel.
  • the control of the mass storage for the controlled operating system kernels is completely done transparent and without knowledge of the other virtual controllers or mass storage.
  • the memory controller is implemented as a hardware component, such as application-specific integrated circuit, ASIC, or via a microcontroller with appropriate programming.
  • Program data for such a microcontroller can be stored, for example, in a region of the mass storage medium.
  • the memory controller By implementing the memory controller as a hardware component, the computing load of the processor of the computer system is reduced. In addition, due to the separation into different hardware components between processor and memory controller increased security against manipulation of the memory controller by malicious programs that run on the processor, given.
  • the virtual controllers forward their requests for access to the defined areas, for example, to the master controller, which controls the physical access to the mass storage medium.
  • this control is done on the basis of the information stored in the mapping table.
  • An initialization and control of the master controller can be done for example by the master operating system kernel.
  • the memory controller is also configured to control access to the defined areas of the mass storage medium based on predetermined priorities.
  • predetermined priorities for example, are also stored in the mapping table.
  • the memory controller or the master controller is set up to use a control distribution of the mass storage medium.
  • so-called wear-leveling mechanisms are used, which ensure a uniform use or wear of memory areas or memory cells of the mass storage medium. As a result, the computing load of the processor of the computer system can be further reduced.
  • FIG. 1 shows a schematic representation of a computer system
  • Figure 2 is a schematic representation of a distribution of a mass storage medium
  • Figure 3 is a schematic representation of another embodiment of a computer system.
  • FIG. 1 shows a schematic representation of an embodiment of a computer system 100 with a processor CPU and a memory controller CTL, to which a mass storage medium FLSH is connected.
  • the mass storage medium FLSH is, for example, a so-called flash memory such as a multimedia card, MMC, or a secure digital memory card, SD card, or the like.
  • the nonvolatile mass storage medium FLSH is a NAND memory, a NOR memory, or a managed NAND memory, each of which may be soldered firmly to the board of the computer system 100 or external to the computer system 100.
  • the mass storage medium FLSH can also be a solid state drive, SSD.
  • the processor CPU is used to execute a master operating system kernel MBS as a so-called host operating system or host operating system H-OS.
  • a master operating system kernel MBS Under the control of the master operating system kernel MBS, in the present embodiment, a first, a second, and a third operating system kernel BS1, BS2, BS3 are executed, which constitute so-called guest operating systems G-OS.
  • the first operating system kernel BS1 is designed for an operating system according to the Automotive Open System Architecture, AUTOSAR, while different Linux operating systems run on the second and third operating system kernel BS2, BS3.
  • the second operating system kernel BS2 is a conventional Linux operating system, which also allows the execution of safety-critical applications or programs, so that in particular the execution of
  • the third operating system kernel BS3 comprises, for example, a secured or hardened Linux system, which is operated, for example, with security guidelines and prevents the execution of safety-critical applications.
  • the first and / or the second operating system kernel BS1, BS2 or their system programs are managed by this secure Linux system.
  • the master operating system kernel MBS is embodied, for example, as a microkernel or separation kernel.
  • the memory controller CTL comprises a master controller MCTRL and a plurality of virtual controllers VC1, VC2, VC3, VC4, VCn, which are connected to the master controller MCTRL. Furthermore, the mass storage medium FLSH is connected to the master controller MCTRL.
  • the memory controller CTL further comprises a mapping table MTBL in which for each of the virtual controllers VC1 to VCn an mapping rule is stored between defined areas of the mass storage medium FLSH and the associated virtual controller. For example, for the first virtual controller VC1 is an entry with the identification of the controller CBl, a Start block SBL stored on the mass storage medium FLSH, an end block EBI on the mass storage medium FLSH and a hardware identification number DEVl, which provides the virtual controller VCl the connected processor CPU. Similarly, entries for controller information CB2 to CBn, start blocks SB2 to SBn, end blocks EB2 to Ebn, and hardware identification numbers DEV2 to DEVn are also stored for the other virtual controllers.
  • the master controller MCTRL is also connected via a special control line to the processor CPU, which in particular allows only the master operating system core MBS control and configuration of the master controller MCTRL via initialization commands INIT and control commands CTRL.
  • the memory controller CTL thus provides the master operating system core with a plurality of virtual controllers VCl to VCn, which in turn are made available to the functionally controlled operating system cores BS1, BS2, BS3 as respective mass storage controllers.
  • each operating system core BS1, BS2, BS3 receives at least its own virtual controller, via which a mass memory allocated to the operating system kernel can be accessed.
  • the memory controller CTL is realized as a separate hardware component, so that no additional processor power of the processor CPU needs to be used.
  • the virtual controllers VC1 to VCn have the functionality of a conventional memory controller, at least for the controlled operating system cores BS1, B2, B3, whereby the mapping table maps virtual block numbers of the virtual controllers VC1 to VCn to physical blocks of the connected mass storage medium FLSH. For example, this mapping is called mapping. by realizing that the virtual block number is added to the start blocks SB1, SB2, SBn serving as an offset. In addition to the pure block numbers, it may be desirable for the chip select lines to be mapped to the virtual controllers VC1 to VCn.
  • mapping table While in the illustrated form physical start and end blocks are stored in the mapping table, it is also possible to store a partition size on the mass storage medium FLSH in the mapping table, in addition to the start blocks SB1, SB2, SBn, by the respective permissible size or permissible access range define for the virtual controller. In both cases, it is provided, for example, that the master controller MCTRL in an access request of the virtual controller VCl to VCn in
  • Direction of the mass storage medium FLSH checks if the requested block is within the area defined by the entries on the mass storage medium.
  • an exception message for example, can be sent in the direction of the processor CPU.
  • This exception message is, for example, a software interrupt, which is then processed by the master operating system kernel MBS.
  • Another desirable information is information about the attached mass storage medium. This allows the master controller MCTRL to know if the physical memory is connected, for example via SDIO, MMC or as a pure NAND device. This device information tells the master controller MCTRL to know if the physical memory is connected, for example via SDIO, MMC or as a pure NAND device. This device information tells the master controller MCTRL to know if the physical memory is connected, for example via SDIO, MMC or as a pure NAND device. This device information tells the
  • Master controller MCTRL also with which Chipselect lines are to be used to access the mass storage medium and in which way an addressing of the connected mass storage device takes place.
  • a plurality of mass storage media may also be connected, in which case Preferably, a plurality of master controllers are provided, which each realize the physical access to a connected Mas sens electricianmedium.
  • the information about the device type of the respective mass storage medium may be useful, for example, for distinguishing between several SD cards which are connected to special SD card controllers.
  • the various defined areas for the operating system cores BS1, BS2, BS3 can thus be stored on different mass storage media. However, it is preferably not envisaged that a defined area extends over a plurality of mass storage media.
  • a configuration of the mass storage medium FLSH by the master controller MCTRL takes place, for example, via the previously described connection between the master controller MCTRL and the master operating system kernel MBS.
  • This configuration is preferably carried out when the master operating system core is started, wherein the configuration data are also stored directly on the mass storage medium FLSH, for example in an initial area or in the first blocks of the mass storage medium FLSH.
  • the master controller MCTRL is preferably set up to notify a faulty configuration, for example due to overlapping block areas, to the master operating system kernel MBS or the host operating system H-OS.
  • Each virtual controller VC1 to VCn is preferably a real hardware instance with its own registers formed in separate memory pages of the physical address range of the processor CPU. This allows each virtual controller to be assigned to a separate partition for a guest operating system using standard computer system mechanisms, such as a memory mapping unit (MMU).
  • MMU memory mapping unit
  • each virtual controller VC1 to VCn can have all the registers necessary to perform read and write accesses to the virtual device, so that each virtual controller behaves like a conventional memory controller.
  • One of the differences from a conventional memory controller is the fact that the actual data transmission is carried out in the physical sense by the master controller MCTRL, which checks the configuration and the mapping table against the transmission or access parameters before the transmission actually takes place is performed.
  • the transmission parameters include, for example, the block numbers, the number of blocks to be read or written, or access permissions.
  • the virtual controllers behave like independent entities that generate exception messages in the event of access violations.
  • the virtual address of the virtual controller is converted to a physical address which is used in the mass storage medium FLSH.
  • FIG. 2 shows an exemplary division of a mass storage medium FLSH into a plurality of defined areas, which can be accessed via the virtual controllers.
  • the mass storage medium FLSH is divided into four defined areas, which are defined by physical block numbers PBN.
  • the first area goes from a physical block 0 to a physical block 1023, the second area from the physical block 1024 to the physical block 33791, the third area from the physical block 33792 to the physical block 66559, and the fourth area from the physical block 66560 to the physical block 1048575.
  • the first area is, for example, a partition for a bootloader at a start of the whole
  • the second area is a first operating system partition which is responsible for the associated operating system partition an internal system and an internal data partition is divided.
  • the line with the internal data partitions is marked INTP.
  • the third area serves as a system partition for a second operating system partition, and the fourth area is again divided into a system partition and a data partition as internal data partitions of a third operating system partition.
  • Logical block numbers LBN starting at 0 and ending for the first area at block 1023, for the second area at block 32767, for the third area at block 32767, and for the fourth area at block 982015, result for the respective areas.
  • the individual areas can also be referred to as superpartitions.
  • the corresponding super partition looks like a complete mass storage for each operating system kernel.
  • a first block such as a so-called master boot record is used, which is common in conventional PC systems.
  • a partition table is stored in this master boot record, which carries information about the internal partitions INTP.
  • Each operating system kernel has access to its associated super partition and can manage access rights to the internal partitions INTP.
  • access to an internal partition is still only possible with the rights assigned to it by the master operating system kernel MBS.
  • an operating system kernel that has read only access to the OS partition 2 can only read the memory of that partition read-only. Accordingly, this operating system kernel can not generate its own partitions or write or write contents to the mass storage medium.
  • another operating system kernel may also be possible for another operating system kernel to have read-only access to the system partition of OS partition 3, while 3 read and write accesses are possible on the internal data partition of the OS partition 3.
  • each super partition is managed by a virtual controller.
  • a plurality of virtual controllers may have access to the same physical area in order to provide a physical area in a secure manner to a plurality of operating system cores. For example, this allows write and read access to the associated superpartition for one virtual controller, while the other virtual controller or controllers only have read accesses to this area.
  • a booting of the computer system is preferably always carried out by the first blocks of the connected mass storage medium FLSH.
  • the mapping table After power up, it is desirable for the mapping table to be padded with zeroes so that all virtual controllers see the entire attached memory area of the mass storage medium FLSH. This is usually possible without problems, since the processor is usually started by a so-called bootloader or the master operating system kernel with a so-called bootstrapping process.
  • This boot loader then preferably initializes the mapping table MTBL before the dependent controlled operating system kernels BS1, BS2, BS3 are started.
  • an initialization code explicitly writes the start and end blocks in the mapping table NTBL. Further, it is possible that the mapping table is initialized by a specific block in the mass storage medium FLSH. The initialization code preferably also ensures that access to the master controller MCTRL is restricted to the master operating system kernel MBS. In addition, the initialization code preferably initializes basic MMU tables, so that the virtual Tual controller in the corresponding master operating system core or the guest operating system cores BSl, BS2, BS3 can be assigned.
  • interoperability with an input / output MMU can also be provided, so that in addition memory area identifications, translation buffers or references to MMU translation buffers are written to a register of the virtual controller.
  • the master controller preferably initiates the interrupt requests for the virtual controllers for which an underlying transmission was performed.
  • the I / O MMU therefore requires an allocation to memory areas, for example a guest partition or the master operating system core, which is generated by the configuration of the virtual controllers to check DMA transfers and map interrupt requests. Accordingly, it is desirable that the
  • Input / output MMU without interception of interrupt requests from the master controller to get the virtual controller. Even if a mass storage medium is merely used as a partition, it is sufficient that the input / output MMU operates only with a virtual controller. In this case, it is desirable that this is the first controller configured to access all storage areas of the mass storage medium. Furthermore, it may be desirable for the computer system to be set up for a prioritization of accesses. Access priorities are non-negligible features for complex systems such as an entertainment system in a vehicle. This is due to the fact that there are usually requirements that the last user setting be stored within a short time of, for example, 1 or 2 milliseconds when a voltage drop and a shutdown of the computer system threatens or is initiated.
  • the computer system should be able to write one or more blocks to the mass storage medium at short notice, thereby overriding or even canceling other requests from other virtual controllers.
  • This can be implemented, for example, by prioritizing each virtual controller.
  • an identification of the virtual controller may be used as an initial priority, for example.
  • the memory controller CTL in a round robin method to regulate the access for virtual controllers with the same priority.
  • the master controller preferably has a list in which transmissions to be processed, that is to say memories or read operations on the mass storage medium, are stored and placed in an order. For this purpose, it may be useful to provide the master controller with a special memory or memory areas from existing memory.
  • exceptions are forwarded to a privileged mode.
  • the master operating system kernel MBS should always be started with full privileges, while the guest operating systems BS1, BS2, BS3 work with lower privileges.
  • Processors that support virtualization in embedded systems include, for example, the ARM Cortex AI5 and the Intel Atom processor.
  • interrupt requests with which exception messages such as access violations are reported, forwarded directly to the master operating system kernel MBS, as well as to the input / output MMU.
  • the master operating system kernel MBS may then select an appropriate defending mechanism, which may range from ignoring the event to pausing or restarting the guest operating system.
  • such exception messages are forwarded to the master operating system core via the master controller MCTRL.
  • a configuration of the memory controller CTL is also possible during the operation of the computer system by the master operating system core or the host operating system H-OS.
  • This facilitates software update procedures.
  • the privileged partition of the mass storage medium to update the installed programs of the host operating system H-OS or master operating system kernel MBS and the guest operating system kernels BS1, BS2, BS3.
  • the guest operating system kernels BS1, BS2, BS3 are stopped or their flow coordination stopped in order to avoid race conditions when accessing the file system.
  • wear leveling it may be necessary for wear leveling to be implemented, either realized as software or directly implemented in the connected mass storage medium.
  • the host operating system H-OS and the guest operating systems BS1, BS2, BS3 can dispense with an application of usage distribution and thus not directly with the physical blocks on the mass storage medium, especially a flash memory. Rather, it is sufficient that the previously as physical Blocks in turn serve as logical or virtual blocks, which are converted directly from the mass storage medium into the actual physical blocks. In other words, an additional logical level of blocks is introduced between memory controller CTL and mass storage medium FLSH.
  • the I / O bandwidth of an access to a flash memory essentially depends on an internal organization in a chip of the flash memory. For example, efficient access is implemented at one manufacturer by alternately using even and odd block numbers, while at another manufacturer, the first and second half of block numbers are alternately used. This essentially depends on which addresses are used to select a logical unit.
  • Outgoing access can be programmed, for example, by arranging read, write or delete commands in an order.
  • Such a processor for the memory controller can also be used as a DMA master to transfer memory to the allocated memory blocks of the operating system cores MBS, BS1, BS2, BS3.
  • a controller processor can itself be initialized by a connected mass storage medium, in particular a flash memory.
  • Creating secure flash partitioning is not just about implementing virtual controllers. Since memory access to the flash memory benefits from the DMA operation, it may also be necessary to disable the DMA transfers. assure. For example, this is done via an input / output MMU, which ensures that a guest operating system BS1, BS2, BS3 or a virtual controller performs an actual memory transfer only if sufficient access rights are available. In the event of an access violation, the I / O MMU may raise an exception message, such as an interrupt request, to the master operating system kernel MBS so that the master operating system kernel MBS resolves the failure by deactivating or rebooting the guest operating system kernel, which triggered the error.
  • an exception message such as an interrupt request
  • FIG. 3 shows a possible application for the previously described principle with reference to an exemplary schematic representation of a computer system 100.
  • three partitions or mass memories MSI, MS2, MS3 are set up on the mass storage medium FLSH by way of example.
  • MBS master operating system kernel
  • the left operating system kernel BS2 is for executing a conventional operating system that enables the use of Internet applications for a web browser, downloadable applications, and multimedia functionality.
  • the operating system kernel BS2 is preferably secured and it is not necessary to provide increased reliability.
  • Operating system files, applications, library files and configuration files are stored for the second operating system kernel BS2 with the second mass storage MS2.
  • the second mass memory MS2 for example, storage space for system files BIN, executable files EXE and configuration files CNF.
  • the master operating system core MBS or the memory controller CTL (not shown here) ensures that the second operating system kernel BS2 has only read access to the second mass storage MS2, but no write access own, characterized by an RO (read only).
  • User data such as music files MP3, image files JPG or other Internet formats HTML are created on the third mass storage MS3, to which the second operating system kernel BS2 has both read and write access. This is indicated by the designation RW (read-write).
  • the right operating system kernel BS1 is used to run a secure operating system under which a software management program is running. Furthermore, a virus scanner and / or specific security guidelines can also be implemented under the first operating system kernel BS1. Access to the first operating system kernel is preferably provided for maintenance purposes only, so that in particular no unsafe multimedia applications or the like can be executed.
  • the first operating system kernel BS1 has write access and read access to the first and second mass storage MSI, MS2.
  • the first mass storage MSI contains a database for software administration SW-DB, security certifications ZERT and a virus scanner VS. Operating system files, applications, library files and configuration files are stored for the first operating system kernel BS1 either also on the second mass storage MS2 or preferably on the first mass storage MSI.
  • the second operating system kernel BS2 has no access to the first one
  • Mass storage MSI and preferably also has no knowledge of the existence of this mass storage MSI.
  • the access to the mass storage medium FLSH or the mass storage MSI, MS2, MS3 is controlled by the master operating system kernel MBS or the memory controller CTL.
  • the first operating system kernel BS1 is used which, on the basis of the software management database, performs an update of the system files in applications on the second mass storage MS2.
  • the first operating system kernel BS1 has a separate virtual control Access to the second mass storage MS2.
  • two separate virtual controllers simultaneously access the second mass storage MS2, while the virtual controller only allows the second operating system kernel BS2 a read access, while the virtual controller for the first operating system kernel BS1 also allows write access.
  • the access of the second operating system kernel BS2 to the mass memory of the first operating system kernel BS1 is prevented.
  • the illustrated embodiment of the computer system makes it possible that even with a compromise of the second operating system kernel BS2 by a malicious program, the change of system files and thus the targeted opening of further vulnerabilities starting from the second operating system kernel BS2 can be prevented.
  • the second operating system kernel Because of the Internet capability and multimedia capability of the second operating system kernel, there is in principle the risk that malicious programs can be introduced into the area of the second operating system kernel due to unrecognized or newly occurring security vulnerabilities, but which due to the lack of write authorization does not lead to a permanent change of the operating system can lead the second operating system kernel BS2. This will cause malware not to remain in the computer system when the system is turned off and on again.
  • the computer system 100 is set up in particular for operation in a motor vehicle.
  • the computer system 100 is implemented as an embedded system.
  • the computer system 100 may also be used in other environments, e.g. used on mobile phones that are operated, for example, with the Android operating system.

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Software Systems (AREA)
  • Computer Security & Cryptography (AREA)
  • Storage Device Security (AREA)

Abstract

Ein Rechnersystem (100) umfasst wenigstens einen Prozessor (CPU), einen ersten Massenspeicher (MSI) und einen zweiten Massenspeicher (MS2). Das Rechnersystem (100) ist eingerichtet, auf dem Prozessor (CPU) einen Master-Betriebssystem-Kern (MBS) sowie einen ersten und wenigstens einen zweiten Betriebssystemkern (BS1, BS2) unter Kontrolle des Master-Betriebssystem-Kerns (MBS) auszuführen. Der Speichercontroller (CTL) ist eingerichtet, dem Master-Betriebssystem-Kern (MBS) definierte Bereiche eines Massenspeichermediums (FLSH) als einen ersten und wenigstens einen zweiten Massenspeicher zur Verfügung zu stellen, die jeweils voneinander unabhängig sind, und eine Abbildung des ersten und des wenigstens einen zweiten Massenspeichers auf die definierten Bereiche des Massenspeichermediums (FLSH) zu steuern. Der Master-Betriebssystem-Kern (MBS) ist eingerichtet, dem ersten und dem wenigstens einen zweiten Betriebssystemkern (BS1, BS2) exklusiven Zugriff auf jeweils zumindest einen der zur Verfügung gestellten Massenspeicher zu ermöglichen.

Description

Beschreibung
SPEICHERCONTROLLER ZUR BEREITSTELLUNG MEHRERER DEFINIERTER BEREICHE EINES MAS SENS PEICHERMEDIUMS ALS UNABHÄNGIGE MASSENSPEICHER AN EINEN
MASTER -BETRIEBSSYSTEM- KERN ZUR EXKLUSIVEN BEREITSTELLUNG AN VIRUTELLE MASCHINEN
Die Erfindung betrifft ein RechnerSystem, welches beispielsweise in einem Kraftfahrzeug oder als eingebettetes System eingesetzt werden kann.
In modernen RechnerSystemen wird vielfach mit der Virtuali- 10 sierung von Betriebssystemen gearbeitet, um beispielsweise
auf den Einsatz zusätzlicher Prozessoren oder MikroController zu verzichten. Aus Sicherheitsgründen wird hierbei versucht, den gegenseitigen Zugriff der virtualisierten Betriebssysteme untereinander zu verhindern. Zudem soll insbesondere der 15 Zugriff von Schadprogrammen auf die verschiedenen virtualisierten Betriebssysteme unterbunden werden. Wenn bei mehreren virtualisierten Betriebssystemen jeweilige Massenspeicher auf demselben physikalischen Mas senspeichermedium abgelegt sind, besteht bei herkömmlichen RechnerSystemen grundsätzlich die 20 Gefahr, dass beispielsweise durch Ausnutzung von Sicherheitslücken unerwünschter Zugriff auf fremde Massenspeicher erfolgt. Dies wird bei herkömmlichen Systemen dadurch umgangen, dass für jedes virtuelle Betriebssystem ein eigener physikalischer Massenspeicher zur Verfügung gestellt wird.
25
Eine zu lösende Aufgabe besteht darin, ein verbessertes Konzept für die Sicherheit von virtualisierten Betriebssystemen anzugeben .
30 Die Aufgabe wird gelöst mit dem Gegenstand des unabhängigen Patentanspruchs. Weiterbildungen und Ausgestaltungen der Erfindung sind Gegenstand der abhängigen Ansprüche.
Das vorgeschlagene Konzept basiert auf der Idee, für ein RechnerSystem einen speziellen Speichercontroller für ein nichtflüchtiges Massenspeichermedium zur Verfügung zu stel len, welcher einen Zugriff auf definierte Bereiche des Mas senspeichermediums jeweils als unabhängigen Massenspeicher ermöglicht, so dass jeweils mindestens einer der unabhängigen Massenspeicher für jeweils ein virtualisiertes Betriebssystem zur Verfügung gestellt wird. Der Speichercontroller ist vor- zugsweise als Hardwarebauteil realisiert, welches unabhängig von einem Prozessor des RechnerSystems ist, auf dem die vir- tualisierten Betriebssysteme ablaufen. Somit kann sichergestellt werden, dass die virtualisierten Betriebssysteme jeweils nur auf die ihnen zugewiesenen Massenspeicher Zugriff haben können.
In einer Ausführungsform weist ein RechnerSystem wenigstens einen Prozessor und einen Speichercontroller für ein nichtflüchtiges Massenspeichermedium auf. Das RechnerSystem ist dabei eingerichtet, auf dem Prozessor einen Master-Betriebssystem-Kern sowie einen ersten und wenigstens einen zweiten Betriebssystemkern unter Kontrolle des Master-Betriebssystem- Kerns auszuführen. Der Speichercontroller ist eingerichtet, dem Master-Betriebssystem-Kern definierte Bereiche eines Mas- senspeichermediums also einen ersten und wenigsten einen zweiten Massenspeicher zur Verfügung zu stellen, die jeweils voneinander unabhängig sind, und eine Abbildung des ersten und des wenigstens einen zweiten Massenspeichers auf die definierten Bereiche des Massenspeichermediums zu steuern. Der Master-Betriebssystem-Kern ist eingerichtet, dem ersten und dem wenigstens einen zweiten Betriebssystemkern exklusiven Zugriff auf jeweils zumindest einen der zur Verfügung gestellten Massenspeicher zu ermöglichen. Das Massenspeichermedium ist beispielsweise ein sogenannter
Flash-Speicher wie eine Mulitmediacard, MMC, oder eine Secure Digital Memory Card, SD-Card, oder dergleichen. Beispielsweise ist das nichtflüchtige Massenspeichermedium ein NAND-Spei- cher, ein NOR-Speicher oder ein gemanagter NAND-Speicher, welche jeweils fest auf der Platine des Rechnersystems gelötet sein können. In anderen Ausführungsformen kann das Massenspeichermedium auch eine Festplatte oder ein Festkörperlaufwerk, englisch: solid State drive, SSD, sein. In verschiedenen Ausführungsformen ist das Massenspeichermedium von dem RechnerSystem um- fasst und beispielsweise fest in dem Rechnersystem integriert .
Der Speichercontroller stellt somit dem Master-Betriebssystem-Kern mehrere Massenspeicher zur Verfügung, welche unter Kontrolle des Master-Betriebssystem-Kerns als jeweilige Massenspeicher für den ersten und den wenigstens einen zweiten Betriebssystemkern zur Verfügung gestellt werden. Dadurch kann jeweils ein geschützter Zugriff auf die definierten Bereiche des Massenspeichermediums erfolgen.
In einer Ausführungsform weist der SpeicherController eine Abbildungstabelle auf, der für jeden zur Verfügung gestellten Massenspeicher eine Abbildungsvorschrift auf die zugehörigen definierten Bereiche des Massenspeichermediums gespeichert hat. Dadurch können die Betriebssystemkerne den jeweils zur Verfügung gestellten Massenspeicher wie einen herkömmlichen Massenspeicher verwenden, wobei eine Umsetzung beziehungsweise Abbildung der Zugriffsanforderungen der Betriebssystemkerne unter Nutzung der Abbildungstabelle beziehungsweise der Abbildungsvorschriften erfolgt.
Beispielsweise sind die definierten Bereiche des Massenspeichermediums durch Partitionen auf dem Massenspeichermedium gebildet, wobei die gespeicherten Abbildungsvorschriften In- formationen über eine Position und Größe der Partitionen umfassen .
Dadurch wird es möglich, dass die Betriebssystemkerne auf die zugeordneten Massenspeicher über jeweils virtuelle Blocknum- mern auf die definierten Bereiche zugreifen, wobei die derart definierten virtuellen Blocknummern durch die Abbildungsvorschriften auf die physikalischen Blocknummern des Massenspei- chermediums abgebildet werden. Durch die Größeninformation der Partitionen in der Abbildungstabelle kann auch gewährleistet werden, dass jeweils nur auf die definierten Bereiche beziehungsweise Partitionen durch den Betriebssystemkern zu- gegriffen wird. Beispielsweise wird verhindert, dass bei einer zu großen virtuellen Blocknummer ein Zugriff auf einen nicht vom definierten Bereich umfassten physikalischen Bereich des Mas senspeichermediums erfolgt. Vorzugsweise weist der Speichercontroller einen Master-Controller auf, der eingerichtet ist, einen Hardwarezugriff auf die definierten Bereiche zu steuern. Insbesondere ist der Master-Controller beispielsweise eingerichtet, eine jeweilige Zugriffsberechtigung auf die definierten Bereiche zu prüfen. Eine solche Zugriffsberechtigung kann unter anderem über die in der Abbildungstabelle gespeicherten Informationen, beispielsweise die Positions- und Größeninformationen, realisiert werden. In verschiedenen Ausführungsformen umfassen die gespeicherten Abbildungsvorschriften auch Informationen über eine Hardware- Identifikationsnummer der jeweiligen Massenspeicher. Diese Hardware-Identifikationsnummer kann beispielsweise von den Betriebssystemkernen beziehungsweise deren Treibern zur An- Steuerung der Massenspeicher verwendet werden.
In verschiedenen Ausführungsformen weist der SpeicherController einen ersten und wenigstens einen zweiten virtuellen Controller auf, die jeweils einen der Massenspeicher zur Verfü- gung stellen und jeweils ein Register aufweisen, das in einen Speicherbereich des Master-Betriebssystem-Kerns abgebildet ist. Damit kann jedem vom Master-Betriebssystem-Kern gesteuerten Betriebssystemkern zumindest ein virtueller Controller zur Verfügung gestellt werden, welcher innerhalb des Adress- bereichs des Betriebsystemkerns unmittelbar angesteuert werden kann. Insbesondere erfolgt die Ansteuerung der Massenspeicher für die kontrollierten Betriebssystemkerne völlig transparent und ohne Kenntnis über die jeweils anderen virtuellen Controller beziehungsweise Massenspeicher.
Vorzugsweise ist der Speichercontroller als Hardwarebaustein realisiert, etwa als applikations spezifischer integrierter Schaltkreis, ASIC, oder über einen MikroController mit entsprechender Programmierung. Programmdaten für einen solchen MikroController können beispielsweise in einem Bereich des Massenspeichermediums abgelegt sein.
Durch die Implementierung des Speichercontrollers als Hardwarebaustein wird die Rechenbelastung des Prozessors des RechnerSystems reduziert. Zudem ist durch die Trennung in verschiedene Hardwarebausteine zwischen Prozessor und Spei- chercontroller eine erhöhte Sicherheit gegenüber Manipulationen des Speichercontrollers durch Schadprogramme, die auf dem Prozessor ablaufen, gegeben.
Die virtuellen Controller leiten ihre Anfragen zum Zugriff auf die definierten Bereiche beispielsweise an den Master- Controller weiter, welcher den physikalischen Zugriff auf das Mas senspeichermedium steuert. Vorzugsweise geschieht diese Steuerung auf Basis der Informationen, die in der Abbildungstabelle gespeichert sind. Eine Initialisierung und Steuerung des Master-Controllers kann beispielsweise durch den Master- Betriebssystem-Kern erfolgen.
In weiteren Ausführungsformen ist der Speichercontroller zudem eingerichtet, einen Zugriff auf die definierten Bereiche des Massenspeichermediums anhand vorgegebener Prioritäten zu steuern. Eine solche Steuerung erfolgt beispielsweise wiederum durch den Master-Controller, wobei die vorgegebenen Prioritäten beispielsweise ebenfalls in der Abbildungstabelle gespeichert sind.
In weiteren Ausführungsformen ist der Speichercontroller beziehungsweise der Master-Controller eingerichtet, eine Nut- zungsverteilung des Mas senspeichermediums zu steuern. Hierbei werden sogenannte Wear-Leveling-Mechanismen eingesetzt, die eine gleichmäßige Nutzung beziehungsweise Abnutzung von Speicherbereichen beziehungsweise Speicherzellen des Massenspei- chermediums gewährleisten. Dadurch kann die Rechenbelastung des Prozessors des RechnerSystems weiter reduziert werden.
Die Erfindung wird nachfolgend an mehreren Ausführungsbeispielen anhand von Figuren näher erläutert. Gleiche Bezugszeichen kennzeichnen hierbei Elemente der Bauteile gleicher Funktion. Soweit sich Elemente oder Bauteile in ihrer Funktion entsprechen, wird deren Beschreibung nicht in jeder der folgenden Figuren wiederholt. Es zeigen:
Figur 1 eine schematische Darstellung eines RechnerSystem,
Figur 2 eine schematische Darstellung einer Aufteilung eines Massenspeichermediums und
Figur 3 eine schematische Darstellung eines weiteren Ausführungsbeispiels eines Rechnersystems.
Figur 1 zeigt eine schematische Darstellung einer Ausführungsform eines RechnerSystems 100 mit einem Prozessor CPU und einem SpeicherController CTL, an den ein Massenspeichermedium FLSH angeschlossen ist. Das Massenspeichermedium FLSH ist beispielsweise ein sogenannter Flash-Speicher wie eine Multimediacard, MMC, oder eine Secure Digital Memory Card, SD-Card, oder dergleichen. Beispielsweise ist das nichtflüchtige Massenspeichermedium FLSH ein NAND-Speicher , ein NOR- Speicher oder ein gemanagter NAND-Speicher, welche jeweils fest auf der Platine des Rechnersystems 100 verlötet sein können oder aber sich extern vom RechnerSystem 100 befinden. Das Massenspeichermedium FLSH kann auch ein Festkörperlauf- werk, englisch: solid State drive, SSD, sein. Der Prozessor CPU dient bei der dargestellten Ausführungsform zur Ausführung eines Master-Betriebssystem-Kerns MBS als sogenanntes Wirt-Betriebssystem oder Host-Betriebssystem H-OS . Unter Kontrolle des Master-Betriebssystem-Kerns MBS werden in der vorliegenden Ausführungsform ein erster, ein zweiter und ein dritter Betriebssystemkern BS1, BS2, BS3 ausgeführt, welche sogenannte Gast-Betriebssysteme G-OS darstellen. Beispielsweise ist der erste Betriebssystemkern BS1 für ein Betriebssystem gemäß der Automotive Open System Architecture , AUTOSAR, ausgebildet, während auf dem zweiten und dritten Betriebssystemkern BS2, BS3 verschiedene Linux-Betriebssysteme ablaufen. Beispielsweise ist der zweite Betriebssystemkern BS2 ein herkömmliches Linux-Betriebssystem, welches auch die Ausführung von sicherheitskritischen Anwendungen oder Pro- grammen zulässt, so dass insbesondere die Ausführung von
Schadprogrammen nicht grundsätzlich verhindert werden kann. Der dritte Betriebssystemkern BS3 umfasst beispielsweise ein gesichertes beziehungsweise gehärtetes Linux-System, welches beispielsweise mit Sicherheitsrichtlinien betrieben wird und die Ausführung sicherheitskritischer Anwendungen unterbindet. Beispielsweise erfolgt eine Verwaltung des ersten und/oder des zweiten Betriebssystemkerns BS1, BS2 beziehungsweise von deren Systemprogrammen durch dieses gesicherte Linux-System. Der Master-Betriebssystem-Kern MBS ist beispielsweise als Mikrokern oder Separationskern ausgeführt.
Der Speichercontroller CTL umfasst einen Master-Controller MCTRL sowie mehrere virtuelle Controller VC1, VC2, VC3, VC4, VCn, die mit dem Master-Controller MCTRL verbunden sind. Ferner ist an den Master-Controller MCTRL das Massenspeicher- medium FLSH angeschlossen. Der Speichercontroller CTL umfasst ferner eine Abbildungstabelle MTBL, in der für jeden der virtuellen Controller VC1 bis VCn eine Abbildungsvorschrift zwischen definierten Bereichen des Massenspeichermediums FLSH und dem zugehörigen virtuellen Controller gespeichert ist. Beispielsweise ist für den ersten virtuellen Controller VC1 ein Eintrag mit der Identifikation des Controllers CBl, einen Startblock SBl auf dem Massenspeichermedium FLSH, einem Endblock EBl auf dem Massenspeichermedium FLSH sowie einer Hardware-Identifikationsnummer DEVl gespeichert, welche der virtuelle Controller VCl dem angeschlossenen Prozessor CPU zur Verfügung stellt. In ähnlicher Weise sind auch für die anderen virtuellen Controller Einträge mit Controllerinformationen CB2 bis CBn, Startblöcken SB2 bis SBn, Endblöcken EB2 bis Ebn und Hardwareidentifikationsnummern DEV2 bis DEVn abgelegt .
Der Master-Controller MCTRL ist zudem über eine besondere Steuerleitung mit dem Prozessor CPU verbunden, welche insbesondere lediglich dem Master-Betriebssystem-Kern MBS eine Steuerung und Konfiguration des Master-Controllers MCTRL über Initialisierungsbefehle INIT und Steuerbefehle CTRL ermöglicht .
Der Speichercontroller CTL stellt somit dem Master-Betriebssystem-Kern eine Vielzahl von virtuellen Controllern VCl bis VCn zur Verfügung, welche wiederum den abhängig kontrollierten Betriebssystemkernen BS1, BS2, BS3 als jeweilige MassenspeicherController zur Verfügung gestellt werden. Somit erhält jeder BetriebssystemKern BS1, BS2, BS3 zumindest einen eigenen virtuellen Controller, über den auf einen dem Be- triebssystemkern zugeordneten Massenspeicher zugegriffen werden kann. Vorzugsweise ist der Speichercontroller CTL als separater Hardwarebaustein realisiert, so dass keine zusätzliche Prozessorleistung des Prozessors CPU genutzt werden braucht .
Die virtuellen Controller VCl bis VCn weisen zumindest für die kontrollierten Betriebssystemkerne BS1, B2, B3 die Funktionalität eines üblichen Speichercontrollers auf, wobei durch die Abbildungstabelle virtuelle Blocknummern der virtu- eilen Controller VCl bis VCn auf physikalische Blöcke des angeschlossenen Massenspeichermediums FLSH abgebildet werden. Beispielsweise wird diese Abbildung, englisch: mapping, da- durch realisiert, dass zu den Startblocks SBl, SB2, SBn, welche als Offset dienen, die virtuelle Blocknummer hinzu addiert wird. Neben den reinen Blocknummern kann es wünschenswert sein, dass auch die Chipselect-Leitungen auf die virtu- eilen Controller VCl bis VCn abgebildet werden.
Während bei der dargestellten Form in der Abbildungstabelle physikalische Start- und Endblocks gespeichert sind, ist es auch möglich, neben den Startblocks SBl, SB2, SBn auch eine Partitionsgröße auf dem Massenspeichermedium FLSH in der Abbildungstabelle abzulegen, um die jeweils zulässige Größe beziehungsweise den zulässigen Zugriffsbereich für die virtuellen Controller definieren. In beiden Fällen ist es beispielsweise vorgesehen, dass der Master-Controller MCTRL bei einer Zugriffsanfrage der virtuellen Controller VCl bis VCn in
Richtung des Massenspeichermediums FLSH überprüft, ob der angeforderte Block innerhalb des durch die Einträge definierten Bereichs auf dem Massenspeichermedium liegt. Im Falle einer Bereichsverletzung, welche durch den Master-Controller MCTRL detektiert wird, kann beispielsweise eine Ausnahmemitteilung, englisch: exception, in Richtung des Prozessors CPU gesendet werden. Diese Ausnahmemitteilung ist beispielsweise ein Software-Interrupt, welcher dann von dem Master-Betriebssystem- Kern MBS verarbeitet wird.
Eine weitere wünschenswerte Information ist eine Information über das angeschlossene Massenspeichermedium. Dadurch kann der Master-Controller MCTRL erfahren, ob der physikalische Speicher beispielsweise über SDIO, MMC oder als reines NAND- Gerät angeschlossen ist. Diese Geräteinformation teilt dem
Master-Controller MCTRL auch mit, welche Chipselect-Leitungen verwendet werden sollen, um auf das Massenspeichermedium zuzugreifen und auf welche Weise eine Adressierung des angeschlossenen Massenspeichergeräts erfolgt.
In verschiedenen Ausführungsformen können auch mehrere Mas- senspeichermedien angeschlossen werden, wobei in diesem Fall vorzugsweise mehrere Master-Controller vorgesehen werden, die jeweils den physikalischen Zugriff auf ein angeschlossenes Mas senspeichermedium realisieren. Die Information über den Gerätetyp des jeweiligen Massenspeichermediums kann bei- spielsweise für eine Unterscheidung zwischen mehreren SD- Karten sinnvoll sein, die an speziellen SD-Karten-Controllern angeschlossen sind. Die verschiedenen definierten Bereiche für die Betriebssystemkerne BS1, BS2, BS3 können somit auf unterschiedlichen Massenspeichermedien abgelegt sein. Jedoch ist es vorzugsweise nicht vorgesehen, dass sich ein definierter Bereich über mehrere Massenspeichermedien erstreckt.
Eine Konfiguration des Massenspeichermediums FLSH durch den Master-Controller MCTRL erfolgt beispielsweise über die zuvor beschriebene Verbindung zwischen dem Master-Controller MCTRL und dem Master-Betriebssystem-Kern MBS. Diese Konfiguration wird vorzugsweise beim Starten des Master-Betriebssystem- Kerns vorgenommen, wobei die Konfigurationsdaten auch unmittelbar auf dem Massenspeichermedium FLSH, beispielsweise in einem Anfangsbereich beziehungsweise in den ersten Blocks des Massenspeichermediums FLSH abgelegt sind. Dabei ist der Master-Controller MCTRL vorzugsweise dazu eingerichtet, eine fehlerhafte Konfiguration, beispielsweise aufgrund von überlappenden Blockbereichen an den Master-Betriebssystem-Kern MBS beziehungsweise das Wirt-Betriebssystem H-OS mitzuteilen.
Jeder virtuelle Controller VC1 bis VCn ist vorzugsweise eine reale Hardwareinstanz mit eigenen Registern, die in separate SpeicherSeiten des physikalischen Adressbereichs des Prozes- sors CPU angebildet sind. Dadurch kann jeder virtuelle Controller zu einer separaten Partition für ein Gast-Betriebssystem zugewiesen werden, wobei Standard-Mechanismen des RechnerSystems verwendet werden, beispielsweise einer Speicherabbildungseinheit, englisch: memory mapping unit, MMU . Zusätzlich kann jeder virtuelle Controller VC1 bis VCn alle Register aufweisen, die notwendig sind um Lese- und Schreibzugriffe auf das virtuelle Gerät auszuführen, so dass sich jeder virtuelle Controller wie ein herkömmlicher Speichercontroller verhält. Ein Unterschied zu einem herkömmlichen SpeicherController liegt unter anderem in der Tatsache begründet, dass die tatsächliche Datenübertragung im physikali- sehen Sinn durch den Master-Controller MCTRL ausgeführt wird, der die Konfiguration und die Abbildungstabelle gegen die Übertragungs- beziehungsweise Zugriffsparameter prüft, bevor die Übertragung tatsächlich ausgeführt wird. Die Übertragungs- beziehungsweise Zugriffsparameter umfassen beispielsweise die Blocknummern, die Zahl von Blocks die gelesen oder geschrieben werden sollen oder Zugriffsberechtigungen. Dadurch verhalten sich die virtuellen Controller wie unabhängige Entitäten, welche Ausnahmemeldungen im Fall von Zugriffsverletzungen erzeugen. Nachdem der Master-Controller die Zugriffsparameter überprüft hat und somit der Zugriff innerhalb des definierten und erlaubten Bereichs liegt, wird die virtuelle Adresse des virtuellen Controllers in eine physikalische Adresse umgewandelt, welche in dem Massenspeicher- medium FLSH verwendet wird.
Figur 2 zeigt eine beispielhafte Aufteilung eines Massenspei- chermediums FLSH in mehrere definierte Bereiche, auf die über die virtuellen Controller zugegriffen werden kann. Hierbei ist in dem dargestellten Ausführungsbeispiel das Massenspei- chermedium FLSH in vier definierte Bereiche eingeteilt, welche durch physikalische Blocknummern PBN definiert sind. Beispielsweise geht der erste Bereich von einem physikalischen Block 0 bis zu einem physikalischen Block 1023, der zweite Bereich vom physikalischen Block 1024 bis zum physikalischen Block 33791, der dritte Bereich vom physikalischen Block 33792 bis zum physikalischen Block 66559, und der vierte Bereich vom physikalischen Block 66560 bis zum physikalischen Block 1048575. Der erste Bereich ist beispielsweise eine Par- tition für einen Bootloader bei einem Start des gesamten
RechnerSystems . Der zweite Bereich ist eine erste Betriebssystempartition, welche für das zugehörige Betriebssystem in eine interne System- und eine interne Datenpartition aufgeteilt ist. Die Zeile mit den internen Datenpartitionen ist mit INTP gekennzeichnet. Der dritte Bereich dient als Systempartition für eine zweite Betriebssystempartition und der vierte Bereich ist wiederum in eine Systempartition und eine Datenpartition als interne Datenpartitionen einer dritten Betriebssystempartition aufgeteilt. Für die jeweiligen Bereiche ergeben sich logische Blocknummern LBN, die jeweils bei 0 beginnen und für den ersten Bereich bei Block 1023, für den zweiten Bereich bei Block 32767, für den dritten Bereich bei Block 32767, und für den vierten Bereich bei Block 982015 endet .
Die einzelnen Bereiche können auch als Superpartitionen be- zeichnet werden. Dadurch sieht für jeden Betriebssystemkern die zugehörige Superpartition wie ein kompletter Massenspeicher aus . In diesem Bereich der Superpartition wird wiederum beispielsweise ein erster Block wie ein sogenannter Master- Boot-Record benutzt, was in ähnlicher Weise bei herkömmlichen PC-Systemen üblich ist. Beispielsweise wird in diesem Master- Boot-Record eine Partitionstabelle gespeichert, welche Informationen über die internen Partitionen INTP trägt.
Jeder Betriebssystemkern hat Zugriff auf seine zugehörige Su- perpartition und kann Zugriffsrechte auf die internen Partitionen INTP verwalten. Für die abhängig ausgeführten Betriebssystemkerne BS1, BS2, BS3 ist ein Zugriff auf eine interne Partition dennoch lediglich mit den Rechten möglich, welche ihm vom Master-Betriebssystem-Kern MBS zugewiesen wer- den. Dementsprechend kann ein Betriebssystemkern, der nur Lesezugriff auf die OS-Partition 2 hat, nur lesend auf den Speicher dieser Partition zugreifen. Dieser Betriebssystemkern kann dementsprechend auch keine eigenen Partitionen erzeugen oder Inhalte auf das Massenspeichermedium schreiben beziehungsweise schreiben lassen. In ähnlicher Weise kann es auch möglich sein, dass ein anderer Betriebssystemkern auf die Systempartition der OS-Partition 3 nur Lesezugriff auf, während auf die interne Datapartition der OS-Partition 3 Lese- und Schreibzugriffe möglich sind. Vorzugsweise wird jede Superpartition bei einem virtuellen Controller verwaltet. In verschiedenen Ausführungsformen ist es auch möglich, dass mehrere virtuelle Controller auf den gleichen physikalischen Bereich Zugriff haben, um einen physikalischen Bereich in gesicherter Weise auch mehreren Betriebssystemkernen zur Verfügung zu stellen. Beispielsweise wird hierbei für einen virtuellen Controller Schreib- und Lesezugriff auf die zugehörige Superpartition ermöglicht, während der oder die anderen virtuellen Controller lediglich Lesezugriffe auf diesen Bereich haben .
Ein Booten des Rechnersystems wird vorzugsweise immer von den ersten Blocks des angeschlossenen Massenspeichermediums FLSH durchgeführt. Nach einem Einschalten ist es wünschenswert, dass die Abbildungstabelle mit Nullen gefüllt wird, so dass alle virtuellen Controller den gesamten angeschlossenen Speicherbereich des Massenspeichermediums FLSH sehen. Dies ist in der Regel ohne Probleme möglich, da der Prozessor üblicherweise durch einen sogenannten Bootloader oder den Master- Betriebssystem-Kern mit einem sogenannten Bootstrapping-Pro- zess gestartet wird. Dieser Bootloader initialisiert vorzugsweise dann die Abbildungstabelle MTBL bevor die abhängig kon- trollierten Betriebssystemkerne BS1, BS2, BS3 gestartet werden .
Hierfür sind unterschiedliche Möglichkeiten vorgesehen. Beispielsweise ist es möglich, dass ein Initialisierungscode die Start- und Endblocks explizit in die Abbildungstabelle NTBL einschreibt. Weiter ist es möglich, dass die Abbildungstabelle durch einen speziellen Block in dem Massenspeichermedium FLSH initialisiert wird. Der Initialisierungscode sorgt vorzugsweise auch dafür, dass ein Zugriff auf den Master-Con- troller MCTRL auf den Master-Betriebssystem-Kern MBS beschränkt ist. Zusätzlich initialisiert der Initialisierungscode vorzugsweise grundlegende MMU-Tabellen, so dass die vir- tuellen Controller im entsprechenden Master-Betriebssystem- Kern beziehungsweise den Gast-Betriebssystem-Kernen BSl, BS2, BS3 zugewiesen werden können. In verschiedenen Ausführungsformen kann auch eine Interoperabilität mit einer Ein-/Ausgabe MMU vorgesehen werden, so dass zusätzlich Speicherbereichsidentifikationen, Übersetzungspuf- fer oder Verweise auf MMU-Übersetzungspuffer in ein Register des virtuellen Controllers geschrieben werden. Bei der Nut- zung einer Ein-/Ausgabe MMU sollte diese in der Lage sein, Unterbrechungsanforderungen der virtuellen Controller abzubilden und abzufangen. Der Master-Controller regt hierbei vorzugsweise die Unterbrechungsanforderungen für die virtuellen Controller an, für die eine zugrundeliegende Übertragung ausgeführt wurde. Die Ein-/Ausgabe MMU benötigt hierfür eine Zuordnung mit Speicherbereichen, zum Beispiel eine Gastpartition oder den Master-Betriebssystem-Kern, welche durch die Konfiguration der virtuellen Controller erzeugt wird, um DMA- Übertragungen zu überprüfen und Unterbrechungsanforderungen abzubilden. Dementsprechend ist es wünschenswert, dass die
Ein-/Ausgabe MMU ohne ein Abfangen von Unterbrechungsanforderungen von dem Master-Controller auf die virtuellen Controller auskommt. Selbst wenn ein Mas senspeichermedium lediglich als eine Partition benutzt wird, ist es ausreichend, dass die Ein-/Ausgabe MMU nur mit einem virtuellen Controller arbeitet. In diesem Fall ist es wünschenswert, dass dies der erste Controller ist, der eingerichtet ist für einen Zugriff auf alle Speicherbereiche des Massenspeichermediums . Weiterhin kann es wünschenswert sein, dass das RechnerSystem für eine Priorisierung von Zugriffen eingerichtet ist . Zugriffsprioritäten sind nicht zu vernachlässigende Merkmale für komplexe Systeme wie beispielsweise bei einem Unterhaltungssystem in einem Fahrzeug. Dies liegt darin begründet, dass üblicherweise Anforderungen gegeben sind, dass die letzte Benutzereinstellung innerhalb einer kurzen Zeit von beispielsweise 1 oder 2 Millisekunden abgespeichert wird, wenn ein Spannungsabfall und ein Abschalten des RechnerSystems droht oder eingeleitet ist. Während dieser Zeit sollte es garantiert werden, dass die vorhandenen Daten auf dem Massen- speichermedium abgelegt und physikalisch gespeichert sind. Um dies zu ermöglichen, sollte das RechnerSystem in der Lage sein, ein oder mehrere Blocks auf das Massenspeichermedium kurzfristig zu schreiben, und dadurch andere Anfragen anderer virtueller Controller zu überholen beziehungsweise sogar abzubrechen. Dies kann beispielsweise dadurch implementiert werden, dass für jeden virtuellen Controller eine Priorität zugewiesen wird. Als Standard kann beispielsweise eine Identifikation des virtuellen Controllers als eine initiale Priorität verwendet werden. In einer Weiterbildung ist es beispielsweise möglich, den virtuellen Controllern während eines Initialisierungsprozesses jeweilige Prioritäten zuzuweisen. Zusätzlich kann es möglich sein, dass der Speichercontroller CTL in einem Rundlaufverfahren (englisch: round robin) den Zugriff für virtuelle Controller mit gleicher Priorität regelt. Vorzugsweise weist der Master-Controller eine Liste auf, in der abzuarbeitende Übertragungen, also Speicher oder Lesevorgänge auf dem Massenspeichermedium, gespeichert und in eine Reihenfolge gebracht werden. Dafür kann es sinnvoll sein, dass dem Master- Controller ein spezieller Speicher oder Speicherbereiche aus vorhandenem Speicher zur Verfügung gestellt wird.
Eine weitere mögliche Eigenschaft des Rechnersystems ist die Bearbeitung von Ausnahmemeldungen, sogenannten exceptions. Vorzugsweise werden alle Ausnahmemeldungen in einen privilegierten Modus weitergeleitet. Der Master-Betriebssystem-Kern MBS sollte immer mit kompletten Privilegien gestartet werden, während die Gast-Betriebssysteme BS1, BS2, BS3 mit niedrigeren Privilegien arbeiten. Prozessoren, die die Virtualisie- rungen bei eingebetteten Systemen unterstützen sind unter anderem beispielsweise der ARM Cortex AI5 und der Intel Atom- Prozessor. Vorzugsweise werden Unterbrechungsanforderungen, mit denen Ausnahmemeldungen wie Zugriffsverletzungen berichtet werden, unmittelbar an den Master-Betriebssystem-Kern MBS weitergeleitet, ebenso für die Ein-/Ausgabe MMU. Der Master- Betriebssystem-Kern MBS kann dann einen entsprechenden Ver- teidigungsmechanismus auswählen, was sich von dem Ignorieren des Ereignisses bis zu einem Anhalten oder Neustart des Gast- Betriebssystems erstrecken kann. Vorzugsweise werden solche Ausnahmemeldungen an dem Master-Betriebssystem-Kern über den Master-Controller MCTRL weitergeleitet.
In verschiedenen Ausführungsformen ist es möglich, dass eine Konfiguration des Speichercontrollers CTL auch während des Betriebs des Rechnersystems durch den Master-Betriebssystem- Kern beziehungsweise das Wirt-Betriebssystem H-OS möglich ist. Dadurch werden Software-Aktualisierungsverfahren erleichtert. So ist es beispielsweise möglich, dass die privilegierte Partition des Massenspeichermediums die installierten Programme des Wirts-Betriebssystems H-OS beziehungsweise Master-Betriebssystem-Kerns MBS und der Gast-Betriebs system- Kerne BS1, BS2, BS3 aktualisiert. Während eines Aktualisierungsvorgangs werden die Gast-Betriebssystem-Kerne BS1, BS2, BS3 beispielsweise angehalten beziehungsweise in ihrer Ablaufkoordination angehalten, um WettlaufSituationen, englisch: race conditions, beim Zugriff auf das Dateisystem zu vermeiden.
In Abhängigkeit der verwendeten Technologie kann es notwendig sein, dass eine Nutzungsverteilung, englisch: wear leveling, durchgeführt wird, entweder realisiert als Software oder di- rekt implementiert in dem angeschlossenen Massenspeicherme- dium. Für den Fall, dass die Nutzungsverteilung direkt durch das Massenspeichermedium ausgeführt wird, können das Wirt- Betriebssystem H-OS und die Gast-Betriebssysteme BS1, BS2, BS3 auf eine Anwendung von Nutzungsverteilung verzichten und somit nicht direkt mit den physikalischen Blocks auf dem Massenspeichermedium, insbesondere einem Flashspeicher arbeiten. Vielmehr ist es ausreichend, dass die zuvor als physikalische Blocks bezeichneten Blocks wiederum als logische beziehungsweise virtuelle Blocks dienen, die direkt vom Massenspeicher- medium in die tatsächlichen physikalischen Blocks umgesetzt werden. Anders ausgedrückt wird eine zusätzliche logische Ebene von Blocks zwischen Speichercontroller CTL und Massen- speichermedium FLSH eingeführt.
Da bei der Nutzungsverteilung Blocks physikalisch verteilt auf dem Massenspeichermedium angeordnet werden, ist es not- wendig, dass gewährleistet wird, dass ein Block gelöscht wird bevor er einem neuen virtuellen Block zugeordnet ist, um mögliche Sicherheitslöcher zu verhindern. Wenn das Massenspeichermedium FLSH keinen eigenen Controller für die Durchführung der Nutzungsverteilung aufweist, ist es zweckmäßig, dass der Master-Betriebssystem-Kern MBS und die kontrolliert ausgeführten Betriebssystemkerne BS1, BS2, BS3 jeweils eigene Nutzungsverteilungsalgorithmen implementiert haben, was in Figur 1 durch die mit WL und NAND bezeichneten Blöcke dargestellt ist. Insbesondere in Verbindung mit der Anwendung von Zugriffsprioritäten, welche zuvor beschrieben wurde, sind die Anforderungen an eine Nutzungsverteilung zusätzlich erhöht. Dies liegt unter anderem darin begründet, dass beispielsweise bei einem gemanagten NAND-Speicher der entsprechende Controller mit der Nutzungsverteilung beschäftigt ist, während ein virtueller Controller des RechnerSystems eine Anforderung für ein Schreiben eines Blocks mit hoher Priorität abschickt. Um in diesem Fall zu garantieren, dass beispielsweise die letzten Benutzermodusdaten geschrieben werden können, kann es notwendig sein, einen zweiten Massenspeicher mit einem unter- schiedlichen Chipselect anzuschließen, so dass Transaktionen mit hoher Priorität unabhängig von internen Abläufen in dem gemanagten NAND-Speicher abgearbeitet werden können.
Ein weiterer Punkt ist ein optimierter Zugriff auf das Mas- senspeichermedium . Die Ein-/Ausgabebandbreite eines Zugriffs auf einen Flash-Speicher hängt im Wesentlichen von einer internen Organisation in einem Chip des Flash-Speichers ab. Beispielsweise ist ein effizienter Zugriff bei einem Hersteller dadurch implementiert, dass gerade und ungerade Blocknummern abwechselnd genutzt werden, während bei einem anderen Hersteller die erste und die zweite Hälfte von Blocknummern abwechselnd genutzt werden. Dies hängt jeweils im Wesentlichen davon ab, welche Adressen zur Auswahl einer logischen Einheit verwendet werden.
Ein auslassender Zugriff kann beispielsweise dadurch program- miert werden, dass Lese-, Schreib- oder Löschkommandos in eine Reihenfolge gebracht werden. Durch das in Reihenfolge bringen der Anforderungen in einer Weise, die am vorteilhaftesten für das verwendete Hardwaregerät ist, können Adressierungszeiten minimiert werden, wodurch sich deutlich höhere Durchsatzraten erreichen lassen.
Für ein gutes Laufzeitverhalten des Systems ist es vorteilhaft, wenn eine Optimierung von solchen Zugriffen möglich bleibt. Für einen vollen Durchsatz kann es notwendig sein, mehr als einen Adressbereich pro virtuellen Controller zu haben, insbesondere wegen der zuvor beschriebenen Auslassungsschemata für den Zugriff. Um dies zu erreichen ist es vorteilhaft, einen separaten, programmierbaren Prozessor als SpeicherController vorzusehen, um eine Adressüberprüfung, ei- ne Umsetzung, eine Nutzungsverteilung und einen optimierten
Zugriff zu erreichen. Ein solcher Prozessor für den Speichercontroller kann auch als DMA-Master zur Übertragung von Speicher auf die zugewiesenen Speicherblöcke der Betriebssystem- Kerne MBS, BS1, BS2, BS3 zu erreichen. Ein Controller-Prozes- sor kann beispielsweise wiederum selbst von einem angeschlossenen Massenspeichermedium, insbesondere einem Flash-Speicher initialisiert werden.
Die Schaffung sicherer Flash-Partitionierung hängt nicht nur von der Umsetzung virtueller Controller ab. Da der Speicherzugriff auf den Flash-Speicher von dem DMA-Betrieb profitiert, kann es auch notwendig sein, die DMA-Übertragungen ab- zusichern. Beispielsweise geschieht dies über eine Ein-/Aus- gabe MMU, welche sicherstellt, dass ein Gast-Betriebssystem BS1, BS2, BS3 oder ein virtueller Controller nur dann eine tatsächliche Speicherübertragung ausführt, wenn ausreichende Zugriffsrechte vorliegen. Im Fall einer Zugriffsverletzung kann die Ein-/Ausgabe MMU eine Ausnahmemeldung, beispielsweise eine Unterbrechungsanforderung an den Master-Betriebssystem-Kern MBS auslösen, so dass der Master-Betriebssystem-Kern MBS den Fehler durch Deaktivierung oder Neustart des Gast- Betriebssystem-Kerns behebt, welches den Fehler ausgelöst hat .
Figur 3 zeigt eine mögliche Anwendung für das zuvor beschriebene Prinzip anhand einer beispielhaften schematischen Dar- Stellung eines RechnerSystems 100. Bei der dargestellten Ausführungsform sind auf dem Massenspeichermedium FLSH beispielhaft drei Partitionen beziehungsweise Massenspeicher MSI, MS2, MS3 eingerichtet. Auf dem Prozessor CPU läuft der Master-Betriebssystem-Kern MBS, welcher zwei separat betreibbare Betriebssystem-Kerne BS1, BS2 kontrolliert.
Der linke Betriebssystemkern BS2 dient zum Ausführen eines herkömmlichen Betriebssystems, welches die Verwendung von Internetanwendungen für einen Webbrowser, herunterladbaren An- Wendungen und Multimedia-Funktionalität ermöglicht. Der Betriebssystemkern BS2 ist vorzugsweise gesichert, wobei es nicht notwendig ist, dass eine erhöhte Zuverlässigkeit bereitgestellt wird. Betriebssystemdateien, Anwendungen, Bibliotheksdateien und Konfigurationsdateien sind für den zwei- ten Betriebssystemkern BS2 mit dem zweiten Massenspeicher MS2 abgelegt. Dazu weist der zweite Massenspeicher MS2 beispielsweise Speicherplatz für Systemdateien BIN, ausführbare Dateien EXE und Konfigurationsdateien CNF auf. Durch den Master- Betriebssystem-Kern MBS beziehungsweise den hier nicht darge- stellten Speichercontroller CTL wird sichergestellt, dass der zweite Betriebssystemkern BS2 auf den zweiten Massenspeicher MS2 lediglich einen Lesezugriff, aber keinen Schreibzugriff besitzt, gekennzeichnet durch ein RO (read only) . Benutzerdaten wie Musikdateien MP3, Bilddateien JPG oder andere Internetformate HTML sind auf dem dritten Massenspeicher MS3 angelegt, auf den der zweite Betriebssystemkern BS2 sowohl Lese- als auch Schreibzugriff besitzt. Dies ist durch die Bezeichnung RW (read-write) gekennzeichnet.
Der rechte Betriebssystemkern BS1 dient zur Ausführung eines sicheren Betriebssystems, unter dem ein Softwareverwaltungs- programm läuft. Ferner können unter dem ersten Betriebssystemkern BS1 auch ein Virenscanner und/oder bestimmte Sicherheitsrichtlinien implementiert sein. Ein Zugriff auf den ersten Betriebssystemkern ist vorzugsweise lediglich zu Wartungszwecken vorgesehen, so dass insbesondere keine unsiche- ren Multimedia-Anwendungen oder dergleichen ausgeführt werden können. Der erste Betriebssystemkern BS1 hat Schreibzugriff und Lesezugriff auf den ersten und den zweiten Massenspeicher MSI, MS2. Auf den ersten Massenspeicher MSI sind eine Datenbank für eine Softwareverwaltung SW-DB, Sicherheitszertifika- te ZERT und ein Virenscanner VS gespeichert. Betriebs system- dateien, Anwendungen, Bibliotheksdateien und Konfigurationsdateien sind für den ersten Betriebssystemkern BS1 entweder ebenfalls auf dem zweiten Massenspeicher MS2 oder vorzugsweise auf dem ersten Massenspeicher MSI abgelegt. Der zweite Be- triebssystemkern BS2 hat keinerlei Zugriff auf den ersten
Massenspeicher MSI und hat vorzugsweise auch keine Kenntnis von der Existenz dieses Massenspeichers MSI. Der Zugriff auf das Massenspeichermedium FLSH beziehungsweise die Massenspeicher MSI, MS2, MS3 ist durch den Master-Betriebssystem-Kern MBS beziehungsweise den Speichercontroller CTL kontrolliert.
Für eine Softwareaktualisierung des zweiten Betriebssystemkerns dient dementsprechend der erste Betriebssystemkern BS1, welcher auf Basis der Datenbank für die Softwareverwaltung eine Aktualisierung der Systemdateien in Anwendungen auf dem zweiten Massenspeicher MS2 durchführt. Dazu hat der erste Betriebssystemkern BS1 über einen separaten virtuellen Control- ler Zugriff auf den zweiten Massenspeicher MS2. Insbesondere greifen zwei separate virtuelle Controller gleichzeitig auf den zweiten Massenspeicher MS2 zu, während der virtuelle Controller den zweiten Betriebssystemkern BS2 lediglich einen Lesezugriff zulässt, während der virtuelle Controller für den ersten Betriebssystemkern BSl auch einen Schreibzugriff ermöglicht. Der Zugriff des zweiten Betriebssystemkerns BS2 auf den Massenspeicher des ersten Betriebssystemkerns BSl ist aber verhindert .
Die dargestellte Ausführungsform des RechnerSystems ermöglicht es, dass selbst bei einer Kompromittierung des zweiten Betriebs systemkerns BS2 durch ein Schadprogramm die Veränderung von Systemdateien und damit die gezielte Öffnung von weiteren Sicherheitslücken ausgehend vom zweiten Betriebssystemkern BS2 verhindert werden kann. Durch die Internetfähigkeit und Multimedia-Fähigkeit des zweiten Betriebssystemkerns besteht nämlich grundsätzlich die Gefahr, dass durch unerkannte oder neu auftretende Sicherheitslücken im System Schadprogramme in den Bereich des zweiten Betriebssystemkerns eingebracht werden können, welche jedoch aufgrund der mangelnden Schreibberechtigung nicht zu einer dauerhaften Veränderung des Betriebssystems unter dem zweiten Betriebssystemkern BS2 führen können. Dies bewirkt, dass Schadprogramme nicht in dem RechnerSystem verbleiben können, wenn das System aus- und wieder eingeschaltet wird.
Das RechnerSystem 100 ist insbesondere für einen Betrieb in einem Kraftfahrzeug eingerichtet. Beispielsweise ist das RechnerSystem 100 als eingebettetes System ausgeführt. Jedoch kann das Rechnersystem 100 auch in anderen Umgebungen, wie z.B. bei Mobiltelefonen, die beispielsweise mit dem Android- Betriebs System betrieben werden, eingesetzt werden.

Claims

RechnerSystem (100) mit wenigstens einem Prozessor (CPU) und einem Speichercontroller (CTL) für ein nichtflüchtiges Massenspeichermedium (FLSH), wobei
- das RechnerSystem eingerichtet ist, auf dem Prozessor (CPU) einen Master-Betriebssystem-Kern (MBS) sowie einen ersten und wenigstens einen zweiten Betriebssystemkern (BS1, BS2) unter Kontrolle des Master- Betriebssystem-Kerns (MBS) auszuführen;
- der Speichercontroller (CTL) eingerichtet ist, dem Master-Betriebssystem-Kern (MBS) definierte Bereiche eines Massenspeichermediums (FLSH) als einen ersten und wenigstens einen zweiten Massenspeicher zur Verfügung zu stellen, die jeweils voneinander unabhängig sind, und eine Abbildung des ersten und des wenigstens einen zweiten Massenspeichers auf die definierten Bereiche des Massenspeichermediums (FLSH) zu steuern und
- der Master-Betriebssystem-Kern (MBS) eingerichtet ist, dem ersten und dem wenigstens einen zweiten Betriebssystemkern (BS1, BS2) exklusiven Zugriff auf jeweils zumindest einen der zur Verfügung gestellten Massenspeicher zu ermöglichen.
RechnerSystem (100) nach Anspruch 1, bei dem der Speichercontroller (CTL) eine Abbildungstabelle (MTBL) aufweist, in der für jeden zur Verfügung gestellten Massenspeicher eine Abbildungsvorschrift auf die zugehörigen definierten Bereiche des Massenspeichermediums (FLSH) gespeichert ist.
RechnerSystem (100) nach Anspruch 2, bei dem die definierten Bereiche des Massenspeichermediums (FLSH) durch Partitionen auf dem Massenspeichermedium (FLSH) gebildet sind, und bei dem die gespeicherten Abbildungsvorschriften Informationen über eine Position und Größe der Partitionen umfassen. RechnerSystem (100) nach Anspruch 2 oder 3, bei dem die gespeicherten Abbildungsvorschriften Informationen über eine Hardware-Identifikationsnummer der Massenspeicher umfas sen .
RechnerSystem (100) nach einem der Ansprüche 1 bis 4, bei dem der Speichercontroller (CTL) einen Master-Controller (MCTRL) aufweist, der eingerichtet ist, einen Hardwarezugriff auf die definierten Bereiche zu steuern.
RechnerSystem (100) nach Anspruch 5, bei dem der Master- Controller (MCTRL) eingerichtet ist, eine jeweilige Zugriffsberechtigung auf die definierten Bereiche zu prüfen .
RechnerSystem (100) nach einem der Ansprüche 1 bis 6, bei dem der Speichercontroller (CTL) einen ersten und wenigstens einen zweiten virtuellen Controller (VC1, VC2, VCn) aufweist, die jeweils einen der Massenspeicher zur Verfügung stellen und jeweils ein Register aufweisen, das in einen Speicherbereich des Master-Betriebssystem-Kerns (MBS) abgebildet ist.
RechnerSystem (100) nach einem der Ansprüche 1 bis 7, bei dem der Speichercontroller (CTL) eingerichtet ist, einen Zugriff auf die definierten Bereiche des Massenspeichermediums (FLSH) anhand vorgegebener Prioritäten zu steuern .
RechnerSystem (100) nach einem der Ansprüche 1 bis 8, bei dem der Speichercontroller (CTL) eingerichtet ist, eine Nutzungsverteilung des Massenspeichermediums (FLSH) zu steuern .
RechnerSystem (100) nach einem der Ansprüche 1 bis 9, ferner umfassend das Massenspeichermedium (FLSH) .
PCT/EP2013/051390 2012-01-27 2013-01-25 Speichercontroller zur bereitstellung mehrerer definierter bereiche eines massenspeichermediums als unabhängige massenspeicher an einen master-betriebssystem - kern zur exklusiven bereitstellung an virutelle maschinen WO2013110736A1 (de)

Priority Applications (3)

Application Number Priority Date Filing Date Title
US14/372,415 US10055361B2 (en) 2012-01-27 2013-01-25 Memory controller for providing a plurality of defined areas of a mass storage medium as independent mass memories to a master operating system core for exclusive provision to virtual machines
CN201380006822.4A CN104081349B (zh) 2012-01-27 2013-01-25 计算机系统
EP13702764.5A EP2807558B1 (de) 2012-01-27 2013-01-25 Speichercontroller zur bereitstellung mehrerer definierter bereiche eines massenspeichermediums als unabhängige massenspeicher an einen master-betriebssystem-kern zur exklusiven bereitstellung an virutelle maschinen

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
DE102012201225A DE102012201225A1 (de) 2012-01-27 2012-01-27 Rechnersystem
DE102012201225.7 2012-01-27

Publications (1)

Publication Number Publication Date
WO2013110736A1 true WO2013110736A1 (de) 2013-08-01

Family

ID=47666102

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/EP2013/051390 WO2013110736A1 (de) 2012-01-27 2013-01-25 Speichercontroller zur bereitstellung mehrerer definierter bereiche eines massenspeichermediums als unabhängige massenspeicher an einen master-betriebssystem - kern zur exklusiven bereitstellung an virutelle maschinen

Country Status (5)

Country Link
US (1) US10055361B2 (de)
EP (1) EP2807558B1 (de)
CN (1) CN104081349B (de)
DE (1) DE102012201225A1 (de)
WO (1) WO2013110736A1 (de)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE102013226700A1 (de) 2013-12-19 2015-06-25 Continental Automotive Gmbh Fahrzeugelektronikeinheit

Families Citing this family (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9342243B2 (en) * 2012-11-28 2016-05-17 Lenovo (Beijing) Co., Ltd. Method and electronic apparatus for implementing multi-operating system
CN104572488B (zh) * 2015-02-13 2017-11-17 西安酷派软件科技有限公司 内存管理方法、内存管理装置和终端
GB2539429B (en) 2015-06-16 2017-09-06 Advanced Risc Mach Ltd Address translation
GB2539435B8 (en) 2015-06-16 2018-02-21 Advanced Risc Mach Ltd Data processing memory access control, in which an owning process for a region of memory is specified independently of privilege level
GB2539436B (en) * 2015-06-16 2019-02-06 Advanced Risc Mach Ltd Secure initialisation
GB2539428B (en) 2015-06-16 2020-09-09 Advanced Risc Mach Ltd Data processing apparatus and method with ownership table
GB2539433B8 (en) 2015-06-16 2018-02-21 Advanced Risc Mach Ltd Protected exception handling
US9769131B1 (en) 2016-08-02 2017-09-19 Architecture Technology Corporation Fast reconfiguring environment for mobile computing devices
CN108763099B (zh) * 2018-04-18 2020-05-08 华为技术有限公司 系统的启动方法、装置、电子设备和存储介质
EP4060487A1 (de) * 2021-03-17 2022-09-21 Aptiv Technologies Limited Elektronische steuereinheit, fahrzeug mit der elektronischen steuereinheit und computerimplementiertes verfahren
CN113688026B (zh) * 2021-09-30 2024-04-05 中汽创智科技有限公司 一种数据模拟仿真方法、装置、设备及存储介质
CN116909937B (zh) * 2023-05-11 2024-02-23 深圳三地一芯电子股份有限公司 闪存容量优化方法、装置、设备及存储介质

Family Cites Families (13)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20020144010A1 (en) * 2000-05-09 2002-10-03 Honeywell International Inc. Communication handling in integrated modular avionics
US7649880B2 (en) * 2002-11-12 2010-01-19 Mark Adams Systems and methods for deriving storage area commands
US7203944B1 (en) * 2003-07-09 2007-04-10 Veritas Operating Corporation Migrating virtual machines among computer systems to balance load caused by virtual machines
US20060075199A1 (en) 2004-10-06 2006-04-06 Mahesh Kallahalla Method of providing storage to virtual computer cluster within shared computing environment
US8341624B1 (en) * 2006-09-28 2012-12-25 Teradici Corporation Scheduling a virtual machine resource based on quality prediction of encoded transmission of images generated by the virtual machine
US20070050767A1 (en) * 2005-08-31 2007-03-01 Grobman Steven L Method, apparatus and system for a virtual diskless client architecture
US8195866B2 (en) 2007-04-26 2012-06-05 Vmware, Inc. Adjusting available persistent storage during execution in a virtual computer system
JPWO2009110111A1 (ja) * 2008-03-04 2011-07-14 三菱電機株式会社 サーバ装置及びサーバ装置の異常検知方法及びサーバ装置の異常検知プログラム
US20100083247A1 (en) * 2008-09-26 2010-04-01 Netapp, Inc. System And Method Of Providing Multiple Virtual Machines With Shared Access To Non-Volatile Solid-State Memory Using RDMA
US8103847B2 (en) 2009-04-08 2012-01-24 Microsoft Corporation Storage virtual containers
CN102231138B (zh) * 2011-07-08 2013-07-03 上海交通大学 计算机内存数据准确采集系统及获取方法
CN102306126B (zh) * 2011-08-24 2014-06-04 华为技术有限公司 内存管理方法、装置和系统
US9342291B1 (en) * 2012-11-14 2016-05-17 Amazon Technologies, Inc. Distributed update service

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
INNOTEK GMBH: "innotek VirtualBox User Manual, Version 1.5.6", 19 February 2008 (2008-02-19), pages 1 - 182, XP055059670, Retrieved from the Internet <URL:http://downloads.bosslinux.in/VIRTUALIZATION/UserManual.pdf> [retrieved on 20130415] *

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE102013226700A1 (de) 2013-12-19 2015-06-25 Continental Automotive Gmbh Fahrzeugelektronikeinheit

Also Published As

Publication number Publication date
CN104081349A (zh) 2014-10-01
US10055361B2 (en) 2018-08-21
CN104081349B (zh) 2019-01-15
DE102012201225A1 (de) 2013-08-01
EP2807558B1 (de) 2020-09-02
EP2807558A1 (de) 2014-12-03
US20150006795A1 (en) 2015-01-01

Similar Documents

Publication Publication Date Title
EP2807558B1 (de) Speichercontroller zur bereitstellung mehrerer definierter bereiche eines massenspeichermediums als unabhängige massenspeicher an einen master-betriebssystem-kern zur exklusiven bereitstellung an virutelle maschinen
DE102006061939B4 (de) Verfahren und Vorrichtung zum Zugriff auf eine speicherabgebildete Vorrichtung durch einen Gast
DE112005002298B4 (de) Leistungssteigerung einer Adreßübersetzung unter Verwendung von Übersetzungstabellen, die große Adreßräume umfassen
DE102011076894B4 (de) Persistenter Speicher für einen Hauptspeicher eines Prozessors
DE112005002304B4 (de) Adreßumsetzung für Eingabe/Ausgabe- Vorrichtungen mittels hierarchischer Umsetzungstabellen
DE102013022405B3 (de) Schutz globaler Register in einem Multithreaded-Prozessor
DE102019110023A1 (de) System mit programmierbarer Multi-Kontext-Beschleuniger-Schaltung
DE102005022893B3 (de) Verfahren zum Zugreifen auf Speicherbereiche einer Speicherkarte durch eine anfordernde Anwendung und Speicherkarte
DE202010017667U1 (de) Datenspeichervorrichtung mit Flash-Speicherchips
DE112007001988T5 (de) Gemeinsames Nutzen von Informationen durch Gäste in einer Virtuelle-Maschine-Umgebung
DE112010005821T5 (de) Kontextwechsel
DE102015002191A1 (de) Sicherheits-Hypervisor-Funktion
DE112017003332T5 (de) Öffnungszugriffsprozessoren, verfahren, systeme und befehle
DE102016220639A1 (de) Speicherschutzeinheit und Verfahren zum Schützen eines Speicheradressraumes
DE102019117794A1 (de) Speichervorrichtungen, die heterogene Prozessoren umfassen, welche sich Speicher teilen, und Verfahren zu deren Betrieb
DE102015107654A1 (de) Dienst und System zum Unterstützen eines kohärenten Datenzugriffs auf einem Multicore-Controller
DE112019002336T5 (de) Speicherpoolzuordnung für ein mehrkern-system
EP2698678A2 (de) Konfigurationstechnik für ein Steuergerät mit miteinander kommunizierenden Anwendungen
DE112016007538T5 (de) Technologie zur realisierung eines binärverzweigten non-volatile-memory-express-treibers
DE112011100854T5 (de) Schnelle Datenfernübertragung und Fernberechnung zwischen Prozessoren
EP2793196A2 (de) Tachograph und On-Board-Einheit für ein Nutzkraftfahrzeug
DE102015210539A1 (de) Speicherschutzeinheit, Speicherverwaltungseinheit und Mikrocontroller
DE102021127304A1 (de) Host-firewall-schnittstellen für steuerungen
DE102015114721A1 (de) Verfahren, Gerät und System zur Datenverarbeitung
DE102018001565A1 (de) Sicherheitselement und Verfahren zur Zugriffskontrolle auf ein Sicherheitselement

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 13702764

Country of ref document: EP

Kind code of ref document: A1

WWE Wipo information: entry into national phase

Ref document number: 2013702764

Country of ref document: EP

WWE Wipo information: entry into national phase

Ref document number: 14372415

Country of ref document: US

NENP Non-entry into the national phase

Ref country code: DE