Interface reverse calling method, system starting method and electronic equipment
By encapsulating API interfaces in the MCU embedded system and utilizing shared memory areas and independent code segment verification mechanisms, the black screen problem during startup and the security challenges of calling upper-layer customer code from the underlying firmware are solved, achieving flexible and secure system startup.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2025-11-20
- Publication Date
- 2026-03-27
AI Technical Summary
In MCU embedded systems, black screen issues often occur during startup, affecting user experience. Furthermore, the underlying firmware cannot directly call upper-layer customer code, making it difficult and insecure to implement customized functions.
The function to be called is encapsulated as an API interface in the control layer, stored in the reverse exit table and saved to the shared storage area. When the loading layer starts, the API interface is read from the shared storage area and called. The security and integrity of the call are ensured through independent code segment verification and shared storage area synchronization mechanism.
Customized functions of the control layer can be called without modifying the startup loading layer code, avoiding black screen issues, reducing storage pressure and ensuring call security, thus improving the flexibility and security of system startup.
Smart Images
Figure CN121742908A_ABST
Abstract
Description
TECHNICAL FIELD
[0001] The present application relates to the field of embedded technology, in particular to an interface reverse calling method, a system starting method and an electronic device. BACKGROUND
[0002] In the MCU (Microcontroller Unit) embedded system, the problem of black screen often occurs in the starting process, which affects the use of users. SUMMARY
[0003] The technical problem solved by the present application is to provide an interface reverse calling method, a system starting method and an electronic device, which can solve the problem of black screen during starting through interface reverse calling.
[0004] In order to solve the above technical problems, one technical solution adopted by the present application is: An interface reverse calling method applied to an electronic device, the method comprising: In the control layer, encapsulating a function to be called as an API interface, storing data of the API interface to a reverse exit table, and storing the reverse exit table to a shared storage area; In the starting loading layer, when the starting loading layer starts, reading the reverse exit table from the shared storage area, and calling the API interface in the reverse exit table.
[0005] In order to solve the above technical problems, another technical solution adopted by the present application is: A system starting method applied to an electronic device, the electronic device comprising a starting loading layer, a control layer and a user application layer, comprising: When the starting loading layer is executed, calling the API interface obtained by the above-mentioned interface reverse calling method; Executing the control layer and the user application layer in sequence.
[0006] In order to solve the above technical problems, another technical solution adopted by the present application is: An electronic device comprising a memory, a processor and a computer program stored in the memory and running on the processor, wherein the processor implements each step of the above-mentioned interface reverse calling method when executing the computer program.
[0007] The beneficial effect of the present application is that: the function to be called is packaged as an API interface in the control layer, the data of the API interface is stored to the reverse exit table, and the reverse exit table is stored to the shared storage area; the reverse exit table is read from the shared storage area when the start loading layer is started, and the API interface in the reverse exit table is called. In this way, the start loading layer can call the customized API interface in the control layer without modifying the code of the start loading layer, avoiding display problems caused by the fact that the control layer has not been loaded when the start loading layer is executed, and relieving the storage pressure of the start loading layer. BRIEF DESCRIPTION OF DRAWINGS
[0008] Figure 1 A step flowchart of an interface reverse calling method provided by an embodiment of the present application is provided. Figure 2 A verification step flowchart of an interface reverse calling method provided by an embodiment of the present application is provided. Figure 3 A structure diagram of an embedded system provided by an embodiment of the present application is provided. Figure 4 A structure diagram of a system applied by an embodiment of the present application is provided. Figure 5 A structure diagram of an electronic device provided by an embodiment of the present application is provided. DETAILED DESCRIPTION
[0009] In order to make the technical problems to be solved by the present application, the technical solutions and beneficial effects clearer, the present application will be further described in detail below with reference to the drawings and embodiments. It should be understood that the specific embodiments described herein are only used to explain the present application, and are not used to limit the present application.
[0010] In the following description, specific details are set forth in order to provide a thorough understanding of embodiments of the application. However, persons of ordinary skill in the art will appreciate that embodiments of the application can be practiced without the specific details, other embodiments, and in other ways. In other instances, well-known systems, devices, circuits, and methods have not been described in detail so as not to unnecessarily obscure aspects of the application.
[0011] It should be understood that when used in the specification and the appended claims, the term "comprising" indicates the presence of the described features, integers, steps, operations, elements, and / or components, but does not exclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and / or groups thereof.
[0012] Reference within the specification of this application to "one embodiment" or "some embodiments" means that a particular feature, structure, or characteristic described in connection with the embodiment is included in at least one embodiment of the application. The appearances of the phrase "in one embodiment" or "in some embodiments" in various places within specified
[0013] In the related art, the OpenCPU architecture becomes an innovative architecture in the field of embedded systems and Internet of Things due to its ability to support customers to directly develop and secondarily develop applications on a device master chip. The architecture includes a chip manufacturer layer, a module manufacturer layer, and a customer application layer. The chip manufacturer layer provides basic firmware, including multi-level Bootloader (such as first-level BootROM and second-level secure Boot) and master driving firmware, and is usually closed source. The module manufacturer layer performs secondary packaging and integration based on the firmware of the chip manufacturer to form a module firmware, which can include its own Bootloader or enhanced master logic, and this layer can also be partially closed source. The customer application layer implements the business logic of the customer on the OpenCPU environment provided by the module, and this layer also usually adopts a hierarchical design, such as a customer BOOT layer, a customer control layer CTRL, and an application layer.
[0014] However, the underlying firmware provided by the chip manufacturer and the module manufacturer is usually closed source, and the customer cannot directly modify the code thereof. The upper-layer customer has a strong need to reverse drive the behavior of the underlying layer. Typical scenarios include: displaying a customer-customized startup logo (the logo format and content can frequently change) in the Bootloader stage of the chip manufacturer; the underlying firmware needs to call a customized processing function (such as special log recording or a specific recovery process) provided by the upper layer when a specific event (such as low voltage or a specific error code) occurs; and the underlying firmware needs to use a complex algorithm or protocol processing function implemented by the upper layer.
[0015] Therefore, in the related art, the space of the underlying firmware is extremely limited and cannot accommodate complex customized functions; and each time the customer's customized requirements change, such as changing the logo picture format, the chip manufacturer or module manufacturer needs to modify the underlying firmware and re-release, which is a cumbersome process, slow response and high cost. Moreover, when the underlying firmware is running, the customer control layer is usually not initialized, and the control layer memory state is unknown and uncontrollable. Therefore, the underlying firmware cannot trust the function pointer provided by the control layer whether it is valid, and the code pointed to is complete or tampered with, and malicious or incorrect customer code can cause the underlying firmware to crash, damaging system security startup.
[0016] The application provides an interface reverse calling method, a system startup method and an electronic device to solve the above problems. The interface reverse calling method of the application is introduced below.
[0017] The interface reverse calling method in the application can be used in the MCU application scenario with extremely limited Flash resources. The electronic device of the application can be a financial-related electronic device, such as a POS machine, a cash register, a key distribution device, etc.
[0018] The interface reverse calling method in the application is introduced below, and the accompanying drawings are referred to. Figure 1 , including steps 110 to 120.
[0019] Step 110, in the control layer, encapsulate the function to be called as an API interface, store the data of the API interface to the reverse exit table, and store the reverse exit table to the shared storage area.
[0020] The control layer is a customer control layer, and the API interface is an interface of the control layer. These interfaces can be provided to the startup loading layer for calling, that is, the functions in the control layer that need to be called by the startup loading layer are encapsulated into API that meets the security constraints, and the data of the API interface is stored in the reverse exit table. The structure of the reverse exit table includes magic number, version number, API quantity and function pointer.
[0021] The shared storage area is a pre-divided shared storage area (SHARED_REVERSE_API_REGION) with an absolute address known to the startup loading layer. The operation of storing to the shared storage area is performed after the control layer is started and confirmed to run normally each time, to ensure that the data of the shared storage area is consistent with the current code version of the control layer.
[0022] Step 120, in the startup loading layer, when the startup loading layer starts, read the reverse exit table from the shared storage area, and call the API interface in the reverse exit table.
[0023] The startup loading layer is a vendor Bootloader. In the startup process, when the function of the control layer needs to be called, the vendor Bootloader first accesses the address of a fixed shared storage region (SHARED_REVERSE_API_REGION), reads the reverse exit table stored therein, and then safely calls the API interface function specified in the reverse exit table after checking the reverse exit table, so as to realize the customized function of the control layer in the vendor Bootloader calling stage. In addition, the startup loading layer and the control layer are executed in sequence when the system starts.
[0024] As can be seen from the above embodiment, the method encapsulates the function that needs to be called by the startup loading layer into an API interface, stores the data of the API interface into a reverse exit table, and stores the reverse exit table into a shared storage region with a pre-divided absolute address known by the startup loading layer. The reverse exit table is read from the shared storage region when the startup loading layer starts, and the API interface in the reverse exit table is called. In this way, the startup loading layer can call the customized API interface provided by the control layer without modifying the code of the startup loading layer, avoids display problems caused by the fact that the control layer has not been loaded when the startup loading layer is executed, and also relieves the storage pressure of the startup loading layer and avoids complex functions in the bottom layer.
[0025] In an embodiment of the present application, reference is made to the accompanying drawings Figure 2 The step of storing the reverse exit table into the shared storage region in step 110 includes steps 111 to 112.
[0026] In step 111, the reverse exit table and the API interface are linked to a separate code segment of the flash memory, and the separate code segment is checked to obtain a first check value.
[0027] Specifically, the code containing the reverse exit table and all API functions pointed to by the reverse exit table, and all bottom layer functions directly dependent on the API, are linked to a separate, continuous flash memory independent code segment using a compilation and linking technology (such as a linking script.ld file), so as to ensure that the code segment is self-contained and can be independently run. The compiler / linker generates accurate information of the independent segment: the start address (rev_code_start), the end address (rev_code_end), and the length (rev_code_size). The independent code segment is checked to obtain a first check value.
[0028] In step 112, the address of the reverse exit table, the start address and the end address of the independent code segment, and the first check value thereof are taken as metadata, and the metadata is written into the shared storage region.
[0029] Specifically, the reverse export table base address, the independent code segment information and the calculated first check value are written into a shared storage region (SHARED_REVERSE_API_REGION) of a pre-divided absolute address known at the bottom layer in the Flash. The operation is performed after the control layer is started each time and it is confirmed that the control layer runs normally, ensuring that the data of the shared storage region is consistent with the current code version thereof.
[0030] As can be seen from the above embodiment, the reverse export table and the API interface are linked to the independent code segment of the Flash, the independent code segment is checked to obtain a first check value, and the address of the reverse export table, the start address and the end address of the independent code segment and the first check value thereof are written into the shared storage region as metadata. In this way, through the independent code segment checking, it is ensured that the code called by the subsequent start loading layer is not tampered, and the shared storage region synchronization mechanism can ensure that the subsequent start loading layer obtains the metadata confirmed to be valid and correct in version by the control layer.
[0031] In an embodiment of the present application, the checking of the independent code segment in step 111 to obtain the first check value includes step 1111.
[0032] Step 1111, the content integrity of the independent code segment is checked according to the start address and the end address of the independent code segment of the Flash using a pre-designed calculation method to obtain the first check value.
[0033] Specifically, the customer control layer performs integrity calculation from the start address to the end address of the independent code segment when running, for example, in the initialization stage, and the integrity calculation is a calculation method such as CRC32 or secure Hash algorithm SHA-256, and the first check value rev_code_checksum is calculated.
[0034] As can be seen from the above embodiment, the content integrity of the independent code segment is checked according to the start address and the end address thereof, and the first check value is obtained, which can ensure the reliability of the data in the independent code segment.
[0035] In an embodiment of the present application, referring to the accompanying drawings Figure 2 Step 120 includes steps 121 to 122.
[0036] Step 121, when the start loading layer is started, the metadata is read from the shared storage region, and the current content of the independent code segment in the Flash is checked for integrity according to the start address and the end address of the independent code segment using a pre-designed calculation method to obtain a second check value.
[0037] Specifically, the vendor Bootloader, in the booting process, when it needs to call the upper layer function (such as before displaying the logo), first accesses the fixed SHARED_REVERSE_API_REGION address, reads the metadata stored therein, and uses the same algorithm, such as the same CRC32 or SHA-256, to calculate the code segment data from the start address to the end address of the independent code segment in the flash memory, to obtain a second check value current_checksum.
[0038] Step 122, judging whether to call the API interface of the reverse exit table corresponding to the address of the reverse exit table in the metadata according to the comparison result of the first check value and the second check value.
[0039] Specifically, the calculated current_checksum is strictly compared with the rev_code_checksum read from the shared storage area, and whether to call the API interface of the reverse exit table corresponding to the address of the reverse exit table in the metadata is determined according to the comparison result.
[0040] As can be seen from the above embodiment, for the particularity that the boot loading layer calls the control layer but the control layer has not been initialized at this time in the reverse calling process, the reverse exit table in the control layer is linked to the independent code segment in advance, the code segment check value is calculated, and the check value and the independent code segment information are stored to the shared storage area. Then, the current check value is calculated according to the independent code segment information in the shared storage area when the boot loading layer starts, and is compared with the code segment check value. According to the comparison result, it can be judged whether the API data of the customer control layer is tampered and the content is complete, that is, the "independent code segment linking + shared area metadata synchronization and verification" mechanism is introduced to build the reverse calling bridge.
[0041] In an embodiment of the present application, step 122 includes steps 1221 to 1222.
[0042] Step 1221, in the boot loading layer, when the first check value and the second check value are successfully compared, the API interface of the reverse exit table corresponding to the address of the reverse exit table in the metadata is called.
[0043] Step 1222, in the boot loading layer, when the first check value and the second check value fail to compare, the API interface of the control layer is stopped.
[0044] Specifically, when the client updates its control layer code (including reverse APIs or dependencies) and starts for the first time, the data in the shared memory area is old or invalid (corresponding to the code before the update). After the client control layer completes its own initialization and verifies that it is running normally, it performs the above-mentioned "calculate the check value" and "write to the shared memory area" operations to synchronize the independent segment information and the check value corresponding to the new code version to the shared memory area. During this startup, if the vendor Bootloader is triggered to call before the client control layer completes synchronization (such as displaying the logo immediately after the system is reset), it will read the old, invalid shared memory area data, resulting in a check failure, thereby safely skipping the call.
[0045] As can be seen from the above embodiment, a successful check value comparison indicates that the independent code segment has not been tampered with since the last client control layer synchronization, and its content is complete and valid. At this time, the vendor Bootloader can trust the reverse export table pointed to by the address of the reverse export table. A failed check value comparison indicates that the code segment is damaged, not synchronized (such as the client control layer running for the first time or not restarting after updating), or maliciously modified, at which time the vendor Bootloader needs to give up calling the upper-layer API and execute a safe backup process, such as skipping the logo display or displaying default information.
[0046] The next time the system starts (or enters the Bootloader again after this reset), the vendor Bootloader reads the valid shared memory area data synchronized by the client CTRL, passes the check, and can successfully call the new version of the API. This ensures that the modification takes effect, and the mechanism is secure.
[0047] In an embodiment of the present application, the reverse export table includes a magic number, a version field, an API interface quantity, and an API interface pointer, and steps 1221 are followed by steps 1223 to 1227.
[0048] Step 1223, verify whether the magic number of the reverse export table matches a preset value, to obtain a first verification result.
[0049] Step 1224, verify whether the version field of the reverse export table is a preset compatible version, to obtain a second verification result.
[0050] Step 1225, verify whether the API interface quantity of the reverse export table is within a preset interface quantity range, to obtain a third verification result.
[0051] Step 1226, perform validity checking on the API interface pointer of the reverse export table, to obtain a fourth verification result.
[0052] Step 1227, when the first verification result, the second verification result, the third verification result and the fourth verification result are all verified, the address of the reverse export table in the metadata is called to correspond to the API interface of the reverse export table.
[0053] Specifically, the vendor Bootloader accesses the reverse export table structure through the address of the reverse export table, and performs a reliability check thereon, verifying the magic number, version compatibility, API quantity validity and API interface pointer validity in sequence. After the check, the vendor Bootloader can safely call the API function (such as display_logo_func()) specified in the export table to realize the required control layer customization function. Since the API and its dependent code are located in the verified independent segment, and the API itself complies with strict security constraints, the call at this time is safe.
[0054] In an embodiment of the present application, the API interface in step 110 needs to meet interface constraint conditions, and the interface constraint conditions include interface parameter passing constraints, interface calling constraints, interface context constraints and interface dependency constraints. The interface parameter passing constraints are that the API does not use global variables or static local variables, the API explicitly passes the transmission state information through function parameters, the API function internally uses local variables on the stack and the passed-in parameters; The interface calling constraints are that the API function is prohibited from calling heap memory management functions; The interface context constraints are that the API function calls other functions that also meet the interface parameter passing constraints and the interface calling constraints; The interface dependency constraints are that the API function does not call operating system related services.
[0055] This embodiment is to ensure that the called control layer API does not depend on the control layer state when called in the startup loading layer environment, and these APIs must strictly comply with the following constraints: (1) Stateless: The API function cannot use any global variables or static local variables. All the state information required for operation must be explicitly passed through function parameters. Only local variables on the stack (automatic variables) and the passed-in parameters should be used inside the function.
[0056] (2) No Dynamic Memory: The API function is prohibited from calling malloc, calloc, realloc, free and other heap memory management functions. The working buffer required by the API should be passed in by the caller (the startup loading layer) through the parameter.
[0057] (3) Context-Independent / Pure Functions: API functions can only call other functions that are also stateless and do not have dynamic memory constraints. Pure functions in the standard library that do not depend on global state and are thread-safe (in this context, stateless) are allowed, such as memcpy, memset, basic mathematical operations (sin, cos need to be confirmed whether their implementation is stateless), etc. Library functions that depend on errno, internal buffers, or static state (such as some implementations of strtok) are prohibited.
[0058] (4) Not dependent on specific OS / RTOS: API functions cannot call any operating system-related services (such as task creation, semaphores, queues, timers specific to the OS) because the OS environment running in the startup loader layer is independent of the control layer.
[0059] The present application can apply the above-mentioned scheme to a resource-constrained microcontroller unit (MCU) platform, and realize a method for the startup loader layer (bottom layer) to safely and reliably call custom function APIs of the customer control layer (upper layer) in a layered heterogeneous execution environment (especially the bottom layer of the chip / module manufacturer firmware layer and the upper layer of the customer application layer developed, compiled, stored, and executed independently in time sequence). The present application is particularly suitable for communication modules, Internet of Things devices, and other scenarios that use OpenCPU architecture, and solves the flexibility and security challenges when the bottom layer of the closed-source firmware and the upper layer of the custom application interact deeply.
[0060] Please refer to Figure 3 Another embodiment of the present application provides a system startup method for an electronic device, the electronic device including a startup loader layer 301, a control layer 302, and a user application layer 303, the method including steps 310 to 320.
[0061] Step 310: When executing the startup loader layer, call the API interface obtained by the above-mentioned interface reverse calling method.
[0062] Step 320: Execute the control layer and the user application layer in sequence.
[0063] Specifically, the manufacturer's startup loading layer 301, the customer's control layer 302 and the user application layer 303 are executed in sequence during system startup, that is, the manufacturer's startup loading layer is executed first after the system is powered on or reset, and the API interface obtained by the above-mentioned interface reverse calling method is called during execution of the startup loading layer to realize interface reverse calling during startup. The user application layer usually shares the same runtime environment as the control layer, such as the same SRAM space, stack, peripheral access permission, and the life cycle of the user application layer is managed by the control layer, such as being started as a thread; the user application layer can implement specific business logic and functions, which depend on the services provided by the control layer. In this way, repeated definition and redundant code of the same API interface in the startup loading layer and the control layer are avoided, thereby effectively reducing hardware cost.
[0064] Please refer to Figure 4 , the application embodiments of the present application will be specifically introduced below, a kind of interface reverse calling method, for electronic equipment, electronic equipment includes manufacturer Bootloader401 (equivalent to Figure 3 The startup loading layer of the manufacturer), customer BOOT402, customer CTRL403 (equivalent to Figure 3 The control layer of the customer) and customer APP404 (equivalent to Figure 3 The user application layer of the customer), wherein customer BOOT402, customer CTRL403 and customer APP404 belong to upper customer code, and the method comprises steps 410 to 420.
[0065] Step 410, in customer CTRL, the function of displaying pictures is packaged as an API interface, and the function of displaying pictures can be the function of displaying logo, supporting multiple formats of pictures, such as BMP, JPG, PNG, etc. The data of the API interface is stored to the reverse export table, and the reverse export table and the API interface are linked to the independent code segment, and the integrity of the independent code segment is checked to obtain the check value rev_code_checksum. Equivalent to step 111.
[0066] Wherein, a separate shared area needs to be separately drawn to fix the address of the reverse export table, the start address and end address of the independent code segment and the check value rev_code_checksum in the shared area. Equivalent to step 112.
[0067] Step 420, in the manufacturer Bootloader, the information in the shared area is obtained by linking to perform integrity check on the current content of the independent code segment, to obtain the check value current_checksum. It is equivalent to the above-mentioned step 121. Further, whether to call the API interface of the reverse exit table is judged by comparing the check value rev_code_checksum and the check value current_checksum. It is equivalent to the above-mentioned step 122.
[0068] Compared with the method of the customer CTRL forward multiplexing the customer BOOT, the forward multiplexing is that the upper layer (customer CTRL) calls the lower layer (customer BOOT) code, and the reverse call of the application embodiment is that the lower layer (manufacturer Bootloader) calls the upper layer (customer CTRL) code. Since the program runs from the lower layer to the upper layer, the normal flow usually has firmware code to verify the integrity and security, and the reverse call cannot normally trigger the firmware code to verify the integrity and security, so the first step of the reverse call needs to verify the integrity of the firmware code of the upper layer in the lower layer. That is, the check is the main difference between the forward multiplexing and the reverse call. Similarly, in the forward multiplexing, the upper layer can be loaded through the lower layer, and the exit table is passed through the register or the absolute address; and the reverse call of the application embodiment needs to fix the API address provided by the upper layer for the lower layer to use to the shared area by drawing a separate shared area, and needs to obtain the shared area where the start address, size and check value of the upper layer code to be called by the lower layer through the linking means.
[0069] It can be seen that, in the existing scheme, since the logo and the like are configured in the customer BOOT, the time of running the manufacturer code after booting is black screen, and the logo appears in the customer BOOT, and in the embodiment, part of the content of the customer BOOT is referenced to be advanced, so that the booting has the logo.
[0070] Please refer to Figure 5 The application further provides an electronic device 500, comprising a memory 501, a processor 502, and a computer program stored in the memory 501 and running on the processor 502, and the processor 502 implements each step of the above-mentioned interface reverse call method when executing the computer program.
[0071] The electronic device of the application has the same advantages as the above-mentioned method, which will not be repeated here.
[0072] Another embodiment of the application provides a system for implementing the above-mentioned method, comprising an upper layer customer application system 601, a lower layer firmware system 602, a pre-defined shared storage area 603 and a compilation tool chain 604.
[0073] Specifically, the upper client application system (such as a client control layer) includes: a reverse API function module for implementing a called function conforming to a security constraint; a reverse export table module for defining and instantiating a struct ctrl_reverse_export_table; a link control module for configuring a compilation tool chain (a link script) to forcibly link the reverse export table and related APIs to an independent continuous segment (.reverse_api_section); a code segment information management module for obtaining an independent code segment physical address range (rev_code_start, rev_code_end, rev_code_size) at runtime; a check calculation module for calculating a check value (rev_code_checksum) of the independent code segment; a shared region synchronization module for writing the export table address, code segment information, and check value to a known shared storage region SHARED_REVERSE_API_REGION at an appropriate time (such as when the module itself is successfully initialized and the shared region data is expired).
[0074] Specifically, the underlying firmware system (such as a vendor Bootloader) includes: a shared region access module for reading metadata in the SHARED_REVERSE_API_REGION; a code segment check module for performing check calculation on a specified Flash range (rev_code_start to rev_code_end) using the same algorithm as the upper layer; a metadata verification module for comparing the calculated check value with the read rev_code_checksum; a reverse export table access module for locating and accessing the export table structure after the check passes; a reliability check module for verifying the export table magic number, version, and API quantity; a secure call module for executing the verified reverse API function pointer; a secure backup processing module for processing cases of check failure or reliability check failure.
[0075] Specifically, the predefined shared storage region (SHARED_REVERSE_API_REGION) is located in a fixed physical address known to both the underlying Bootloader and the upper CTRL in the Flash, the size of the shared storage region is sufficient to store the metadata structure (export table address, code segment start and end address / size, check value, etc.), and is reserved during the system design phase and is usually not erased by the regular program.
[0076] Specifically, the compilation tool chain supports link script customization, which can realize accurate link positioning of independent code segments.
[0077] In summary, the interface reverse calling method, system starting method and electronic device provided by the application enable the closed-source starting loading layer firmware to safely call the customized functions of the open-source customer control layer, meet the deep customization needs (such as displaying the customer logo in the Boot phase), do not need to modify the code of the vendor starting loading layer, thereby breaking through the closed-source limitation; and the customer can independently update the customized functions (such as replacing the logo picture or processing logic) in the control layer, which are automatically adapted by the starting loading layer firmware, greatly shortening the customization period and reducing the cooperation cost, thereby improving the flexibility and response speed. Through the independent code segment integrity check, it is ensured that the code called by the starting loading layer is not tampered with and is complete and effective, the shared storage region synchronization mechanism is used to ensure that the starting loading layer obtains the metadata confirmed by the control layer to be effective, the strict API security constraints (stateless, no heap, etc.) can prevent the calling from damaging the starting loading layer environment, the reliability check (magic number, version) can prevent the access to invalid or compatible export tables, and the safety backup mechanism upon check failure can prevent system crashes, in this way, the system safety is ensured. At the same time, the application implements the complex functions (such as picture decoding) in the control layer with relatively abundant resources, reuses the code, avoids occupying the extremely limited underlying (such as Bootloader) storage space, avoids using position-independent code (PIC), and reduces the complexity of writing the control layer driving code.
[0078] The above is only an embodiment of the application, and does not limit the patent scope of the application, and any equivalent transformation or direct or indirect application in the related technical field based on the content of the specification and drawings of the application is also included in the patent protection scope of the application.
Claims
1. An interface reverse call method, characterized in that, The method is applied to an electronic device and comprises: In a control layer, encapsulating a function to be invoked as an API interface, storing data of the API interface to a reverse exit table, and storing the reverse exit table to a shared storage area; In a startup loading layer, when the startup loading layer starts, reading the reverse exit table from the shared storage area, and invoking the API interface in the reverse exit table.
2. The interface reverse calling method according to claim 1, characterized in that, Storing the reverse exit table to the shared storage area comprises: Linking the reverse exit table and the API interface to a separate code segment of the flash memory, verifying the separate code segment to obtain a first verification value; Storing an address of the reverse exit table, the separate code segment, and the first verification value of the separate code segment as metadata, and writing the metadata to the shared storage area.
3. The interface reverse calling method according to claim 2, characterized in that, The separate code segment comprises a start address and an end address; The verifying the separate code segment to obtain the first verification value comprises: Using a pre-designed calculation method to perform integrity verification on content of the separate code segment according to the start address and the end address of the separate code segment of the flash memory to obtain the first verification value.
4. The interface reverse calling method according to claim 3, characterized in that, When the startup loading layer starts, reading the metadata from the shared storage area, and using the pre-designed calculation method to perform integrity verification on current content of the separate code segment according to the start address and the end address of the separate code segment in the flash memory to obtain a second verification value; According to a comparison result of the first verification value and the second verification value, determining whether to invoke the API interface of the reverse exit table corresponding to the address of the reverse exit table in the metadata. According to a comparison result of the first verification value and the second verification value, determining whether to invoke the API interface of the reverse exit table corresponding to the address of the reverse exit table in the metadata comprises:
5. The interface reverse calling method according to claim 4, characterized in that, In the startup loading layer, when the first verification value and the second verification value are successfully compared, invoking the API interface of the reverse exit table corresponding to the address of the reverse exit table in the metadata. According to a comparison result of the first verification value and the second verification value, determining whether to invoke the API interface of the reverse exit table corresponding to the address of the reverse exit table in the metadata comprises:
6. The interface reverse calling method according to claim 4, characterized in that, In the startup loading layer, when the first verification value and the second verification value fail to be compared, stopping invoking the API interface of the control layer. The reverse exit table comprises a magic number, a version field, an API interface quantity, and an API interface pointer; 7. The interface reverse calling method according to claim 5, characterized in that, The invoking the API interface of the reverse exit table corresponding to the address of the reverse exit table in the metadata comprises: Verifying whether the magic number of the reverse exit table matches a preset value to obtain a first verification result; Verifying whether the version field of the reverse exit table is a preset compatible version to obtain a second verification result; Verifying whether the API interface quantity of the reverse exit table is within a preset interface quantity range to obtain a third verification result; Performing validity checking on the API interface pointer of the reverse exit table to obtain a fourth verification result; and When the first verification result, the second verification result, the third verification result, and the fourth verification result are all correct, invoking the API interface of the reverse exit table corresponding to the address of the reverse exit table in the metadata. When the first verification result, the second verification result, the third verification result and the fourth verification result are all verified, an API interface of a reverse exit table corresponding to an address of the reverse exit table in the metadata is called.
8. The interface reverse calling method according to claim 1, characterized in that, The API interface satisfies an interface constraint condition, and the interface constraint condition includes an interface parameter passing constraint, an interface calling constraint, an interface context constraint and an interface dependency constraint. The interface parameter passing constraint is that the API does not use a global variable or a static local variable, the API explicitly passes transmission state information through a function parameter, the API function internally uses a local variable on a stack and an incoming parameter; The interface calling constraint is that the API function is prohibited from calling a heap memory management function; The interface context constraint is that the API function calls other functions also satisfying the interface parameter passing constraint and the interface calling constraint; The interface dependency constraint is that the API function does not call a service related to an operating system.
9. A system booting method for an electronic device, the method comprising: The electronic device includes a startup loading layer, a control layer and a user application layer, and includes: When the startup loading layer is executed, the API interface obtained by the interface reverse calling method in any one of claims 1 to 8 is called; The control layer and the user application layer are executed in sequence.
10. An electronic device comprising a memory, a processor, and a computer program stored on the memory and running on the processor, characterized in that, The processor executes the computer program to implement each step in the interface reverse calling method in any one of claims 1 to 8.