Mirror image starting method and device, medium and electronic equipment

Abstract

The invention provides a mirror image starting method and device, a medium and electronic equipment. The mirror image starting method comprises the steps that an IU request message sent by a host to a switch is received, and fields of the IU message comprise a destination MAC address, a source MAC address, the Ethernet type of an IU, the length of an IU part of the IU request message, whether the request IU message needs to be responded or not, a switch identifier, the type of sent switch, an error number, the type of the IU message, IU message data and an IU response identifier; the IU response identifier is an IU request type or an IU response type; sending an IU response message to the host based on the IU request message, wherein the IU response message comprises switch information; and based on the IU request message and the IU response message, starting an executable mirror image loaded to a memory. According to the method, the switch can only maintain one mirror image code, and independent development and maintenance for different hosts are not needed. In addition, the cpu applied in the switch can access the register more quickly.

Description

Technical Field

[0001] This disclosure pertains to the field of switching chips and relates to image booting methods, particularly to image booting methods, apparatus, media, and electronic devices. Background Technology

[0002] Generally, dumb switches without flash memory cannot load software after startup and can only perform simple register access. When the switch chip has flash memory, the software image can be loaded by accessing the switch from an external SoC (System-on-a-Chip) via SMI (Serial Management Interface). However, when there are multiple switches under the central control unit, each switch requires its own flash memory, resulting in high costs. In addition, this method of external SoC accessing the switch via SMI to load the software image is inefficient. Summary of the Invention

[0003] The purpose of this disclosure is to provide a method, apparatus, medium, and electronic device for booting from an image, in order to solve the problem of low efficiency in existing image booting methods where an external SoC accesses a switch via SMI to load a software image.

[0004] In a first aspect, embodiments of this disclosure provide an image booting method, comprising: receiving an IU (Image Upgrade) request message sent by a host (client) to a switch, wherein the fields of the IU message include: a destination MAC (Media Access Control) address, a source MAC address, an Ethernet type of the IU, the length of the IU portion of the IU request message, whether a response is required for the request IU message, a switch identifier, the type of the sending switch, an error number, an IU message type, IU message data, and an IU response identifier, wherein the IU response identifier is an IU request type or an IU response type; sending an IU response message to the host based on the IU request message, wherein the IU response message includes switch information; and booting an executable image loaded into memory based on the IU request message and the IU response message, wherein the IU request message includes information about the executable image.

[0005] In one embodiment of this disclosure, the method for sending an IU response message to the host based on the IU request message includes: the IU request message includes: an image upgrade discovery request message, an image upgrade security module handshake request message, an image upgrade security module data request message, an image upgrade configuration handshake request message, an image upgrade configuration data request message, an image upgrade software handshake request message, and an image upgrade software data request message; sending an image upgrade discovery response message to the host based on the image upgrade discovery request message; sending an image upgrade software handshake response message to the host based on the image upgrade security module handshake request message; sending an image upgrade security module data response message to the host based on the image upgrade security module data request message; sending an image upgrade configuration handshake response message to the host based on the image upgrade configuration handshake request message; sending an image upgrade configuration data response message to the host based on the image upgrade configuration data request message; sending an image upgrade software handshake response message to the host based on the image upgrade software handshake request message; and sending an image upgrade software data response message to the host based on the image upgrade software data request message.

[0006] In one embodiment of this disclosure, the method for launching an executable image loaded into memory based on the IU request message and the IU response message includes: when the switch When efuse is in insecure boot mode: The system obtains the first hash value of the security module based on the security module; obtains the second hash value of the security module based on the security module data; compares the first hash value and the second hash value of the security module to obtain a first comparison result. If the first comparison result is that the hashes are different, the insecure boot fails. Otherwise: The system obtains the first hash value of the configuration image based on the configuration image; obtains the second hash value of the configuration image based on the security module data; compares the first hash value and the second hash value of the configuration image to obtain a second comparison result. If the second comparison result is that the hashes are different, the insecure boot fails. Otherwise: The system obtains the first hash value of the software image based on the software image; obtains the second hash value of the software image based on the security module data; compares the first hash value and the second hash value of the software image to obtain a third comparison result. If the third comparison result is that the hashes are different, the insecure boot fails. Otherwise, the system jumps to the memory loading address of the software image and starts the software image.

[0007] In one embodiment of this disclosure, the method for launching an executable image loaded into memory based on the IU request message and the IU response message includes: when the switch efuse is in secure boot mode: obtaining the hash value of the public key in the security module based on the security module data; and comparing the hash value of the public key in the security module with the switch efuse data. The system compares the hash value of the public key corresponding to efuse to obtain a fourth comparison result. If the fourth comparison result is different, the secure startup fails. Otherwise: Based on the public key and digital signature in the security module, the security module is verified to obtain a verification result. If the verification result is that the verification fails, the secure startup fails. Otherwise: Based on the configuration image, the system obtains the third hash value of the configuration image; based on the security module data, the system obtains the fourth hash value of the configuration image; the system compares the third hash value and the fourth hash value of the configuration image to obtain a fifth comparison result. If the fifth comparison result is that the hashes are different, the secure startup fails. Otherwise: Based on the software image, the system obtains the third hash value of the software image; based on the security module data, the system obtains the fourth hash value of the software image; the system compares the third hash value and the fourth hash value of the software image to obtain a sixth comparison result. If the sixth comparison result is that the hashes are different, the secure startup fails. Otherwise, the system jumps to the memory loading address of the software image and starts the software image.

[0008] In one embodiment of this disclosure, the method for sending an image upgrade discovery response message to the host based on the image upgrade discovery request message includes: filling the original image upgrade discovery response message with the switch model, whether the switch requires secure boot, the switch state, the flash information of the current switch, the boot partition of the current program, the logical block start address of the primary flash partition in the switch, the size of the primary flash partition in the switch, the logical block start address of the secondary flash partition in the flash, and the size of the secondary flash partition in the flash, to obtain the image upgrade discovery response message; and sending the image upgrade discovery response message to the host.

[0009] In one embodiment of this disclosure, the method for sending an IU response message to the host based on the IU request message includes: the IU request message is a unicast IU request message or a multicast IU request message; when the IU request message is a unicast IU request message, if the destination address in the IU request message matches the switch, then the IU request message is processed based on the switch identifier in the IU request message; otherwise, the IU request message is forwarded based on a Layer 2 forwarding table; when the IU request message is a multicast IU request message, if the switch identifier in the IU request message is equal to the identifier of the switch or the switch identifier in the IU request message is 0xF, then the IU request message is processed, and a unicast IU response message is sent to the host and the IU request message is forwarded based on a multicast forwarding table; otherwise, the IU request message is directly forwarded based on the multicast forwarding table, where 0xF indicates forwarding to all switching chips.

[0010] In one embodiment of this disclosure, the method for processing the IU request message based on the switch identifier in the IU request message includes: if the switch identifier in the IU request message is equal to the identifier of the switch or the switch identifier in the IU request message is 0xF, then the IU request message is processed and a unicast IU response message is sent to the host; otherwise, the IU request message is discarded.

[0011] Secondly, embodiments of this disclosure provide an image booting apparatus, comprising: a message receiving module, configured to receive an IU request message sent by a host to a switch, wherein the fields of the IU message include: destination MAC address, source MAC address, Ethernet type of the IU, length of the IU portion of the IU request message, whether the request IU message requires a response, switch identifier, type of the sending switch, error number, IU message type, IU message data, and IU response identifier, wherein the IU response identifier is an IU request type or an IU response type; a message response module, configured to send an IU response message to the host based on the IU request message, wherein the IU response message includes switch information; and an image execution module, configured to start an executable image loaded into memory based on the IU request message and the IU response message, wherein the IU request message includes information about the executable image.

[0012] Thirdly, embodiments of this disclosure provide a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the image boot method described in the first aspect.

[0013] Fourthly, embodiments of this disclosure provide an electronic device, including: a memory; and a processor coupled to the memory and configured to perform the image booting method described in the first aspect.

[0014] As described above, the image booting method, apparatus, medium, and electronic device described in this application have the following beneficial effects:

[0015] In the image startup method described above, by starting the executable image loaded into memory based on the IU request message, the switch only needs to maintain one copy of the image code, eliminating the need to develop and maintain separate versions for each client's different hosts. Furthermore, it allows for faster CPU register access within the switch. Attached Figure Description

[0016] Figure 1 The diagram shown illustrates how the controller loads an executable image onto a dumb switch via a network in an embodiment of this disclosure.

[0017] Figure 2 The flowchart shown is a process for image startup method according to an embodiment of this disclosure.

[0018] Figure 3 The flowchart shown is a method for sending an IU response message to the host based on the IU request message in an embodiment of this disclosure.

[0019] Figure 4 The flowchart shown is an implementation method for launching an executable image loaded into memory based on the IU request message and the IU response message according to an embodiment of this disclosure.

[0020] Figure 5 The flowchart shown is an implementation method for launching an executable image loaded into memory based on the IU request message and the IU response message according to an embodiment of this disclosure.

[0021] Figure 6 The diagram shown illustrates how the controller downloads the image to the dumb switch via IU messages in an embodiment of this disclosure.

[0022] Figure 7 The diagram shows the network startup time of an embodiment of this disclosure.

[0023] Figure 8 The diagram shown is a schematic representation of the mirror startup device according to an embodiment of this disclosure.

[0024] Figure 9 The diagram shown is a structural schematic of an electronic device according to an embodiment of this disclosure. Detailed Implementation

[0025] The following specific examples illustrate the implementation of this disclosure. Those skilled in the art can easily understand other advantages and effects of this disclosure from the content disclosed in this specification. This disclosure can also be implemented or applied through other different specific embodiments, and various details in this specification can also be modified or changed based on different viewpoints and applications without departing from the spirit of this disclosure. It should be noted that, unless otherwise specified, the following embodiments and features in the embodiments can be combined with each other.

[0026] It should be noted that the illustrations provided in the following embodiments are only schematic representations of the basic concept of this disclosure. Therefore, the illustrations only show the components related to this disclosure and are not drawn according to the number, shape and size of the components in actual implementation. In actual implementation, the form, quantity and proportion of each component can be arbitrarily changed, and the layout of the components may also be more complex.

[0027] The technical solutions of the present disclosure will be described in detail below with reference to the accompanying drawings.

[0028] The following will describe in detail the principles and implementation methods of the image boot method and image boot device of this disclosure, so that those skilled in the art can understand the image boot method and image boot device of this disclosure without creative effort.

[0029] The image boot method provided in this application can run in a switch chip. Figure 1 For example, Figure 1 This is a schematic diagram of the network environment for running the image boot method. Network environment 100 includes various electronic devices 102, 104, 106, such as one or more servers, computers, data storage devices, network components, network devices, etc. In one or more embodiments, network environment 100 includes a large network of a group of servers, server repositories, storage area networks, and / or interconnected computers or network devices. In one or more embodiments, network environment 100 includes one or more other devices, such as one or more mobile devices, tablet devices, set-top box (STB) devices, storage devices, desktop computers, routers, switches, bridges, or any other machine or device.

[0030] One or more network devices (e.g., switch device 110) may be implemented in network environment 100 to facilitate communication between one or more electronic devices 102, 104, 106. The electronic devices 102, 104, 106 of network environment 100 are connected to each other or otherwise communicate with each other via or using switch device 110. For example, electronic devices 102, 104, 106 may each be coupled to one or more physical ports of switch device 110 via network transmission lines (e.g., Ethernet transmission lines, coaxial transmission lines, optical transmission lines, fiber optic channels, or generally any transmission line). In one or more embodiments, one or more of electronic devices 102, 104, 106 are wirelessly coupled to switch device 110.

[0031] Switching device 110 may include several integrated circuits or chips referred to as switch chips. Switch chips may be mounted on a common substrate and / or one or more switch chips may be mounted on a separate substrate, such as a separate line card. Each switch chip is coupled to one or more ports of switching device 110 and processes data units transmitted through the port and / or received at the port. For purposes of explanation, a data unit may be primarily referred to herein as a unit, such as a portion of a packet; however, a data unit may be a packet, protocol data unit (PDU), data block, or generally any describable data unit. To facilitate the processing of data units, each switch chip may include one or more ingress processors, egress processors, and / or memory management units (MMUs).

[0032] Figure 2 This is a flowchart illustrating a mirror boot method according to an embodiment of the present disclosure. For example... Figure 2 As shown, this embodiment provides an image boot method, which can be executed via a switch statement. The image boot method includes:

[0033] Step S11: Receive the IU request message sent by the host to the switch. The fields of the IU message include: destination MAC address, source MAC address, Ethernet type of IU, length of the IU part of the IU request message, whether the request IU message needs a response, switch identifier, type of the sending switch, error number, IU message type, IU message data, and IU response identifier. The IU response identifier is either the IU request type or the IU response type.

[0034] Optionally, the IU message type may include image upgrade discovery message type, image upgrade security module handshake message type, and image upgrade software data message type. The IU request message may include multiple message types, including: image upgrade discovery request message, image upgrade security module handshake request message, image upgrade security module data request message, image upgrade configuration handshake request message, image upgrade configuration data request message, image upgrade software handshake request message, and image upgrade software data request message. The switch identifier is the switch device identifier, which can be represented by Switch device ID.

[0035] Step S12: Send an IU response message to the host based on the IU request message, wherein the IU response message includes switch information.

[0036] Optionally, the switch information may include the switch model, whether the switch requires secure boot, switch status, flash information of the current switch, boot partition of the current program, logical block start address of the primary flash partition in the switch, size of the primary flash partition in the switch, logical block start address of the secondary flash partition in the flash, and size of the secondary flash partition, etc.

[0037] Optionally, the method for sending an IU response message to the host based on the IU request message includes: the IU request message is a unicast IU request message or a multicast IU request message; when the IU request message is a unicast IU request message, if the destination address in the IU request message matches the switch, then the IU request message is processed based on the switch identifier in the IU request message; otherwise, the IU request message is forwarded based on the Layer 2 forwarding table; when the IU request message is a multicast IU request message, if the switch identifier in the IU request message is equal to the identifier of the switch or the switch identifier in the IU request message is 0xF, then the IU request message is processed, and a unicast IU response message is sent to the host and the IU request message is forwarded based on the multicast forwarding table; otherwise, the IU request message is directly forwarded based on the multicast forwarding table, where 0xF indicates forwarding to all switching chips.

[0038] Optionally, the method for processing the IU request message based on the switch identifier in the IU request message includes: if the switch identifier in the IU request message is equal to the identifier of the switch or the switch identifier in the IU request message is 0xF, then the IU request message is processed and a unicast IU response message is sent to the host; otherwise, the IU request message is discarded.

[0039] Step S13: Based on the IU request message and the IU response message, start the executable image loaded into memory, wherein the IU request message includes information about the executable image.

[0040] As described above, the image startup method includes: receiving an IU request message sent by the host to the switch, wherein the fields of the IU request message include: destination MAC address, source MAC address, Ethernet type of the IU, length of the IU portion of the IU request message, whether the request IU message requires a response, switch identifier, type of the sending switch, error number, IU message type, IU message data, and IU response identifier, wherein the IU response identifier is either an IU request type or an IU response type; sending an IU response message to the host based on the IU request message, wherein the IU response message includes switch information; and starting an executable image loaded into memory based on the IU request message and the IU response message, wherein the IU request message includes information about the executable image.

[0041] In the image startup method, by starting the executable image loaded into memory based on the IU request message and the IU response message, the switch only needs to maintain one copy of the image code, eliminating the need to develop and maintain separate code for each client's different host. Furthermore, CPU access to registers within the switch can be faster.

[0042] Figure 3 This is a flowchart illustrating a method for sending an IU response message to the host based on the IU request message, according to an embodiment of this disclosure. Figure 3 As shown, this embodiment provides a method for sending an IU response message to the host based on the IU request message, including:

[0043] Step S21: Send an image upgrade discovery response message to the host based on the image upgrade discovery request message.

[0044] Optionally, the switch model, whether the switch requires Secure Boot, switch status, current switch flash information, current program boot partition, logical block start address of the primary flash partition in the switch, size of the primary flash partition in the switch, logical block start address of the secondary flash partition, and size of the secondary flash partition are filled into the original image upgrade discovery response message to obtain the image upgrade discovery response message; and the image upgrade discovery response message is sent to the host.

[0045] Step S22: Based on the image upgrade security module handshake request message, send an image upgrade software handshake response message to the host.

[0046] Step S23: Send an image upgrade security module data response message to the host based on the image upgrade security module data request message.

[0047] Step S24: Send an image upgrade configuration handshake response message to the host based on the image upgrade configuration handshake request message.

[0048] Step S25: Send an image upgrade configuration data response message to the host based on the image upgrade configuration data request message.

[0049] Step S26: Send an image upgrade software handshake response message to the host based on the image upgrade software handshake request message.

[0050] Step S27: Send an image upgrade software data response message to the host based on the image upgrade software data request message.

[0051] Figure 4 This is a flowchart illustrating an implementation method for starting an executable image loaded into memory based on the IU request message and the IU response message, according to an embodiment of this disclosure. Figure 4 As shown, this embodiment provides a method for launching an executable image loaded into memory based on the IU request message and the IU response message, including:

[0052] When the switch efuse (electronic fuse of the switch) is in non-secure boot mode:

[0053] Step S31: Obtain the first hash value of the security module based on the security module.

[0054] Optionally, the first hash value of the security module may refer to the hash value calculated and obtained by the security module in the insecure boot mode. The security module is the security module in the image upgrade security module data request message.

[0055] Optionally, the calculation process of the first hash value of the security module may refer to performing a hash calculation on the number of bytes in the first secure_module_len (security module length) - secure_hash_algorithm_id (security hash algorithm ID) of the secure module according to secure_hash_algorithm_id (MD5=0x10, SHA256=0x20), and filling the calculated hash value (secure_hash_algorithm_id bytes) into the last secure_hash_algorithm_id bytes of the secure module.

[0056] Optionally, the method for obtaining the first hash value of the security module based on the security module includes: calculating the first hash value of the security module using MD5 and SHA256.

[0057] Step S32: Obtain the second hash value of the security module based on the security module data.

[0058] Optionally, the second hash value of the security module may refer to the hash value of the security module carried in the security module data in the insecure startup mode.

[0059] Step S33: Compare the first hash value and the second hash value of the security module to obtain a first comparison result. If the first comparison result is that the hashes are different, the non-secure startup fails; otherwise, proceed to step S34.

[0060] Step S34: Obtain the first hash value of the configuration image based on the configuration image.

[0061] Optionally, the first hash value of the configuration image may refer to the hash value calculated and obtained by the configuration image in the insecure boot mode. The calculation process of the configuration image will not be elaborated in this embodiment. The configuration image can be the image in the image upgrade configuration data request message.

[0062] Step S35: Obtain the second hash value of the configuration image based on the security module data.

[0063] Optionally, the second hash value of the configuration image may refer to the hash value of the configuration image carried in the security module data in the non-secure boot mode.

[0064] Step S36: Compare the first hash value and the second hash value of the configuration image to obtain a second comparison result. If the second comparison result shows that the hashes are different, the insecure startup fails; otherwise, proceed to step S37.

[0065] Step S37: Obtain the first hash value of the software image based on the software image.

[0066] Optionally, the first hash value of the software image may refer to the hash value calculated and obtained by the software image in the insecure boot mode. The calculation process of the software image will not be described in detail in this embodiment. The software image can be the image in the image upgrade software data request message.

[0067] Step S38: Obtain the second hash value of the software image based on the security module data.

[0068] Optionally, the second hash value of the software image may refer to the hash value of the software image carried in the security module data in the insecure boot mode.

[0069] Step S39: Compare the first hash value and the second hash value of the software image to obtain a third comparison result. If the third comparison result is that the hashes are different, the insecure startup fails; otherwise, jump to the memory loading address of the software image and start the software image.

[0070] Figure 5 This is a flowchart illustrating an implementation method for starting an executable image loaded into memory based on the IU request message and the IU response message, according to an embodiment of this disclosure. Figure 5 As shown, this embodiment provides a method for launching an executable image loaded into memory based on the IU request message and the IU response message, including:

[0071] When the switch efuse is in Safe Boot mode:

[0072] Step S41: Obtain the hash value of the public key in the security module based on the security module data.

[0073] Optionally, the hash value of the public key in the security module can be the hash value of the public key carried in the security module data in the secure startup mode.

[0074] Step S42: Compare the hash value of the public key in the security module with the hash value of the public key corresponding to the switch efuse to obtain a fourth comparison result. If the fourth comparison result is different, the secure startup fails; otherwise:

[0075] Step S43: Based on the public key and digital signature in the security module, verify the signature of the security module to obtain the verification result. If the verification result is that the signature fails, the secure startup fails; otherwise, proceed to step S44.

[0076] Step S44: Obtain the third hash value of the configuration image based on the configuration image.

[0077] Optionally, the third hash value of the configuration image may refer to the hash value calculated and obtained by the configuration image in the secure boot mode.

[0078] Step S45: Obtain the fourth hash value of the configuration image based on the security module data.

[0079] Optionally, the fourth hash value of the configuration image may refer to the hash value of the configuration image carried in the security module data in the secure boot mode.

[0080] Step S46: Compare the third hash value and the fourth hash value of the configuration image to obtain a fifth comparison result. If the fifth comparison result shows that the hashes are different, the secure startup fails; otherwise, proceed to step S47.

[0081] Step S47: Obtain the third hash value of the software image based on the software image.

[0082] Optionally, the third hash value of the software image may refer to the hash value calculated and obtained by the software image in the secure boot mode.

[0083] Step S48: Obtain the fourth hash value of the software image based on the security module data.

[0084] Optionally, the fourth hash value of the software image may refer to the hash value of the software image carried in the security module data in the secure boot mode.

[0085] Step S49: Compare the third hash value and the fourth hash value of the software image to obtain a sixth comparison result. If the sixth comparison result is that the hashes are different, the secure startup fails; otherwise, jump to the memory loading address of the software image and start the software image.

[0086] Optionally, during hash comparison for non-secure boot: the first hash value is the calculated hash value, and the second hash value is the hash value in the secure module data of non-secure boot. For secure boot: the third hash value is the calculated hash value, and the fourth hash value is the hash value in the secure module data of secure boot.

[0087] Optionally, whether the switch efuse starts in safe mode can be determined by sm_is_trusted in the security module. When sm_is_trusted is 1, safe mode is started; when sm_is_trusted is 0, non-safe mode is started.

[0088] In one embodiment of this disclosure, the IU supports three message formats: Discover IU, Handshake IU, and ImageData IU. The IU header fields are shown in Table 1 below:

[0089]

[0090] Table 1

[0091] Where DA: Destination MAC address

[0092] The IU supports multicast and unicast; the multicast address is 65:DF:10:00:00:06

[0093] SA: Source MAC address

[0094] ET: Ethernet type for IU - 0x4955 (ASCII code for "IU")

[0095] IU_length: The length of the IU portion of the IU message (including the length field itself).

[0096] Needack: Whether a response is required for the IU message.

[0097] resp:0 - request IU, 1 - response IU

[0098] device_id:Switch device ID (switch identification)

[0099] When swcith receives an IU message, it compares the device ID in the message with its own device ID. If they are equal, or the device ID in the message is 0xF, it will process the IU message and give a response; otherwise, it will forward the IU message directly.

[0100] 0-0xE: Single switch device ID.

[0101] 0xF: for all switch devices (for all switching chips);

[0102] to_switch_type: The type of switch to send;

[0103] 00: to all switches;

[0104] 01: to flashless switches;

[0105] 02: to flash switches;

[0106] 03: reserved;

[0107] error_code: Error number;

[0108] 0: success;

[0109] others: fail reason;

[0110] For the request IU, it's 0;

[0111] IU_type: IU message type

[0112] 0: Discover IU;

[0113] 1: handshake IU (handshake IU);

[0114] 2: data IU;

[0115] IU_data: IU message data, the data is different for each IU type;

[0116] It is important to note that:

[0117] 1. The IU can support a single-layer VLAN (Virtual Local Area Network). If there is a VLAN, the VLAN field is after the SA field and before the ET field.

[0118] 2. When the switch receives a unicast IU message:

[0119] 1) If the destination MAC address of the message matches its own, send it to the internal CPU of the switch.

[0120] - If the device ID in the message is equal to the switch's device ID or 0xF, then the switch processes the IU message and gives a unicast response IU (DA is the original message SA, SA is the switch MAC).

[0121] - Otherwise, discard the IU message.

[0122] 2) Otherwise, the IU will be forwarded according to the Layer 2 forwarding table (the final IU message will reach its destination switch).

[0123] 3. When the switch receives a multicast IU message:

[0124] 1) If the device ID in the message is equal to the switch's device ID or 0xF, then the switch processes the IU message, gives a unicast response IU (DA is the original message SA, SA is the switch MAC), and forwards the IU message according to the multicast forwarding table.

[0125] 2) Otherwise, forward the IU message directly according to the multicast forwarding table.

[0126] The Discover Request IU (image upgrade discovery request) is used by the central controller to send a discovery message to the switch. Upon receiving this message, the switch will respond with a Discover Response IU (image upgrade discovery response) message. The response message will include fields such as chip_id and trusted_boot, based on the switch's own information. The data portion of the Discover IU can be shown in Table 2 below.

[0127]

[0128] Table 2

[0129] Among them, chip id: switch returns the switch model in Discover resposne IU;

[0130] trusted boot: The switch returns whether it needs a secure boot in the Discover response IU;

[0131] Device state: The switch returns the switch's state in the Discover response IU, such as startup, running, downloading, etc.

[0132] skip flash: 0: The current switch has flash; 1: The current switch does not have flash.

[0133] boot partition: switch which partition the current program boots from (flash primary partition, flash backup partition, and network partition).

[0134] Primary partition logical block address: The starting address of the logical block of the primary partition in the switch flash;

[0135] primary partition size: the size of the primary partition in the switch flash;

[0136] Secondary partition logical block address: The starting address of the logical block of the secondary partition in flash memory;

[0137] Secondary partition size: The size of the secondary partition in the switch flash;

[0138] The Handshake IU is used for the handshake before downloading the image (generally, Secure Boot requires at least the download of the secure module image, the software image, and possibly the configuration image).

[0139] It is important to note that:

[0140] 1. The image_secure_module (security module image) must exist and must be the first image downloaded. When handling the software image, if the program is running in the flash image (i.e., flash switch, not dumb switch), you need to erase the temporary partition.

[0141] 2. Software image (must exist) This must be the last image downloaded. After downloading, it performs secure module signature verification, image verification, etc. Once verification is successful, the software image is launched, and a handshake is performed. The data portion of the IU is shown in Table 3 below:

[0142]

[0143] Table 3

[0144] Among them, "image type" refers to the type of image to be downloaded, and "request Handshake IU" should be filled in.

[0145] - P_image_secure_module(0) / / Primary partition

[0146] - S_image_secure_module(1) / / Secodary partition

[0147] - B_image_secure_module(2) / / Boot partition or network partition, dumb switch requires network partition;

[0148] - image_boot_zone(3) / / This is optional. The flash version upgrade patch will not have this image in the network loading of dumb switch.

[0149] - image_software(4) / / This needs to be the last image downloaded;

[0150] - image_config(5) / / Used for startup recovery configuration, optional;

[0151] Image size: The size of the image to be downloaded. This should be entered in the Request Handshake IU field.

[0152] ram load addr: For dumb switches without flash, the address where the image is downloaded to RAM. Enter this in requestHandshake IU.

[0153] chunk_size: The size of the image data transmitted in each request message (the last message can transmit less than this value), which is filled in by the request Handshake IU;

[0154] max_chunk_size: The maximum value of image data transmitted in each message, filled in by the response Handshake IU. After receiving the message, if chunk_size <= max_chunk_size, the central controller can continue to transmit ImageData IU at chunk_size; if chunk_size > max_chunk_size, the central controller needs to send a handshake again and fill the received max_chunk_size value into the chunk_size field of the sent message.

[0155] Each image is transmitted via ImageData IU (image data) after a handshake. Considering that ImageData request IU is generally quite large, while the purpose of ImageData response IU is only to acknowledge the response, the response message format of ImageData IU is different from that of request message format in order to reduce network overhead. The response message is very short and only transmits some essential information required for the response. The data part of ImageDataRequest IU is shown in Table 4 below:

[0156]

[0157] Table 4

[0158] Where, chunk number: the currently transmitted block number; data: the transmitted data, its length is IU length – IU header – sizeof (rsvd + chunk number) = IU length – 10. The data part of ImageData Response IU is shown in Table 5 below:

[0159]

[0160] Table 5

[0161] Among them, window size: how many IU packets the switch can receive;

[0162] last received chunk number: the most recently received chunk number;

[0163] Expected chunk number: The chunk number of the last chunk for which data was expected to be received. Normally, this value should be equal to the lastreceived chunk number.

[0164] The format of a secure module is shown in Table 6 below:

[0165]

[0166] Table 6

[0167] The negotiation handshake for secure module transmission:

[0168] The host sends a Handshake IU message for the secure module and negotiates with the switch to determine the size of the secure module, the block size to be transferred, the address where the secure module is stored, and other information.

[0169] Transmission of secure modules:

[0170] The host transmits the secure module to the switching chip, and the switching chip receives it and stores the secure module at the negotiated address.

[0171] Transfer configuration image:

[0172] The configuration image is a collection of NMU messages. It can also be omitted when starting the dumb switch. Instead, the central control unit sends down the NMU messages from the configuration image and gives them to the switch for execution after the dumb switch has obtained the software image that supports NMU.

[0173] Configure the negotiation handshake for mirror transport:

[0174] The host sends a Handshake IU message for the configuration image and negotiates with the switch to determine the size of the configuration image, the block size to be transferred, the address where the configuration image is stored, and other information.

[0175] Configure image transfer:

[0176] The host transmits the configuration image to the switching chip, and the switching chip receives it and stores the configuration image at the negotiated address.

[0177] Transfer software image:

[0178] The software image must be the last image transferred. After downloading, secure module verification (secure boot) or hash verification (insecure boot) should be performed, as well as hash verification for each image.

[0179] Negotiation handshake for software image transfer:

[0180] The host sends a Handshake IU message for the software image and negotiates with the switch to determine the size of the software image, the block size to be transferred, the address where the software image is stored, and other information.

[0181] Software image transmission: The host transmits the software image to the switching chip, and the switching chip receives it and stores the software image at the negotiated address.

[0182] Switch boot software image: The Switch's efuse stores the boot mode (secure boot or non-secure boot) and the hash values ​​of the three public keys with ECC error correction used for secure boot.

[0183] The process of using a switch to start a software image is as follows:

[0184] The Switch's efuse stores the boot mode (secure boot or insecure boot) and the hash values ​​of the three public keys with ECC error correction used for secure boot.

[0185] Insecure boot mode: When Switch EFS is configured to insecure boot mode, after the Switch's bootrom finishes downloading the software, it will...

[0186] 1. Check the secure module's sm_is_trusted. If sm_is_trusted is 1, the match fails; if it is 0, the match passes and the next step continues.

[0187] 2. Calculate the hash value of the secure module (excluding the last item digital_signature / hash) using the secure_hash_algorithm_id algorithm (md5 or sha256), and compare it with the last item hash in the secure module. If they match, continue to the next step.

[0188] 3. Calculate the hash value of the configuration image, and then compare it with the configuration_hash in the secure module. If they match, continue to the next step.

[0189] 4. Calculate the hash value of the software image, and then compare it with the software_hash in the secure module. If they match, continue to the next step.

[0190] 5. Jump to the memory loading address of the software image and start the software image. Usually, the software image will support NMU and other protocols such as gPTP.

[0191] Safe Boot Mode:

[0192] When Switch EFS is configured for Secure Boot mode, after the Switch's bootrom downloads the software, it will...

[0193] 1. Check the secure module's sm_is_trusted. If sm_is_trusted is 0, the match fails; if it is 1, the match passes and the next steps continue.

[0194] 2. Press Figure 3 Verify the public key and calculate the hash value of the public_key in the secure module (including public_key_mod and public_key_exp_size). If this hash value is equal to the hash value of the public_key_id-th public key stored in switch efuse, then the public key of this secure module is considered valid, and the process continues to the next step.

[0195] 3. Using the public_key and the last item of the secure module, digital_signature, verify the secure module according to the secure_verify_algorithm_id algorithm (usually RSA). If it passes, continue to the following steps;

[0196] 4. Calculate the hash value of the configuration image, and then compare it with the configuration_hash in the secure module. If they match, continue to the next step.

[0197] 5. Calculate the hash value of the software image, and then compare it with the software_hash in the secure module. If they match, continue to the next step.

[0198] 6. Jump to the memory loading address of the software image and start the software image. Usually, the software image will support NMU (Network Management Unit) and other protocols such as gPTP (Generalized Precision Time Protocol).

[0199] Figure 6 This is a schematic diagram illustrating the control downloading of the image to the dumb switch via IU messages in an embodiment of this disclosure. Further details will not be elaborated upon in this embodiment.

[0200] In one embodiment of this disclosure, Figure 7 This is a schematic diagram illustrating the network startup time of an embodiment of this disclosure, using a 100Mbps port to... Figure 6 Downloading a software image of approximately 256KB, a relatively small secure module, and configuration to the dumb switch takes about 33 milliseconds (excluding verification time, only the packet transmission time). For comparison, loading flash at an SPI 50Mbps rate takes approximately 37ms in two-wire mode and approximately 23 milliseconds in four-wire mode.

[0201] The scope of protection of the image boot method described in this disclosure is not limited to the execution order of the steps listed in this embodiment. Any solution implemented by adding, subtracting, or replacing steps in the prior art based on the principles of this disclosure is included within the scope of protection of this disclosure.

[0202] Figure 8 This illustrates a mirror boot device according to an embodiment of the present disclosure. For example... Figure 8As shown, this embodiment provides a mirror boot device 800, including:

[0203] The message receiving module 810 is used to receive IU request messages sent by the host to the switch. The fields of the IU message include: destination MAC address, source MAC address, Ethernet type of IU, length of the IU part of the IU request message, whether the request IU message needs a response, switch identifier, type of the sending switch, error number, IU message type, IU message data and IU response identifier, wherein the IU response identifier is either the IU request type or the IU response type.

[0204] The message response module 820 is used to send an IU response message to the host based on the IU request message, wherein the IU response message includes switch information.

[0205] The image execution module 830 is used to start an executable image loaded into memory based on the IU request message and the IU response message, wherein the IU request message includes information about the executable image.

[0206] In the mirror startup device 800, the message receiving module 810 corresponds one-to-one with step S11, the message response module 820 corresponds one-to-one with step S12, and the mirror execution module 830 corresponds one-to-one with step S13.

[0207] In the several embodiments provided in this disclosure, it should be understood that the disclosed apparatus or method can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative. For instance, the division of modules / units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple modules or units may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection of apparatuses or modules or units may be electrical, mechanical, or other forms.

[0208] The modules / units described as separate components may or may not be physically separate. The components shown as modules / units may or may not be physical modules; that is, they may be located in one place or distributed across multiple network units. Some or all of the modules / units can be selected to achieve the objectives of the embodiments of this disclosure, depending on actual needs. For example, the functional modules / units in the various embodiments of this disclosure may be integrated into one processing module, or each module / unit may exist physically separately, or two or more modules / units may be integrated into one module / unit.

[0209] Those skilled in the art will further recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of both. To clearly illustrate the interchangeability of hardware and software, the components and steps of the various examples have been generally described in terms of functionality in the foregoing description. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this disclosure.

[0210] like Figure 9 As shown, the electronic device of the present invention is embodied in the form of a general-purpose computing device. The components of the electronic device may include, but are not limited to: one or more processors or processing units 91, a memory 92, and a bus 93 connecting different system components (including the memory 92 and the processing unit 91).

[0211] Bus 93 represents one or more of several bus architectures, including a memory bus or memory controller, a peripheral bus, a graphics acceleration port, a processor, or a local bus using any of the various bus architectures. For example, these architectures include, but are not limited to, the Industry Standard Architecture (ISA) bus, the Micro Channel Architecture (MAC) bus, the Enhanced ISA bus, the Video Electronics Standards Association (VESA) local bus, and the Peripheral Component Interconnect (PCI) bus.

[0212] Electronic devices typically include a variety of computer-readable media. These media can be any available media that can be accessed by the electronic device, including volatile and non-volatile media, and removable and non-removable media.

[0213] Memory 92 may include computer system readable media in the form of volatile memory, such as random access memory (RAM) 921 and / or cache memory 922. The electronic device may further include other removable / non-removable, volatile / non-volatile computer system storage media. By way of example only, storage system 923 may be used to read and write non-removable, non-volatile magnetic media (…). Figure 9 Not shown; usually referred to as a "hard drive"). Although Figure 9As not shown, a disk drive for reading and writing to a removable non-volatile disk (e.g., a "floppy disk") and an optical disk drive for reading and writing to a removable non-volatile optical disk (e.g., a CD-ROM, DVD-ROM, or other optical media) may be provided. In these cases, each drive may be connected to bus 93 via one or more data media interfaces. Memory 92 may include at least one program product having a set (e.g., at least one) of program modules configured to perform the functions of the embodiments of the present invention.

[0214] A program / utility 924 having a set (at least one) of program modules 9241 may be stored, for example, in memory 92. Such program modules 9241 include, but are not limited to, an operating system, one or more application programs, other program modules, and program data. Each or some combination of these examples may include an implementation of a network environment. Program modules 9241 typically perform the functions and / or methods described in the embodiments of the present invention.

[0215] The electronic device can also communicate with one or more external devices (e.g., keyboard, pointing device, display, etc.), and with one or more devices that enable a user to interact with the electronic device, and / or with any device that enables the electronic device to communicate with one or more other computing devices (e.g., network interface card, modem, etc.). This communication can be performed through input / output (I / O) interface 94. Furthermore, the electronic device can also communicate with one or more networks (e.g., local area network (LAN), wide area network (WAN), and / or public networks, such as the Internet) through network adapter 95. Figure 9 As shown, network adapter 95 communicates with other modules of the electronic device via bus 93. It should be understood that, although not shown in the figure, other hardware and / or software modules can be used in conjunction with the electronic device, including but not limited to: microcode, device drivers, redundant processing units, external disk drive arrays, RAID systems, tape drives, and data backup storage systems.

[0216] This disclosure also provides a computer-readable storage medium. Those skilled in the art will understand that all or part of the steps in the methods of the above embodiments can be implemented by a program instructing a processor. The program can be stored in a computer-readable storage medium, which is a non-transitory medium, such as random access memory, read-only memory, flash memory, hard disk, solid-state drive, magnetic tape, floppy disk, optical disk, and any combination thereof. The storage medium can be any available medium accessible to a computer or a data storage device such as a server or data center that integrates one or more available media. The available medium can be a magnetic medium (e.g., floppy disk, hard disk, magnetic tape), an optical medium (e.g., digital video disc (DVD)), or a semiconductor medium (e.g., solid-state drive (SSD)).

[0217] This disclosure also provides a computer program product comprising one or more computer instructions. When the computer instructions are loaded and executed on a computing device, all or part of the processes or functions described in this disclosure are generated. The computer instructions may be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions may be transmitted from one website, computer, or data center to another via wired (e.g., coaxial cable, fiber optic, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) means.

[0218] When the computer program product is executed by a computer, the computer performs the method described in the foregoing method embodiments. The computer program product can be a software installation package; when the foregoing method is required, the computer program product can be downloaded and executed on the computer.

[0219] The descriptions of the processes or structures corresponding to the above figures each have their own emphasis. For parts of a process or structure that are not described in detail, please refer to the relevant descriptions of other processes or structures.

[0220] The above embodiments are merely illustrative of the principles and effects of this disclosure and are not intended to limit this disclosure. Any person skilled in the art can modify or alter the above embodiments without departing from the spirit and scope of this disclosure. Therefore, all equivalent modifications or alterations made by those skilled in the art without departing from the spirit and technical concept disclosed in this disclosure should still be covered by the claims of this disclosure.

Claims

1. A method for booting from an image, characterized in that, Applications in switch chips include: The system receives a mirror upgrade IU request message sent by the client host to the switch. The fields of the IU message include: destination MAC address, source MAC address, Ethernet type of the IU, length of the IU part of the IU request message, whether the request IU message needs a response, switch identifier, type of the sending switch, error number, IU message type, IU message data, and IU response identifier. The IU response identifier is either the IU request type or the IU response type. Based on the IU request message, an IU response message is sent to the host, and the IU response message includes switch information; The executable image loaded into memory is started based on the IU request message and the IU response message, wherein the IU request message includes information about the executable image.

2. The image boot method according to claim 1, characterized in that, The method for sending an IU response message to the host based on the IU request message includes: The IU request message includes: image upgrade discovery request message, image upgrade security module handshake request message, image upgrade security module data request message, image upgrade configuration handshake request message, image upgrade configuration data request message, image upgrade software handshake request message, and image upgrade software data request message; Based on the image upgrade discovery request message, an image upgrade discovery response message is sent to the host; Based on the image upgrade security module handshake request message, an image upgrade software handshake response message is sent to the host; Based on the image upgrade security module data request message, send an image upgrade security module data response message to the host; Based on the image upgrade configuration handshake request message, send an image upgrade configuration handshake response message to the host; Based on the image upgrade configuration data request message, send an image upgrade configuration data response message to the host; Based on the image upgrade software handshake request message, send an image upgrade software handshake response message to the host; Based on the image upgrade software data request message, a mirror upgrade software data response message is sent to the host.

3. The image boot method according to claim 2, characterized in that, The method for launching the executable image loaded into memory based on the IU request message and the IU response message includes: When the switch efuse is in a non-secure boot mode: Based on the security module, obtain the first hash value of the security module; The second hash value of the security module is obtained based on the data of the security module. The first hash value and the second hash value of the security module are compared to obtain a first comparison result. If the first comparison result shows that the hashes are different, the non-secure startup fails; otherwise: Obtain the first hash value of the configuration image based on the configuration image; The second hash value of the configuration image is obtained based on the security module data; The first hash value and the second hash value of the configuration image are compared to obtain a second comparison result. If the second comparison result shows that the hashes are different, the insecure boot fails; otherwise: Obtain the first hash value of the software image based on the software image; The second hash value of the software image is obtained based on the security module data; The first hash value and the second hash value of the software image are compared to obtain a third comparison result. If the third comparison result is that the hashes are different, the non-secure startup fails; otherwise, the process jumps to the memory loading address of the software image and starts the software image.

4. The image boot method according to claim 2, characterized in that, The method for launching the executable image loaded into memory based on the IU request message and the IU response message includes: When the switch efuse is in Safe Boot mode: The hash value of the public key in the security module is obtained based on the data in the security module. The hash value of the public key in the security module is compared with the hash value of the public key corresponding to the switch efuse to obtain a fourth comparison result. If the fourth comparison result is different, the secure startup fails; otherwise: Based on the public key and digital signature in the security module, the security module is verified to obtain a verification result. If the verification result is that the verification fails, the secure startup fails; otherwise: Obtain the third hash value of the configuration image based on the configuration image; The fourth hash value of the configuration image is obtained based on the security module data; The third hash value and the fourth hash value of the configuration image are compared to obtain a fifth comparison result. If the fifth comparison result shows that the hashes are different, then secure startup fails; otherwise: Obtain the third hash value of the software image based on the software image; The fourth hash value of the software image is obtained based on the security module data; The third hash value and the fourth hash value of the software image are compared to obtain a sixth comparison result. If the sixth comparison result is that the hashes are different, the secure startup fails; otherwise, the process jumps to the memory loading address of the software image and starts the software image.

5. The image boot method according to claim 2, characterized in that, The method for sending an image upgrade discovery response message to the host based on the image upgrade discovery request message includes: Fill in the original image upgrade discovery response message with the switch model, whether the switch needs secure boot, switch status, current switch flash information, current program boot partition, logical block start address of the main flash partition in the switch, size of the main flash partition in the switch, logical block start address of the secondary flash partition in the flash and size of the secondary flash partition in the flash, in order to obtain the image upgrade discovery response message. Send the image upgrade discovery response message to the host.

6. The image boot method according to claim 1, characterized in that, The method for sending an IU response message to the host based on the IU request message includes: The IU request message is either a unicast IU request message or a multicast IU request message; When the IU request message is a unicast IU request message, if the destination address in the IU request message matches the switch, the IU request message is processed based on the switch identifier in the IU request message; otherwise, the IU request message is forwarded based on the Layer 2 forwarding table. When the IU request message is a multicast IU request message, if the switch identifier in the IU request message is equal to the switch identifier or the switch identifier in the IU request message is 0xF, then the IU request message is processed, and a unicast IU response message is sent to the host and the IU request message is forwarded based on the multicast forwarding table; otherwise, the IU request message is forwarded directly based on the multicast forwarding table. The 0xF indicates that it is forwarded to all switching chips.

7. The image boot method according to claim 6, characterized in that, The method for processing the IU request message based on the switch identifier in the IU request message includes: If the switch identifier in the IU request message is equal to the switch identifier or the switch identifier in the IU request message is 0xF, then the IU request message is processed and a unicast IU response message is sent to the host; otherwise, the IU request message is discarded.

8. A mirror-start device, characterized in that, include: The message receiving module is used to receive IU request messages sent by the client host to the switch. The fields of the IU message include: destination MAC address, source MAC address, Ethernet type of IU, length of the IU part of the IU request message, whether the request IU message needs a response, switch identifier, type of the sending switch, error number, IU message type, IU message data, and IU response identifier, wherein the IU response identifier is either the IU request type or the IU response type. The message response module is used to send an IU response message to the host based on the IU request message, wherein the IU response message includes switch information; The image execution module is used to start the executable image loaded into memory based on the IU request message and the IU response message, wherein the IU request message includes information about the executable image.

9. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by the processor, it implements the image boot method as described in claims 1-7.

10. An electronic device, characterized in that, include: Memory; The processor is coupled to the memory and configured to execute the image boot method according to claims 1-7.

Images