back to article Every major OS maker misread Intel's docs. Now their kernels can be hijacked or crashed

Linux, Windows, macOS, FreeBSD, and some implementations of Xen have a design flaw that could allow attackers to, at best, crash Intel and AMD-powered computers. At worst, miscreants can, potentially, "gain access to sensitive memory information or control low-level operating system functions,” which is a fancy way of saying …

Page:

  1. A Non e-mouse Silver badge

    Re-Education

    The Register expects plenty of OS developers are about to be sent to compulsory re-education sessions on the x86-64 architecture

    The x86 architecture is so big and complex I'd be surprised if anyone knew it completely. The instruction set reference guide from Intel is over 2,000 pages long alone. And that's just one of the four volumes!

    The more complex a device, the less likely you are to fully understand how it works and the easier it is to get it (horribly) wrong.

    1. TRT Silver badge

      Re: the easier it is to get it (horribly) wrong.

      No exceptions?

      1. Warm Braw Silver badge

        Re: the easier it is to get it (horribly) wrong.

        No exceptions?

        Merely traps for the unwary...

        1. John Brown (no body) Silver badge

          Re: the easier it is to get it (horribly) wrong.

          "Merely traps for the unwary..."

          Who was that masked interrupt?

    2. stephanh

      Re: Re-Education

      Especially since this whole "pop ss" hack is a throwback to the 16-bit segmented DOS days.

      The expectation being that the next thing you do is adjust the sp register and thereby restore the entire segmented ss:sp stack pointer to some previous location. If an interrupt handler would run inbetween it would smash some arbitrary memory at new-ss:old-sp.

      So no sane application program has been using this for >20 years but of course the complexity-induced insecurity remains with us.

      1. Anonymous Coward
        Anonymous Coward

        "is a throwback to the 16-bit segmented DOS days."

        Different instruction can manipulate SS, because there are situation to switch stacks - i.e. going from user to kernel and back (SYSENTER/SYSEXIT do change SS, and INT may as well). A CALL through a call gate will push the caller SS:ESP on the callee stack (so parameters pushed on the caller stack can be accessed).

        Intel CPU were never designed around a single (or a few OS) - that's a mistake usually only AMD does - so instruction that actual main OSes may not use do exist, and for good reasons, and could be use by other OSes.

        x86 segments were far more secure than the page bits used now to protect memory - just they were slower - exactly because all the security checks when an instruction went through a segment boundary. For this reasons, one day they will be back, not as a physical<->virtual memory mapping solution, but as a way to protect memory properly.

        1. Primus Secundus Tertius

          Re: "is a throwback to the 16-bit segmented DOS days."

          Segmented address spaces are an utter pain for software development, and programmers welcomed the unified 32-bit address space when it appeared. But the worst situation I met was a system designed by hardware people, with hardware memory test logic screwing up data on addresses at 2**13 boundaries. However, as the software was in assembler one could avoid putting code or data there.

          The real problem here seems to be that code is interruptible at a weak point.

          1. Anonymous Coward
            Anonymous Coward

            "Segmented address spaces are an utter pain for software development,"

            Sorry, you don't understand segments. Small 64K segments like those in 16bit days were a pain, true, because you had to reload code and data registers too often. Allocating and swapping memory at the segment level, too, because segments became simply too large. With 32 bit segments and pagination, these limitations went away. You can use segments and pagination at the same time.

            But the flat 32 bit address space were code and data segments are fully the same was a very ill-fated decision, because it opened the doors to a lot of vulnerabilities and attacks. With a proper use of segments, Data won't be executable. Buffer overflows would raise exceptions. Code won't be readable nor writable, and techniques like return oriented programming would be very hard if not impossible to use.

            A sounder implementation would have used just a few segment to keep separated code and data. No need to use multiple segment - but for very secure implementation. But flat spaces were easier to implement, and were compatible with other architectures. Most of these design were forced by the need to be compatible with older processor that weren't as sophisticated as Intel ones, and because, yes, security has performance implications.

            We pay now the fee in terms of far less robust architectures - up to Meltdown stemming down by the stupid decision to map kernel memory into user space to save cycles when entering kernel mode.

            Anyway this vulnerability has nothing to do with segmentation, just POP SS it's not a relic of segmentation either - even in other architectures you may need to change stack....

      2. Jaybus

        Re: Re-Education

        "If an interrupt handler would run in between it would smash some arbitrary memory at new-ss:old-sp"

        Yes, which is the reason for the special interrupt-delaying handling of POP SS in the first place. Even the decades old 80386 manual stated "A POP SS instruction inhibits all interrupts, including the NMI interrupt, until after execution of the next instruction. This action allows sequential execution of POP SS and MOV ESP, EBP instructions without the danger of having an invalid stack during an interrupt1. However, use of the LSS instruction is the preferred method of loading the SS and ESP registers."

        Note that last sentence!

        Now note the footnote indicated at the end of the second sentence. The footnote states:

        1. Note that in a sequence of instructions that individually delay interrupts past the following instruction, only the first instruction in the sequence is guaranteed to delay the interrupt, but subsequent interrupt-delaying instructions may not delay the interrupt. Thus, in the following instruction sequence:

        STI

        POP SS

        POP ESP

        interrupts may be recognized before the POP ESP executes, because STI also delays interrupts for one instruction.

        The manual seems pretty clear on the subject of interrupt-delaying instructions, even going so far as to point out the exception when a sequence of interrupt-delaying instructions exists and, more importantly, to strongly suggest the use of the LSS instruction to load SS and ESP in an atomic manner.

        So, is it lack of clarity in the manual, or is it failure to RTFM?

    3. Steve Davies 3 Silver badge

      Re: Re-Education

      2000 pages and 4 volumes?

      I lean back in my office chair and look lovingly at the 3/8ths of an inch thick 'tome' that details the PDP-11 Instruction Set.

      Sigh. I really am getting old and need to give up this sofware development malarkey.

      1. JohnArchieMcKown

        Re: Re-Education

        I remember the IBM S/370 "Principles of Operation" manual back in the 1970s. It was about that same size. The great^n grand son of that, the IBMz z14 machine is 1902 pages long. I just looked.

      2. onefang

        Re: Re-Education

        My arms used to be stronger, from all that constant lifting up of heavy programming manuals. Now I'm getting old, and the only exercise I get most of the day is moving my mouse around. I should go back to sysadmin work, where at least I get to juggle servers every now and then.

        1. TRT Silver badge

          Re: My arms used to be stronger,

          Hence the term "manual labour".

      3. bobajob12

        Re: Re-Education

        I lean back in my office chair and look lovingly at the 6 foot thick 'slim manuals' that details the Nortel DMS-10 Instruction Set. From the days when the manuals arrived on a shipping pallet all their own.

        1. Steve Davies 3 Silver badge

          Re: Docs arriving on a Pallet

          Shudder.... That reminds me so much of the VMS V5.0 release. AFAIK, almost every printer in Ireland was used to print the damm things.

          1. Anonymous Coward
            Anonymous Coward

            Re: Docs arriving on a Pallet

            almost every printer in Ireland was used to print the damm things.

            But it was worth it, for real documentation.

      4. CrazyOldCatMan Silver badge

        Re: Re-Education

        look lovingly at the 3/8ths of an inch thick 'tome' that details the PDP-11 Instruction Set

        We recently threw out our old POPS manuals (IBM S/370 assembler) left over from our TPF days. Their main use for the last 25 years has been to prop up various bits of tat in the garage.

        1. onefang

          Re: Re-Education

          "Their main use for the last 25 years has been to prop up various bits of tat in the garage."

          That's what I use the Yellow Pages for, a monitor stand. The base of my main monitor is almost precisely the same dimensions as a copy of Telstra Yellow Pages, almost as if the book was designed for that purpose.

    4. HmmmYes

      Re: Re-Education

      X86 is big. Its not complex, well it us, its more shit.

      Its like an instruction set with old crap bolted into it.

      Maybe intel can license power and just cincentrate on caches and inter chip links?

    5. panoptiq

      Re: Re-Education

      There needs to be a purging of the x86 architecture; in fact, it should have started 20 years ago. Oh well, long live unfulfilled computing potential.

      1. Anonymous Coward
        Anonymous Coward

        Re: Re-Education

        More than an x86 purge, Intel did try to begin again completely with Itanium ~20 years ago. I think the (approximate) death of Itanium is a shame. Sure, at the time it was expensive and under-performing. The constraints on instruction combinations in the VLIW code meant it was full of NOP instructions, a waste of cache among other things. Compilers couldn't handle the default parallelism so there were barriers (stops) everywhere;;

        With relatively abundant cache and possibility of high clock speeds today, these things would matter less - especially since the Itanium is (allegedly) immune to Spectre.

        Sadly, the lasting effect of Itanium seems to have been to kill off other promising architectures (e.g. Alpha) as almost everyone except AMD seemed to hang around waiting for Itanium to become much good.

    6. Anonymous Coward
      Anonymous Coward

      Not the major OS maker then?!!

      "Every major OS maker"

      Notice the biggest,most widespread OS isn't on that list.... Android has more active devices than Windows these days. Let's not forget that, so clearly it's not every major OS maker...

  2. malle-herbert
    Facepalm

    So all of this is just a case of...

    RTFM ?

    1. spodula

      Re: So all of this is just a case of...

      Well, RTFM followed by a session of guessing what the hell was going through the Intel Engineers head, cos it sounds like the manual was far from clear.

      1. Anonymous Coward
        Anonymous Coward

        Re: So all of this is just a case of...

        "Every major OS maker misread Intel's docs".

        From which it follows that the docs were unclear. If OS developers - highly intelligent people with excellent knowledge and understanding of their domain - misunderstood, almost by definition the documentation was faulty. The principle has been clearly understood (and enunciated) for more than 1900 years:

        "One should not aim at being possible to understand, but impossible to misunderstand".

        - Marcus Fabius Quintilian

        And he was just talking about trivial matters like law and politics. Computer architecture is far more important.

        1. Anonymous Coward
          Anonymous Coward

          "From which it follows that the docs were unclear. "

          Os that developers copied each other - happened even before StackOverflow was available...

          1. FuzzyWuzzys

            Re: "From which it follows that the docs were unclear. "

            "Os that developers copied each other - happened even before StackOverflow was available..."

            I was thinking that too, is this simply a case where Fred was the first to read the manuals, he wrote about it and didn't get it quite right then others have simply thought, "Sod reading the manuals, this looks OK.", tested it and it works. Then that knowledge passes into lore and before you know it's simply the "done thing" without question.

            1. Fred Flintstone Gold badge

              Re: "From which it follows that the docs were unclear. "

              is this simply a case where Fred was the first to read the manuals, he wrote about it and didn't get it quite right then others have simply thought, "Sod reading the manuals, this looks OK.", tested it and it works.

              Hang on, I'm not involved :)

              (a) The number of years since I was that close to a CPU in programming is measured in decades and (b) it then involved a mere 8 bit chip.

              I plead the Shaggy defense :)

          2. sw guy

            Re: "From which it follows that the docs were unclear. "

            Linux code copied from Windows ?

            Non-GPL copied from Linux code ?

            I wonder which one is the less probable.

            However, OS developers sharing a common way of thinking, and reading the same (obfuscated) manual, this is something already seen elsewhere.

            In the past, an experiment was done by providing the same high level specification of a radar system to several teams, and they made comparable errors in same areas, that is where specifications where not clear enough.

            1. LDS Silver badge

              Re: "From which it follows that the docs were unclear. "

              Kernel developers may not be a very large community. People move from a company to another, they share knowledge and ideas on newsgroup and forums, meetings, etc. etc.

              Some approaches, after having being shared, could have become "facts" before they were fully validated.

            2. stephanh

              Re: "From which it follows that the docs were unclear. "

              "Linux code copied from Windows ?

              Non-GPL copied from Linux code ?"

              Both copied from BSD? Windows has used code from BSD for networking, not so far-fetched to think that they also look there for "inspiration" on other topics.

        2. Munchausen's proxy
          Pint

          Re: So all of this is just a case of...

          "If OS developers - highly intelligent people with excellent knowledge and understanding of their domain"

          Try to work with memory overcommit in a shared HPC environment, then try to repeat that with a straight face.

          A kernel house of cards designed for no other real purpose than to make bad code run (for a while).

    2. oiseau Silver badge
      WTF?

      Re: So all of this is just a case of...

      Hello:

      RTFM ?

      Hmmm ...

      Me thinks not.

      You see, when someone writes a manual and everyone interprets the same text/set of instructions in that manual in the same manner (ie: wrong), the problem quite obviously does not lie in those who interpreted it.

      It lies solely in those who wrote it and obviously did it in a manner that could not be interpreted properly.

      ie: Intel

      Just my $0.02.

      Cheers,

      O.

      1. Iain 14
        WTF?

        Re: So all of this is just a case of...

        The problem with "RTFM" is that it makes inherent assumptions regarding the quality of the manual and the ease by which the reader can correctly interpret it. The "polite" meaning of RTFM that I was always taught was "Read The Fine Manual", and I like this because it puts some of the onus back on the manual writer - i.e. if the manual contains material that's wrong or open to misinterpretation, it's not "Fine", and therefore you can't really blame the reader for any resulting fallout.

        As someone who's currently having to rewrite someone-else's manual because an error in it caused an engineer to waste several days trying to work out why the hell his installation didn't work, this is a bit of a sore point at the moment - and I'm sure many here have had similar experiences...

      2. JohnArchieMcKown

        Re: So all of this is just a case of...

        IBM likes, or liked, to put in a sentence in some of their programming manuals which said something similar to:

        This manual describes IBM implementation of <some standard> as of <some date> as interpreted by IBM.

        or maybe it was "as understood" instead of "as interpreted".

    3. Vanir

      Re: So all of this is just a case of...

      Read the flawed manual?

    4. Anonymous Coward
      Anonymous Coward

      Re: So all of this is just a case of...

      RTFM.

      If the manual was anything like a Novell Netware manual, they probably just guessed.

  3. Teiwaz Silver badge

    So....

    What's the expected performance hit when the fixes get applied?

    There's going to be one, right?

    These things are getting like unexpected tax bills.

    1. Captain TickTock

      Re: So....

      Well, if it's all to do the segmented memory from the 16bit days, it should hardly ever come up, No?

      1. defiler

        Re: So....

        it should hardly ever come up, No?

        Firstly, I am not a programmer. Secondly, it strikes me that you're correct in normal use.

        However, somebody intent on causing trouble can pop this into a malicious program to cause havoc. It's like saying the bullet will be safe so long as it's kept in the box.

        Can anyone offer a reason for using this segmented crap in any 32-bit system? If we're needing backwards compatibility for shitty old 16-bit applications, surely that can be isolated in an emulator or something these days?

        1. Anonymous Coward
          Anonymous Coward

          "Can anyone offer a reason for using this segmented crap "

          Would you like the kernel stack to be accessible by user code? Even if not using Intel "segments", you may want to change "registers" allowing access to different parts of memory when switching from a privilege level to another, to disallow less privileged code to access data of more privileged ones.

          There's a misconception about segments, because Intel used them for two separate tasks. One was to map physical memory to virtual one, and this can be handled better by pagination.

          The other was to set privileges and rights on a block of virtual memory. You can set what privilege level a segment belongs to, and what could be done with it - read/write/execute. You may have segments the CPU can execute but code can't read their contents - nice, isn't it?

          Pagination doesn't have so granular controls - even the NX bit was added later when it became clear that being able to execute any address was very dangerous. And pagination doesn't perform the privilege access checks segments does - which unluckily also makes their use slower.

          Yet better designed OSes cold have used at least an executable only code segment, a read-only segment for true constants, and a read/write, but not executable, segment for data - at least for non-script applications, instead of having a flat read/write/execute address space.

          Such kind of OS would be much more secure but incompatible with a most old code - so you'll never see it.

          1. defiler

            Re: "Can anyone offer a reason for using this segmented crap "

            There's a misconception about segments, because Intel used them for two separate tasks. One was to map physical memory to virtual one, and this can be handled better by pagination.

            A-ha. I'd assumed that the segmentation was for the nasty old 16-bit-style memory paging, which (in my opinion) should be dead and gone by now. If it's actually still used for memory protection then I can't really complain.

            Told you I wasn't a programmer!

          2. Daniel von Asmuth
            Windows

            Re: "Can anyone offer a reason for using this segmented crap "

            Raad Tanenbaum's book on computer architecture, particularly the part about the design of the virtual memory system for Multics, and you find no reason to think that there is anything wrong with their combination of segmentation and paging.

            Then read about the Intel X86 design and figure out that their trick for addressing 16-bit address registers together with 160-bit segment selectors to produce 20-bit adresses was easy for Intel, but hard for developers.... Intel & Microsoft: a marriage made in hell.

            1. Anonymous Coward
              Anonymous Coward

              " together with 160-bit segment selectors to produce 20-bit adresses"

              That is a matter for system developers only. It's totally transparent to application developers. The OS setups segment descriptors, from an application perspective loading a segment register with a real memory address, or a selector, is transparent, they're just numbers - the CPU will do whatever is required behind the scene to get the physical address.

              Anyway, just look at how the pagination mechanism work - especially when more indirection are used - it's not much less complex - and it's a little simpler only because it lacks the security features of segments.

              Of course adding the security features at the page level makes little sense because whenever a different page is accessed checks should be performed, and it would be a bigger burden than making it at the segment level.

              So it really makes sense to use pages to manage memory mappings, and segments for security,

            2. Anonymous Coward
              Anonymous Coward

              Re: "Can anyone offer a reason for using this segmented crap "

              "Intel & Microsoft: a marriage made in hell".

              But bloody profitable.

          3. Anonymous Coward
            Anonymous Coward

            Re: "Can anyone offer a reason for using this segmented crap "

            Ignoring Ring N-3 (i.e. IME), I hope you do realize that no one, to my knowledge, uses anything except Ring 0 and Ring 3. Would that we did have the other two in use, our security models just might improve a smidgen.

            1. Anonymous Coward
              Anonymous Coward

              Re: "Can anyone offer a reason for using this segmented crap "

              OS do use only two rings because most CPU but Intel did have only two level, supervisor and user. Thereby for compatibility (even NT did support MIPS and Alpha) designers did use only two. Moreover, the more the ring transitions, the less the performance.

              But looking at it form a security perspective, the Intel design which proposed ring 0 core kernel, ring 1 I/O routines, ring 2 system libraries, ring 3 application was very sound and clever, and would have led to a much more secure OS (albeit quite slower). It was defense in depth.

              Just, for a long time, and probably still, most companies are obsessed with performance only, and we see how many avoidable security bugs we see each month.

              But as long as many people have been brainwashed that designs made forty years ago based on much more primitive CPUs are the best one and don't need to be revised and updated, we'll keep on having to face big vulnerabilities.

              Even more so when CPU start to be designed around outdated OS, instead of vice versa. As more advanced features disappear from CPUs, it will be impossible to design and create a more secure OS, let's keep on living in the '70s... and having the same security.

              It's impossible to create a secure OS without hardware support, software-only security is far less robust. But people usually understand such issues only when they hurt them badly.

              1. kirk_augustin@yahoo.com

                Re: "Can anyone offer a reason for using this segmented crap "

                Yes, the problem is Intel processors do not support OS security needs. If Intel had done paging right and not called it segmentation, then Intel could have done segmentation right and have a pair of guard registers for every user process. This is very old stuff and no one has to reinvent anything, just Intel did it all wrong.

      2. Anonymous Coward
        Anonymous Coward

        "t should hardly ever come up, No?"

        Non malicious code will never contain such instruction. But malicious code can use them explicitly to exploit the vulnerability, of course. AFAIK POP SS is not a privileged instruction, so it can be used by user code without being trapped.

    2. Anonymous Coward
      Anonymous Coward

      Re: So....

      A tax bill should never be unexpected to an educated adult.

      Any more than death...

Page:

POST COMMENT House rules

Not a member of The Register? Create a new account here.

  • Enter your comment

  • Add an icon

Anonymous cowards cannot choose their icon

Biting the hand that feeds IT © 1998–2021