debatem1 (u/debatem1)

debatem1 commented on 4k NASA employees opt to leave agency through deferred resignation program kcrw.com/news/shows/npr/n... · Posted by u/ProAm

SoftTalker · a month ago

The flip side of that complaint is Democrats stuffing government bureaucracies with do-nothing jobs for their buddies. Both sides play in this cesspool. It would be nice if we as a nation could just do the work that needs to be done for the people without all of those games but it never has really been that way.

debatem1 · a month ago

> Democrats stuffing government bureaucracies with do-nothing jobs for their buddies

Ignoring the partisanship this argument doesn't make sense on its face: government jobs pay extremely poorly. You might say "well what if you hold more than one of them?", but you can't do that: a federal employee can be employed in two different roles, but their pay is capped at 40 hours a week across the federal government.

Anyone keen on that level of grift has vastly better options in the private sector.

debatem1 commented on Windsurf employee #2: I was given a payout of only 1% what my shares where worth twitter.com/premqnair/sta... · Posted by u/rfurmani

01HNNWZ0MV43FF · a month ago

I remember when my old employer was doing another round of funding

They offered to sell me more shares

I countered that I'd been trying to dump the shares they already gave me and if the shares are truly worth X dollars they should buy them back from me

Anyway glad I quit

debatem1 · a month ago

> if the shares are truly worth X dollars they should buy them back from me

I always offer companies pushing equity hard to trade for cash at 10% of the highest number they try to get me to value it at. Nobody has ever taken me up on it, even when they really should have.

debatem1 commented on eBPF: Connecting with Container Runtimes h0x0er.github.io/blog/202... · Posted by u/forxtrot

debatem1 · 2 months ago

None of these snippets appear to involve eBPF at all?

debatem1 commented on Starcloud ycombinator.com/companies... · Posted by u/wiley1454

slashdev · 4 months ago

I agree, this is makes no sense at all.

Can I take the other side of this investment? Like an angel funding round, but selling short?

debatem1 · 4 months ago

If you figure out how to do this I will invest in your fund.

debatem1 commented on A more robust raw OpenBSD syscall demo nullprogram.com/blog/2025... · Posted by u/signa11

saagarjha · 6 months ago

If they can ROP they can jump to a syscall instruction with controlled arguments

debatem1 · 6 months ago

The point of what I spelled out above is that they can jump to the instruction but the kernel will kill the program if they don't go through the function up to that point. That allows you to restrict the arguments to the syscall at the point of call.

debatem1 commented on A more robust raw OpenBSD syscall demo nullprogram.com/blog/2025... · Posted by u/signa11

saagarjha · 6 months ago

What’s the threat model this protects against?

debatem1 · 6 months ago

"Attacker has ROP and shouldn't be able to make arbitrary syscalls".

Seems mildly useful if you have a really flexible syscall you can't forbid (ioctl, say) but which you only use for a specific narrow purpose.

debatem1 commented on A more robust raw OpenBSD syscall demo nullprogram.com/blog/2025... · Posted by u/signa11

debatem1 · 6 months ago

Seems like an interesting if maybe not practical protection to implement in eBPF for programs that never make a naked syscall.

Step one would be to ensure that every syscall has a wrapper. Place a uprobe at the start of that wrapper which, when hit, sets a per-thread permission bit and a per-thread-per-syscall permission bit in an eBPF map. Place a corresponding uretprobe that clears the per-thread-per-syscall bit. For each syscall place a kprobe which checks the per-thread table to make sure the thread is one which has enabled the feature, and which then checks to make sure the per-thread-per-syscall bit is set for that syscall. If not, sigkill.

Performance would probably suck but it seems like it would protect the syscall entrypoints enough to do some potentially interesting attack surface reduction. The question is really why you would do that there instead of by attaching to, say, the LSM hooks where you have stronger guarantees vis a vis userspace.

debatem1 commented on Imposing memory security in C [video] fosdem.org/2025/schedule/... · Posted by u/transpute

debatem1 · 6 months ago

I don't think anyone ever doubted that a C program could be memory safe. The problem is knowing without exhaustive work whether yours is one of them.

These aren't bad practices, but I don't think they satisfy that desire either.

debatem1 commented on Show HN: Uscope, a new Linux debugger written from scratch github.com/jcalabro/uscop... · Posted by u/jcalabro

Analemma_ · 7 months ago

Is gdb another thing like gcc where the un-hackability and un-extendability was a deliberate choice by rms to ensure nobody would ever build proprietary toolchains on top of it?

debatem1 · 7 months ago

I don't know if it was deliberate, but writing code that interfaces with GDB is unpleasant enough that I opted to build our debugger-like tooling in eBPF + pyelftools instead.

debatem1 commented on Maslow 4: Large format CNC routing made accessible maslowcnc.com... · Posted by u/mdaniel

johnobrien1010 · 10 months ago

What business did you build around it?

debatem1 · 10 months ago

Custom forms for concrete pours. Also did a little bit of work making supports for plaster casting.

I was never really able to sell the advantages to artists, but got some good side gig money for landscaping stuff.

(Just to clarify: the business is wound down, but I personally still use the approach in art projects)

u/debatem1

KarmaCake day1715October 15, 2016View Original