7 ms·

I had no idea UEFI booted directly into long mode... I feel like a moron who hasn't kept up with the times, but admittedly I'm not super into kernel dev. Can I

by webkike 10y ago

I had no idea UEFI booted directly into long mode... I feel like a moron who hasn't kept up with the times, but admittedly I'm not super into kernel dev. Can I just ignore segmentation entirely? It has always been my least favorite part of programming on x86

yuhong 10y ago
You still need a GDT, but most of the values are ignored in long mode. There is still limited support in the form of changing the FS/GS segment bases, which is useful for the SYSCALL/SYSRET instructions.
pgeorgi 10y ago
It depends. Cheap Intel boards come with a 32bit UEFI (for whatever reason, it's not like UEFI is paid by the address bit), leading to all kinds of issues. But even then, segmentation is not an issue.
- jdietrich 10y ago
  >(for whatever reason, it's not like UEFI is paid by the address bit) 32 bit Windows 10 is 4GB smaller than the 64 bit version. This matters on cheap tablets and netbooks that come with <32gb of MMC storage. I've heard that 32 bit OEM licenses are also slightly cheaper, but I can't find confirmation of that. https://blogs.intel.com/evangelists/2015/07/22/why-cheap-systems-run-32-bit-uefi-on-x64-systems/ https://blogs.intel.com/evangelists/2015/07/22/why-cheap-sys...
  - yuhong 10y ago
    In retrospect, it probably would have been better for x64 OSes to run the EFI runtime services in compatibility mode.
  - byuu 10y ago
    I know we're probably ten years or more out from it (because it'd break way too much software ... I have an application I want to use but can't due to a 16-bit installer ... in 2016); but I really hope Microsoft eventually puts out a 64-bit only operating system. It would be lovely to be rid of SYSWOW64, Program Files (x86), the alternate shadow registry, ~3GB of wasted space for all the 32-bit code, etc. I intentionally leave off the 32-bit compatibility with my FreeBSD systems, and it's lovely. Of course, it's so much easier there with everything being open source.
    - MarkSweep 10y ago
      Since at least Windows Server 2008 R2 in Server Core mode you can uninstall 32-bit compatibility: https://msdn.microsoft.com/en-us/library/windows/desktop/dd371790(v=vs.85).aspx https://msdn.microsoft.com/en-us/library/windows/desktop/dd3... Additionally Nano server does not have it. Not sure if it is yet possible to remove from the desktop yet, but I'm doubtful.
      - Sanddancer 10y ago
        Not yet. There are still way too many programs that are 32 bit only.
    - prodigal_erik 10y ago
      I feel just the opposite. I have a pile of the most powerful general-purpose commodity hardware ever built, and it's a damning indictment of the industry that it can no longer run software that used to work fine on tiny machines.
      - Sanddancer 10y ago
        I disagree. Things that made sense on a tiny machine, like the original 8086's wraparound at 1 MB led to hacks like the A20 gate [1]. Or timing loops that were dependent on a processor running at 4.77 mhz, requiring things like the turbo button. Compatibility is a balancing game, because you end up needing to keep bugs lying around that otherwise would be fixed at some point in a newer architecture. I'm more of the opinion that we're much better off explicitly emulating those areas, so they are run in their own context and it's a lot easier to mitigate damage. While compatibility is a positive thing, improvement is a much more positive thing. [1] https://en.wikipedia.org/wiki/A20_line#A20_gate https://en.wikipedia.org/wiki/A20_line#A20_gate
        prodigal_erik 10y ago
        I agree that virtualization is better than support for old instruction sets in new cores, but users should expect that virtualization to be ever-present and reliable rather than mutely accept when tools randomly stop working.
- amluto 10y ago
  64-bit Linux kernels can be configured to so that they can be booted by 32-bit UEFI. It's messy but it works. Even runtime services like UEFI variables work. I think the idea is that long mode can be fused off. IIRC there's some MS requirement that boxes that have 64-bit CPUs must use 64-bit Windows, so keeping 32-bit firmware and adding a fuse works around it for users who care.
byuu 10y ago
> I had no idea UEFI booted directly into long mode I was really surprised to learn that it requires PE executables and Windows' custom x64 calling convention. I know it's just a small technical detail for booting ... but it's kind of scary that Microsoft had so much sway in the design of how our future PCs will boot =(
- yuhong 10y ago
  MS even had to add ARM64 to the PE spec in order to support ARM SBSA. At least I think the FAT LFN patents has expired by now.
  - DiabloD3 10y ago
    Microsoft has granted a patent license for FAT patents for anyone implementing stuff required for UEFI.
  - slipstream- 10y ago
    There is lots of evidence that a port of NT to ARM64 exists.
  - cocotino 10y ago
    Do you even need LFN for UEFI? I don't think it should be a requirement for a FS that is not exposed to the user...
- gizmo686 10y ago
  Another small technical detail. Windows has a mechanism to sign executables. The certificate in this mechanism is defined with the following structure [0]: typedef struct _WIN_CERTIFICATE { DWORD dwLength; WORD wRevision; WORD wCertificateType; BYTE bCertificate[ANYSIZE_ARRAY]; } WIN_CERTIFICATE, *PWIN_CERTIFICATE; UEFI has a shockingly simmilar structure [1, page 1812]: typedef struct _WIN_CERTIFICATE { UINT32 dwLength; UINT16 wRevision; UINT16 wCertificateType; //UINT8 bCertificate[ANYSIZE_ARRAY]; } WIN_CERTIFICATE; [0] https://msdn.microsoft.com/en-us/library/windows/desktop/dn582059(v=vs.85).aspx https://msdn.microsoft.com/en-us/library/windows/desktop/dn5... [1] http://www.uefi.org/sites/default/files/resources/UEFI%20Spec%202_6.pdf http://www.uefi.org/sites/default/files/resources/UEFI%20Spe...

by webkike 10y ago

yuhong 10y ago

You still need a GDT, but most of the values are ignored in long mode. There is still limited support in the form of changing the FS/GS segment bases, which is useful for the SYSCALL/SYSRET instructions.

pgeorgi 10y ago

It depends. Cheap Intel boards come with a 32bit UEFI (for whatever reason, it's not like UEFI is paid by the address bit), leading to all kinds of issues. But even then, segmentation is not an issue.

jdietrich 10y ago
>(for whatever reason, it's not like UEFI is paid by the address bit) 32 bit Windows 10 is 4GB smaller than the 64 bit version. This matters on cheap tablets and netbooks that come with <32gb of MMC storage. I've heard that 32 bit OEM licenses are also slightly cheaper, but I can't find confirmation of that. https://blogs.intel.com/evangelists/2015/07/22/why-cheap-systems-run-32-bit-uefi-on-x64-systems/ https://blogs.intel.com/evangelists/2015/07/22/why-cheap-sys...
- yuhong 10y ago
  In retrospect, it probably would have been better for x64 OSes to run the EFI runtime services in compatibility mode.
- byuu 10y ago
  I know we're probably ten years or more out from it (because it'd break way too much software ... I have an application I want to use but can't due to a 16-bit installer ... in 2016); but I really hope Microsoft eventually puts out a 64-bit only operating system. It would be lovely to be rid of SYSWOW64, Program Files (x86), the alternate shadow registry, ~3GB of wasted space for all the 32-bit code, etc. I intentionally leave off the 32-bit compatibility with my FreeBSD systems, and it's lovely. Of course, it's so much easier there with everything being open source.
  - MarkSweep 10y ago
    Since at least Windows Server 2008 R2 in Server Core mode you can uninstall 32-bit compatibility: https://msdn.microsoft.com/en-us/library/windows/desktop/dd371790(v=vs.85).aspx https://msdn.microsoft.com/en-us/library/windows/desktop/dd3... Additionally Nano server does not have it. Not sure if it is yet possible to remove from the desktop yet, but I'm doubtful.
    - Sanddancer 10y ago
      Not yet. There are still way too many programs that are 32 bit only.
  - prodigal_erik 10y ago
    I feel just the opposite. I have a pile of the most powerful general-purpose commodity hardware ever built, and it's a damning indictment of the industry that it can no longer run software that used to work fine on tiny machines.
    - Sanddancer 10y ago
      I disagree. Things that made sense on a tiny machine, like the original 8086's wraparound at 1 MB led to hacks like the A20 gate [1]. Or timing loops that were dependent on a processor running at 4.77 mhz, requiring things like the turbo button. Compatibility is a balancing game, because you end up needing to keep bugs lying around that otherwise would be fixed at some point in a newer architecture. I'm more of the opinion that we're much better off explicitly emulating those areas, so they are run in their own context and it's a lot easier to mitigate damage. While compatibility is a positive thing, improvement is a much more positive thing. [1] https://en.wikipedia.org/wiki/A20_line#A20_gate https://en.wikipedia.org/wiki/A20_line#A20_gate
      - prodigal_erik 10y ago
        I agree that virtualization is better than support for old instruction sets in new cores, but users should expect that virtualization to be ever-present and reliable rather than mutely accept when tools randomly stop working.
amluto 10y ago
64-bit Linux kernels can be configured to so that they can be booted by 32-bit UEFI. It's messy but it works. Even runtime services like UEFI variables work. I think the idea is that long mode can be fused off. IIRC there's some MS requirement that boxes that have 64-bit CPUs must use 64-bit Windows, so keeping 32-bit firmware and adding a fuse works around it for users who care.

byuu 10y ago

> I had no idea UEFI booted directly into long mode I was really surprised to learn that it requires PE executables and Windows' custom x64 calling convention. I know it's just a small technical detail for booting ... but it's kind of scary that Microsoft had so much sway in the design of how our future PCs will boot =(

yuhong 10y ago
MS even had to add ARM64 to the PE spec in order to support ARM SBSA. At least I think the FAT LFN patents has expired by now.
- DiabloD3 10y ago
  Microsoft has granted a patent license for FAT patents for anyone implementing stuff required for UEFI.
- slipstream- 10y ago
  There is lots of evidence that a port of NT to ARM64 exists.
- cocotino 10y ago
  Do you even need LFN for UEFI? I don't think it should be a requirement for a FS that is not exposed to the user...
gizmo686 10y ago
Another small technical detail. Windows has a mechanism to sign executables. The certificate in this mechanism is defined with the following structure [0]: typedef struct _WIN_CERTIFICATE { DWORD dwLength; WORD wRevision; WORD wCertificateType; BYTE bCertificate[ANYSIZE_ARRAY]; } WIN_CERTIFICATE, *PWIN_CERTIFICATE; UEFI has a shockingly simmilar structure [1, page 1812]: typedef struct _WIN_CERTIFICATE { UINT32 dwLength; UINT16 wRevision; UINT16 wCertificateType; //UINT8 bCertificate[ANYSIZE_ARRAY]; } WIN_CERTIFICATE; [0] https://msdn.microsoft.com/en-us/library/windows/desktop/dn582059(v=vs.85).aspx https://msdn.microsoft.com/en-us/library/windows/desktop/dn5... [1] http://www.uefi.org/sites/default/files/resources/UEFI%20Spec%202_6.pdf http://www.uefi.org/sites/default/files/resources/UEFI%20Spe...