13 ms·

Intel and AMD Contemplate Different Replacements for x86 Interrupt Handling

200 points by eklitzke 5y ago

einpoklum 5y ago
> interrupt handling would be faster, simpler, more complete, and less prone to corner-case bugs. If it's simpler, I can see why it will be faster and less prone to corner-case bugs (at least, the hardware will have fewer corner cases; the software is a different question). But how can simplification supposed to make FRED more "complete"?
vlovich123 5y ago
Given the multi core, NUMA and Spectre/meltdown reality we’re living in, and the clear benefits of the io_uring approach, why not just have a dedicated core(s) to handle “interrupts” which are nothing more than entries in a shared memory table?
- electricshampo1 5y ago
  This is essentially the approach taken by https://www.dpdk.org/ https://www.dpdk.org/ (network) and https://spdk.io/ https://spdk.io/ (storage) Anything trying to squeeze perf doing IO intensive work should switch to this model (context permitting of course).
- eklitzke 5y ago
  This approach works for I/O devices (and for things like network cards the kernel will typically poll them anyway), but I/O isn't the only thing that generates interrupts. For instance, a processor fault (e.g. divide by zero) should be handled immediately and synchronously since the CPU core generating the fault can't do any useful work until the fault is handled.
  - vlovich123 5y ago
    Is that actually true? Wouldn’t this imply you could launch a DOS attack against cloud providers just generating divisions by zero?
    - bonzini 5y ago
      You would only attack yourself. The CPU time you're paying for would be spent processing division by zero exceptions.
      - vlovich123 5y ago
        Then the CPU isn’t stopping and is moving on doing other work. Meaning the divide by zero could be processed by a background CPU and doesn’t require immediate handling. Same for page faults.
        bonzini 5y ago
        Your instance can still be preempted by the hypervisor.
        fulafel 5y ago
        The hypervisor is just some software that runs on the same CPU. It wouldn't help if the assertion that the CPU can't continue was true.
        bonzini 5y ago
        The CPU can't continue running user code because it jumps to the exception handler. But it can get to the hypervisor at any instruction boundary. (I write a hypervisor for a living :)).
        bananabreakfast 5y ago
        Incorrect. The "CPU" is stopping and handling the fault. There is no background CPU from your perspective. In a cloud provider you are always in a virtual environment and using a vCPU which is constantly being preempted by the hypervisor. You cannot DOS a hypervisor just by bogging down your virtualized kernel.
        bonzini 5y ago
  - justincormack 5y ago
    Faults for divide by zero are a terrible legacy thing, Arm etc do not do this, you test for zero if you want to, otherwise you get a value.
    - eklitzke 5y ago
      That was just an example, there are many other things the CPU can do that will generate a fault (for example, trying to execute an illegal instruction).
    - DblPlusUngood 5y ago
      A better example: a page fault for a non-present page.
      - vlovich123 5y ago
        Could be handled by having the CPU switch to a different process while the kernel CPU faults the data in.
        ben509 5y ago
        The CPU doesn't know what processes are, that's handled by the OS. So there still needs to be a fault.
        vlovich123 5y ago
        You’re thinking about computer architecture as designed today. There’s no reason there isn’t a common data structure defined that the CPU can use to select a backup process, much how it uses page table data structures in main memory to resolve TLB misses.
        gpderetta 5y ago
        X86 had the concept of harware assisted context switching. Yet another unsued feature dropped in 64bit mode.
  - bonzini 5y ago
    Or interprocessor interrupts for flushing the TLB, terminating the scheduling quantum, or anything else.
- deleted 5y ago
  [deleted]
- devit 5y ago
  There must be a way to alter a core's instruction pointer from another core or from hardware to support killing processes running untrusted machine code, and to support pre-emptive multithreading without needing to have compilers add a check for preemption on all backward branches and calls. These features are very worth the hassle of providing this capability (which is known as "IPI"s), and once you have that hardware interrupts become pretty much free to support by using the same capability and the OS/user can then decide whether to dedicate a core, to affinity them to a core, to load balance them among all cores or to disable the interrupts and poll instead.
  - vlovich123 5y ago
    I was thinking rather than mucking with instruction pointers you would just send a message back to the other CPU saying “pause & switch to context X”. Technically an interrupt but one that can be handled internally within the CPU.
    - ori_b 5y ago
      What do you think "switch to context X" does, if not muck with the instruction pointer? Where do you think mucking with the instruction pointer is handled, if not within the CPU?
- knz42 5y ago
  This is the approach proposed in http://doi.org/10.1109/TPDS.2015.2492542 http://doi.org/10.1109/TPDS.2015.2492542 (preprint: https://science.raphael.poss.name/pub/poss.15.tpds.pdf https://science.raphael.poss.name/pub/poss.15.tpds.pdf )
  - DSingularity 5y ago
    And old systems like Corey OS.
- bostonsre 5y ago
  Would guess it would be complicated and difficult to update the kernel to support something like that. Not sure Linus would entertain PRs for custom boards that do something like that. Would think it would need to be an industry wide push for that. But just speculation..
  - vlovich123 5y ago
    We’re talking about the CPU architecture here, not custom one-off ARM boards. Think x86 or ARM not a Qualcomm SoC. And yes of course. Linus’ opinion would be needed.
    - bostonsre 5y ago
      Yea, that could probably be an even bigger impediment to trying to implement a separate interrupt processing unit I guess. My grasp of this area is tenuous, didn't even contemplate that. Would a new physical setup be required for something like this? Or would it all be in the cpu architecture?
ChuckMcM 5y ago
Argh, why do author's write stuff like this -- "It is, not to put too fine a point on it, a creaking old bit of wheezing ironmongery that, had the gods of microprocessor architecture been more generous, would have been smote into oblivion long ago." Just because a technology is "old" doesn't mean it is useless, or needs to be replaced. I'm all in favor of fixing problems, and refactoring to improve flow and remove inefficiencies. I am not a fan of re-inventing the wheel because gee, we've had this particular wheel for 50 years and its doing fine but hey let's reimagine it anyway. That said, the kink in x86 architecture was put their by "IBM PC Compatibility" and a Windows/Intel monopoly that went on way too long. But even knowing why the thing has these weird artifacts that just means the engineers are working under constraints you don't understand, doesn't give you license to dismiss what they've done as needing to be "wiped away." We are in a period where enthusiasts can design, build, and operate a completely bespoke ISA and micro-architecture with dense low cost FPGAs. Maybe they don't run at multi-GHz speeds but if you want to contribute positively to the question of computer architecture, there has never been a better time. You don't even have to build the whole thing! You can just add it into an existing architecture and compare how you do against it. Want to do flow control colored register allocation for speculative instruction retirement? You can build the entire execution unit in an FPGA and throw instructions at it to your hearts content and provide analysis of the results. Okay, enough ranting. I want AARCH64 to win so we can reset the problem set back to a smaller number of workarounds, but I think the creativity of people trying to advance the x86 architecture given the constraints is not something to belittled, it is to be admired.
- lazide 5y ago
  Well, no one gets promoted/a raise by writing ‘and everything is actually fine’ right? On the engineering side, similar more often than not. You get promoted by solving the ‘big problem’. The really enterprising (and ones you need to watch) often figure out how to make the big problem the one they are trying/well situated to solve - even if it isn’t really a problem.
  - Tuna-Fish 5y ago
    > Well, no one gets promoted/a raise by writing ‘and everything is actually fine’ right? But in this specific case, everything is absolutely not actually fine? x86 interrupt handling is terrible. It's slow, it's extremely fragile, and everything about it is just byzantine and overcomplicated.
PopePompus 5y ago
Since cloud servers are a bigger market than users who want to run an old copy of VisiCalc, why doesn't either Intel or AMD produce a processor line that has none of the old 16 and 32 bit architectures (and long-forgotten vector extensions), implemented in silicon? Why not just make a clean (or as clean as possible) 64 bit x86 processor?
- th3typh00n 5y ago
  Because the number of transistors used for that functionality is absolutely negligible, so removing it has virtually no benefit.
  - Symmetry 5y ago
    The number of transistors sure. The engineer time to design new features that don't interfere with old features is high. The verification time to make sure every combination of features plays sensibly together is extremely high. To the extent that Intel and AMD are limited by the costs of employing and organizing large numbers of engineers it's a big deal. Though that's also the reason they'll never make a second, simplified, core.
    - failwhaleshark 5y ago
      It's never going to happen. The ISA is a hardware contract.
      - PopePompus 5y ago
        When things get to the point where AMD is considering making nonmaskable interrupts maskable (as the article states), maybe it's time to invoke "force majeure".
  - PopePompus 5y ago
    Even so, doesn't having a more complex instruction set, festooned with archaic features needed by very few users, increase the attack surface for hacking exploits and increase the likelyhood of bugs being present? Isn't it a bad thing that the full boot process is understood in depth by only a tiny fraction of the persons programming for x86 systems (I'm certainly not one of them)?
raverbashing 5y ago
> Rather than use the IDT to locate the entry point of each handler, processor hardware will simply calculate an offset from a fixed base address So, wasn't the 8086 like this? Or at least some microprocessors that jump to $BASE + OFFSET to a point where one JMP fits more or less
- sounds 5y ago
  I have no idea how Intel's proposal handles this, but the 8086 jump was to a fixed location. i.e. BASE was always 0.
young_unixer 5y ago
Linus' opinion: https://www.realworldtech.com/forum/?threadid=200812&curpostid=200822 https://www.realworldtech.com/forum/?threadid=200812&curpost...
- bryanlarsen 5y ago
  tldr: AMD is "fix the spec bugs". Intel is "replace with better approach". Linus: do both, please!
- bogomipz 5y ago
  Thanks for posting this link. I was curious about a, b and d: >"(a) IDT itself is a horrible nasty format and you shouldn't have to parse memory in odd ways to handle exceptions. It was fundamentally bad from the 80286 beginnings, it got a tiny bit harder to parse for 32-bit, and it arguably got much worse in x86-64." What is it about IDT that requires parsing memory in odd ways? What is odd about it? >"(b) %rsp not being restored properly by return-to-user mode." Does anyone know why this is? Is this a historical accident or something else? >"(d) several bad exception nesting problems (NMI, machine checks and STI-shadow handling at the very least)" Is this one these two exceptions are nested together or is this an issue when either one of these is present in the interrupt chain? Is there any good documentation on this?
  - Someone 5y ago
    Reading https://wiki.osdev.org/Interrupt_Descriptor_Table https://wiki.osdev.org/Interrupt_Descriptor_Table, the table contains a 32-bit offset that’s split into two halves for IA-32 or a 64-bit one split into 3 parts for AMD64. There also seems to be some cruft from having segments and still having (¿some?) 16-bit code support, but I think that’s par for the game.
nanaahow 5y ago
Really nice <a href="https://nanahow.com/how-to-make-brown/">how https://nanahow.com/how-to-make-brown/">how to make brown</a>
korethr 5y ago
Somewhat off topic from the main thread of the article, but I have always wondered about the multiple privilege levels. What's the expected/intended use for them? The only thing I think of is separating out hardware drivers (assuming ring 1 can still directly read/write I/O ports or memory addresses mapped to hardware) so they can't crash the kernel should the drivers or hardware turn out to be faulty. But I don't think I've ever heard of such a design being used in practice. It seems everyone throws their driver code into ring 0 with the rest of the kernel, and if the driver or hardware faults and takes the kernel with it, too bad, so sad. Ground R̅E̅S̅E̅T̅ and start over. What I find myself wondering is why? It seems like a good idea on paper, at least. Is it just a hangover from other CPU architectures that only had privileged/unprivileged modes, and programmers just ended up sticking with what they were already familiar and comfortable with? Was there some painful gotcha about multiple privilege modes that made them impractical to use, like the time overhead of switching privilege levels made it impossible to meet some hardware deadline? Silicon-level bugs? Something else?
- monocasa 5y ago
  It works with the call gates. You could have a sort of nested microkernel idea if it wasn't such a mess with each ring able to include the lower privileged ring's address spaces. And not just a free for all, but the kernel really is just the control plane, but can set up all sorts of per process descriptor tables (the LDTs). So you'd have a tiny kernel at ring 0 which could R/W everything but wasn't responsible for much. Under that you'd have drivers at ring 1 that can't see the kernel, but can R/W user code at rings 2 and 3. Under that you'd have system daemons at ring 2 that can R/W regular programs but not drivers or the kernel. And then under that you had regular processes at ring 0 that have generally the same semantics as today's processes. Each process of any ring can export a syscall like table through the call gates, and so user code could directly invoke drivers or daemons without going throught the kernel at all. Basically IPC with about the same overhead as a C++ virtual method call. So what happened? The exact underlying semantics didn't exactly match many OSs anyone wanted to build (particularly OSs that anyone cared about in the late 80s early 90s). And you can enforce similar semantics all in software with the exception of the cheap IPC anyway.
- dmitrygr 5y ago
gwbas1c 5y ago
Why continue with x86? Given how popular ARM is, why not just join the trend?
- ronsor 5y ago
  x86 is not going anywhere for performance computing, backwards compatibility, and plethora of other reasons.
  - halayli 5y ago
    Given the recent trend initiated by cloud providers offering cheaper and almost equally performant arm based alternatives, I predict that arm and hopefully risc-v will be the popular choice in ~3 years. As for the consumer vertical, samsung and the like will most likely offer arm based laptops to complete against Apple's M1. In other words, x86 will be fading away as most of the money is being invested in alternatives including Intel. This shift reminds me of the time when cloud was still a new trend and many were saying at the time that companies won't run their business in a cloud for security reasons and more. When the alternative is simply better for businesses, they adjust to the new reality to stay in business.
bogomipz 5y ago
The author states: >'The processor nominally maintained four separate stacks (one for each privilege level), plus a possible “shadow stack” for the operating system or hypervisor.' Can someone elaborate on what the "shadow stack" is and what it's for exactly? This is the first time I've heard this nomenclature.
- sedachv 5y ago
  That is probably referring to System Management Mode (privilege level/ring -2) and Intel Management Engine (privilege level/ring -3). Two very terrible things.
  - saagarjha 5y ago
    More likely to be https://en.wikipedia.org/wiki/Shadow_stack https://en.wikipedia.org/wiki/Shadow_stack.
    - sedachv 5y ago
      Probably not. Shadow stacks don't really have anything to do with privilege levels or interrupts. And Intel only started shipping CPUs with "Control-flow Enforcement Technology" (which has their implementation of shadow stacks, and other things) last year.
linda172 5y ago
Thanks for your share I would argue the author is not really saying "old" is "bad", but instead that we have been piling more and more craft onto the old so it has now become a significant engineering exercise to work around the idiosyncrasies of the old system every time you want to do something else. To use your wheel analogy. It's sort of like starting with the wheel of horse cart and adding bits and pieces to that same wheel to make it somehow work as the landing gear wheel for a jumbo jet. At some point it might be a good idea to simply design a new wheel. https://couponswa.com/stores/nordstrom-coupons/ https://couponswa.com/stores/nordstrom-coupons/

200 points by eklitzke 5y ago

> interrupt handling would be faster, simpler, more complete, and less prone to corner-case bugs. If it's simpler, I can see why it will be faster and less prone to corner-case bugs (at least, the hardware will have fewer corner cases; the software is a different question). But how can simplification supposed to make FRED more "complete"?

vlovich123 5y ago

Given the multi core, NUMA and Spectre/meltdown reality we’re living in, and the clear benefits of the io_uring approach, why not just have a dedicated core(s) to handle “interrupts” which are nothing more than entries in a shared memory table?

electricshampo1 5y ago
This is essentially the approach taken by https://www.dpdk.org/ https://www.dpdk.org/ (network) and https://spdk.io/ https://spdk.io/ (storage) Anything trying to squeeze perf doing IO intensive work should switch to this model (context permitting of course).
eklitzke 5y ago
This approach works for I/O devices (and for things like network cards the kernel will typically poll them anyway), but I/O isn't the only thing that generates interrupts. For instance, a processor fault (e.g. divide by zero) should be handled immediately and synchronously since the CPU core generating the fault can't do any useful work until the fault is handled.
- vlovich123 5y ago
  Is that actually true? Wouldn’t this imply you could launch a DOS attack against cloud providers just generating divisions by zero?
  - bonzini 5y ago
    You would only attack yourself. The CPU time you're paying for would be spent processing division by zero exceptions.
    - vlovich123 5y ago
      Then the CPU isn’t stopping and is moving on doing other work. Meaning the divide by zero could be processed by a background CPU and doesn’t require immediate handling. Same for page faults.
      - bonzini 5y ago
        Your instance can still be preempted by the hypervisor.
        fulafel 5y ago
        The hypervisor is just some software that runs on the same CPU. It wouldn't help if the assertion that the CPU can't continue was true.
        bonzini 5y ago
        The CPU can't continue running user code because it jumps to the exception handler. But it can get to the hypervisor at any instruction boundary. (I write a hypervisor for a living :)).
      - bananabreakfast 5y ago
        Incorrect. The "CPU" is stopping and handling the fault. There is no background CPU from your perspective. In a cloud provider you are always in a virtual environment and using a vCPU which is constantly being preempted by the hypervisor. You cannot DOS a hypervisor just by bogging down your virtualized kernel.
        bonzini 5y ago
- justincormack 5y ago
  Faults for divide by zero are a terrible legacy thing, Arm etc do not do this, you test for zero if you want to, otherwise you get a value.
  - eklitzke 5y ago
    That was just an example, there are many other things the CPU can do that will generate a fault (for example, trying to execute an illegal instruction).
  - DblPlusUngood 5y ago
    A better example: a page fault for a non-present page.
    - vlovich123 5y ago
      Could be handled by having the CPU switch to a different process while the kernel CPU faults the data in.
      - ben509 5y ago
        The CPU doesn't know what processes are, that's handled by the OS. So there still needs to be a fault.
        vlovich123 5y ago
        You’re thinking about computer architecture as designed today. There’s no reason there isn’t a common data structure defined that the CPU can use to select a backup process, much how it uses page table data structures in main memory to resolve TLB misses.
        gpderetta 5y ago
        X86 had the concept of harware assisted context switching. Yet another unsued feature dropped in 64bit mode.
- bonzini 5y ago
  Or interprocessor interrupts for flushing the TLB, terminating the scheduling quantum, or anything else.
deleted 5y ago
[deleted]
devit 5y ago
There must be a way to alter a core's instruction pointer from another core or from hardware to support killing processes running untrusted machine code, and to support pre-emptive multithreading without needing to have compilers add a check for preemption on all backward branches and calls. These features are very worth the hassle of providing this capability (which is known as "IPI"s), and once you have that hardware interrupts become pretty much free to support by using the same capability and the OS/user can then decide whether to dedicate a core, to affinity them to a core, to load balance them among all cores or to disable the interrupts and poll instead.
- vlovich123 5y ago
  I was thinking rather than mucking with instruction pointers you would just send a message back to the other CPU saying “pause & switch to context X”. Technically an interrupt but one that can be handled internally within the CPU.
  - ori_b 5y ago
    What do you think "switch to context X" does, if not muck with the instruction pointer? Where do you think mucking with the instruction pointer is handled, if not within the CPU?
knz42 5y ago
This is the approach proposed in http://doi.org/10.1109/TPDS.2015.2492542 http://doi.org/10.1109/TPDS.2015.2492542 (preprint: https://science.raphael.poss.name/pub/poss.15.tpds.pdf https://science.raphael.poss.name/pub/poss.15.tpds.pdf )
- DSingularity 5y ago
  And old systems like Corey OS.
bostonsre 5y ago
Would guess it would be complicated and difficult to update the kernel to support something like that. Not sure Linus would entertain PRs for custom boards that do something like that. Would think it would need to be an industry wide push for that. But just speculation..
- vlovich123 5y ago
  We’re talking about the CPU architecture here, not custom one-off ARM boards. Think x86 or ARM not a Qualcomm SoC. And yes of course. Linus’ opinion would be needed.
  - bostonsre 5y ago
    Yea, that could probably be an even bigger impediment to trying to implement a separate interrupt processing unit I guess. My grasp of this area is tenuous, didn't even contemplate that. Would a new physical setup be required for something like this? Or would it all be in the cpu architecture?

ChuckMcM 5y ago

Argh, why do author's write stuff like this -- "It is, not to put too fine a point on it, a creaking old bit of wheezing ironmongery that, had the gods of microprocessor architecture been more generous, would have been smote into oblivion long ago." Just because a technology is "old" doesn't mean it is useless, or needs to be replaced. I'm all in favor of fixing problems, and refactoring to improve flow and remove inefficiencies. I am not a fan of re-inventing the wheel because gee, we've had this particular wheel for 50 years and its doing fine but hey let's reimagine it anyway. That said, the kink in x86 architecture was put their by "IBM PC Compatibility" and a Windows/Intel monopoly that went on way too long. But even knowing why the thing has these weird artifacts that just means the engineers are working under constraints you don't understand, doesn't give you license to dismiss what they've done as needing to be "wiped away." We are in a period where enthusiasts can design, build, and operate a completely bespoke ISA and micro-architecture with dense low cost FPGAs. Maybe they don't run at multi-GHz speeds but if you want to contribute positively to the question of computer architecture, there has never been a better time. You don't even have to build the whole thing! You can just add it into an existing architecture and compare how you do against it. Want to do flow control colored register allocation for speculative instruction retirement? You can build the entire execution unit in an FPGA and throw instructions at it to your hearts content and provide analysis of the results. Okay, enough ranting. I want AARCH64 to win so we can reset the problem set back to a smaller number of workarounds, but I think the creativity of people trying to advance the x86 architecture given the constraints is not something to belittled, it is to be admired.

lazide 5y ago
Well, no one gets promoted/a raise by writing ‘and everything is actually fine’ right? On the engineering side, similar more often than not. You get promoted by solving the ‘big problem’. The really enterprising (and ones you need to watch) often figure out how to make the big problem the one they are trying/well situated to solve - even if it isn’t really a problem.
- Tuna-Fish 5y ago
  > Well, no one gets promoted/a raise by writing ‘and everything is actually fine’ right? But in this specific case, everything is absolutely not actually fine? x86 interrupt handling is terrible. It's slow, it's extremely fragile, and everything about it is just byzantine and overcomplicated.

PopePompus 5y ago

Since cloud servers are a bigger market than users who want to run an old copy of VisiCalc, why doesn't either Intel or AMD produce a processor line that has none of the old 16 and 32 bit architectures (and long-forgotten vector extensions), implemented in silicon? Why not just make a clean (or as clean as possible) 64 bit x86 processor?

th3typh00n 5y ago
Because the number of transistors used for that functionality is absolutely negligible, so removing it has virtually no benefit.
- Symmetry 5y ago
  The number of transistors sure. The engineer time to design new features that don't interfere with old features is high. The verification time to make sure every combination of features plays sensibly together is extremely high. To the extent that Intel and AMD are limited by the costs of employing and organizing large numbers of engineers it's a big deal. Though that's also the reason they'll never make a second, simplified, core.
  - failwhaleshark 5y ago
    It's never going to happen. The ISA is a hardware contract.
    - PopePompus 5y ago
      When things get to the point where AMD is considering making nonmaskable interrupts maskable (as the article states), maybe it's time to invoke "force majeure".
- PopePompus 5y ago
  Even so, doesn't having a more complex instruction set, festooned with archaic features needed by very few users, increase the attack surface for hacking exploits and increase the likelyhood of bugs being present? Isn't it a bad thing that the full boot process is understood in depth by only a tiny fraction of the persons programming for x86 systems (I'm certainly not one of them)?

raverbashing 5y ago

> Rather than use the IDT to locate the entry point of each handler, processor hardware will simply calculate an offset from a fixed base address So, wasn't the 8086 like this? Or at least some microprocessors that jump to $BASE + OFFSET to a point where one JMP fits more or less

sounds 5y ago
I have no idea how Intel's proposal handles this, but the 8086 jump was to a fixed location. i.e. BASE was always 0.

young_unixer 5y ago

Linus' opinion: https://www.realworldtech.com/forum/?threadid=200812&curpostid=200822 https://www.realworldtech.com/forum/?threadid=200812&curpost...

bryanlarsen 5y ago
tldr: AMD is "fix the spec bugs". Intel is "replace with better approach". Linus: do both, please!
bogomipz 5y ago
Thanks for posting this link. I was curious about a, b and d: >"(a) IDT itself is a horrible nasty format and you shouldn't have to parse memory in odd ways to handle exceptions. It was fundamentally bad from the 80286 beginnings, it got a tiny bit harder to parse for 32-bit, and it arguably got much worse in x86-64." What is it about IDT that requires parsing memory in odd ways? What is odd about it? >"(b) %rsp not being restored properly by return-to-user mode." Does anyone know why this is? Is this a historical accident or something else? >"(d) several bad exception nesting problems (NMI, machine checks and STI-shadow handling at the very least)" Is this one these two exceptions are nested together or is this an issue when either one of these is present in the interrupt chain? Is there any good documentation on this?
- Someone 5y ago
  Reading https://wiki.osdev.org/Interrupt_Descriptor_Table https://wiki.osdev.org/Interrupt_Descriptor_Table, the table contains a 32-bit offset that’s split into two halves for IA-32 or a 64-bit one split into 3 parts for AMD64. There also seems to be some cruft from having segments and still having (¿some?) 16-bit code support, but I think that’s par for the game.

nanaahow 5y ago

Really nice <a href="https://nanahow.com/how-to-make-brown/">how https://nanahow.com/how-to-make-brown/">how to make brown</a>

korethr 5y ago

Somewhat off topic from the main thread of the article, but I have always wondered about the multiple privilege levels. What's the expected/intended use for them? The only thing I think of is separating out hardware drivers (assuming ring 1 can still directly read/write I/O ports or memory addresses mapped to hardware) so they can't crash the kernel should the drivers or hardware turn out to be faulty. But I don't think I've ever heard of such a design being used in practice. It seems everyone throws their driver code into ring 0 with the rest of the kernel, and if the driver or hardware faults and takes the kernel with it, too bad, so sad. Ground R̅E̅S̅E̅T̅ and start over. What I find myself wondering is why? It seems like a good idea on paper, at least. Is it just a hangover from other CPU architectures that only had privileged/unprivileged modes, and programmers just ended up sticking with what they were already familiar and comfortable with? Was there some painful gotcha about multiple privilege modes that made them impractical to use, like the time overhead of switching privilege levels made it impossible to meet some hardware deadline? Silicon-level bugs? Something else?

monocasa 5y ago
It works with the call gates. You could have a sort of nested microkernel idea if it wasn't such a mess with each ring able to include the lower privileged ring's address spaces. And not just a free for all, but the kernel really is just the control plane, but can set up all sorts of per process descriptor tables (the LDTs). So you'd have a tiny kernel at ring 0 which could R/W everything but wasn't responsible for much. Under that you'd have drivers at ring 1 that can't see the kernel, but can R/W user code at rings 2 and 3. Under that you'd have system daemons at ring 2 that can R/W regular programs but not drivers or the kernel. And then under that you had regular processes at ring 0 that have generally the same semantics as today's processes. Each process of any ring can export a syscall like table through the call gates, and so user code could directly invoke drivers or daemons without going throught the kernel at all. Basically IPC with about the same overhead as a C++ virtual method call. So what happened? The exact underlying semantics didn't exactly match many OSs anyone wanted to build (particularly OSs that anyone cared about in the late 80s early 90s). And you can enforce similar semantics all in software with the exception of the cheap IPC anyway.
dmitrygr 5y ago

gwbas1c 5y ago

Why continue with x86? Given how popular ARM is, why not just join the trend?

ronsor 5y ago
x86 is not going anywhere for performance computing, backwards compatibility, and plethora of other reasons.
- halayli 5y ago
  Given the recent trend initiated by cloud providers offering cheaper and almost equally performant arm based alternatives, I predict that arm and hopefully risc-v will be the popular choice in ~3 years. As for the consumer vertical, samsung and the like will most likely offer arm based laptops to complete against Apple's M1. In other words, x86 will be fading away as most of the money is being invested in alternatives including Intel. This shift reminds me of the time when cloud was still a new trend and many were saying at the time that companies won't run their business in a cloud for security reasons and more. When the alternative is simply better for businesses, they adjust to the new reality to stay in business.

bogomipz 5y ago

The author states: >'The processor nominally maintained four separate stacks (one for each privilege level), plus a possible “shadow stack” for the operating system or hypervisor.' Can someone elaborate on what the "shadow stack" is and what it's for exactly? This is the first time I've heard this nomenclature.

sedachv 5y ago
That is probably referring to System Management Mode (privilege level/ring -2) and Intel Management Engine (privilege level/ring -3). Two very terrible things.
- saagarjha 5y ago
  More likely to be https://en.wikipedia.org/wiki/Shadow_stack https://en.wikipedia.org/wiki/Shadow_stack.
  - sedachv 5y ago
    Probably not. Shadow stacks don't really have anything to do with privilege levels or interrupts. And Intel only started shipping CPUs with "Control-flow Enforcement Technology" (which has their implementation of shadow stacks, and other things) last year.

linda172 5y ago

Thanks for your share I would argue the author is not really saying "old" is "bad", but instead that we have been piling more and more craft onto the old so it has now become a significant engineering exercise to work around the idiosyncrasies of the old system every time you want to do something else. To use your wheel analogy. It's sort of like starting with the wheel of horse cart and adding bits and pieces to that same wheel to make it somehow work as the landing gear wheel for a jumbo jet. At some point it might be a good idea to simply design a new wheel. https://couponswa.com/stores/nordstrom-coupons/ https://couponswa.com/stores/nordstrom-coupons/