3 ms·

CPU would raise a signal just as null pointer exception? And it seems a lot of code (for eg, safeintadd metioned below) assumes no exception. Would not all that

CPU would raise a signal just as null pointer exception? And it seems a lot of code (for eg, safeintadd metioned below) assumes no exception. Would not all that code get messed up? Would it be possible to just silently replace with arbitrary sized integer and not break any code like safeintadd?

dahfizz 5y ago
CPUs don't raise exceptions, that is a software concept. CPUs do have traps, like for division by zero, but those are not exceptions in the way you think. Null pointers are also handled by the kernel, not the CPU. Its called a segmentation fault because you are trying to access a memory segment that the OS doesn't want you to.
- airocker 5y ago
  I dont think kernel handles NPEs: https://stackoverflow.com/questions/63091446/what-happens-at-cpu-level-if-you-dereference-a-null-pointer https://stackoverflow.com/questions/63091446/what-happens-at...
  - account42 5y ago
    From your link: A NULL pointer in most (but not all) C implementations is address 0. Normally this address is not in a valid (mapped) page. Any access to a virtual page that's not mapped by the HW page tables results in a page-fault exception. e.g. on x86, #PF. This invokes the OS's page-fault exception handler to resolve the situation.
    - airocker 5y ago
      Yes, page fault exceptions happen within the CPU, they cannot happen in software. I think of it as C is close to assembly and does not check every memory address is referencing. It just compiles and CPU starts running it. If somehow a memory of 0 is dereferenced, it is already run by the CPU in its fetch/decode cycle. but of course once the excetion happens, Kernel is responsible for killing the actual process. So both CPU and kernel do it together.
- agalunar 5y ago
  It's worth noting that the term "exception" is in fact used for traps that aren't interrupts.
jerf 5y ago
In C, you can't "just" replace with arbitrary-sized integers. They are fundamentally different memory shapes. You may not be able to turn enforcement on for all code immediately. There's even the rare bits of code that depend on current overflow behavior. (Due to our human brains and the fact that we can easily name these bits of code, making the cognitively available, people often grotesquely overestimate the amount of code that operates this way. I'm sure it's only a matter of how many zeros belong in the 0.001%.) But we need this support to be available for code to be turn on easily and cheaply. But what really boggles my mind, again given all the security work we've done, is that the reaction to this remains a combination of silence and "we can't do that!", when it seems to me the reaction ought to be "well duh jerf we all know that already." I don't get this. I don't get this attitude at all. This is a huge source of errors, a good fraction of which are security bugs, and nobody seems to care. Incomprehensible. This is, arguably, the number one thing that could be getting changed right now to fix security issues, and I just get slack-jawed "whaaaa?" in response to the idea. One hundred plus one hundred is not negative fifty six! Here we are trying to hold together megabytes upon megabytes of security-critical code in a world where 100 + 100 = -56. Is it any wonder that writing any sort of code to maintain security invariants is tough in an environment where 100 + 100 = -56?
- airocker 5y ago
  I feel like carefully planned with compiler level errors(not warnings), and some glibc non-backward compatible changes. we can achieve this in software layer.

dahfizz 5y ago

CPUs don't raise exceptions, that is a software concept. CPUs do have traps, like for division by zero, but those are not exceptions in the way you think. Null pointers are also handled by the kernel, not the CPU. Its called a segmentation fault because you are trying to access a memory segment that the OS doesn't want you to.

airocker 5y ago
I dont think kernel handles NPEs: https://stackoverflow.com/questions/63091446/what-happens-at-cpu-level-if-you-dereference-a-null-pointer https://stackoverflow.com/questions/63091446/what-happens-at...
- account42 5y ago
  From your link: A NULL pointer in most (but not all) C implementations is address 0. Normally this address is not in a valid (mapped) page. Any access to a virtual page that's not mapped by the HW page tables results in a page-fault exception. e.g. on x86, #PF. This invokes the OS's page-fault exception handler to resolve the situation.
  - airocker 5y ago
    Yes, page fault exceptions happen within the CPU, they cannot happen in software. I think of it as C is close to assembly and does not check every memory address is referencing. It just compiles and CPU starts running it. If somehow a memory of 0 is dereferenced, it is already run by the CPU in its fetch/decode cycle. but of course once the excetion happens, Kernel is responsible for killing the actual process. So both CPU and kernel do it together.
agalunar 5y ago
It's worth noting that the term "exception" is in fact used for traps that aren't interrupts.

jerf 5y ago

In C, you can't "just" replace with arbitrary-sized integers. They are fundamentally different memory shapes. You may not be able to turn enforcement on for all code immediately. There's even the rare bits of code that depend on current overflow behavior. (Due to our human brains and the fact that we can easily name these bits of code, making the cognitively available, people often grotesquely overestimate the amount of code that operates this way. I'm sure it's only a matter of how many zeros belong in the 0.001%.) But we need this support to be available for code to be turn on easily and cheaply. But what really boggles my mind, again given all the security work we've done, is that the reaction to this remains a combination of silence and "we can't do that!", when it seems to me the reaction ought to be "well duh jerf we all know that already." I don't get this. I don't get this attitude at all. This is a huge source of errors, a good fraction of which are security bugs, and nobody seems to care. Incomprehensible. This is, arguably, the number one thing that could be getting changed right now to fix security issues, and I just get slack-jawed "whaaaa?" in response to the idea. One hundred plus one hundred is not negative fifty six! Here we are trying to hold together megabytes upon megabytes of security-critical code in a world where 100 + 100 = -56. Is it any wonder that writing any sort of code to maintain security invariants is tough in an environment where 100 + 100 = -56?

airocker 5y ago
I feel like carefully planned with compiler level errors(not warnings), and some glibc non-backward compatible changes. we can achieve this in software layer.