Explaining Intel Rapid Start Technology
Jul. 2nd, 2013 03:50 pm![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
mjg59Recent Intel-based systems often implement something called Intel Rapid Start Technology. Like many things with the word "Technology" in the name, there's a large part of this that's marketing. The relatively small amount of technical documentation available implies that it's tied to your motherboard chipset and CPU, but as far as I can tell it's entirely implemented in firmware and could work just as well on, say, a Cyrix on a circa 1996 SIS-based motherboard if someone wrote the BIOS code[1]. But since nobody has, we're stuck with the vendors who've met Intel's requirements and licensed the code.
The concept of IRST is pretty simple. There's a firmware mechanism for setting a sleep timeout. If you suspend your computer and this timeout expires, it'll resume. However, instead of handing control back to the OS, the firmware just copies the entire contents of RAM to a special partition and turns the computer off. Next time you hit the power button, the firmware dumps the partition contents back into RAM and resumes as if nothing had changed. This takes a few seconds longer than resume from S3 but is far faster than resume from hibernation since it starts the moment the system gets power.
At a more technical level, it's a little more complicated. The first thing to know about this feature is that it's entirely invisible unless your hard drive is set up correctly. There needs to be a partition that's at least the size of your system's physical RAM. For GPT systems, this needs to have a type GUID of D3BFE2DE-3DAF-11DF-BA-40-E3A556D89593. For MBR systems, you need a partition type of 0x84[2]. If the firmware doesn't find an appropriate partition then the OS will get no indication that the firmware supports it. Boo.
(The second thing is that it seems like it really does have to be on an SSD, and if you try to do this on spinning media your firmware will ignore it anyway)
If all the prerequisites are in place, an ACPI device with an HID of INT3392 will exist. It has four methods associated with it: GFFS, SFFS, GFTV and SFTV. GFFS returns an integer representing the events that will cause the system to wake up from S3 and suspend to SSD. The system will wake after the timeout expires if bit 0 is set, and will wake when the battery becomes critically low if bit 1 is set. The other bits appear to be unused at the moment[3]. SFFS sets the wakeup events, using the same bit values as GFFS. GFTV returns an integer containing the current wakeup timeout in minutes. SFTV sets it. Values above 1440 (ie, 24 hours) seem to be considered invalid - if I set them the value instead ends up as 10 and the timeout flag gets cleared from the wakeup events field.
I've submitted a patch that adds a sysfs interface for setting these values, and unless anyone objects it'll probably end up in 3.11. There's still the remaining question of how userspace should make use of these, and also how installers should behave when it comes to systems that support IRST. As previously mentioned, there's no obvious indication to the OS that the feature is supported unless the appropriate partition already exists. The easiest way to deal with this is for installers to default to retaining any partitions with the magic IDs, but I'm still looking into whether it's possible to get the firmware to cough up some more information so it can be created automatically even if the drive's entirely blank.
And now, having got this working on a test machine, I just need to split my Thinkpad's swap partition in half and make sure it works here as well. Woo.
[1] Note: I am not going to do this.
[2] Conveniently, the same as the partition type that APM systems used for suspend to disk back when dubstep hadn't been invented yet
[3] At least, if you attempt to set them they get ignored.
The concept of IRST is pretty simple. There's a firmware mechanism for setting a sleep timeout. If you suspend your computer and this timeout expires, it'll resume. However, instead of handing control back to the OS, the firmware just copies the entire contents of RAM to a special partition and turns the computer off. Next time you hit the power button, the firmware dumps the partition contents back into RAM and resumes as if nothing had changed. This takes a few seconds longer than resume from S3 but is far faster than resume from hibernation since it starts the moment the system gets power.
At a more technical level, it's a little more complicated. The first thing to know about this feature is that it's entirely invisible unless your hard drive is set up correctly. There needs to be a partition that's at least the size of your system's physical RAM. For GPT systems, this needs to have a type GUID of D3BFE2DE-3DAF-11DF-BA-40-E3A556D89593. For MBR systems, you need a partition type of 0x84[2]. If the firmware doesn't find an appropriate partition then the OS will get no indication that the firmware supports it. Boo.
(The second thing is that it seems like it really does have to be on an SSD, and if you try to do this on spinning media your firmware will ignore it anyway)
If all the prerequisites are in place, an ACPI device with an HID of INT3392 will exist. It has four methods associated with it: GFFS, SFFS, GFTV and SFTV. GFFS returns an integer representing the events that will cause the system to wake up from S3 and suspend to SSD. The system will wake after the timeout expires if bit 0 is set, and will wake when the battery becomes critically low if bit 1 is set. The other bits appear to be unused at the moment[3]. SFFS sets the wakeup events, using the same bit values as GFFS. GFTV returns an integer containing the current wakeup timeout in minutes. SFTV sets it. Values above 1440 (ie, 24 hours) seem to be considered invalid - if I set them the value instead ends up as 10 and the timeout flag gets cleared from the wakeup events field.
I've submitted a patch that adds a sysfs interface for setting these values, and unless anyone objects it'll probably end up in 3.11. There's still the remaining question of how userspace should make use of these, and also how installers should behave when it comes to systems that support IRST. As previously mentioned, there's no obvious indication to the OS that the feature is supported unless the appropriate partition already exists. The easiest way to deal with this is for installers to default to retaining any partitions with the magic IDs, but I'm still looking into whether it's possible to get the firmware to cough up some more information so it can be created automatically even if the drive's entirely blank.
And now, having got this working on a test machine, I just need to split my Thinkpad's swap partition in half and make sure it works here as well. Woo.
[1] Note: I am not going to do this.
[2] Conveniently, the same as the partition type that APM systems used for suspend to disk back when dubstep hadn't been invented yet
[3] At least, if you attempt to set them they get ignored.
![[identity profile]](https://www.dreamwidth.org/img/silk/identity/openid.png){kind=small}
Threat to dm-crypt
Date: 2013-07-03 06:31 pm (UTC)Re: Threat to dm-crypt
Date: 2013-07-03 06:43 pm (UTC)What goes around comes around
Date: 2013-07-03 07:12 pm (UTC)Re: Threat to dm-crypt
Date: 2013-07-03 07:26 pm (UTC)Encrypting the root file system or whole disk would require scrubbing the keys from RAM before suspend, being able to prompt for credentials on resume, and reattach. One-time keys for encrypted swap would have to be written into that secure storage area too and somehow re-opened. You still have to hope nothing confidential remains anywhere in RAM. And/or do a scrub of the rapid-start partition after resume, hoping the SSD is actually overwriting the same blocks.
In summary, if the machine might be still logged into something non-public, like a website account or email box, or has been used to view/create/store anything since booting that should stay private, this feature is junk and you wouldn't want to use it.
Re: Threat to dm-crypt
Date: 2013-07-03 07:37 pm (UTC)Re: Threat to dm-crypt
Date: 2013-07-03 08:07 pm (UTC)Zeroing on resume is some comfort, probably reducing the persistence of this on disk.
But whilst appearing to be a convenience, at least temporarily it must write a snapshot of the user's activities since the last cold boot onto non-volatile storage. (Mostly recent, and falling off logarithmically by age). That data might stay there for months until the device is stolen, sent away for repair, sold or disposed of. It might include documents and media, session cookies, password keyrings, random excerpts of keyboard input or copies things from removable media, and probably lots of email and Internet history, even if that was transferred encrypted. And still recoverable if since deleted on-disk with a 'secure erase', or encryption products used for swap, individual files, containers or the whole disk.
Re: Threat to dm-crypt
Date: 2013-07-03 08:14 pm (UTC)Reading secrets from the disk will generally leave behind no evidence. All the bad guy needs is a screwdriver. Reading them from memory is very likely to leave evidence in the form of scrambled/lost memory. In any event I'd claim the cost to the bad guys is $10 to grab data from disk (leaving no evidence it has been done) versus $1000 to grab from ram but being evident. Not the same order of magnitude as usual crypto gives ("$millions") but a noticeable difference.
Re: Threat to dm-crypt
Date: 2013-07-03 08:34 pm (UTC)Requires SSD?
Date: 2013-07-03 11:08 pm (UTC)Sounds like an effort to goose the sales of SSDs. I can't think of any technical reason that IRST wouldn't work on a spining disk. I can think of a marketing reason, though -- it won't feel so rapid any more.
Re: Requires SSD?
Date: 2013-07-03 11:55 pm (UTC)Interesting post
Date: 2013-07-04 12:15 am (UTC)You brought up a point relating to trusting your firmware. Since it's probably proprietary, and since it's not possible to trust proprietary stuff, maybe you can get in on the coreboot team and give the world a Free Software BIOS? Wouldn't that be awesome?
The bonus is that you wouldn't have to fight with arbitrary binary code, and you could implement awesome things!
Cheers,
James
Re: Interesting post
Date: 2013-07-04 12:23 am (UTC)Quirks?
Date: 2013-07-04 12:33 am (UTC)Re: Quirks?
Date: 2013-07-04 12:36 am (UTC)Re: Threat to dm-crypt
Date: 2013-07-04 01:08 am (UTC)Re: What goes around comes around
Date: 2013-07-04 05:56 am (UTC)Intel Rapid Start Technology
Date: 2013-07-04 06:28 am (UTC)The fujitsu service is telling me that the disk is OK! but they are working on found out why the SSD partition has been disappeared.
Is it possible that this feature (intel rapid start technology) is being glued with the specific board or is it possible that a UEFI setting exist that tells the board the specs of the disk ?
It seems idiotic to me to exist such a connection but its being 3 weeks now and none of the fujitsu technicians cant reply to me on this.
btw This is my second UH572. I had the same problem with the board on the first but they have replaced it as the problem occurred 3 days after the purchase of it
Thanks for this!
Date: 2013-07-04 06:54 am (UTC)I have an SSD in my machine that is currently blank while I try to figure out what to use it for. So I think I will leave this enabled for a bit and see how it goes. So far so good.
Unfortunately, the firmware only allows for up to 3 hours before the IRST kicks in. You say that 24 hours is invalid, but does adjustment with your patch allow you to go over the bios listed max at all?
PS D'oh, I got the anti-spam question wrong...
Re: Requires SSD?
Date: 2013-07-04 09:07 am (UTC)Re: Threat to dm-crypt
Date: 2013-07-04 10:13 am (UTC)You come back from lunch, spill your coffee over the device and it won't switch back on. You send the machine for repair or sell it as spares, but all manner of sensitive data is retrievable from SSD. Even if a person took sensible precautions such as using a master passphrase to protect stored passwords, use a corporate VPN and password-protected authentication keys, encrypt your emails, all removable media, files, swap space or whole disk...
Re: Requires SSD?
Date: 2013-07-04 10:34 am (UTC)Although, it could be optimised by encrypting the data written out to disk and then only the key needs to be erased. Already that would improve the security/privacy situation, especially if hardware crypto were used, and maybe a 'reset' button to erase/change the key.
Re: Thanks for this!
Date: 2013-07-04 01:58 pm (UTC)Re: Thanks for this!
Date: 2013-07-04 01:58 pm (UTC)Re: Intel Rapid Start Technology
Date: 2013-07-04 01:59 pm (UTC)Re: Threat to dm-crypt
Date: 2013-07-04 05:13 pm (UTC)Also, many SSDs these days have strong encryption tied to your BIOS disk password. Not as safe as dm-crypt, but still decent.