GSC: Difference between revisions
No edit summary |
No edit summary |
||
Line 6: | Line 6: | ||
The second generation GSC (D2) uses the Ti50 firmware. It shares some parts in common with Cr50, but appears to use some rust code as well (source?). | The second generation GSC (D2) uses the Ti50 firmware. It shares some parts in common with Cr50, but appears to use some rust code as well (source?). | ||
The firmware is signed by google and appears to be impossible to replace. Even if you could replace it, the firmware has many closed source components that would have to be recreated. | |||
== CCD == | == CCD == | ||
Line 15: | Line 16: | ||
=== SPI === | === SPI === | ||
Using flashrom, one can flash the main AP SPI flash (and the EC SPI flash on select platforms) over CCD. To do so, add `-p raiden_debug_spi:target=AP` to the flashrom command to select the raiden programmer. The AP target will flash the main AP SPI flash. On boards with a dedicated EC SPI (only older ones), you can use the EC target as well. Newer ECs with embedded flash can be programmed with google's flash_ec script in cros_sdk (TODO: Add instructions to flash without cros_sdk). | Using flashrom, one can flash the main AP SPI flash (and the EC SPI flash on select platforms) over CCD. To do so, add `-p raiden_debug_spi:target=AP` to the flashrom command to select the raiden programmer. The AP target will flash the main AP SPI flash. On boards with a dedicated EC SPI (only older ones), you can use the EC target as well. Newer ECs with embedded flash can be programmed with google's flash_ec script in cros_sdk (TODO: Add instructions to flash without cros_sdk). | ||
== RO Firmware verification == | |||
This feature only exists on Ti50, and only enabled on newer builds (starting when?). Google supposedly decided that SPI WP isn't enough, and the contents of RO firmware must be hashed and verified. Normally, this would be done with a SoC-specific secureboot mechanism, such as Intel BootGuard. To still allow for users to replace the firmware, Google put the RO firmware verification in the GSC. On supported GSCs, the GSC will verify the hashed contents of RO firmware against a hash stored in TPM NVRAM. If the hash doesn't match, the EC will be held in reset, preventing the device from booting. RO verification can be disabled by setting the AllowUnverifiedRo CCD flag to always. This can be done with gsctool or the GSC UART console. Alternatively, RO verification can be temporarily disabled by a [https://www.chromium.org/chromium-os/developer-library/guides/device/ro-firmware-unlock/#recovering-a-device-that-doesnt-boot special key combination]. |
Latest revision as of 17:37, 5 September 2025
GSC (Google Security Chip) is a custom chip created by Google for security use on chromebooks and pixel phones. It is marketed as the "Titan Chip". The design is proprietary but we know it uses risc-v cores (source?). This page will only cover usage in chromebooks.
Firmware
There are two versions of the firmware, corresponding to two versions of the GSC. The first generation GSC (H1) uses the Cr50 firmware. It is based on cros ec and is partially open source. Certain components of the firmware are only available internally at google.
The second generation GSC (D2) uses the Ti50 firmware. It shares some parts in common with Cr50, but appears to use some rust code as well (source?).
The firmware is signed by google and appears to be impossible to replace. Even if you could replace it, the firmware has many closed source components that would have to be recreated.
CCD
Perhaps the most useful function of the GSC is case-closed debugging (CCD). CCD allows you to get access to 3-4 uarts, and flash the main firmware, along with the ec firmware. To get access to CCD, you need a "SuzyQ" cable. This special usb cable has a type c connector on one end and a type a connector on the other. The type c connector goes into the chromebook's debug usb-c port and tells the GSC to enable debug mode. The GSC will act as a usb device which the host can talk to use the custom "raiden" protocol.
UART
The usb_serial_simple driver on linux will automatically create 3-4 ttyUSB* devices for uart access. The first will be for GSC uart, the second for AP uart, and the third one is EC uart. On Ti50, an additional 4th char dev will give FPMCU uart.
SPI
Using flashrom, one can flash the main AP SPI flash (and the EC SPI flash on select platforms) over CCD. To do so, add `-p raiden_debug_spi:target=AP` to the flashrom command to select the raiden programmer. The AP target will flash the main AP SPI flash. On boards with a dedicated EC SPI (only older ones), you can use the EC target as well. Newer ECs with embedded flash can be programmed with google's flash_ec script in cros_sdk (TODO: Add instructions to flash without cros_sdk).
RO Firmware verification
This feature only exists on Ti50, and only enabled on newer builds (starting when?). Google supposedly decided that SPI WP isn't enough, and the contents of RO firmware must be hashed and verified. Normally, this would be done with a SoC-specific secureboot mechanism, such as Intel BootGuard. To still allow for users to replace the firmware, Google put the RO firmware verification in the GSC. On supported GSCs, the GSC will verify the hashed contents of RO firmware against a hash stored in TPM NVRAM. If the hash doesn't match, the EC will be held in reset, preventing the device from booting. RO verification can be disabled by setting the AllowUnverifiedRo CCD flag to always. This can be done with gsctool or the GSC UART console. Alternatively, RO verification can be temporarily disabled by a special key combination.