Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

RISC-V J extension – Instructions for JITs

github.com

Post reply on HN
Print view View original

51–56 of 56 posts

Re: RISC-V J extension – Instructions for JITs

#51

Post by snek_case »

pjmlp wrote: post #28
snek_case wrote: post #16

There's a document in there about pointer masking: https://github.com/riscv/riscv-j-extension/blob/master/point... It seems like the objective of this is to implement different access privileges... but why do you need specialized instructions for this? This is typically done by the OS and memory protection. The pointer masking extension would be to have multiple levels of privilege within a single process? I'm assumi…

Fixing C, hardware memory tagging is the ultimate mitigation strategy for pointer tricks. Already being successfully used for decades in Solaris SPARC, iOS/macOS and Android are increasingly pushing for it on ARM CPUs, Pluton on Azure Sphere OS,...

I found this post on ARM MTE which was helpful in understanding the concept: https://www.anandtech.com/show/16759/sponsored-post-keep-you...

Seems to me this will have an execution overhead though, and that the best way to improve security would be to finally move beyond C. Most modern languages make buffer overflows impossible.

Re: RISC-V J extension – Instructions for JITs

#52

Post by pjmlp »

snek_case wrote: post #51
pjmlp wrote: post #28

Earlier quoted context omitted.

Fixing C, hardware memory tagging is the ultimate mitigation strategy for pointer tricks. Already being successfully used for decades in Solaris SPARC, iOS/macOS and Android are increasingly pushing for it on ARM CPUs, Pluton on Azure Sphere OS,...

I found this post on ARM MTE which was helpful in understanding the concept: https://www.anandtech.com/show/16759/sponsored-post-keep-you... Seems to me this will have an execution overhead though, and that the best way to improve security would be to finally move beyond C. Most modern languages make buffer overflows impossible.

Except all those fine people writing UNIX clones and embedded stuff will never do it, so here we are.

It was already known since the early days how bad C was versus the competition.

UNIX made it famous, UNIX won the server room wars, UNIX will keep it going.

Re: RISC-V J extension – Instructions for JITs

#53

Post by pjmlp »

blibble wrote: post #48
pjmlp wrote: post #47

Earlier quoted context omitted.

Apparently someone is lacking reading skills in how WIL is used on the kernel.

okay, so there exists a library that allows people to write C++ code that can be loaded into the kernel this doesn't mean the ntoskrnl.exe is written in C++ the fact nvidia's linux loadable kernel blob is written in C++ doesn't suddenly mean linux is written in C++ "grasping at straws" would seem to sum up your position

Why do you think Microsoft decided to drop C support beyond C89 and only caved in due to the pressure of FOSS projects?

A kernel without drivers, only produces heat.

> "grasping at straws" would seem to sum up your position

Fits exactly the position of someone that desperately wants to assert ntoskernel.exe is written just like when NT 3.51 got released into the world.

"Kernel proper - This is mostly written in C. Things like the memory manager, object manager, etc. are mostly written in C. The boot loaders are written in ASM, but set up a C environment rather quickly.

Drivers - that said, a lot of newer kernel mode drivers are actually written in C++ (however, its style is more akin to "C with classes". Lower level code has been much slower to adopting anything past C++98)

User land - Mostly C++ with varying levels of quality and version compliance. If it's a pre-Windows 8.0 component, it was written against mostly C++98. More recent features are C++14 and better."

-- https://www.reddit.com/r/cpp/comments/4oruo1/windows_10_code...

Bye, have fun with C.

Re: RISC-V J extension – Instructions for JITs

#54

Post by blibble »

pjmlp wrote: post #53
blibble wrote: post #48

Earlier quoted context omitted.

okay, so there exists a library that allows people to write C++ code that can be loaded into the kernel this doesn't mean the ntoskrnl.exe is written in C++ the fact nvidia's linux loadable kernel blob is written in C++ doesn't suddenly mean linux is written in C++ "grasping at straws" would seem to sum up your position

Why do you think Microsoft decided to drop C support beyond C89 and only caved in due to the pressure of FOSS projects? A kernel without drivers, only produces heat. > "grasping at straws" would seem to sum up your position Fits exactly the position of someone that desperately wants to assert ntoskernel.exe is written just like when NT 3.51 got released into the world. "Kernel proper - This is mostly written in C. Th…

> "Kernel proper - This is mostly written in C.

thank you

only took 17 hours to get there, but we finally got there

Re: RISC-V J extension – Instructions for JITs

#55

Post by [deleted] »

KerrAvon wrote: post #6
aidenn0 wrote: post #3

For tagged values, I loved the POWER rlwinm: Rotate Left Word Immediate aNd with Mask (and it's companion rlimi). Pretty much any sane tagging scheme could be converted to the unboxed value with that single instruction; even somewhat exotic tagging schemes like mixing high-bit and low-bit tagging could be handled by it. Of course in modern architectures being able to do something in one instruction is only tenuously…

I heard someone use those instructions once as examples of something compilers could do better than humans writing assembly -- Apple's MPW C compilers for PowerPC were capable of peephole optimizations that would produce them where a human might not think of them. (At least, that was the argument.)

[deleted]

Re: RISC-V J extension – Instructions for JITs

#56

Post by socialdemocrat »

adgjlsfhk1 wrote: post #29
pjmlp wrote: post #27

Earlier quoted context omitted.

This has been tried plenty of times, ARM just decided something else because reasons. Also to note that all hardware vendors are adopting hardware memory tagging as the only way to fix C. Intel messed up with MPX, but I definitely see they coming with an alternative, as I bet they won't like to be seen as the only vendor left without such capabilities.

I'm honestly not sure why we haven't just admitted C isn't fixable.

Zig seems like a good replacement. It interfaces really well with C and works as a drop in replacement. Better type checking, error handling, memory management etc.
Post reply on HN