« first day (2960 days earlier)      last day (1721 days later) » 

b degnan
b degnan
12:37 AM
@FutureSecurity I've learned a few things about how other people make MMUs. I've made MMUs for SPARCs and my own CPUs. I had linked lists that kept track of the locations in memory so the memory addresses didn't have to be contiguous. Apparently, in x86, that's not a thing. You need to have contiguous memory for a pointer. So... can someone please tell me I'm wrong about this. I just cannot understand the Intel documentation.
Basically, I did more than just remap the high bits because I didn't know any better... I guess. I'm trying to reach 20 years back in the archives for wtf I was thinking when I first read about and implemented on of these things.
 
peterh
peterh
@bdegnan I am not talking about hiding the pages, I am talking about protecting them. Simply the process should have no permission to access them. But the accessibility of a RAM page will then depend on an information, i.e. if you can find somehow a way to trick a daemon to give a memory address, you already have a sechole. It opens the door before a whole new class of secholes.
 
b degnan
b degnan
Well, the processes don't have permission to access them if your MMU is any good. Even if I have the memory address of a valid place in memory, the hardware prevents reading it due to the fact that the process number is tied to the enable lookup.
That's the point of the mmu, to protect memory and give faults.
I have a feeling that x86 MMUs just suxrox, like everything else in the x86. I have to applaud Intel and Microsoft for 30 years of backward compatibility, but because of that they have strange choices.
so, on my Mac, if I try to read the kernel space, which is a fixed address (interrupt table) from userland, it throws a shoe. If I sudo, it just gave me the addresses. So, if you can become root, you can see it.
 
 
1 hour later…
b degnan
b degnan
1:56 AM
Group Proofs, is in verifying that all of the 20 computers on my network are part of the group. In the real world, where does one use that? I just reviewed part of a paper where this was the premise in IoT. I did the hardware part of the review, but I have no idea what the practical application is.
(nothing seemed to come up on crypto.se fyi)
 
 
2 hours later…
forest
forest
3:46 AM
@peterh There is. There are actually two different PRNGs. One, implemented in the file lib/random32.c, is an LFSR-based PRNG which is very bad, but fast. The other, implemented in arch/x86/drivers/char/random.c, is a strong CSPRNG that collects randomness from physical and unpredictable processes. They expose different APIs into the kernel, and the latter additionally exposes it to userspace. The problem is that the former, LFSR-based API is used to generate secrets in parts of the kernel.
@peterh ASLR is not memory-protection. It's intended for scriptless exploits (e.g. exploiting the vulnerability in an image or video parser) which cannot adjust their payloads dynamically based on the behavior of the target program. Against an attack that can adjust itself, it's fatally flawed and there are dozens of ways to predict offsets. For static attacks such as the ones mentioned, it is actually good.
@bdegnan You need contiguous pages for a pointer when it comes to logical pages. The page tables allow the actual pages to be in non-contiguous regions of physical memory, but the logical addresses must be contiguous (unless, of course, you implement some kind of memory-management in-process, as with the heap).
@bdegnan That's not quite how it works. On Mac (and any other *nix), root is just another ring 3 process like any other user. What is happening is that trying to read kernel memory must be done through a kernel API (like /dev/kmem). During the read(), the kernel checks what your UID is and, if it's 0 or you otherwise have high privileges, the kernel will return privileged memory to you. But if you try to access the memory directly, root or not, it throws a GPF.
@bdegnan Are you thinking of network access controls using remote attestation?
 
Future Security
Future Security
4:16 AM
I was in the process of writing something about that second part. It sounds like you're mistaken @peterh. On modern general-purpose machines each page has its own read, write, and execute permissions. Those permissions are enforced on the hardware level. This could be used to prevent one process from accessing another process's private memory.
In practice, that's not actually the primary way one process's memory is protected from another. Each process gets its own flat continuous virtual address space. There is the physical address space and virtual address spaces. When an OS runs multiple processes concurrently you do have parts of each program stored in different regions of physical RAM at the same time. But from the perspective of a process it wouldn't even look like you were sharing memory with any other process.
Process A's virtual address space is entirely different from process B's virtual address space. (Basically... you can actually request that specific pages are shared between multiple processes. That's an OS feature that enables "inter-process communication". Sharing writable memory is only by request though.)
If you read one byte at a time starting from address zero going all the way to 2^64 - 1 (bytes from any page you had read permissions for, anyway) then at no point would you read another process's private memory. Process A's memory at (virtual) address 0x100000000 is not the same memory as process B's memory at address 0x100000000.
From the perspective of an unpriveledge process it looks like that process has exclusive access to its entire address space. Virtual memory isolates processes from one another. Hardware on the CPU does translation back and forth between virtual addresses and physical addresses. It almost looks like magic.
That's simplified. There may be additional restrictions that real world hardware, but those don't let unprivileged malicious processes from accessing a separate process's memory.
ASLR plays no role in protecting the memory of one process from another. It basically only exists to complicate software exploits. It's not a substitute for writing code without bugs that enable remote code execution. Nor for process isolation. Nor for memory permissions.
 
forest
forest
@FutureSecurity Although there are three different permissions, on some architectures, read implies execute. On pretty much all architectures (including x86 sans MPK), execute implies read.
And MPK is not implemented in the same way as page table permissions in the MMU, so it's slow.
I think EPT can also do that, but then you're using VT-x (hardware virtualization) as a hack.
 
Future Security
Future Security
I almost used the phrase "permission bits", but I knew that was definitely not 100% accurate.
 
forest
forest
@FutureSecurity 64-bit x86 doesn't have a 64-bit address space.
It's usually 48-bit virtual address space (and 36-bit physical).
 
Future Security
Future Security
4:31 AM
It has up to 64 bits.
 
forest
forest
82
Q: Why do x86-64 systems have only a 48 bit virtual address space?

er4z0rIn a book I read the following: 32-bit processors have 2^32 possible addresses, while current 64-bit processors have a 48-bit address space My expectation was that if it's a 64-bit processor, the address space should also be 2^64. So I was wondering what is the reason for this limitation?

x86-64 cpu-architecture virtual-memory processor-architecture
 
Future Security
Future Security
@forest What's MPK and EPT stand for?
 
forest
forest
MPK = Memory Protection Keys. EPT = Extended Page Tables.
MPK is a feature in new Intel processors that allows more fine-grained control over pages, but it's slow. EPT is a virtualization feature in modern VT-x which allows for better efficiency and flexibility.
But, in a pinch, EPT can be used to simulate some features of MPK for a guest under a hypervisor.
E.g. you can use MPK (or a hack with EPT) to have true execute-only without allowing reads. That is, you could set RIP to the address, but attempts to read from anything there will trigger a general protection fault. But with the regular x86 MMU, if something is executable, it's also readable.
In theory, true execute-only would be useful to make ROP harder, but side-channels still exist.
It would also limit the damage from arbitrary read primitives.
 
Future Security
Future Security
Interesting. I'm surprised "protection keys" wasn't vocabulary I heard in my education. It's not that complex, but I can see why hey simplified it to "permissions".
 
forest
forest
Well it's a new feature and it's Intel-specific. It's not part of the x86 ISA.
It's like MPX or RDRAND or UMIP.
The NX feature in modern CPUs is actually just a slight change to page permission handling. Before NX, if a page is readable, then you can set the IP to that address and begin executing. With NX, you additionally need the executable flag in order to do that without it bailing on you.
But it just turns out that the reverse of NX (via MPK) is too difficult to implement without a perf-hit.
 
Future Security
Future Security
4:43 AM
I can't imagine learning about x86 specifics in a bottom up approach. Reading from published docs that is.
 
forest
forest
It's painful. I only know a very small fraction of it. I read a 2000-page document on one specific PCH and even that was, supposedly, only a very small portion of the total (internal) documentation.
But generally, there's the official books from Intel on the architecture that are authoritative.
They mostly explain microarchitectural reasons behind certain optimizations and stuff like that, but there are also additional documents such as the (huge) document on VT-x.
And, of course, a myriad of non-public documents for OEMs, and fully internal developer docs.
@FutureSecurity We've come a long way from cooperative multitasking, huh. :P
 
Future Security
Future Security
Sometimes I day dream about using an operating system designed only to run applications from source code.
 
forest
forest
Gentoo!
Or any other source-based distro. It's really nice.
 
Future Security
Future Security
But using a restricted well-defined language instead of C. Then you could implement some security features not implementable on current hardware.
 
forest
forest
Ah
I'm a fan of kernel-based isolation and sandboxing, so you can still use C, but you can define strong privilege boundaries. The seL4 microkernel can do that and is formally verified, too.
It does require some heavy threat modeling to use with non-trivial applications, though.
bbiab
 
Future Security
Future Security
4:52 AM
I vaguely remember reading about an experimental OS that didn't even have processes and instead used only threads. It probably used Java, so it wasn't possible to manipulate raw pointers to violate memory safety.
And there was no language feature that existed to enumerate variables that belonged to another application.
Different programs were not allowed to share mutable objects. There was no way to share references to mutable data between what would normally be treated as separate processes. Basically "process" isolation was enforced at the compiler level instead of the hardware level. The compiler was a critical part of the OS.
 
Future Security
Future Security
5:07 AM
There are interesting opportunities in something like that. Such a system can use a global garbage collection system, for example. Which actually isn't a bad thing. Unlike traditional binary code applications, the OS could employ a very aggressive "moving" GC and de-duplication.
 
Future Security
Future Security
5:24 AM
"Compactifying GC" was the term I was looking for. They move objects around in memory to free up space that would otherwise be inaccessible due to fragmentation. Combined with generational GC, they perform better than general purpose manual memory management.
In a sense, anyway. Better performance if you're looking at throughput. Worse if you're looking at it like latency because compacting the heap "pauses" the program. The "mutator" part of the program anyway.
 
forest
forest
6:13 AM
Huh, that's an interesting concept.
It seems like it'd be a security nightmare, though.
 
Future Security
Future Security
Oof. Forgot the original reason I made the connection. The opposite actually. In general anyways. Not the specific case of complex GCs.
 
forest
forest
I personally prefer memory management with a very light runtime.
Probably not surprising that C is what fits that bill.
Unrelated, but interesting:
48
Q: Unsolved Problems (Not Independent of ZFC) due to Lack of Computational Power

StackUpPhysicsI was recently reading up about computational power and its uses in maths particularly to find counterexamples to conjectures. I was wondering are there any current mathematical problems which we are unable to solve due to our lack of computational power or inaccessibility to it. What exactly am...

soft-question computer-science computational-mathematics big-list computer-assisted-proofs
I'm sure cryptography has a lot of those.
 
Future Security
Future Security
Interesting. Maybe not? Aren't a lot of those problems solved by finding counter examples or doing exhaustive proof?
Brute force is the same as exhaustive proof of course, but it's not like there are alternative proof methods for those kinds of problems. And we can just respond to better bruteforce power by increasing the number of bits we use and then we're in the same situation we are today.
 
forest
forest
I was thinking of things like finding differential trails past more than a nominal number of rounds.
Or finding GNFS polynomials, but I guess that's not really an "unsolved problem".
Oh, ideal S-boxes. Would finding an ideal 8-bit S-box count, do you think?
 
Future Security
Future Security
Depends on what you think of when you hear "unsolved problem". In a more mathy context I guess I'd expect things more like unproven conjectures.
 
forest
forest
6:29 AM
I recall reading a paper on ideal 4-bit (or 3-bit?) S-boxes which put forth explicit conjectures.
 
Future Security
Future Security
Stuff like that is my weakest area of cryptography. I didn't mean to learn it so I never learned much cryptanalysis or block ciphery stuff. No curriculum or books.
 
forest
forest
Block ciphers are what interests me the most.
Block ciphers, hashes (whether based on block ciphers or not), etc. Mostly because they don't require the very strange mathematics of some of the more complex asymmetric schemes and FHE.
 
Future Security
Future Security
I got into authentication and RNG related stuff because that was the stuff I could partially understand and see a practical use for. A few years of reading stuff I initially didn't understand, I realized I knew made good progress at learning that stuff.
 
forest
forest
It's a very interesting subject for sure.
I initially just wanted to learn things that would be helpful for security consultancy because I hated having to say that someone else needs to analyze a cryptographic protocol shown to me.
Heh, I was wondering if anyone had published a paper on analyzing all 5-bit S-boxes, but then I did the math and found out that there are more than 2^117 5-bit S-boxes, compared to 2^44 for 4-bit.
 
Future Security
Future Security
Being able to find faults in other people's designs was when I had my "when did I even learn this" moment...
 
forest
forest
6:45 AM
ikr
 
Future Security
Future Security
I remember the OS connection now. I was thinking about how if you're given source code you can either automatically insert instructions to yield to other threads or prove that a program will periodically yield. That lets you get some of the performance benefits of cooperative multitasking and some of the convenience of preemptive multitasking.
There's potential for interesting stuff, if we could invest too much time and money into overhauling how we do computing.
 
forest
forest
There's a lot of research into completely novel computing paradigms.
I wonder how much different modern life would be if the Lisp machine took off...
 
Future Security
Future Security
(Insert cliche about spacecraft specifications only having a certain property because of the width of roads in ancient Rome)
Can't remember what the actual story is. If I were less tired I'd look it up and check if it was actually true or not. (But it definitely sounded plausible)
 
forest
forest
7:04 AM
Btw, if you ever want to learn a lot about Intel... follow this guy: twitter.com/_markel___
Well him and twitter.com/h0t_max (they work together).
CPUs scare the shit out of me.
 
 
4 hours later…
b degnan
b degnan
10:47 AM
@forest Ha, i wasn't thinking of that network thing. I have no idea what you were talking about. :P Also, I'm not up on that "ring" thing. It remember reading how I thought it was a bad idea, it's still a bad idea. I'm only speaking from the perspective of a hardware designer who has opinions of how things are supposed to work.
CPUs should. It's the "it compiled and it worked on the first time" scenario.
 
forest
forest
The ring thing was a good idea, although using more than two was not that great...
ARM got it right, by having a user and supervisor mode (equivalent to ring 3 and 0, respectively).
Because no one, except maybe some old OS/2 and VMWare systems, used any other rings.
 
b degnan
b degnan
68000 had rings if your short description is true.
dunno man. Not a fan of Intel
0th order, the intel MMU is unlike everything else. PowerPC, POWER, SPARC, MIPS. I've just recently looked at ARM too, and it's more MIPSy.
btw, my only take away so far is why 32-bit and 64-bit binaries aren't interchangeable. You have to do a bunch of awkward remaps if you are in one mode of the other. What'd like like to know is why you couldn't just compile things with relative jumps.
that'd make it so the software didn't care. The best I can figure is that the few stack cycles that you take for "ret" over "mov eax,DESTINATION_VA;jmp eax" on a return is what people care about.
 
forest
forest
11:25 AM
@bdegnan Because 1) 32 and 64-bit syscalls differ and 2) registers are different sizes.
@bdegnan Rings is just Intel-specific terminology.
But yeah I agree, Intel sucks. And their MMU is way more complicated than it needs to be.
I like ARM and MIPS. And I hate x86.
 
 
1 hour later…
b degnan
b degnan
12:38 PM
@forest gotcha. I didn't use an x86 until Apple went that way. It was sort of jarring. Growing up, I had a Macintosh and a SUN IPC. That's what you get when your mother is a multilingual chemist.
 
 
2 hours later…
Patriot
Patriot
2:47 PM
@Paul Uszak I am promoting your website with South Korean and Chinese info science people I know--most of them are academics. Check to see if you are getting more hits from over here. I am also going to put in a few words for this website in a few days.
 
 
3 hours later…
Crypto HNQ
Crypto HNQ
5:40 PM
2
Q: How can we effectively compute the sqrt of some element in the group?

Ray JamesI only know one way, if this group is a cyclic group, and we know the element can be expressed in $g^m$, then $g^{(m/2)}$ is the answer. Another question, if $m$ is an odd number, can we be sure there is no answer? Is it possible to find another generator $g_1$ and an even number $k$ that satis...

group-theory
 
Crypto HNQ
Crypto HNQ
6:20 PM
3
Q: Randomness Testing of Cryptographic Algorithim

aneelaI am new to algorithim randomness and confused at I guess a basic level question. Is it common for any cryptographic algorithim to have repetitions in its output i.e.let say 34 and D8 are two consective bytes which are repeting at random intervals. I have got an encrypted file and it has 34 D8 ...

encryption randomness
 
Maarten Bodewes
Maarten Bodewes
6:48 PM
@forest I hate x86 and x64 too, but I don't hate my fast AMD 370X for sure - crap, this thing is fast!
At least, I hope to find out it is fast, it is barely ticking over doing any mundane task.
Maybe I should connect my motherboard connectors by now. It has been running for multiple days without power switch :P
 

« first day (2960 days earlier)      last day (1721 days later) »