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 …
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.
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.
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.
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.
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....
"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?
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.
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.
"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.
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.
"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.
"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.
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 :)
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.
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.
"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).
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.
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...
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".
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?
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.
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!
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.
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,
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.
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.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
