This project has moved. For the latest updates, please go here.

Two Boot Loader questions!

Topics: Feature Requests, Users Discussion
Mar 10, 2015 at 8:23 PM
It has been about 3 years since I read all of Intel's whitepapers on their processors and other docs on typical booting procedure. I remember (possibly incorrectly) that it is possible to switch Intel/AMD processors into 64-bit mode to do some computing, and the switch back to 16-bit mode to either use BIOS services or boot the computer (without corruption). If this is possible, it could mean significantly faster hashing at boot time.

So is this technically possible or is my memory just bad?

And a second question: How much disk space do you have for the boot loader currently? Is it possible to use sectors at the end of the disk for extra storage? How about storing the boot loader on an external USB thumbdrive and that is used to boot the system drive (then in theory you have GB's of space)!
Coordinator
Mar 11, 2015 at 8:59 AM
Thank you for sharing these ideas.

Actually, another user pointed out a similar capability on an issue discussion because I was planning to implement a multi-stage bootloader whereas one can have a single 16-bit bootloader that can call 32-bit/64-bit code.

In order to implement this, extra assembly code have to be written using nasm or yasm to implement this since the current 16-bit legacy Microsoft compiler that is used has many limitations.

So, technically this is possible. It is just waiting to be done!

The maximum allowed size for VeraCrypt bootloader is 32 KB: first half is used for the actual bootloader and the second half is use to store a second copy of the bootloader that will be used if the first copy has been corrupted (this can happen because some software can write data to the first drive track as explained here) . The only exception is when using a cascade cipher in which cases the bootloader is too big to be copied twice (around 19 KB) so we are vulnerable in this case to bootloader corruption and that's why a warning is displayed when cascade is chosen for boot encryption.

Using extra space at the end of the partition is not always possible as there may not be free space there. For in-place encryption, we perform an NTFS shrink operation to put all data at the beginning of the partition because we need space at the end of it in order to store some data. We don't do this for system encryption because the system is running and shrinking operation can not be performed while there are write operations.

Implementing support for booting using an external drive is already planned: https://veracrypt.codeplex.com/workitem/27
Mar 11, 2015 at 9:43 PM
Edited Mar 11, 2015 at 9:44 PM
If it helps any, I have used MASM (www.masm32.com) with version 8.0 of ML.EXE (and link16.exe) to create mixed-code bootloaders before. MASM may be your best bet for bootloader creation. MASM is free and newer versions of ML.EXE are released by Microsoft from time to time, also for free.
Coordinator
Mar 12, 2015 at 12:44 AM
Thank you for the hints.

As you seem to have a good knowledge on this, I wanted share some elements:
  • If we choose to call 32-bit code from 16-bit bootloader, we can't address memory using 32-bit registers so we have to use an implementation were computation is done in 32-bit using memory accessed through 16-bit. This can be done in assembly with no problem but I want to re-use the C code of cryptographic routines without rewriting everything in assembly, which is a huge amount of work. Do you have any advices on this?
  • If we use a 2-stage bootloader, the first stage would run in real mode while the second stage would execute in 32-bit protected mode, giving us full performance. For now, the protected mode code is not written yet and it appears that it can be tricky to implement correctly. Again, any advices are welcomed.
Mar 12, 2015 at 3:36 AM
There is a third option, which you can consider. But it may be more difficult because all of the bootloader code needs to be in ASM (so this includes the hashing algorithms, and encryption algorithms, and BIOS disk services hook). It is not necessary to use a two-stage bootloader to take advantage of mixed-code (a better term may be mixed-mode). A good guide can be found here:

http://wiki.osdev.org/Real_Mode

The general idea is that the 16-bit real mode code can be mixed with other code, all within the same file, even inside the same function. Off the top of my head it went something like this:

// Real mode
mov ax, 1
mov bx, 2
mov cx, dx
// Set up protected mode
far jmp label1
label1:
mov eax, 123456
// Set up real mode
far jmp label2
label2:

The general idea would be to boot into Real Mode, use the BIOS disk services to load up the 32kb of bootloader code, switch to x64 mode (or x86), and use the full power of the CPU for the hashing procedure. Then once the correct password is entered and the BIOS disk services are hooked properly, return to Real Mode and then call the original disk bootloader application.

In theory... it should work :p