![]() This is a somewhat tricky topic since write protection implementations can differ between chips and the hardware write protection has changed over time. Thus we can confidently tell customers: if you can reboot a Chromebook into the login screen, you know it's secure. ![]() kernel/root filesystem) and interrupt the normal boot flow initiating the Chrome OS recovery process. This is a physical line to the flash (where the RO firmware is stored) that tells the flash chip to mark some parts as read-only and to reject any modification requests. So even if Chrome OS was full of bugs and was exploited to gain all the permissions for direct write access to all pieces of hardware in the system, any RO firmware write attempts from code running on the CPU would be stopped by the flash chip itself. Then when the system reboots, the verified boot process would detect any modifications or corruption to the hard drive (e.g. We guarantee the RO firmware integrity via the Write Protect (WP) signal. The point is that the entire system security hinges upon the integrity of the RO firmware. There might be other components that are loaded/chained (read-write (RW) firmware, etc.) before loading the Linux kernel (see Verified Boot for more information), but those details are immaterial here. ![]() The RO firmware is the first thing executed at power on/boot and is responsible for verifying & loading the next piece of code in the system which is usually the Linux kernel. The core of the Chrome OS security model is rooted in a firmware image that we fully control and whose integrity we can guarantee. All existing designs have accomplished this through a dedicated flash part which is guaranteed to be read-only once the device is shipped to customers. This is colloquially referred to as the “read-only (RO) firmware”.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |