The device does not belong to OEMs, to Google, to Chrome OS, or to anyone else. Since the start of the project, the Chrome OS team strongly believes that when someone buys a device, they own it fully. Some people ask why we allow the RO firmware to be made writable in the first place if it‘s so critical to the security of Chrome OS.
Usb write protection remover software#
One case where we're using this is devices that originally get flashed with development signing keys, but eventually get upgraded to production keys, after which software WP would get enabled. This allows us to ship systems with hardware WP on, but leaving software WP off until a point in time where software decided to engage it. The Block Protect, BP, bits mask the regions within the SPI flash data address space such that access that results in mutations can be controlled. In the hardware protection mode, the Write Status Register (WRSR) instruction is no longer accepted for execution and the SRWD bit and Block Protect bits (BP2, BP1, BP0) are read only. The hardware protection mode requires SRWD set to 1 and WP# pin signal asserted low. The Status Register Write Disable (SRWD), a non-volatile bit, is operated together with Write Protection (WP#) pin for providing hardware protection mode. In addition to the hardware WP signal, there is a software WP setting that allows us some more flexibility in managing write protection. Note that even in case of the devices protected by the SE, opening up the device and disconnecting the battery would still disable write protection. This secure element firmware is fully authored and controlled by Google.
That separate chip is often referred to as a secure element (SE), the firmware controlling the SE is called Cr50. It still takes long time and physical presence to diable write protection, and can be configured such that only the device owners are authorized to disable write protection. That way we have more flexible control over the WP signal. In newer devices, we've moved away from the WP signal being controlled by a physical screw and to a separate chip controlling the WP signal. Our security goals have been that, in order to disable flash WP, someone needs extended physical access to the device, and it would take a non-trivial amount of effort and time to open up the device in order to remove the WP screw (and thus disable the WP signal making the RO firmware writable from software). Historically, the WP signal has been controlled by a physical screw (colloquially referred to as the “WP screw”) inside of the Chromebook. 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.
Usb write protection remover full#
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 kommentar(er)
