3 ms·

> Exactly what I was talking about. No, you were saying that this empty space would be claimed by the MSR, and that it wouldn't work otherwise due to some host

by 1996 6y ago

> Exactly what I was talking about. No, you were saying that this empty space would be claimed by the MSR, and that it wouldn't work otherwise due to some hostile intent by Microsoft. So I edited to add that nothing would "claim" this space, as out-of-sequence partitions are not done by OS: the gaps will be left empty. > Can we get a show of hands for how many Windows users have been doing this to their MSR? I do, and a lot of people do - because it's technically possible. If you don't know how to, it's your problem, not Microsoft problems. The modern GPT scheme + UEFI boot as used currently by Windows is extremely permissive yet secure: TPM and MOKs allow signed EFI payloads, and you even got a dedicated EFI partition with lots of free space to put them there! Add a LUKS partition and you're just as secure as Windows Secureboot on Bitlocker. But you have to learn on how to use these new things, as it's not your grandpa MBR.

fuzzfactor 6y ago
>you even got a dedicated EFI partition with lots of free space to put them there! I like this well enough to prefer a 32GB FAT32 volume for EFI, so there's enough space for some Live Linux distributions, along with all the boot files I can muster. I gather that you are quite advanced about the partitioning process, I appreciate it and this is something more people should be aware of. Under the latest Windows 10 GPT scheme, the MSR by default now extends from sector 34 to the first sector of your system volume, and for performance your system volume is hopefully aligned at a location such as 8192, although 1024 was common for a while. So all these sectors are now well spoken-for. This is fairly recent and until then sectors 34 through 8191 for instance were being unused by Windows 10, out-of-partition, and unallocated by default. Even though GPT was touted the whole time as having no unallocated sectors by default. These sectors were not being scanned by Windows Defender. This amounted to significantly more out-of-partition space than most of the 21st century BIOS arrangements, where things like GRUB could mainly rely only on sectors 1 through 62 for bootcode in excess of a single sector (like when GRUB stages were installed right there rather than optionally contained within an actual filesystem). So now the MSR takes up this space with an actual GPT partition here instead of leaving it fallow like it did originally. GRUB does not need this space for GPT use since UEFI GRUB is only targeted to boot code in files within a filesystem, like Windows does in its own way too. Windows partitions still have boot sectors but they are not used for booting any more under GPT. As mentioned, now the only thing generally remaining for potentially malicious or useful out-of-partition hacking on GPT is in about the sector 4 to 33 range, even though these are already taken and have always been spoken for by design, virtually nobody has anything but zeros there. >But you have to learn on how to use these new things, as it's not your grandpa MBR. Mainly only Linux users who want to get equivalent boot performance compared to MBR systems. Revocation of previous Microsoft-signed Linux keys (just as they were becoming viable) was looming but now really here, so since after 2019 additional mastery even further beyond that required by Windows is needed just to achieve or maintain parity, eventually. Which I was wrong about, it's actually been about 9 years of hostility so far. Take a look at what might be happening/proposed with SYSTEMD for booting and with the proper input plus great care a new Linux bootloader could arise to overcome remaining obstacles. This needs to really be jumped on before it has a chance to become misguided. There simply needs to be a single Microsoft-signed bootloader that can boot any Linux, or Windows, from a user-configurable menu. Along these lines a focused amount of work needs to be done with UEFI Shell programs, and that might be all it requires. Obviously Microsoft could have provided this long ago or incorporate it into their current routine if they had a truly non-hostile approach to open-source. So it looks like Microsoft is still lying at least about one of the most important things.
- 1996 6y ago
  > like this well enough to prefer a 32GB FAT32 volume for EFI, so there's enough space for some Live Linux distributions, along with all the boot files I can muster Great idea, so it's always there when you need it! > Under the latest Windows 10 GPT scheme, the MSR by default now extends from sector 34 to the first sector of your system volume, and for performance your system volume is hopefully aligned at a location such as 8192, although 1024 was common for a while. So all these sectors are now well spoken-for. This is fairly recent and until then sectors 34 through 8191 for instance were being unused by Windows 10, out-of-partition, and unallocated by default. It must be very recent because it never happened to me. If it did, I would just move the MSR. I guess Microsoft is just trying to use the leftovers to be less intrusive? But with a large enough EFI, I don't really care. > Revocation of previous Microsoft-signed Linux keys Use your own keys! Don't depend on someone else's keys! > Take a look at what might be happening/proposed with SYSTEMD for booting and with the proper input plus great care a new Linux bootloader could arise to overcome remaining obstacles It has already happened: I follow the Arch way of a "fat" EFI payload using systemd EFI stuff: so I have a kernel + initrd (+ cmdline) in one EFI file - and no need for a bootloader anymore, as the UEFI can directly boot this EFI payload. Sign this file with your own keys (MOK) and you're king of your castle > There simply needs to be a single Microsoft-signed bootloader that can boot any Linux, or Windows, from a user-configurable menu A menu is a waste of time. I keep my EFI payload on the EFI partition. I never need to change the kernel cmdline. One less piece of software (a good thing as grub2 had recent vulnerabilities) > Along these lines a focused amount of work needs to be done with UEFI Shell programs, and that might be all it requires There are a few good ones, that can help you in case of problems - but booting a live distribution is almost faster. Your idea of keeping it right in the EFI partition is great - we simply need to change our habits and create larger EFI partitions. It's the ideal place to put it, as Windows or anything else won't dare touch it there. > So it looks like Microsoft is still lying at least about one of the most important things. Maybe - but we don't really need them with MOK keys and the systemd EFI stub.

by 1996 6y ago

fuzzfactor 6y ago

>you even got a dedicated EFI partition with lots of free space to put them there! I like this well enough to prefer a 32GB FAT32 volume for EFI, so there's enough space for some Live Linux distributions, along with all the boot files I can muster. I gather that you are quite advanced about the partitioning process, I appreciate it and this is something more people should be aware of. Under the latest Windows 10 GPT scheme, the MSR by default now extends from sector 34 to the first sector of your system volume, and for performance your system volume is hopefully aligned at a location such as 8192, although 1024 was common for a while. So all these sectors are now well spoken-for. This is fairly recent and until then sectors 34 through 8191 for instance were being unused by Windows 10, out-of-partition, and unallocated by default. Even though GPT was touted the whole time as having no unallocated sectors by default. These sectors were not being scanned by Windows Defender. This amounted to significantly more out-of-partition space than most of the 21st century BIOS arrangements, where things like GRUB could mainly rely only on sectors 1 through 62 for bootcode in excess of a single sector (like when GRUB stages were installed right there rather than optionally contained within an actual filesystem). So now the MSR takes up this space with an actual GPT partition here instead of leaving it fallow like it did originally. GRUB does not need this space for GPT use since UEFI GRUB is only targeted to boot code in files within a filesystem, like Windows does in its own way too. Windows partitions still have boot sectors but they are not used for booting any more under GPT. As mentioned, now the only thing generally remaining for potentially malicious or useful out-of-partition hacking on GPT is in about the sector 4 to 33 range, even though these are already taken and have always been spoken for by design, virtually nobody has anything but zeros there. >But you have to learn on how to use these new things, as it's not your grandpa MBR. Mainly only Linux users who want to get equivalent boot performance compared to MBR systems. Revocation of previous Microsoft-signed Linux keys (just as they were becoming viable) was looming but now really here, so since after 2019 additional mastery even further beyond that required by Windows is needed just to achieve or maintain parity, eventually. Which I was wrong about, it's actually been about 9 years of hostility so far. Take a look at what might be happening/proposed with SYSTEMD for booting and with the proper input plus great care a new Linux bootloader could arise to overcome remaining obstacles. This needs to really be jumped on before it has a chance to become misguided. There simply needs to be a single Microsoft-signed bootloader that can boot any Linux, or Windows, from a user-configurable menu. Along these lines a focused amount of work needs to be done with UEFI Shell programs, and that might be all it requires. Obviously Microsoft could have provided this long ago or incorporate it into their current routine if they had a truly non-hostile approach to open-source. So it looks like Microsoft is still lying at least about one of the most important things.

1996 6y ago
> like this well enough to prefer a 32GB FAT32 volume for EFI, so there's enough space for some Live Linux distributions, along with all the boot files I can muster Great idea, so it's always there when you need it! > Under the latest Windows 10 GPT scheme, the MSR by default now extends from sector 34 to the first sector of your system volume, and for performance your system volume is hopefully aligned at a location such as 8192, although 1024 was common for a while. So all these sectors are now well spoken-for. This is fairly recent and until then sectors 34 through 8191 for instance were being unused by Windows 10, out-of-partition, and unallocated by default. It must be very recent because it never happened to me. If it did, I would just move the MSR. I guess Microsoft is just trying to use the leftovers to be less intrusive? But with a large enough EFI, I don't really care. > Revocation of previous Microsoft-signed Linux keys Use your own keys! Don't depend on someone else's keys! > Take a look at what might be happening/proposed with SYSTEMD for booting and with the proper input plus great care a new Linux bootloader could arise to overcome remaining obstacles It has already happened: I follow the Arch way of a "fat" EFI payload using systemd EFI stuff: so I have a kernel + initrd (+ cmdline) in one EFI file - and no need for a bootloader anymore, as the UEFI can directly boot this EFI payload. Sign this file with your own keys (MOK) and you're king of your castle > There simply needs to be a single Microsoft-signed bootloader that can boot any Linux, or Windows, from a user-configurable menu A menu is a waste of time. I keep my EFI payload on the EFI partition. I never need to change the kernel cmdline. One less piece of software (a good thing as grub2 had recent vulnerabilities) > Along these lines a focused amount of work needs to be done with UEFI Shell programs, and that might be all it requires There are a few good ones, that can help you in case of problems - but booting a live distribution is almost faster. Your idea of keeping it right in the EFI partition is great - we simply need to change our habits and create larger EFI partitions. It's the ideal place to put it, as Windows or anything else won't dare touch it there. > So it looks like Microsoft is still lying at least about one of the most important things. Maybe - but we don't really need them with MOK keys and the systemd EFI stub.