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

ChkTag: x86 Memory Safety

community.intel.com

Post reply on HN
Print view View original

141–147 of 147 posts

Re: ChkTag: x86 Memory Safety

#141

Post by sparkie »

sparkie wrote: post #109
afishhh wrote: post #45

Earlier quoted context omitted.

There's a technique known as "NaN boxing" which exploits the fact double precision floats allow you to store almost 52 bits of extra data in what would otherwise be NaNs. If you assume the top 16 bits of a pointer are unused[1], you can fit a pointer in there. This lets you store a pointer or a full double by-value (and still have tag bits left for other types!). Last I checked LuaJIT and WebKit both still used this…

> On amd64 they actually need to be sort of "sign extended" so require some fixup once extracted. Pointers need to be canonical if LAM/UAI is not enabled. The simplest way to do it is to shift left by 16, then shift arithmetic right by 16. (Or 7 if using 5-level paging). Alternatively, you can store the pointer shifted left by 16 bits, and have the tag in the lower 16 bits, then canonicalizing the pointer is just a s…

Apologies, there's a mistake in the godbolt link above. `SIGN_BIT` should be `0x8000` and not `0x1000`.

Re: ChkTag: x86 Memory Safety

#142

Post by superkuh »

tredre3 wrote: post #49
superkuh wrote: post #4

I hope there are OS level (ie kernel build options) to turn this kind of thing off or just ignore the 'tags'. I know it's important for corporate use cases and monetary transactions and all that, but on my personal computer I use for fun I want to be able to peek and poke.

If you're worried that this is going to prevent you from peeking and poking, I think you're mistaken. This is to protect a process against itself, not the outside. It will also likely be a single bit flip away of being unenforced at runtime, as most x86 protections already are to be to make debugging tools feasible. By the way, there are already systems in place to prevent you from accessing certain memory zones. Yes…

I have a patch set to removes virtual memory interprocess blocking for linux 5.6 that I run as kernel on a couple of my machines. I'm just hoping that this is patchable out too.

Re: ChkTag: x86 Memory Safety

#143

Post by IshKebab »

pjmlp wrote: post #139
IshKebab wrote: post #121

Earlier quoted context omitted.

Sure but nobody is actually writing foundational software (as we are now calling it) in Lisp, Java or Ada (and it also has no good answer for use-after-free which is a huge class of vulnerabilities). This is the first point in history where it's actually feasible in real non-research life to write an entire system in only memory safe languages. (And no, the existence of `unsafe` doesn't invalidate this point.)

I see plenty of foundational software in the biggest mobile OS, IoT devices and cloud computing infrastructure. Ada only has use-after-free if unchecked deallocation is used, since we are way beyond Ada83, alternatives do exist in Ada 2022. If anything we will only get more foundational software in safer languages, when the generation that only accepts C and C++ for specific domains is no longer among us. Unfortunate…

> Ada only has use-after-free if unchecked deallocation is used

You mean if you just never deallocate? Or is there a third option? Genuine question; I don't follow Ada closely.

> If anything we will only get more foundational software in safer languages, when the generation that only accepts C and C++ for specific domains is no longer among us.

I'm more optimistic - the Rust in Linux people are making progress and that's probably the thickest den of naysayers. Uutils is actually being used in Ubuntu (and sudo-rs I think?).

It'll probably take a long time until Rust outweighs C but I think we're talking 10-20 years not 30-40.

Re: ChkTag: x86 Memory Safety

#144

Post by [deleted] »

tdullien wrote: post #122
mshroyer wrote: post #105

Earlier quoted context omitted.

Yeah it's the most succinct explanation I've seen of weird machines and memory tagging. Definitely bookmarking this one. I wonder if video of the talk that presumably presented this is available.

I don't know tbh, and I gave that talk when I was in terrible shape, so I'm not upset ;). If people care a lot, I can record a YouTube video on the topic.

[deleted]

Re: ChkTag: x86 Memory Safety

#145

Post by musicale »

pjmlp wrote: post #133
musicale wrote: post #91

Earlier quoted context omitted.

> Fil-C shows this can be solved at the software layer for things in this category that can afford the overhead of a GC. Mainline clang and g++ are also getting better with things like -fbounds-safety and -fsanitize=address. As I understand it, they typically have some overhead, but I'm willing to accept that overhead to have a kernel, web browser, etc. without memory errors. The decision that memory safety is too co…

Nah, it was only a UNIX thing and C, see the world of systems languages and OS written in them outside Bell Labs. Had UNIX and C a price tag on their source code comparable to the competition, instead of a symbolic price and an annotated source code book, history would have played a different music.

What competing OSes/languages do you think might have/should have surpassed Unix and C?

Re: ChkTag: x86 Memory Safety

#146

Post by pjmlp »

IshKebab wrote: post #143
pjmlp wrote: post #139

Earlier quoted context omitted.

I see plenty of foundational software in the biggest mobile OS, IoT devices and cloud computing infrastructure. Ada only has use-after-free if unchecked deallocation is used, since we are way beyond Ada83, alternatives do exist in Ada 2022. If anything we will only get more foundational software in safer languages, when the generation that only accepts C and C++ for specific domains is no longer among us. Unfortunate…

> Ada only has use-after-free if unchecked deallocation is used You mean if you just never deallocate? Or is there a third option? Genuine question; I don't follow Ada closely. > If anything we will only get more foundational software in safer languages, when the generation that only accepts C and C++ for specific domains is no longer among us. I'm more optimistic - the Rust in Linux people are making progress and th…

In practice, Unchecked_Deallocation should be used as much as unsafe in Rust.

Ada provides a series of features towards that goal.

First one, already present in Ada 83, is that stack allocation is dynamic, a bit like C99 VLAs, with the differenc that it is bounds checked and and exception is thrown if there is not enough space, instead of corrupting the stack.

Also Ada pointers (access types), have some type constraints, so already with that one can make some kind of arena like storage that doesn't depend on using pointers all over the place.

Ada 95 introduced controlled types, which is basically RAII in Ada, providing yet another way not to use Unchecked_Deallocation directly on "userspace" code.

Ada 2005 introduced bounded and unbounded container types, further extended and improved in later versions, which allow to write many algorithms and data structures that build upon them, without having to go into low level memory allocation approaches.

With Ada 2012 formal proofs, coupled with SPARK 2014 tooling, you can additionally ensure specific conditions are met before doing whatever with specific resources, including ownership.

Re: ChkTag: x86 Memory Safety

#147

Post by pjmlp »

musicale wrote: post #145
pjmlp wrote: post #133

Earlier quoted context omitted.

Nah, it was only a UNIX thing and C, see the world of systems languages and OS written in them outside Bell Labs. Had UNIX and C a price tag on their source code comparable to the competition, instead of a symbolic price and an annotated source code book, history would have played a different music.

What competing OSes/languages do you think might have/should have surpassed Unix and C?

VMS could have been one, for example.

PL/I variants were being widely used, Apple was a Pascal fan, and is the company that actually created Object Pascal, not Borland.

Modula-2 was around as well, unfortunely without an OS to go to market alongside it.

The real question is, all things on equal footing regarding price, without access to source code to just type in/copy, what operating systems would people be willing to pay for.

Post reply on HN