I feel silly I haven't o ask this, but what is the best guide to learning rust?
I am biased, but the book is the most complete resource: https://doc.rust-lang.org/book/ There's also http://rustbyexample.com/
Hey, thanks :-)
Redox – A Unix-Like Operating System Written in Rust
201–210 of 215 posts
Re: Redox – A Unix-Like Operating System Written in Rust
#202Earlier quoted context omitted.
> In other words, like GNU HURD. That design is very very hard to make correct and fast. There are plenty of counterexamples to slow microkernels nowadays. In addition, we trade speed for things like garbage collection. I'd happily trade some speed for increased security.
Every example of a "fast" microkernel has either ripped out expected functionality (debug traces for example) or simply been the first to make an optimization that can be applied to monolithic kernels as well. Fundamentally, microkernels are slower. A bit of thought should make it clear that this can not be otherwise. No matter how fast you can pass a message, it's still faster to not pass a message at all. Also, the…
Does OS X's Mach count as a "fast" microkernel by your definition?
Re: Redox – A Unix-Like Operating System Written in Rust
#203Earlier quoted context omitted.
re embedded vs digital design Yeah, embedded was what I was talking about and trial&error was what I was worried about. What I've seen people write up is a lot more difficult than software in general. I remember one had severe application issues when it ran with instant on that were eventually resolved as the PLL's not synced up. They put a delay in to let them warm up. Program worked fine. Seen some stuff in immunit…
> I'll send you my stuff later today. It's no rush :-). I'm always looking forward to this kind of stuff. Nothing keeps one's mind fresh the way someone else's well-informed opinions do. A long time ago, I thought about doing something similar to Dijkstra's letters -- bringing a few colleagues together and beginning to circulate small notes whenever we had something interesting and cohesive enough that it might be wo…
"A long time ago, I thought about doing something similar to Dijkstra's letters -- bringing a few colleagues together and beginning to circulate small notes whenever we had something interesting and cohesive enough that it might be wort putting into writing."
Interesting idea. They sort of do that already with ACM letters, online articles, and so on. If anything, we have so much of this going on that each community silos. That's partly why high assurance INFOSEC and the ITSEC field are two different things. ;) I do occasionally bring up the idea of creating a site hosting top papers and developments in software/security engineering that only invites people that do the research or job. Just people that know shit with a track record and something to bring. They can read the papers, discuss what's in them in moderated forum, and so on. Quite a few like the idea but it will be hard to bootstrap.
"o serious test methodology, no attempt to at least document assumptions first. It's a wonder we're not at the point where a computer kills someone every day yet."
People scratch an itch by modifying an embedded RTOS's kernel. Yeah, I'm amazed we're all still here too.
"Trial and error is a natural way to learn things, but it should generally be done just once, ideally by as few persons as possible. We're... not only are we not there yet, we're doing the precise opposite of it."
Excatly. One example was Burrough's including stack protection into their CPU's. That should've showed up in Intel's stuff as soon as stack attacks became more prevalent. Instead, you see all this trial and error research into tactics that all got beaten. Anything but actually managing one's stack or modifying a CPU to do so. Intel eventually puts it in their off-brand, but good, Itanium CPU. I know Secure64's OS uses it but idk about rest. People still countering stack attacks with tactics to this day despite it solved in 1961.
Ask me about setuid if you want another one even more clever.
"One could have thousands of MC14500s on a single chip with today's technology; granted, they could not all talk to each other at the same time due to the limits of interconnects, and not all could be independently interfaced with the outside world, but a hierarchical architecture built out of reliable nodes (and with plenty of room for redundance) might at least be worth investigating.""
Funny you say that because that was one of my first thoughts. Look up Kilocore for one of those. Other thought was reimplementing ABC Thinking Machines 65,000 CPU design on one or a few chips. The chip's were barely functional: just ALU's or whatever. Still did amazing things in genetic algorithms. One 256 8-bit core design on 500nm accelerated neural networks well in past, too. So, 8-16-bit MPP on a chip are conceivably useful to this day.
Re: Redox – A Unix-Like Operating System Written in Rust
#204Earlier quoted context omitted.
Just keep it simple and do HTTP/1.0, that's not all that complex.
A web server has no utility by itself, it only gains value by running content on top of it. This is where simple becomes too simple in almost every case. A DNS server however can basically start being useful as soon as it is connected to the internet.
> I'll add a web server, Redox or UNIX compatible, that's efficient enough to be deployed in all these web-enabled embedded devices.
I took that to mean something capable of being used as a web admin console for the other services. HTTP/1.0 is fully capable of that. I agree that HTTP/1.0 would be a bit anemic for those that want to support an actual site, but as a simple included way to provide an admin interface, it should be sufficient.
Re: Redox – A Unix-Like Operating System Written in Rust
#205Earlier quoted context omitted.
A web server has no utility by itself, it only gains value by running content on top of it. This is where simple becomes too simple in almost every case. A DNS server however can basically start being useful as soon as it is connected to the internet.
> I'll add a web server, Redox or UNIX compatible, that's efficient enough to be deployed in all these web-enabled embedded devices. I took that to mean something capable of being used as a web admin console for the other services. HTTP/1.0 is fully capable of that. I agree that HTTP/1.0 would be a bit anemic for those that want to support an actual site, but as a simple included way to provide an admin interface, it…
That was the intent and solution I had in mind. Appreciate the positive feedback as I might do it myself given all the ridiculously tiny web servers people have made.
My favorite trick I saw was one that replied directly with TCP/IP packets pre-encoded from the HTML. Cool, huh? That could even be done with highly assured tools in safer language as part of CMS or web build system.
Re: Redox – A Unix-Like Operating System Written in Rust
#206Earlier quoted context omitted.
No, those do not perform well. They are just less horrible than GNU HURD. When you apply similar optimization and implement similar functionality, monolithic kernels always win. It cannot be otherwise; think about it. Self-healing is generally a security problem. It gives the attacker a second chance. It's also generally a failure. You might think you can restart, but there are huge problems: Instead of a crash, you…
"No, those do not perform well. They are just less horrible than GNU HURD. When you apply similar optimization and implement similar functionality, monolithic kernels always win. It cannot be otherwise; think about it." I do. It doesn't have to be better. It simply has to perform well enough that users accept it. Older systems did that slowly. BeOS was a great example where it was running on 90's hardware several mov…
Could you elaborate on:
"Most systems are unable to keep DMA from scribbling all over everything in RAM, and probably all are unable to keep it from scribbling all over a filesystem."
In what context do you mean? When would this occur?
Thanks
Re: Redox – A Unix-Like Operating System Written in Rust
#207Earlier quoted context omitted.
Every example of a "fast" microkernel has either ripped out expected functionality (debug traces for example) or simply been the first to make an optimization that can be applied to monolithic kernels as well. Fundamentally, microkernels are slower. A bit of thought should make it clear that this can not be otherwise. No matter how fast you can pass a message, it's still faster to not pass a message at all. Also, the…
It's an architecture problem. What makes QNX fast are a few basic design decisions: - The basic interprocess communication mechanism works like a synchronous subroutine call - you call, you wait, you get data back. Most slower microkernels have unidirectional I/O as a primitive. - This is very tightly integrated with CPU dispatching, so that calling a service which isn't currently busy is just a context switch, not a…
Can you elaborate on what you mean by "CPU dispatcher"? I am not familiar with the term and have not heard it before. Is this something specific to certain SoC designs? I've never heard mention of this in x86 architectures.
Re: Redox – A Unix-Like Operating System Written in Rust
#208Earlier quoted context omitted.
It's an architecture problem. What makes QNX fast are a few basic design decisions: - The basic interprocess communication mechanism works like a synchronous subroutine call - you call, you wait, you get data back. Most slower microkernels have unidirectional I/O as a primitive. - This is very tightly integrated with CPU dispatching, so that calling a service which isn't currently busy is just a context switch, not a…
As a thought experiment, let's make QNX faster. We keep the same IPC mechanism. We compile the filesystem process right into the kernel. Having done this, we can now avoid half of the IPC mechanism. We enter the "microkernel" just once now, instead of twice, and we leave it once instead of twice. Since the filesystem is now in the "microkernel", we don't need to switch MMU state and have a TLB invalidate. This is a h…
What exactly is the QNX IPC system? How is it different from regular IPC?
Can mapping QNX into the top of userspace processes avoid the TLB flush/invalidate?
I vaguely remember the Solaris Doors which is similar to pipe correct? How does it relate to this discussion.
Thanks.
Re: Redox – A Unix-Like Operating System Written in Rust
#209Earlier quoted context omitted.
"Performance keeps getting better." Performance is great until those things crash my system. The stuff still happens with graphics drivers on my Linux distro's. I know it's not necessary because it doesn't happen on the microkernel systems and even Windows dodges a lot of it with their SLAM toolkit. "Let's also look at things from the other perspective. You could add the QNX IPC mechanism into any monolithic kernel.…
IMO microkernels are a dead end, to get better performance you have to shove stuff in kernelspace, while for say an exokernel the opposite is mostly true.
except that Mach OS X's mach is a microkernel right? Or am I missing something?
Re: Redox – A Unix-Like Operating System Written in Rust
#210Earlier quoted context omitted.
"No, those do not perform well. They are just less horrible than GNU HURD. When you apply similar optimization and implement similar functionality, monolithic kernels always win. It cannot be otherwise; think about it." I do. It doesn't have to be better. It simply has to perform well enough that users accept it. Older systems did that slowly. BeOS was a great example where it was running on 90's hardware several mov…
Could you elaborate on: "Most systems are unable to keep DMA from scribbling all over everything in RAM, and probably all are unable to keep it from scribbling all over a filesystem." In what context do you mean? When would this occur? Thanks
That was burfog's comment I was quoting. It refers to the fact that direct memory access by some devices can bypass any OS or software protections. Breaks whole security model as memory can change arbitrarily. So, risk of attacks or leaks should be mitigated there.
A few methods follow:
1. Use non-DMA links.
2. Use trusted hardware/firmware that mediates things properly.
3. Use IOMMU to enforce access controls on DMA.
4. Use a combo of full safety in system and careful API for access to DMA features.
I used 1 and 2. A few use 4. Number 3 is most common with basic version mainstreaming. Not enough, though, as complex firmware and OS's still provide attack opportunities.
Note: There's also interrupt floods and other esoteric issues to counter. So, it's the start rather than full solution. EMSEC issues too with malicious peripherals.