I think so. He would be super excited to work on the dissassembler. He doesn't have linux kernel experience, but he's on the list of people I'd hire to do a kernel driver, if I needed such a thing. (Really, he's only on the top of that list because everyone else I know who is proven in that field is fully employed and super expensive. But this guy is definitely smart enough to handle it.)
he was the original author of a serial class for qt[1]... of course, I know that is not anything like a device driver, but it's something.
I also body-shopped and sysadmined for him on a project that involved reverse-engineering a windows program.
but... you'd have to make it clear that you are okay that he doesn't have linux kernel experience, so long as he's willing to try it.
I think he'd also be cool with contract work, if you want to try him out.
my email is lsc@prgmr.com- I don't really feel like it would be cool to post his email on the open internet but I can forward something.
[1]qextserialport, which I am given to understand isn't the standard.
Oh my. I know somebody who needs that job. Probably the "Georgetown, KY" on his resume is the difficulty, but he's willing to move. He can do C#, Java, and C++. He even has a traditional 4-year computer science degree.
Pass along his email if you can: markcahalan@yahoo.com
Depending on the town and your specialty, you might be surprised. Not every place outside of the typical hot spots is corporate-fief. Specialization means you can have a good job market without the crowds causing traffic jams and running up the cost of living.
For example, you might not expect much good in Melbourne, FL. You'd be wrong if you happen to like low-level code (assembly, reverse engineering, vulnerability research, embedded development, etc.) or EE stuff. There are both larger companies (Harris, Lockheed, Northrop Grumman, and the http://advancedsecuritylabs.com/ part of Raytheon) and lots of startup-ups.
Since a specialized area (like Melbourne, FL doing low-level stuff) doesn't have too many nerds outside that specialty, the cost of living stays low. You can get a cheap house within a mile of work and there isn't much traffic.
This is likely in Melbourne/Indialantic Florida. It could also be in Texas, Virginia, or Maryland. Note that Florida combines low housing costs, lack of an income tax, super-short commutes, and very little traffic. It can be a shock compared to what you may be used to. This is ONSITE. An active Top Secret/SCI security clearance is required.
Any overtime would be paid; we don't make you work for free. You get flex-time and an office with solid walls.
We need a system administrator.
The users mostly run Ubuntu, but some run Windows and other things. The users are primarily software developers.
You should be familiar with virtualization
(Open Stack, VMWare, VSphere, VCenter), scripting, LDAP, DNS, security, backups, and running cables.
This is Melbourne/Indialantic Florida,
Austin and San Antonio Texas, Maryland, Virginia,
Greer South Carolina,
Fayetteville North Carolina,
Huntsville Alabama, Cambridge (near Boston) Massachusetts, Seattle Washington, and more.
Note that a few of those locations combine low housing costs, lack of an income tax, super-short commutes, and very little traffic. It can be a shock compared to what you may be used to.
This is ONSITE. We hire at all levels, including INTERNS.
We can only hire US citizens due to government requirements. Our background check includes a polygraph.
We do lots of reverse engineering, vulnerability research, custom in-house emulation (with JIT and/or hypervisor), constraint solvers, and static analysis of both source and binary code. We work with numerous OSes and processor types. You could write the tools (emulator, JIT, hypervisor, debugger, static analysis, etc.) or you could make use of them to find vulnerabilities. An understanding of compilers is often helpful.
You can run Linux. We don't expect overtime, but we'll pay you for it if you want to do it. Most locations have extreme flex-time and offices with solid walls.
If you happen to be at DEF-CON 23 in Las Vegas (August 6-9) you can catch us there.
Extra keywords: assembly assembler IDA Pro MIPS x86 x64 ppc PowerPC ARM ROP security VMX decompiler kernel driver embedded C99 buffer overflow opcode ASLR NX SMEP SMAP MPX
8051 MSP430 AVR32 MCU TOP SECRET TS/SCI SSBI classified clearance cleared formal verification sandbox fuzzer fuzzing crashes
We wanted our own site because the parent company's branding was extra-uncool and they wouldn't change it for us, but they wouldn't let us use their name without controlling the branding. This was the compromise. Aside from a few issues like that, we are pretty distinct from the rest of the company. We have our own culture (unusually lively for a defense contractor, almost start-up-like) and we like to show it.
The comment about being women being treated differently
when they wear a dress shows misunderstanding. The male
equivalent to that is not a T-shirt and jeans. It's the
suit. I'd sure be treated differently if I wore a suit.
I'd be trading one kind of signaling for another, giving
up technical cred in favor of business cred.
A sundress is much closer to a suit than it is to a T-shirt and jeans.
Considering modesty though, a woman in a sundress is equivalent to a man wearing a tank top. We don't get males in the office wearing tank tops or anything else that would expose the collarbone, armpits, shoulders, or shoulderblades. These things are normally considered inappropriate. We also don't normally see males wearing snug form-fitting shirts. It's not considered appropriate. Feel free to wear that stuff while you weed your lawn at home.
So that is two strikes against the sundress. It's kind of formal, yet no more modest than a tank top.
I see one place seemingly using RISC-V with an MMU in the classic desktop PowerPC style (Linus Torvalds posted a great rant about the stupidity of that MMU) and another place that is seemingly using RISC-V with an MMU that is very much like x86 (the paging part, obviously no segmentation) but with distinct rwx.
Which is it? Did this not get specified? Constantly changing the MMU greatly hurt 32-bit SPARC and PowerPC.
FWIW, this is good: Bits 0..11 direct mapped, bits 12..29 are x86-style page table tree node indexes that are hardware-walked, and bits 30..63 are software-filled like MIPS. (a forest of trees) In the low bits of the bottom level you get: can read, did read, can write, did write, can execute, did execute, user/super (exclusive), type ram/framebuffer/mmio/pte (two bits), reserved, and validity. The "did foo" bits on PTE pages do get updated.
Thanks. The following concerns paging, not the base/limit system:
From a security and reliability perspective, I'm saddened to see that rwx got supported while --x did not get supported. That is backwards. Having to change permissions after code modification is not bad; this provides a convenient point for cache flushing and ASLR-enforced address changes. Preventing executable code from being misused as data is valuable.
I'm also saddened to see that user access implies supervisor access. This too is exactly backwards; nothing should be both user and supervisor accessible. Given that data access can be performed at a less-privileged level by setting MPRV=1, the ability of the supervisor to access user pages normally is especially strange.
Lack of distinct did-execute and did-read bits is mildly annoying. If a page is marked as being accessed and executable, one must assume that it is now in BOTH the instruction cache and the data cache.
I have mixed feelings about having page frame numbers shifted over by two bits. The win is Sv32 getting a reach of 16 GiB. I suppose this is worth the minor annoyance when debugging OS kernel code.
Other than that, I like it. It's certainly sane. The traditional page table is pretty good for the middle bits of the virtual address. I think it is less good for the upper bits due to ASLR, and I hate to see anything that encourages a failure to use all 64 bits of the virtual address space.
You should read through the RISCV mailing list archives (https://lists.riscv.org/lists/) for discussions on these topics, and contribute your own thoughts if they haven't been covered. The ISA-dev list should be the most relevant. They have thought very carefully about these things and I'm sure they'd appreciate additional feedback on the topic.
Oh, one other problem. The referenced (R) and dirty (D) bits are only updated in leaf nodes. I strongly suspect that any performance you gain here will be more than consumed by OS software needing to scan all the leaf nodes for these bits. If you update non-leaf nodes, then the OS can use those to avoid checking many of the leaf nodes.
Underwater RF is no trouble in this case. You have the signal backwards. As long as there is no problem, regularly transmit an identity beacon. Loss of signal is the alert.
How does the regular beacon transmit if it's underwater? Someone standing in the shallow end of the pool or treading water in the deep end may pretty easily keep their wrist underwater for minutes at a time.
There's two things that such a device would need to have: quite low false positives (so that the lifeguard isn't distracted by false alarms - leading to a boy-who-cried-wolf scenario), and vanishingly small false negatives (the first time a kid dies because the device didn't work, it'll be a bad day). In-water RF would be very hard to do to make those two conditions true.
Edit: Don't get me wrong, I think it's a fabulous idea. Wearing my EE hat though, I haven't thought of a good way to do it that would work reliably enough for a life-saving device.
Uh, maybe. Is he OK with low-level stuff too? We do use Qt, but we might ask him to write a disassembler or a kernel driver.