IAmLiterallyAB

Use the -u flag instead of -a. Doesn't add new files, just existing ones.

Oops, you're right. I was thinking of those as nearly interchangeable but they're actually pretty different.

I might give it a try when I have a chance, I'll let you know if anything comes of it.

I wonder if an adversarial user could bypass the checks and achieve memory corruption / code execution. Maybe not a practical attack in most situations but a fun exercise.

> This includes things like asm volatile("" : : : "memory"), which is an old-school way of saying atomic_signal_fence(memory_order_seq_cst).

Not quite. AIUI, the first is just a barrier for the compiler, while the second is also a CPU memory barrier. Godbolt seems to confirm that.

https://godbolt.org/z/a844zKej8

Yes but at best their "solution" is equally secure, not any better.

That's a privacy violation, not relevant.

For the old version support. Why not do some compile time #ifdef SUPPORT_ES3? That way library writers can support it and if the user doesn't need it they can disable it at compile time and all the legacy code will be removed

It doesn't bypass it exactly, it's still accessing it via virtual memory and the page tables. It's just that the kernel maintains one big linear memory map of RAM that's writable.

Citation needed. We don't even know if indistinguishability obfuscation is possible.

And everyone uses Ghidra exclusively where I work. I'd say we're a serious operation

Amusing because gmail doesn't even follow spec. I had to workaround gmail quirks when I worked at an email company.

Better than outlook though. What a nightmare.

Half the time when people say they're using telnet (including in this thread) they're really just using the client as a TCP client, not doing anything with the Telnet protocol.

No one is stopping you from using the telnet client. And really you should just use netcat

That doesn't work on any* NAND flash device, be it a flash drive, NVME, SATA, whatever.

The block device you see is an abstraction provided by the SSD controller. In reality, the flash capacity is larger. Pages are swapped out for wear leveling. If a block goes bad, it'll be taken out of commission, and your data may hide in there.

All of this happens on the SSD controller. The kernel doesn't know. You have no way to directly erase or modify specific blocks.

*Okay, there are raw NAND flash chips without controllers, but that is not you're working with when you have a SSD or flash drive. If you do have a raw flash chip, you can more directly control flash contents.

To maximize device performance when wiping a drive to use for something else, I use nvme format with --ses=1.

Which in theory should free all of the blocks on the flash.

Really hard to find good documentation on this stuff. Doesn't help that 95% of internet articles just say "overwrite with zeroes" which is useless advice

As far as I know, there is NO way to securely erase a USB flash drive (barring some undocumented vendor specific commands that may exist).

They explicitly check if the referrer is hackernews and do that.

Another related writeup https://www.latacora.com/blog/2019/07/16/the-pgp-problem/

Another hackernews hater checking the http referrer I'd guess

Opus?

Switch to an ILP32 ABI and you get a lot of that space back

I don't know if it was filename exactly, but a similar story:

> Jon Ross, who wrote the original version of SimCity for Windows 3.x, told me that he accidentally left a bug in SimCity where he read memory that he had just freed. Yep. It worked fine on Windows 3.x, because the memory never went anywhere. Here’s the amazing part: On beta versions of Windows 95, SimCity wasn’t working in testing. Microsoft tracked down the bug and added specific code to Windows 95 that looks for SimCity. If it finds SimCity running, it runs the memory allocator in a special mode that doesn’t free memory right away. That’s the kind of obsession with backward compatibility that made people willing to upgrade to Windows 95.

https://www.joelonsoftware.com/2000/05/24/strategy-letter-ii...

What's preventing a compromised kernel on one core from hijacking the other cores? This doesn't seem like much of a security boundary

My limited understanding is. There is no safe subset (That's what was just discontinued, profiles are the alternative.)

And C++ code simply doesn't have the necessary info to make safety decisions. Sean explains it better than I can https://www.circle-lang.org/draft-profiles.html

Maybe, but the first one was so incredible, why not play it first?

It did remind me of that. Tom7 is a treasure

ty is already in the same repo as ruff, so integrating seems likely

Yeah this is the third programming language named Bolt that I'm aware of

> we don't want vtables

Then don't use virtual functions. Then there will be no vtables.

You might have known that already, but in general I'm surprised how many engineers think that all C++ classes have vtables. No, most in fact do not. C++ classes generally have the same memory layout as a C struct as long as you don't use virtual functions.

Minimum reputation to submit might help

Been wanting to play with the citadel interface. Last time I looked at it there was 0 public information, but that was years ago. And if there still isn't, then it'll be a good excuse to RE

Also, the titan chip has been around since the Pixel 3 I believe, so "newer" might be a strong word :)