Re: [arch-general] Rerun bootloader from initramfs

2015-11-20 Thread Mauro Santos
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


Re: [arch-general] Rerun bootloader from initramfs

2015-11-20 Thread Jayesh Badwaik
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


Re: [arch-general] Rerun bootloader from initramfs

2015-11-20 Thread Mauro Santos
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


Re: [arch-general] Rerun bootloader from initramfs

2015-11-20 Thread Mauro Santos
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


Re: [arch-general] Rerun bootloader from initramfs

2015-11-20 Thread Mauro Santos
On 20-11-2015 16:13, Damjan Georgievski wrote:
> On 20 November 2015 at 17:04, Mauro Santos  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.
>>>
>>> [1]https://wiki.archlinux.org/index.php/Disk_encryption
>>
>> 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


Re: [arch-general] Rerun bootloader from initramfs

2015-11-20 Thread Aron Widforss

On 11/20/2015 05:13 PM, Damjan Georgievski wrote:

On 20 November 2015 at 17:04, Mauro Santos  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.

[1]https://wiki.archlinux.org/index.php/Disk_encryption


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


Re: [arch-general] Rerun bootloader from initramfs

2015-11-20 Thread Jayesh Badwaik
> 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


Re: [arch-general] Rerun bootloader from initramfs

2015-11-20 Thread Damjan Georgievski
On 20 November 2015 at 17:04, Mauro Santos  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.
>>
>> [1]https://wiki.archlinux.org/index.php/Disk_encryption
>
> 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


Re: [arch-general] Rerun bootloader from initramfs

2015-11-20 Thread Mauro Santos
On 20-11-2015 17:19, Joan Aymà wrote:
> Why should not be easier to boot following Disk_Encryption on the wiki[1]?
> 
> Regards.
> 
> [1]https://wiki.archlinux.org/index.php/Disk_encryption

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


Re: [arch-general] Rerun bootloader from initramfs

2015-11-20 Thread Joan Aymà
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).
> 


Re: [arch-general] Rerun bootloader from initramfs

2015-11-20 Thread Mauro Santos
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


Re: [arch-general] Rerun bootloader from initramfs

2015-11-20 Thread Bennett Piater
> 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



signature.asc
Description: OpenPGP digital signature


[arch-general] Rerun bootloader from initramfs

2015-11-20 Thread 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.

-- 
Mauro Santos