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

Don't Clobber the Frame Pointer

nsrip.com

Post reply on HN
Print view View original

11–20 of 46 posts

Re: Don't Clobber the Frame Pointer

#11

Post by dpifke »

kibwen wrote: post #6
tptacek wrote: post #4

Earlier quoted context omitted.

Major Rust cryptography libraries (see for instance Ring) use assembly, too. It's a pretty normal thing to do.

It's kinda weird that languages (or at least languages with pretensions to cryptography) are still forcing people to resort to asm directly rather than offering some sort of first-class support for constant time operations and not leaving secrets lying around in memory. It doesn't need to be super high level, it just needs to clear the infinitely low bar of assembly language. Does any language offer such a dedicated…

Go does have first class support for this in the standard library, e.g. https://pkg.go.dev/crypto/subtle.

It's not at all weird that the language authors needed assembly to implement such a thing. They figured out the tricky bits so you don't have to.

Re: Don't Clobber the Frame Pointer

#12

Post by matheusmoreira »

kibwen wrote: post #6
tptacek wrote: post #4

Earlier quoted context omitted.

Major Rust cryptography libraries (see for instance Ring) use assembly, too. It's a pretty normal thing to do.

It's kinda weird that languages (or at least languages with pretensions to cryptography) are still forcing people to resort to asm directly rather than offering some sort of first-class support for constant time operations and not leaving secrets lying around in memory. It doesn't need to be super high level, it just needs to clear the infinitely low bar of assembly language. Does any language offer such a dedicated…

As someone who's made a very simple language, I would say there are far too many moving parts involved to guarantee anything of the sort. It's probably better to just integrate libsodium.

Interpreters will literally switch on the type of things in order to figure out what to do with the value. They've lost the side channel battle before it even began. Compilers? Who knows what sort of code they will generate? Who knows how many of your precautions they will delete in an effort to "optimize"? Libsodium has its own memory zeroing function because compilers were "optimizing" the usage of the standard ones.

If you're writing anything cryptography related, you probably want to be talking directly to the processor which will be running your code. And only after you've studied the entire manual. Because even CPUs have significant gaps in the properties they guarantee and the conditions they guarantee them in.

Cryptographers might even consider lowering the level even further. They might want to consider building their own cryptoprocessor that works exactly like they want it to work. Especially if you need to guarantee things like "it's impossible to copy keys and secrets". I own three yubikeys for the sole purpose of guaranteeing this.

Re: Don't Clobber the Frame Pointer

#13

Post by wbl »

kibwen wrote: post #6
tptacek wrote: post #4

Earlier quoted context omitted.

Major Rust cryptography libraries (see for instance Ring) use assembly, too. It's a pretty normal thing to do.

It's kinda weird that languages (or at least languages with pretensions to cryptography) are still forcing people to resort to asm directly rather than offering some sort of first-class support for constant time operations and not leaving secrets lying around in memory. It doesn't need to be super high level, it just needs to clear the infinitely low bar of assembly language. Does any language offer such a dedicated…

That's not why cryptographers use assembly. We use assembly because performance often requires instructions the complier will never use that the CPU maker makes for us. Intrinsics invite all sorts of spilling issues and aren't quite as good.

Re: Don't Clobber the Frame Pointer

#14

Post by wbl »

matheusmoreira wrote: post #12
kibwen wrote: post #6

Earlier quoted context omitted.

It's kinda weird that languages (or at least languages with pretensions to cryptography) are still forcing people to resort to asm directly rather than offering some sort of first-class support for constant time operations and not leaving secrets lying around in memory. It doesn't need to be super high level, it just needs to clear the infinitely low bar of assembly language. Does any language offer such a dedicated…

As someone who's made a very simple language, I would say there are far too many moving parts involved to guarantee anything of the sort. It's probably better to just integrate libsodium. Interpreters will literally switch on the type of things in order to figure out what to do with the value. They've lost the side channel battle before it even began. Compilers? Who knows what sort of code they will generate? Who kno…

Interpreters don't need to have dynamic typing: for example the JVM and the interpreters before JIT. Even with dynamic types there are some spectacularly clever tricks people use: Smalltalk VMs are where they were invented and practiced a bunch.

In crypto code branching is exactly what you don't want to do to guarantee security. Branches go both ways if an attacker can force a mispeculate and microarchitectural state is not rolled back because it can't be.

Re: Don't Clobber the Frame Pointer

#15

Post by Veserv »

nimish wrote: post #7
tptacek wrote: post #4

Earlier quoted context omitted.

Major Rust cryptography libraries (see for instance Ring) use assembly, too. It's a pretty normal thing to do.

Sure but golang has its own special assembly flavor rather than using standard gcc flavor inline assembly. Probably because it's a soup to nuts compiler but still.

This is not at all comparable to inline assembly which interleaves two different languages into the same source file.

The presented examples are just a straight distinct assembly language associated with the golang ecosystem used in their own dedicated source files called via a FFI. This is comparable to just writing a pure assembly file and linking it into your program which is actually a much more reasonable thing to do than the insanity of inline assembly.

The problems being highlighted are just cases of people who do not understand ABIs and ABI compatibility. This is extremely common when crossing a language boundary due to abstraction mismatches and is made worse, not better, by doing even more magic behind the scenes to implicitly paper over the mismatches.

Re: Don't Clobber the Frame Pointer

#16

Post by userbinator »

Speaking as an Asm programmer for several decades: Calling conventions are stupid. They are the results of mindless stupid-compiler-oriented thinking from a time when compilers produced horrible copy-paste-replace code. The CPU itself couldn't care less which registers you use for what. So many wasted bytes on moving values between registers, just because the calling convention wanted it there, and no other reason. The only need to pay attention to calling conventions is when you're interfacing with compiler-generated code. Modern CPUs are fast, but there's still tons of inefficiency in compiler output.

Re: Don't Clobber the Frame Pointer

#17

Post by the8472 »

kibwen wrote: post #6
tptacek wrote: post #4

Earlier quoted context omitted.

Major Rust cryptography libraries (see for instance Ring) use assembly, too. It's a pretty normal thing to do.

It's kinda weird that languages (or at least languages with pretensions to cryptography) are still forcing people to resort to asm directly rather than offering some sort of first-class support for constant time operations and not leaving secrets lying around in memory. It doesn't need to be super high level, it just needs to clear the infinitely low bar of assembly language. Does any language offer such a dedicated…

Most crypto wants constant-time execution, optimizing compilers are not designed with that in mind. They have optimization passes that will happily turn your carefully crafted constant-time code back into branches when their heuristics deem that profitable.

Currently the most reliable way to get exactly the assembly you want is to write the assembly you want.

Re: Don't Clobber the Frame Pointer

#18

Post by nimish »

tptacek wrote: post #8
nimish wrote: post #7

Earlier quoted context omitted.

Sure but golang has its own special assembly flavor rather than using standard gcc flavor inline assembly. Probably because it's a soup to nuts compiler but still.

The point of this article is that Go-specific assembler generators (Avo in particular) are better than standard assembly for this purpose.

That doesn't preclude syntactic compatibility, does it?

Re: Don't Clobber the Frame Pointer

#19

Post by lmz »

userbinator wrote: post #16

Speaking as an Asm programmer for several decades: Calling conventions are stupid. They are the results of mindless stupid-compiler-oriented thinking from a time when compilers produced horrible copy-paste-replace code. The CPU itself couldn't care less which registers you use for what. So many wasted bytes on moving values between registers, just because the calling convention wanted it there, and no other reason. T…

> The only need to pay attention to calling conventions is when you're interfacing with compiler-generated code.

So, the vast majority of code out there in the wild?

Re: Don't Clobber the Frame Pointer

#20

Post by almostgotcaught »

lmz wrote: post #19
userbinator wrote: post #16

Speaking as an Asm programmer for several decades: Calling conventions are stupid. They are the results of mindless stupid-compiler-oriented thinking from a time when compilers produced horrible copy-paste-replace code. The CPU itself couldn't care less which registers you use for what. So many wasted bytes on moving values between registers, just because the calling convention wanted it there, and no other reason. T…

> The only need to pay attention to calling conventions is when you're interfacing with compiler-generated code. So, the vast majority of code out there in the wild?

vast majority doesn't even begin to describe it - i would wager 10 years of my salary that the fraction of all currently running CPU instructions that were handwritten is so small that it's within the margin of error (i.e., random bit flips) for whatever computer you use to perform the count.
Post reply on HN