[arch-general] Rerun bootloader from initramfs
I've been searching if rerunning the bootloader from an initramfs is possible but my searches have come up empty. Anyone here knows how to do it or if it is possible? I would be happy if someone could provide me with some pointers. -- Mauro Santos
I've been searching if rerunning the bootloader from an initramfs is possible but my searches have come up empty.
Anyone here knows how to do it or if it is possible? I would be happy if someone could provide me with some pointers.
I'm afraid I can't help you, but now I'm curious as to why you would want to do that :) Cheers, Bennett -- GPG fingerprint: 871F 1047 7DB3 DDED 5FC4 47B2 26C7 E577 EF96 7808
On 20-11-2015 12:59, Bennett Piater wrote:
I'm afraid I can't help you, but now I'm curious as to why you would want to do that :)
For the specific case of self encrypting disks. When you turn the system on the disk will present what is called a shadow mbr, where a pre boot authentication (PBA) image is stored. This image will ask the user for a password (or keyfile or something else) to unlock the disk, if unlocking is successful only then the "normal" disk is accessible. If using a PBA image based on arch, leveraging what is provided by mkinitcpio, then the sequence is like this: cold boot - run PBA image and authenticate - reboot - boot "normal" system. If it could be possible to (re)run the bootloader right from the initramfs of the PBA image, this time using the bootloader of the "normal" system, then the intermediate reboot step would not be needed and would streamline the process a bit (and make it faster). -- Mauro Santos
Why should not be easier to boot following Disk_Encryption on the wiki[1]? Regards. [1]https://wiki.archlinux.org/index.php/Disk_encryption El 20/11/15 a les 15:08, Mauro Santos ha escrit:
On 20-11-2015 12:59, Bennett Piater wrote:
I'm afraid I can't help you, but now I'm curious as to why you would want to do that :)
For the specific case of self encrypting disks.
When you turn the system on the disk will present what is called a shadow mbr, where a pre boot authentication (PBA) image is stored. This image will ask the user for a password (or keyfile or something else) to unlock the disk, if unlocking is successful only then the "normal" disk is accessible. If using a PBA image based on arch, leveraging what is provided by mkinitcpio, then the sequence is like this: cold boot - run PBA image and authenticate - reboot - boot "normal" system.
If it could be possible to (re)run the bootloader right from the initramfs of the PBA image, this time using the bootloader of the "normal" system, then the intermediate reboot step would not be needed and would streamline the process a bit (and make it faster).
On 20-11-2015 17:19, Joan Aymà wrote:
Why should not be easier to boot following Disk_Encryption on the wiki[1]?
Regards.
Because I'm talking about this [1] and not software based encryption. [1] https://en.wikipedia.org/wiki/Hardware-based_full_disk_encryption -- Mauro Santos
On 20 November 2015 at 17:04, Mauro Santos <registo.mailling@gmail.com> wrote:
On 20-11-2015 17:19, Joan Aymà wrote:
Why should not be easier to boot following Disk_Encryption on the wiki[1]?
Regards.
Because I'm talking about this [1] and not software based encryption.
[1] https://en.wikipedia.org/wiki/Hardware-based_full_disk_encryption
I'd sincerely advice against using these 'hardware' disk encryptions. what happens when your motherboard is at fault, and you need the data on the disk *now* and it wont work in a USB enclosure? anyway, maybe you could use kexec in your PBA and run the installed linux kernel with that. -- damjan
On 11/20/2015 05:13 PM, Damjan Georgievski wrote:
On 20 November 2015 at 17:04, Mauro Santos <registo.mailling@gmail.com> wrote:
On 20-11-2015 17:19, Joan Aymà wrote:
Why should not be easier to boot following Disk_Encryption on the wiki[1]?
Regards.
Because I'm talking about this [1] and not software based encryption.
[1] https://en.wikipedia.org/wiki/Hardware-based_full_disk_encryption
I'd sincerely advice against using these 'hardware' disk encryptions. what happens when your motherboard is at fault, and you need the data on the disk *now* and it wont work in a USB enclosure?
anyway, maybe you could use kexec in your PBA and run the installed linux kernel with that.
And when a vuln is found it is helluva lot harder to fix the hardware than just patchinig the system. Vänligen, Aron Widforss
On 20-11-2015 16:54, Aron Widforss wrote:
And when a vuln is found it is helluva lot harder to fix the hardware than just patchinig the system.
Unless said vuln is easily exploitable by garden variety thieves I'll take my chances. For other adversaries see: http://xkcd.com/538/ -- Mauro Santos
On 20-11-2015 16:13, Damjan Georgievski wrote:
On 20 November 2015 at 17:04, Mauro Santos <registo.mailling@gmail.com> wrote:
On 20-11-2015 17:19, Joan Aymà wrote:
Why should not be easier to boot following Disk_Encryption on the wiki[1]?
Regards.
Because I'm talking about this [1] and not software based encryption.
[1] https://en.wikipedia.org/wiki/Hardware-based_full_disk_encryption
I'd sincerely advice against using these 'hardware' disk encryptions. what happens when your motherboard is at fault, and you need the data on the disk *now* and it wont work in a USB enclosure?
I am well aware of that problem, that's a risk I'm willing to take. Meanwhile I'm enjoying how quiet and snappy it is now vs SW encryption on my old laptop that doesn't support AES-NI ;)
anyway, maybe you could use kexec in your PBA and run the installed linux kernel with that.
I did think about this but it would make me parse bootloader configuration files to find all the options I would need to pass on the kernel's command line. I suspect that it would also force me to use a larger PBA image that might have to be updated more often, which I'd like to avoid. -- Mauro Santos
Because I'm talking about this [1] and not software based encryption. [1] https://en.wikipedia.org/wiki/Hardware-based_full_disk_encryption Shouldn't BIOS take care of that?
-- Cheers Jayesh Badwaik
On 20-11-2015 16:24, Jayesh Badwaik wrote:
Because I'm talking about this [1] and not software based encryption. [1] https://en.wikipedia.org/wiki/Hardware-based_full_disk_encryption Shouldn't BIOS take care of that?
Not really, BIOS is old and it doesn't know anything about OPAL drives. I don't know about UEFI machines but I suspect not many know about SEDs/OPAL either. On the other hand, you don't know what kind of treatment the BIOS would do to the password before sending it to the SED, one bios could send it plaintext, others could send key scancodes, you don't want to get anywhere near that kind of nonsense. This would mean that you might not be able to unlock the disk if you move it to another machine. -- Mauro Santos
On Friday, November 20, 2015 05:46:18 PM Mauro Santos wrote:
Not really, BIOS is old and it doesn't know anything about OPAL drives. I don't know about UEFI machines but I suspect not many know about SEDs/OPAL either. By BIOS, I meant UEFI, sorry about that. My UEFI is from 2013 (Dell Latitude) and it knows enough about SEDs. I use SSDs and I use Hardware Based Encryption with it (Samsung 850 Evo).
On the other hand, you don't know what kind of treatment the BIOS would do to the password before sending it to the SED, one bios could send it plaintext, others could send key scancodes, you don't want to get anywhere near that kind of nonsense. This would mean that you might not be able to unlock the disk if you move it to another machine. That is something I have never paid any attention to. But I can set a password through the linux's hdparm utility, and then you can unlock it from the the BIOS and vice-versa. So, I think that makes it standard enough, but not sure.
-- Cheers Jayesh Badwaik Center for Applicable Mathematics Tata Institute of Fundamental Research
On 20-11-2015 17:57, Jayesh Badwaik wrote:
On Friday, November 20, 2015 05:46:18 PM Mauro Santos wrote:
Not really, BIOS is old and it doesn't know anything about OPAL drives. I don't know about UEFI machines but I suspect not many know about SEDs/OPAL either. By BIOS, I meant UEFI, sorry about that. My UEFI is from 2013 (Dell Latitude) and it knows enough about SEDs. I use SSDs and I use Hardware Based Encryption with it (Samsung 850 Evo).
On the other hand, you don't know what kind of treatment the BIOS would do to the password before sending it to the SED, one bios could send it plaintext, others could send key scancodes, you don't want to get anywhere near that kind of nonsense. This would mean that you might not be able to unlock the disk if you move it to another machine. That is something I have never paid any attention to. But I can set a password through the linux's hdparm utility, and then you can unlock it from the the BIOS and vice-versa. So, I think that makes it standard enough, but not sure.
This is starting to get off-topic but here goes, if you say you can lock your ssd with hdparm and unlock it with the UEFI firmware then what you are using is a plain old ata security password, which in the case of Samsung they claim will encrypt the media encryption key (MEK). This method of providing a password to protect the MEK is not standard and I guess they do it as a convenience for the user. What I've been talking about from the start is SEDs that support TCG Opal[1]. [1] https://en.wikipedia.org/wiki/Opal_Storage_Specification -- Mauro Santos
participants (6)
-
Aron Widforss
-
Bennett Piater
-
Damjan Georgievski
-
Jayesh Badwaik
-
Joan Aymà
-
Mauro Santos