[Cryptography] How to lock registers with GCC?

tpb-crypto at laposte.net tpb-crypto at laposte.net
Thu May 15 13:15:57 EDT 2014


> Message du 10/05/14 00:02
> De : "Nemo" 
> tpb-crypto at laposte.net writes:
> 
> > Is it possible to give a directive to GCC while compiling and/or does
> > it support some macro/routine/directive/library/whatever, that would
> > allow to load values into processor registers and then lock one or two
> > registers, which would become unchangeable? Performance
> > notwithstanding.
> 
> GCC supports global register variables:
> 
> http://gcc.gnu.org/onlinedocs/gcc/Global-Reg-Vars.html
> 
> "Defining a global register variable in a certain register reserves that
> register entirely for this use, at least within the current
> compilation. The register is not allocated for any other purpose in the
> functions in the current compilation, and is not saved and restored by
> these functions."
> 
> So this is a step towards what you want, provided you compile the entire
> application (including all libraries) with the same global declaration
> visible.
> 
> However, as others have pointed out, your next problem is the operating
> system. You would need to recompile the kernel with the same global
> declaration visible there, too, so that the kernel's own code would not
> use it. You would need to audit all of the assembly in the kernel to
> eliminate any uses there, too.
> 
> Obviously, you would need to modify the context switch machinery not to
> save and restore the register.
> 
> Finally, any other application running on the same core following a
> context switch might clobber the register... So you would either need to
> perform the same exercise for all applications on the system, or you
> would need to use the "CPU binding" machinery (see "numactl
> --physcpubind ..." for a starting point) to ensure your process and only
> your process runs on a certain core.
> 
> All of this just to ensure that someone with total access to your
> physical memory cannot steal your password. Is there anything else in
> memory that might be of interest to such an attacker?
> 
> I wonder, though... How many registers would it take, in principle, to
> encrypt/decrypt every memory access?
> 
> - Nemo
> https://self-evident.org/

Your message was very helpful, I've written a very long missive about the ideas that are floating in my head and it may be very boring to you guys.

This is a tl;dr version of the long missive for you guys that do not have patience for walls of text written by foreigners, but wish to collaborate anyway:


I need to pick your guys brains on a few other issues, if you help me maybe this thing can become a reality in one year or so:
- Can we use numactl against all processors? How much universal is this thing? Ripping it apart to put it into an OpenBSD is a no-no because of its GPL license. Other suggestions besides begging the original goder for an exception?
- Are there GCC routines to determine how many cores a system has and how many registers of all types are available? Is there a library for that? Can we ask the OS itself at boot time? Because this critter would run in OS boot time, it creates a problem shell commands cannot solve for us, which is to identify what are the resources we messing with at the startup moment.
- Do you guys know any symmetric encryption routine that is quantum-breaking-proof and is compatible with OpenBSD license and offers good protection from as little as 96 bit keys or even less?
- What can we do with the libraries that weren't compiled to exclude a certain CPU core and registers? Is the OS process scheduler good enough to keep all programs from poking into that core? More suggestions to protect that core, please? Can we sandbox the entire kernel? lol
- Can you guys suggest a simple process scheduler routine to put in a single CPU core that is fast and battle-tested and compatible with OpenBSD license? My goal is to make it run as a one single process to use that core and slice it in threads. It must run at 100% if the pseudorandom is necessary like in servers, or just do its little job when called in cellphones, then it goes to sleep again.
- What common barebones multicore hardware should I buy (arm, mips, sparc, etc)? That are cheap enough for a poor coder to buy for peanuts, but are good enough to run OpenBSD to test this thing? I wanna make it multi-platform to the biggest possible measure.


Proprietary systems be damned, but if they want to implement it after we created the standard, good for them. The standard is not mine either, you guys will be invited to collaborate at the right moment, meanwhile we are merely working out together the possible technical barriers.

For the next two weeks I still have to work on a project that uses a cellphone to shutdown a laptop when the two are taken far enough away from each other by means of bluetooth parity, it is my priority at this moment.

So, my answering e-mails will be sloppy at best for the next two weeks, cause my brain is old and uses preemptive tasking schedule.

I'm also sorry for the sloppy English because I'm not a native speaker and this wall of text beat my entire vocabulary to a bloody pulp.


Thank you,
TPB


More information about the cryptography mailing list