XTS-AES模式主要是解决什么问题，是怎样解决的? XTS-AES模式主要是解决什么问题，是怎样解决的?作者：蒋伟伟链接：https://www.zhihu.com/question/26452995/answer/142440391来源：知乎著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。XTS即基于XEX(XOR-ENCRYPT-XOR)的密文窃取算法的可调整的密码本模式（Tweakable Codebook mode），该算法主要用于以数据单元（包括扇区、逻辑磁盘块等）为基础结构的存储设备中静止状态数据的加密。以上是官方的解释，谈一下我的理解。我们都知道磁盘上的数据是有一定格式的，比如一个扇区是512字节，磁盘加密直接要对写入扇区的明文进行加密，记录在磁盘扇区上的是相应的密文。而我们通过传统的AES加密方法，比如CBC加密模式，密文须包含一个128bit的初始向量。那么问题来了，我们岂不是要腾出额外的128个bit专门存储初始向量？这样做是增加了磁盘的开销，而且明文和密文在扇区上的存储也不是一一对应的，这给磁盘底层的加密实现带来很大的麻烦。更为关键的是，传统的加密算法，更改密匙非常不便，一旦更改，就意味着要重新进行密匙扩展算法，对磁盘来说要增加很大的开销，同时还要担心密匙泄露的问题。在这种情况下，针对磁盘加密的特点，2002年，Moses Liskov，Ronald L.Rivest, David Wagner,首次提出了可调整的分组密码这个概念，跟传统的分组密码相比，除了密匙和明文这两个输入外，还引入另外一个输入---tweak，即可调整值。这样做的好处是，在不更改密匙的情况下，仅仅改变tweak值，就可以给加密系统提供多变性，既减少了磁盘的开销，也不怕密匙泄露，因为tweak值是公开的，就算泄露了tweak值，如果不知道密匙，是无法破解系统的。而且，这种算法，不需要初始向量，也就避免我们上面所述的明文和密文在扇区上的存储不对应的问题。XTS-AES算法是基于以上思想，被IEEE采用的一个标准。简单介绍下其原理，以传输单个128bit数据块为例：i为128-bit调整值，j为128-bit数据块在数据单元中的位置值,C为128-bit密文数据块。AES-enc为标准AES算法，key2为调整值密匙，key1为数据密匙，模乘操作中 α为GF(2^128)域中对应于多项式x的本源。计算的步骤顺序如下：T <---- AES-enc(key2,i) ⓧ (α^j );PP <----P⊕Thttp://3.CC<---AES-enc(Key1,PP)C<--CC⊕T需要指出的是，j代表数据块在数据单元里的index，比如256个bit数据块，那么 0bit-127bit的j=1，128bit-256bit 的j=2。j 的引入，是让各个数据块的加密保持独立。Disk encryption theoryFrom Wikipedia, the free encyclopediaJump to navigationJump to searchDisk encryption is a special case of data at rest protection when the storage medium is a sector-addressable device (e.g., a hard disk). This article presents cryptographic aspects of the problem. For an overview, see disk encryption. For discussion of different software packages and hardware devices devoted to this problem, see disk encryption software and disk encryption hardware.Contents1Problem definition2Block cipher-based modes2.1Cipher-block chaining (CBC)2.1.1Encrypted salt-sector initialization vector (ESSIV)2.1.2Malleability attack2.2Liskov, Rivest, and Wagner (LRW)2.3Xor–encrypt–xor (XEX)2.3.1XEX-based tweaked-codebook mode with ciphertext stealing (XTS)2.3.2XTS weaknesses2.4CBC–mask–CBC (CMC) and ECB–mask–ECB (EME)3Patents4See also5References6Further reading7External linksProblem definition[edit]Disk encryption methods aim to provide three distinct properties:1.The data on the disk should remain confidential.2.Data retrieval and storage should both be fast operations, no matter where on the disk the data is stored.3.The encryption method should not waste disk space (i.e., the amount of storage used for encrypted data should not be significantly larger than the size of plaintext).The first property requires defining an adversary from whom the data is being kept confidential. The strongest adversaries studied in the field of disk encryption have these abilities:1.they can read the raw contents of the disk at any time;2.they can request the disk to encrypt and store arbitrary files of their choosing;3.and they can modify unused sectors on the disk and then request their decryption.A method provides good confidentiality if the only information such an adversary can determine over time is whether the data in a sector has or has not changed since the last time they looked.The second property requires dividing the disk into several sectors, usually 512 bytes (4096 bits) long, which are encrypted and decrypted independently of each other. In turn, if the data is to stay confidential, the encryption method must be tweakable; no two sectors should be processed in exactly the same way. Otherwise, the adversary could decrypt any sector of the disk by copying it to an unused sector of the disk and requesting its decryption.The third property is generally non-controversial. However, it indirectly prohibits the use of stream ciphers, since stream ciphers require, for their security, that the same initial state not be used twice (which would be the case if a sector is updated with different data); thus this would require an encryption method to store separate initial states for every sector on disk—seemingly a waste of space. The alternative, a block cipher, is limited to a certain block size (usually 128 or 256 bits). Because of this, disk encryption chiefly studies chaining modes, which expand the encryption block length to cover a whole disk sector. The considerations already listed make several well-known chaining modes unsuitable: ECB mode, which cannot be tweaked, and modes that turn block ciphers into stream ciphers, such as the CTR mode.These three properties do not provide any assurance of disk integrity; that is, they don't tell you whether an adversary has been modifying your ciphertext. In part, this is because an absolute assurance of disk integrity is impossible: no matter what, an adversary could always revert the entire disk to a prior state, circumventing any such checks. If some non-absolute level of disk integrity is desired, it can be achieved within the encrypted disk on a file-by-file basis using message authentication codes.Block cipher-based modes[edit]Like most encryption schemes, block cipher-based disk encryption makes use of modes of operation, which allow encrypting larger amounts of data than the ciphers' block-size (typically 128 bits). Modes are therefore rules on how to repeatedly apply the ciphers' single-block operations.Cipher-block chaining (CBC)[edit]Main article: Cipher-block chainingCipher-block chaining (CBC) is a common chaining mode in which the previous block's ciphertext is xored with the current block's plaintext before encryption:Since there isn't a "previous block's ciphertext" for the first block, an initialization vector (IV) must be used as . This, in turn, makes CBC tweakable in some ways.CBC suffers from some problems. For example, if the IVs are predictable, then an adversary may leave a "watermark" on the disk, i.e., store a specially created file or combination of files identifiable even after encryption. The exact method of constructing the watermark depends on the exact function providing the IVs, but the general recipe is to create two encrypted sectors with identical first blocks  and ; these two are then related to each other by . Thus the encryption of  is identical to the encryption of , leaving a watermark on the disk. The exact pattern of "same-different-same-different" on disk can then be altered to make the watermark unique to a given file.To protect against the watermarking attack, a cipher or a hash function is used to generate the IVs from the key and the current sector number, so that an adversary cannot predict the IVs. In particular, the ESSIV approach uses a block cipher in CTR mode to generate the IVs.Encrypted salt-sector initialization vector (ESSIV)[edit]ESSIV[1] is a method for generating initialization vectors for block encryption to use in disk encryption. The usual methods for generating IVs are predictable sequences of numbers based on, for example, time stamp or sector number, and prevents certain attacks such as a watermarking attack. ESSIV prevents such attacks by generating IVs from a combination of the sector number SN with the hash of the key. It is the combination with the key in form of a hash that makes the IV unpredictable.ESSIV was designed by Clemens Fruhwirth and has been integrated into the Linux kernel since version 2.6.10, though a similar scheme has been used to generate IVs for OpenBSD's swap encryption since 2000.[2]ESSIV is supported as an option by the dm-crypt[3] and FreeOTFE disk encryption systems.Malleability attack[edit]While CBC (with or without ESSIV) ensures confidentiality, it does not ensure integrity of the encrypted data. If the plaintext is known to the adversary, it is possible to change every second plaintext block to a value chosen by the attacker, while the blocks in between are changed to random values. This can be used for practical attacks on disk encryption in CBC or CBC-ESSIV mode.[4]Liskov, Rivest, and Wagner (LRW)[edit]In order to prevent such elaborate attacks, different modes of operation were introduced: tweakable narrow-block encryption (LRW and XEX) and wide-block encryption (CMC and EME).Whereas a purpose of a usual block cipher  is to mimic a random permutation for any secret key , the purpose of tweakable encryption is to mimic a random permutation for any secret key  and any known tweak . The tweakable narrow-block encryption (LRW)[5] is an instantiation of the mode of operations introduced by Liskov, Rivest, and Wagner[6] (see Theorem 2). This mode uses two keys:  is the key for the block cipher and  is an additional key of the same size as block. For example, for AES with a 256-bit key,  is a 256-bit number and  is a 128-bit number. Encrypting block  with logical index (tweak)  uses the following formula:Here multiplication  and addition  are performed in the finite field ( for AES). With some precomputation, only a single multiplication per sector is required (note that addition in a binary finite field is a simple bitwise addition, also known as xor): , where  are precomputed for all possible values of . This mode of operation needs only a single encryption per block and protects against all the above attacks except a minor leak: if the user changes a single plaintext block in a sector then only a single ciphertext block changes. (Note that this is not the same leak the ECB mode has: with LRW mode equal plaintexts in different positions are encrypted to different ciphertexts.)Some security concerns exist with LRW, and this mode of operation has now been replaced by XTS.LRW is employed by BestCrypt and supported as an option for dm-crypt and FreeOTFE disk encryption systems.Xor–encrypt–xor (XEX)[edit]Main article: Xor–encrypt–xorAnother tweakable encryption mode, XEX (xor–encrypt–xor), was designed by Rogaway[7] to allow efficient processing of consecutive blocks (with respect to the cipher used) within one data unit (e.g., a disk sector). The tweak is represented as a combination of the sector address and index of the block within the sector (the original XEX mode proposed by Rogaway[7] allows several indices). The ciphertext, , is obtained using:where: is the plaintext, is the number of the sector, is the primitive element of  defined by polynomial ; i.e., the number 2, is the number of the block within the sector.The basic operations of the LRW mode (AES cipher and Galois field multiplication) are the same as the ones used in the Galois/Counter Mode (GCM), thus permitting a compact implementation of the universal LRW/XEX/GCM hardware.XEX has a weakness.[8]XEX-based tweaked-codebook mode with ciphertext stealing (XTS)[edit]Ciphertext stealing provides support for sectors with size not divisible by block size, for example, 520-byte sectors and 16-byte blocks. XTS-AES was standardized on 2007-12-19[9] as IEEE P1619.[10] The standard supports using a different key for the IV encryption than for the block encryption; this is contrary to the intent of XEX and seems to be rooted in a misinterpretation of the original XEX paper, but does not harm security.11 As a result, users wanting AES-256 and AES-128 encryption must supply 512 bits and 256 bits of key respectively.On January 27, 2010, NIST released Special Publication (SP) 800-38E[12] in final form. SP 800-38E is a recommendation for the XTS-AES mode of operation, as standardized by IEEE Std 1619-2007, for cryptographic modules. The publication approves the XTS-AES mode of the AES algorithm by reference to the IEEE Std 1619-2007, subject to one additional requirement, which limits the maximum size of each encrypted data unit (typically a sector or disk block) to 220 AES blocks. According to SP 800-38E, "In the absence of authentication or access control, XTS-AES provides more protection than the other approved confidentiality-only modes against unauthorized manipulation of the encrypted data."XTS is supported by BestCrypt, Botan, NetBSD's cgd,[13] dm-crypt, FreeOTFE, TrueCrypt, VeraCrypt,[14] DiskCryptor, FreeBSD's geli, OpenBSD softraid disk encryption software, OpenSSL, Mac OS X Lion's FileVault 2, Windows 10's BitLocker[15] and wolfCrypt.XTS weaknesses[edit]XTS mode is susceptible to data manipulation and tampering, and applications must employ measures to detect modifications of data if manipulation and tampering is a concern: "...since there are no authentication tags then any ciphertext (original or modified by attacker) will be decrypted as some plaintext and there is no built-in mechanism to detect alterations. The best that can be done is to ensure that any alteration of the ciphertext will completely randomize the plaintext, and rely on the application that uses this transform to include sufficient redundancy in its plaintext to detect and discard such random plaintexts." This would require maintaining checksums for all data and metadata on disk, as done in ZFS or Btrfs. However, in commonly used file systems such as ext4 and NTFS only metadata is protected against tampering, while the detection of data tampering is non-existent.[16]The mode is susceptible to traffic analysis, replay and randomization attacks on sectors and 16-byte blocks. As a given sector is rewritten, attackers can collect fine-grained (16 byte) ciphertexts, which can be used for analysis or replay attacks (at a 16-byte granularity). It would be possible to define sector-wide block ciphers, unfortunately with degraded performance (see below).[17]CBC–mask–CBC (CMC) and ECB–mask–ECB (EME)[edit]CMC and EME protect even against the minor leak mentioned above for LRW. Unfortunately, the price is a twofold degradation of performance: each block must be encrypted twice; many consider this to be too high a cost, since the same leak on a sector level is unavoidable anyway.CMC, introduced by Halevi and Rogaway, stands for CBC–mask–CBC: the whole sector encrypted in CBC mode (with ), the ciphertext is masked by xoring with , and re-encrypted in CBC mode starting from the last block. When the underlying block cipher is a strong pseudorandom permutation (PRP) then on the sector level the scheme is a tweakable PRP. One problem is that in order to decrypt  one must sequentially pass over all the data twice.In order to solve this problem, Halevi and Rogaway introduced a parallelizable variant called EME (ECB–mask–ECB). It works in the following way:the plaintexts are xored with , shifted by different amount to the left, and are encrypted: ;the mask is calculated: , where  and ;intermediate ciphertexts are masked:  for  and ;the final ciphertexts are calculated:  for .Note that unlike LRW and CMC there is only a single key .CMC and EME were considered for standardization by SISWG. EME is patented, and so is not favored to be a primary supported mode.[18]Patents[edit]While the authenticated encryption scheme IAPM provides encryption as well as an authentication tag, the encryption component of the IAPM mode completely describes the LRW and XEX schemes above, and hence XTS without the ciphertext stealing aspect. This is described in detail in Figures 8 and 5 of the US patent 6,963,976.[19]See also[edit]Data remanenceCold boot attackDisk encryption softwareDisk encryption hardwareIEEE P1619, standardization project for encryption of the storage dataReferences[edit]1.^ Clemens Fruhwirth (July 18, 2005). "New Methods in Hard Disk Encryption" (PDF). Institute for Computer Languages: Theory and Logic Group (PDF). Vienna University of Technology.2.^ "Encrypting Virtual Memory" (Postscript).3.^ Milan Broz. "DMCrypt dm-crypt: Linux kernel device-mapper crypto target". gitlab.com. Retrieved April 5, 2015.4.^ Jakob Lell (2013-12-22). "Practical malleability attack against CBC-encrypted LUKS partitions".5.^ Latest SISWG and IEEE P1619 drafts and meeting information are on the P1619 home page [1].6.^ M. Liskov, R. Rivest, and D. Wagner. Tweakable block ciphers [2], CRYPTO '02 (LNCS, volume 2442), 2002.7.^ Jump up to:a b c Rogaway, Phillip (2004-09-24). "Efficient Instantiations of Tweakable Blockciphers and Refinements to Modes OCB and PMAC" (PDF). Dept. Of Computer Science(PDF). University of California, Davis.8.^ https://link.springer.com/content/pdf/10.1007/978-3-540-74462-7_8.pdf section 4.1.9.^ Karen McCabe (19 December 2007). "IEEE Approves Standards for Data Encryption". IEEE Standards Association. Archived from the original on 2008-03-06.10.^ Standard for Cryptographic Protection of Data on Block-Oriented Storage Devices. IEEE Xplore Digital Library. April 18, 2008. doi:10.1109/IEEESTD.2008.4493450. ISBN 978-0-7381-5363-6.11.^ Liskov, Moses; Minematsu, Kazuhiko (2008-09-02). "Comments on XTS-AES" (PDF)., On the Use of Two Keys, pp. 1–3.12.^ Morris Dworkin (January 2010). "Recommendation for Block Cipher Modes of Operation: The XTS-AES Mode for Confidentiality on Storage Devices" (PDF). NIST Special Publication 800-38E. National Institute of Standards and Technology.13.^ "NetBSD cryptographic disk driver".14.^ "Modes of Operation". VeraCrypt Documentation. IDRIX. Retrieved 2017-10-13.15.^ "What's new in BitLocker?". November 12, 2015. Retrieved 2015-11-15.16.^ Standard for Cryptographic Protection of Data on Block-Oriented Storage Devices (PDF), IEEE P1619/D16, 2007, p. 34, archived from the original (PDF) on 14 April 2016, retrieved 14 September 201217.^ Thomas Ptacek; Erin Ptacek (2014-04-30). "You Don't Want XTS".18.^ P. Rogaway, Block cipher mode of operation for constructing a wide-blocksize block cipher from a conventional block cipher, US Patent Application 20040131182 A1.19.^ * U.S. Patent 6,963,976, "Symmetric Key Authenticated Encryption Schemes" (filed Nov. 2000, issued Nov. 2005, expires 25 Nov. 2022) 3.Further reading[edit]S. Halevi and P. Rogaway, A Tweakable Enciphering Mode, CRYPTO '03 (LNCS, volume 2729), 2003.S. Halevi and P. Rogaway, A Parallelizable Enciphering Mode [5], 2003.Standard Architecture for Encrypted Shared Storage Media, IEEE Project 1619 (P1619), [6].SISWG, Draft Proposal for Key Backup Format [7], 2004.SISWG, Draft Proposal for Tweakable Wide-block Encryption [8], 2004.James Hughes, Encrypted Storage — Challenges and Methods [9]J. Alex Halderman, Seth D. Schoen, Nadia Heninger, William Clarkson, William Paul, Joseph A. Calandrino, Ariel J. Feldman, Jacob Appelbaum, and Edward W. Felten (2008-02-21). "Lest We Remember: Cold Boot Attacks on Encryption Keys" (PDF). Princeton University. Archived from the original (PDF) on 2008-05-14.Niels Fergusson (August 2006). "AES-CBC + Elephant Diffuser: A Disk Encryption Algorithm for Windows Vista" (PDF). Microsoft.External links[edit]Security in Storage Working Group SISWG."The eSTREAM project". Retrieved 2010-03-28.

浅谈芯片的bringup 一，浅谈芯片研发谈到芯片，中美贸易战的中兴事件引发了社会对芯片行业的大量关注，本文不做累述芯片行业现状、痛点，只给大家展现芯片行业纯技术的某一面。先以芯片研发流程开篇，下图为个人理解的芯片研发流程图。图1 芯片研发流程图任何产品都有面向群体，芯片也不例外，面向手机、相机等消费类电子产品，面向机器人、行业自动化等工控类设备，目前主流芯片偏向消费类电子。芯片的面向最终都是转换成规格和需求，需求方或领导层先提要求，架构工程师、项目经理、项目管理、各技术组组长坐在一起讨论拍板出我们芯片所需要的规格list和需求list，这是第一步。接着，项目管理、经理负责资源组和人员的调配。技术方面，架构师是重点，对需求和规格list进行细化到具体，搭建架构，架构的分析与建模，仿真出可行性，比如整个集成芯片划分为几个模块、CPU选型、主频、总线划分等。如果涉及到高层次算法，需要完成芯片中数字部分的高层次算法，为硬件提供一个正确的软件功能模型，通过大量的高层次仿真和调试，为RTL实现提供总体性的设计指导。芯片从功能上来看，是由各个IP综合集成出来的。国内多数集成芯片都是采购IP，自研IP多数为小IP，一般ARM、DSP、普罗米修斯等CPU类IP多为采购，当然也不乏大公司自研DSP、超级CPU等，DDR PHY、SD PHY等高速接口IP也多为采购，国内算法能力很强，目前ISP、GPU、CNN、CODEC等都有大公司在自研。集成和实现都是RTL阶段，CRG（Clock Reset Gate）就是在这个阶段设计的，另外系统、总线、安全等相关控制也是RTL集成和实现的重点。集成将所有IP集合，安排和分配好脉搏、功能信号。实现靠近实际，RTL实现之后就是软件人员所看到的寄存器手册。集成阶段非常重要的是时序，尤其是异步时序，所以需要验证。验证由根据平台划分为EDA验证、FPGA验证、ZEBU验证等。嵌入式接触比较多的是FPGA和ZEBU验证。EDA验证是模拟的环境上验证的，但其最接近最后的AISC，但仿真毕竟是仿真，离实际差异还是很大；FPGA只能做前端验证，它最真实，也是验证速度最快的，但其频率的限制、模拟器件无法模拟，导致很多功能并不能验证的很完整，CRG 、power control、pinmux根本无法验证，，各类高速接口的PHY无法真实测试，FPGA的CRG一般尽量按比例集成；ZEBU平台也是基于FPGA上集成的，但其可完全模拟出时序关系，不过也存在FPGA的其它通病，而且其验证速度比EDA更慢，跑一个复杂点的验证用例可能需要一天。各大仿真或验证平台各有优缺点，但实际的芯片并没有验证环境那么理想，有corner、生产工艺、功耗散热、DDR稳定性等各种因素，导致最后的芯片问题百出。需要注意，验证并不是固定顺序的，任何一个阶段都需要。前面陈述的都属于前端，国内后端不甚重视，总体上按顺序有数据整理提供、布图、布局、preCTS（setup优化）、CTS（clock tree setup）、postCTS（进一步优化）、布线、post布线、ECO（进入此过程再无法修改数据）、finish、signoff（检查和验证）、tapeout（设计数据传递给制造方）。最后就是流片生产，多数在台积电、台联电，嵌入式在此过程需要准备回片bring up的代码，重点在CRG、power、高速IP等仿真无法覆盖完整的代码。然后等芯片回来，芯片一旦回来，就是嵌入式的大头戏，回片bring up阶段，所有人都在关注着这最后一炮的成功与否，芯片就是一锤子买卖，题外话的说，芯片的回片现场非常类似robocon比赛现场。以下以常用的ARM cortex-A为主的SOC系列芯片bring up为例。本文纯手敲，如有出入，自行参考。二，整体bring up流程回片bring up工作非常关键，但芯片是否如意并不是嵌入式能决定的，虽然前期有负责FPGA、ZEBU验证起到验证作用，但芯片行业的核心不在嵌入式，我们只是检验大家成果的一面镜子。但换个方向思考，嵌入式是处于最底层的软件，对芯片负责，如果过了嵌入式把问题释放出去，那就会收到无数的投诉、黑评等。回片工作流程如图2。图2 芯片回片bring up流程回片工作基本上所有IP的冒烟都需要两个前提，coresight(debug/trace)和DDR。图2中还少了SOC的基本功能冒烟实现这个前提，比如CRG、power manager、安全等，由于其牵涉到每一模块，故不加入图中。DDR冒烟非常关键，通常三大巨头公司海力士、镁光和三星都需要测试，开始时有bypass training方案，高频方案等，与产品实际性能需求有关，后面为了稳定性还得进行不同corner芯片、高低温下的压力测试。DDR之后就可以并行工作了，此时需要根据芯片应用场景进行对应IP功能冒烟，图2提供了多种场景的bring up实现，最基础的kernel的启动、sensor-显示通路、图像识别和处理、编解码等。本文重心在系统的bring up介绍，不展开场景介绍。三，系统的bring up系统的启动流程是bootrom->bootloader->kernel->filesystem，具体可参考图3。图3 某芯片启动流程详解图1，bootrombootrom是系统之始，也就是第一份代码，例如BIOS就是windows的bootrom。大部分嵌入式开发者或者谷歌BSP（Board Support Package）一般最多深究到bootloader，忽略bootrom也是因为它是随着生产固化的，与芯片本身息息相关，硬件工程师关注比较多，软件不可更改，也没必要修改。但如果想对芯片真正了解，必须对bootrom的代码甚为了解。bootrom里面做了以下几个事：(1)主CPU boot，一般bootrom只启动单核，并配置处于次低频态；(2)切入slow或normal模式；(3)efuse相关位检测；(4)如果涉及到，调整芯片的安全相关属性；(5)如果涉及到，将必须的电压打开；(6)配置debug串口，提供开发者调试；(7)检测是否非默认引导方式，并引导，有flash/emmc、USB fastboot、ETH等引导；(8)根据所选方式引导，跳转到RAM起始地址。值得注意的是既然有多种引导方式，那就可以用以太网、USB甚至串口传输boot程序给芯片，让其运行自己想要的非主线分支程序，比如fastboot功能的实现、安全属性强行修改等。当然，芯片安全问题不用担心，efuse里会有加密信息，bootrom会去校验你的FW，俗称签名。2，bootloaderbootloader非常关键，是底层软件大展身手的地方。bootloader最终目的是启动内核，至于内核是linux、rtos或者其它OS都可以。bootloader也并不止uboot，还有little kernel、redboot、armboot等，甚至可以自己手写，个人接触比较多的是uboot和little kernel。uboot适应性高，对成熟芯片可以做到是快速上板，对新开发芯片能做到参考作用，但其内容繁琐，全新芯片开发难度比little kernel更大。此处以更为通用的uboot展开，讲述bootloader具体干了什么事情。Uboot，即universal-bootloader，分为两个阶段，SPL阶段和uboot第二阶段，划分两个阶段是因为片内RAM的价格高昂，且大小一般都只有几十上百K。uboot为了适应各种平台适应各种OS，越到后面版本越来越庞大，为此设计者将uboot一分为二，将初始化flash/emmc并把存储的程序搬运到片外RAM的小uboot称为SPL，将启动内核的大uboot放入片外RAM（一般是DDR，即SDRAM），采取图4流程启动OS。Uboot也支持单阶段启动或者直接flash启动，但都非常少用，个人曾强行简化uboot到100K，但把uboot很多模块给去除了，比如交互界面、哈希表，导致代码完全像重写，后面弃用不了了之。图4 uboot启动流程图4是常见的一种uboot流程，由于是两片内存空间，两个阶段都需要做系统的初始化工作，异常向量表、堆栈、BSS、data、heap、代码段，值得重视的是SPL在底层初始化阶段是无BSS、data、heap段的。SPL阶段的流程很简单：(1)ARM的boot，SP、exception设置，关闭MMU、Icache、Dcache；(2)初始化CRG，电压、频点和工作模式初始化；(3)初始化debug串口，初始化FLASH，初始化片外RAM；(4)如果有需要，release其它核或其他CPU，如DSP、cortex-M系列ARM等；(5)如果有安全需要，boot TrustZone OS；(6)Relocate堆栈、GB等到第二阶段uboot；(7)直接跳转到片外RAM执行第二阶段。第二阶段就是uboot真正起作用的阶段了，其主要流程见图5。uboot的核心在于boot起各类kernel，但它本身不止于此，它还有改写flash内容，对内存映射区域改写，修改启动环境参数等功能，实现都在图5的最后console界面里，俨然是一个小型的裸机交互系统。图5 第二阶段uboot流程这里只浅谈下核心部分，也就是起kernel功能。uboot启动的内核为uImage或者zImage，也可以是压缩包，内核格式一般是由两部分组成：真正的内核和内核头部组成，头部中包括内核中的一些信息，比如内核的种类，加载地址，入口地址。以linux为例：uboot在接收到启动命令后，要做的主要是，读取内核头部信息，移动内核到合适的加载地址，启动内核，执行do_bootm_linux。do_bootm_linux主要做的为，设置启动参数，在特定的地址，保存启动参数arg，传递设备树dtb，以及根文件系统rootfs信息，解压kernel并放置到指定片外RAM位置，跳到入口地址，启动内核。3，Kernel大部分嵌入式都是在kernel之上做着辛勤的工作，调用各种标准的写驱动接口，基于各种驱动做开发，标准的代码接口，比如linux的io control、debugfs、sysfs、用户态程序，再如rtos的任务创建挂起、信号量、邮箱等等。本节非常浅面的谈谈kernel的bring up过程。以linux为例，主要流程如图6。图6 linux启动流程首先，从bootloader接管控制权后，首先读入根目录下的内核文件，该过程对设备树进行了扫描注册。内核文件加载以后，就开始运行第一个程序linuxrc或init，它的作用是初始化系统环境，这个进程的PID为1，后面称之为init进程。这时候，许多程序需要开机启动，这些在Windows叫做“服务”（service），在Linux就叫做"守护进程"（daemon），init进程的一大任务，就是去运行这些开机启动的程序。但是，不同的场合需要启动不同的程序，linux允许为不同的场合，分配不同的开机启动程序，这就叫做“运行级别”（runlevel）。接着，每个运行级别的运行程序在/etc目录下面，都有一个对应的子目录rc*.d，选择后通过init.d链接启动。这时，开机启动程序加载完毕，然后要让用户登录，有三种登陆方式：命令行登录、ssh登录和图形界面登录，为了方便一般用ssh登录或者直接默认登录某user用户来方便开发者调试。至此，Linux的启动过程就算结束了。4，filesystem文件系统的格式极其多，每种格式都有独立的生成标准，最常用的格式，ext4、fat32，一个是linux常用，一个是windows常用，占了大片江山。所有格式文件系统说白了都是对操作系统用于在存储介质上组织文件的方法。存储设备不管是易失的RAM，还是不丢失的ROM，只要可以提供标准的initialization、read、write，都可以对某个区域或者整个区域进行格式化。比较常见的文件系统格式化设备有SD卡、硬盘、EMMC等ROM设备，一般不用于RAM中。rtos一般是等系统起来后通过进程去管理文件系统，不会用到RAM文件系统。但linux不同，在boot loader 配置了某些参数的情况下（这也是常规做法），它的启动不会一来就加载ROM的文件系统，这就涉及到一个中间系统，称为initrd、ramdisk或者initramfs，后面简称initrd。而最后我们敲shell命令的界面所在文件系统称作rootfs，也即根文件系统。以下浅要介绍linux启动所用的到文件系统。在linux内核启动前，boot loader 会将存储介质中的initrd文件加载到片外RAM，内核启动时会在访问真正的根文件系统前先访问该内存中的initrd 文件系统。内核启动被分成了两个阶段，第一阶段先执行initrd 文件系统中的某个初始化文件，完成加载驱动模块等任务，第二阶段才会执行真正的根文件系统（rootfs）中的init 进程。linux是基于unix的系统，unix的设计之初有一哲学核心思想，即“一切皆文件”，在linux上的体现就是rootfs。简单的说，rootfs是一个带有linux整套内核体系结构和硬件设备注册的文件系统，可以看到设备节点，用户进程，debug信息等。相信linux驱动工程师了如指掌。不管是rootfs还是initrd，其实都是一样的文件形式，可以做成同源。rootfs的生成比较有名的工具叫做busybox，busybox自带有许多设备操作和shell的库。在这介绍两个开源代码，一个叫做buildroot，一个叫做yocto，都是基于busybox工具上的rootfs生成项目，都具备可视化可裁剪定制界面，库自选，busybox还带有许多boot kernel相关开源代码，同样initrd也可通过它们获得。至此，芯片的系统bring up结束。接下来就是各模块的驱动开发，和各种业务场景的实现了。版权声明：本文来源网络，免费传达知识，版权归原作者所有。如涉及作品版权问题，请联系我进行删除。https://www.eet-china.com/mp/a350381.html

SSH协议详解 作为程序员，一定不会没有用过ssh吧。当我们需要远程登录到服务器上进行操作的时候，一般就会用ssh。ssh是secure shell的简称，它相对于早起的telnet和rsh的明文传输，提供了加密、校验和压缩，使得我们可以很安全的远程操作， 而不用担心信息泄露(当然不是绝对的，加密总有可能被破解，只是比起明文来说那是强了不少)。本文会详细的讲解SSH协议是怎么定义的，以及他是怎么实现安全的加密。几个基本概念在介绍ssh协议之前，有几个涉及到的基本概念首先需要介绍，它们对于理解ssh协议本身有非常重要和关键的作用。加密加密的意思是将一段数据经过处理之后，输出为一段外人无法或者很难破译的数据，除了指定的人可以解密之外。 一般来说，加密的输入还会有一个key，这个key作为加密的参数， 而在解密的时候也会用一个相关联(有可能是相同)的key作为输入。粗略来说是下面的流程：加密方encrypted_data = encrypt(raw_data, key)解密方raw_data = decrypt(encrypted_data, key1)目前主流的加密算法一般分为下面两类：1.私钥(secret key)加密，也称为对称加密2.公钥(public key)加密私钥加密所谓的私钥加密，是说加密方和解密方用的都是同一个key，这个key对于加密方和解密方来说是保密的，第三方是不能知道的。在第三方不知道私钥的情况下，是很难将加密的数据解密的。一般来说是加密方先产生私钥，然后通过一个安全的途径来告知解密方这个私钥。公钥加密公钥加密，是说解密的一方首先生成一对密钥，一个私钥一个公钥，私钥不会泄漏出去，而公钥则是可以任意的对外发布的。用公钥进行加密的数据，只能用私钥才能解密。加密方首先从解密方获取公钥，然后利用这个公钥进行加密，把数据发送给解密方。解密方利用私钥进行解密。如果解密的数据在传输的过程中被第三方截获，也不用担心，因为第三方没有私钥，没有办法进行解密。公钥加密的问题还包括获取了公钥之后，加密方如何保证公钥来自于确定的一方，而不是某个冒充的机器。假设公钥不是来自我们信任的机器，那么就算我们用公钥加密也没有用，因为加密之后的数据是发送给了冒充的机器，该机器就可以利用它产生的私钥进行解密了。所以公钥加密里面比较重要的一步是身份认证。需要说明一下，一般的私钥加密都会比公钥加密快，所以大数据量的加密一般都会使用私钥加密，而公钥加密会作为身份验证和交换私钥的一个手段。数据一致性/完整性数据一致性说得是如何保证一段数据在传输的过程中没有遗漏、破坏或者修改过。一般来说，目前流行的做法是对数据进行hash，得到的hash值和数据一起传输，然后在收到数据的时候也对数据进行hash，将得到的hash值和传输过来的hash值进行比对，如果是不一样的，说明数据已经被修改过；如果是一样的，则说明极有可能是完整的。目前流行的hash算法有MD5和SHA-1算法。身份验证身份验证说的是，判断一个人或者机器是不是就是你想要联系的。也就是说如果A想要和B通信，一般来说开始的时候会交换一些数据，A怎么可以判断发送回来的数据就真的是B发送的呢？现实中有很多方法可以假冒一个机器。在SSH里面，这主要是通过公钥来完成的。首先客户端会有一个公钥列表，保存的是它信任的机器上面的公钥。在开始SSH连接之后，服务器会发送过来一个公钥，然后客户端就会进行查找，如果这个公钥在这个列表里面，就说明这个机器是真的服务器。当然实际的情况会复杂一些。实际上服务器不是真的发送公钥过来，因为这很容易被第三方盗取。这个在下面会详细的讲述。SSH2协议概况理解一个协议最好是从他的大概信息交流流程来了解。这个在《SSH: The Secure》里面有很详细的说明，我从中摘取了几个主要的图来说明一下。首先是一个主要的脉络图：可以看到，里面有几个关键的key：1.session key: 这个是用来作为secret key加密用的一个key，同时也作为每个ssh连接的标识ID。2.host key: 这个是用来作为server的身份验证用的。3.known-hosts: 这个是存在客户端的一个可信server的public key列表。4.user key: 这个是用来作为client的身份验证用的。当server和client交换了session key之后，所有的数据都会使用这个session来进行私钥加密。上面的图是一个很粗略的描述，下面这个图是对SSH2协议的一个详细的描述：上面这幅图大致的说明了SSH2协议的全景。首先SSH2协议分为3个子协议，分别是SSH-TRANS, SSH-AUTH和SSH-CONN。其中SSH-TRANS是传输协议，定义了传输的包和加密通道，其他两个协议是建立在这个协议之上的。SSH-AUTH是SSH里面用于验证客户端身份的协议。我们在用ssh命令输入密码的那一步实际上就是在这个阶段。可以看到的是，虽然传输的是用户名和密码，但是由于这个协议建立在SSH-TRANS之上，所以内容都是加密的，可以放心的传输。而SSH-CONN是真正的应用协议。在这里可以定义各种不同的协议，其中我们经常使用的scp、sftp还有正常的remote shell都是定义在这里的一种协议实现。这里的各种应用协议都要首先经过SSH-AUTH的验证之后才可以使用。这个三个协议之间的关系可以用下面这幅图来说明：其中SSH-TRANS是基本的协议，SSH-AUTH和SSH-CONN都是通过这个协议来实现安全加密的。虽然在时序上，SSH-CONN发生在SSH-AUTH之后，但是SSH-CONN并不依赖于SSH-AUTH。SSH ProtocolSSH-TRANS首先介绍一下SSH-TRANS的基本结构。在客户端连接上SSH服务器之后，会进行下面协议通信：客户端和服务端都向对方发送一个ssh版本字符串。字符串的格式如下：SSH-protoversion-softwareversion SP comments CR LF其中comment是可选的。 一般来说，目前用的ssh服务器和客户端一般都是支持SSH2，所以一个开始的version string一般就像下面这样：SSH-2.0-OpenSSH CR LF接下来的通信都用SSH自身定义的一个Binary Packet Protocol进行通信。这个Binary Packet Protocol其实就是将所有的用户数据都加上长度头，然后再进行加密。一个Packet的定义如下：uint32 packet_lengthbyte padding_lengthbyte[n1] payload; n1 = packet_length - padding_length - 1byte[n2] random padding; n2 = padding_lengthbyte[m] mac (Message Authentication Code - MAC); m = mac_length实际上所有的数据都放在payload里面。最后的mac是用来给数据计算校验码用的。在传输完ssh version string之后，客户端和服务端会开始进行key exchange，简称kex。Kex是用来让客户端和服务器生成本次通信的密钥和session ID的。 在kex之后，服务器和客户端都有一个key和hash，而私钥加密用的secret key就是通过这两个值来生成的。 具体的算法这里就不阐述了，可以去看SSH-TRANS的RFC[2]。在kex的最后一步，服务器会给客户端发送他自己的public key。 而客户端会通过在自己的known_hosts里面查找这个public key来验证服务器的身份。 至此，服务器和客户端都用来secret key，所以接下来所以数据都会进行加密，而不用担心信息泄露。 在kex之后，客户端就可以开始进行SSH-AUTH，也就是叫服务器验证自己的身份。SSH-AUTH在客户端的身份认证中，有3种预先定义好的方法可以用。1.public key2.password3.hostbased其中前两种是我们平常最常用的：password就是一般的密码验证，而public key就是一般的无密码验证。 当服务器成功的验证了客户端的身份之后，就会开始客户端请求的服务(service)了。 需要注意的是，服务器的验证方式并不是说3种方式任选其一，而是可以组合的。也就是说，服务器可以要求客户端同时通过Password和public key两种方式的认证。SSH-CONN这个也就是我们最后用到的一个服务的协议定义了。最常用的包括shell， port forwarding，X11 forwarding等等。在SSH-CONN里面最重要的就是Channel的机制了。在SSH-CONN里面，和服务器的通信基本上都是通过建立channel来通信的。 多个channel共享同一个ssh session。SSH协议自身定义如何负责多个channel之间消息的分发。 对于使用者来说只需要开多个channel就可以了。 比如说普通在ssh的客户端开启port forwarding的时候，就会开启一个shell channel和一个forwarding channel。 这一part对于程序员来说都是比较熟悉的。Library目前看的ssh的库主要有libssh和libssh2。其中的比较可以在这里找到。从接口上来说， libssh2的接口定义比较清晰，不过libssh2只能用于client端的开发，而libssh可以进行server和client端的开发。 而且libssh2的文档比libssh的文档要差些。在做开发的时候文档是一个很关键的因素。References:.SSH: The Secure Shell.SSH-TRANS.SSH-ARCH.SSH-AUTH.SSH-CONN

CMSIS 到底是什么？ CMSIS 到底是什么？先来看看ARM公司对CMSIS的定义：ARM® Cortex™ 微控制器软件接口标准 (CMSIS) 是 Cortex-M 处理器系列的与供应商无关的硬件抽象层。CMSIS 可实现与处理器和外设之间的一致且简单的软件接口，从而简化软件的重用，缩短微控制器开发人员新手的学习过程，并缩短新设备的上市时间。软件的创建是嵌入式产品行业的一个主要成本因素。通过跨所有 Cortex-M 芯片供应商产品将软件接口标准化（尤其是在创建新项目或将现有软件迁移到新设备时），可以大大降低成本。我们知道，不同厂家，比如FSL，ST，Energy Micro等不同厂家的内核都是使用Cortex M，但是这些MCU的外设却大相径庭，外设的设计、接口、寄存器等都不一样，因此，一个能够非常熟练使用STM32软件编程的工程师很难快速地上手开发一款他不熟悉的，尽管是Cortex M内核的芯片。而CMSIS的目的是让不同厂家的Cortex M的MCU至少在内核层次上能够做到一定的一致性，提高软件移植的效率。CMSIS的结构：CMSIS 包含以下组件：CMSIS-CORE：提供与 Cortex-M0、Cortex-M3、Cortex-M4、SC000 和 SC300 处理器与外围寄存器之间的接口CMSIS-DSP：包含以定点（分数 q7、q15、q31）和单精度浮点（32 位）实现的 60 多种函数的 DSP 库CMSIS-RTOS API：用于线程控制、资源和时间管理的实时操作系统的标准化编程接口CMSIS-SVD：包含完整微控制器系统（包括外设）的程序员视图的系统视图描述 XML 文件此标准可进行全面扩展，以确保适用于所有 Cortex-M 处理器系列微控制器。其中包括所有设备：从最小的 8 KB 设备，直至带有精密通信外设（例如以太网或 USB）的设备。（内核外设功能的内存要求小于 1 KB 代码，低于 10 字节 RAM）。框架看上去CMSIS-Core和CMSIS-DSP很好理解，但是CMSIS-RTOS不好理解，这玩意是干嘛的再看一张图吧：看了这张图的含义更清楚些，CMSIS-RTOS在用户的应用代码和第三方的RTOS Kernel直接架起一道桥梁，一个设计在不同的RTOS之间移植，或者在不同Cortex MCU直接移植的时候，如果两个RTOS都实现了CMSIS-RTOS，那么用户的应用程序代码完全可以不做修改。已经支持的MCU和工具链： 完整的CMSIS文档可以从ARM公司网站下载，大小有100多M字节。   如何使用CMSIS，需要哪些文件，以Freescale Kinetis L系列举例。独立于编译器的文件：● Cortex-M3内核及其设备文件(core_cm0.h + core_cm0.c)─ 访问Cortex-M0内核及其设备：NVIC等─ 访问Cortex-M0的CPU寄存器和内核外设的函数● 微控制器专用头文件(device.h)  -  MKL25Z4.h─ 指定中断号码(与启动文件一致)─ 外设寄存器定义(寄存器的基地址和布局)─ 控制微控制器其他特有的功能的函数(可选)● 微控制器专用系统文件(system_device.c)  -- system_MKL25Z4.h + system_MKL25Z4 .c ─ 函数SystemInit，用来初始化微控制器--函数 void SystemCoreClockUpdate (void); 用于获取内核时钟频率─SystemCoreClock，该值代表系统时钟频率─ 微控制器的其他功能(可选)● 编译器启动代码(汇编或者C)(startup_device.s)  -  startup_MKL25Z4.s for Keil─ 微控制器专用的中断处理程序列表(与头文件一致)─ 弱定义(Weak)的中断处理程序默认函数(可以被用户代码覆盖)一、前言二、CMSIS标准三、CMSIS文件1、Include文件2、Source文件四、总结一、前言使用过ARM单片机的朋友肯定听说过CMSIS，可以说CMSIS是开启ARM单片机的金钥匙，是不是想到单片机的启动文件了呢，对的，启动文件只是CMSIS的一部分，你是不是跟我一样对它感到既熟悉又陌生呢？二、CMSIS标准CMSIS ( Cortex Microcontroller Software Interface Standard )，翻译过来是ARM Cortex™ 微控制器软件接口标准 。这个标准是谁提的呢？提的这个标准是用来干什么的呢？这里不得不说说ARM和STM32、TI这些公司的关系了，ARM 是一个做芯片标准的公司，它负责的是芯片内核的架构设计，而TI、ST这样的公司，他们并不做标准，他们是芯片公司，他们是根据 ARM 公司提供的芯片内核标准设计自己的芯片。所以，任何一个做 Cortex M3 芯 片 ，他们的内核结构都是一样的，不同的是他们的存储器容量， 片上外设 IO 以及其他模块的区别。标准是谁提的呢？ARM跟芯片厂商共同提出的，目的就是为了不同芯片厂商生产的Cortex-M3芯片能在软件上基本兼容，各芯片厂商就得按照这个标准去编写自己芯片内核的驱动程序，比如系统函数的命名、芯片初始化启动流程等；STM32的官方库（标准库、HAL库、LL库）就是按照这个标准写的。这个标准是用来干什么的呢？如下图它向下负责与内核和各个外设直接打交道，向上提供实时操作系统用户程序调用的函数接口。分为 3 个基本功能层：核内外设访问层：ARM 公司提供的访问，定义处理器内部寄存器地址以及功能函数。中间件访问层：定义访问中间件的通用 API, 也是 ARM 公司提供。外设访问层：定义硬件寄存器的地址以及外设的访问函数。三、CMSIS文件看完上面的介绍是不是已经晕菜了，看完跟没看一样没看到实际的代码。下面就打开任意一工程下的CMSIS，我以STM32F4xx为例，在路径 \CMSIS\Device\ST\STM32F4xx 下，有Include、Source两个文件，我们主要用到了这两个文件下的微控制器专用头文件、启动代码 。1、Include文件在该文件中主要使用了stm32f4xx.h 和 stm32f429xx.h(不同的芯片这个文件不同)，如下图（1）在stm32f429xx.h 头文件包含了该芯片所有外设的寄存器定义和封装内存操作，直接操作这些寄存器就可以控制外设了，使用STM32任何型号的芯片都需要包含这个头文件。（2）在stm32f4xx.h中会根据芯片型号宏标识符(我这里是STM32F429xx )选择对应的头文件（stm32f429xx.h），如果定义了USE_HAL_DRIVER宏标识符，还会将HAL库外设驱动包含进来，具体包含关系为：2、Source文件在该文件中主要用到了 system_stm32f4xx.c、startup_stm32f429xx.s、stm32f429xx_flash.icf。如下图：startup_stm32f429xx.s启动文件的作用主要是进行堆栈的初始化，中断向量表以及中断函数定义等。会设置系统复位后，直接调用 SystemInit函数进行系统初始化。还有一个很重要的作用就是系统复位后引导进入 main函数。system_stm32f4xx.c主要是声明和定义了系统初始化函数 SystemInit 以及系统时钟更新函数 SystemCoreClockUpdate。SystemInit函数的作用是进行时钟系统的一些初始化操作以及中断向量表偏移地址设置，但它并没有设置具体的时钟值stm32f429xx_flash.icf定义了芯片的FLASH和RAM的起始和结束地址、以及大小STM32单片机的启动流程：四、总结CMSIS就是定义了一套芯片外设控制及编写规范的标准。我们在移植一个新的工程时，只需要修改添加：1、添加system_stm32f4xx.c、startup_stm32f429xx.s、stm32f429xx_flash.icf2、添加stm32f4xx.h3、修改全局宏标识 STM32F429xx

网页嵌入网页 嵌入网页文件<html> <head> <meta charset="utf-8" /> >title<page nesting</title> </head> <body> <! --Navigation column header location --> 80" 80"= height"100%"= width"header.html"iframe" scrolling="no" frameborder="no"></iframe> >"content" =iddiv<I am content</div> <! --End footer position --> 80" 80"= height"100%"= width"footer.html"iframe" scrolling="no" frameborder="no"></iframe> </body> </html>添加一个ifram 嵌入网页全屏显示按钮code here...上面代码，可以将header.html替换为其他网页文件Embed url<html> <head> >title<Cloud Music</title> </head> <body> <iframe src="http://www.tuwei.space/home.html" width="100%" height="1000" frameborder="0" allowfullscreen="true"></iframe> </body> </html>上面代码，width 是100%, 表示可以根据窗口大小自动铺满，allowfullscreen表示容许全屏Embed search engine dialog box<form action="http://www.baidu.com/baidu" target="_blank"> <table bgcolor="#FFFFFF"><tr><td> <input name=tn type=hidden value=baidu> <a href="http://www.baidu.com/"> <img src="http://img.baidu.com/img/logo-80px.gif" alt="Baidu" align="bottom" border="0"> </a> <input type=text name=word size=30> <input type="submit" value="百度搜索"> </td></tr> </table> </form>效果： 添加全屏按钮<html> <head> <style> #myFrame { width: 100vw; height: 100vh; } .fullscreen { position: fixed; top: 0; left: 0; width: 100vw; height: 100vh; z-index: 9999; background-color: #ffffff; } </style> </head> <body> <button onclick="openFullscreen()">全屏显示</button> <div id="myFrame"> <iframe id="iframeContent" src="https://www.pilisf.com" width="100%" height="1000" frameborder="0" allowfullscreen="true"></iframe> <div id="fullscreenOverlay" class="fullscreen" style="display:none;"></div> </div> <script> var iframe = document.getElementById("iframeContent"); function openFullscreen() { var fullscreenOverlay = document.getElementById("fullscreenOverlay"); if (iframe.requestFullscreen) { iframe.requestFullscreen(); } else if (iframe.mozRequestFullScreen) { iframe.mozRequestFullScreen(); } else if (iframe.webkitRequestFullscreen) { iframe.webkitRequestFullscreen(); } else if (iframe.msRequestFullscreen) { iframe.msRequestFullscreen(); } else { fullscreenOverlay.style.display = "block"; } } </script> </body> </html>效果：点击全屏显示，嵌入网页就会全屏显示