colanderman (u/colanderman)

colanderman commented on D4D4 nmichaels.org/musings/d4d... · Posted by u/csense

JdeBP · 5 days ago

And this is where the OpenBSD people will paraphrase Henry Spencer and say that those who do not understand OpenBSD are doomed to reinvent it badly. (Personally, I think that that's putting OpenBSD onto a pedestal. It's no ideal; one gets the same tradeoffs and problems as everywhere else.) In this case, the reinvention for LLVM targetting ARM, that credits seeing this committed to OpenBSD by Theo de Raadt, totally ignored that the original for gas targetting x86 both trapped and jumped.

I intentionally also pointed you to a collection of several critiques of the whole idea, long-since made. (-:

colanderman · 5 days ago

Why, in your own words, is the jump supposed to be there? (Keep in mind this code is in between two functions.)

And why, in your own words, is it OK for the jump to be a conditional backwards jump?

colanderman commented on D4D4 nmichaels.org/musings/d4d... · Posted by u/csense

colanderman · 5 days ago

From your own link:

> The trapsleds implemented in this diff convert NOP sleds longer than 2 bytes from a series of 0x66666690 instructions to a 2 byte short JMP over a series of INT3 instructions that fill the rest of the gap.

The BMI instructions in the article are not jumping over breakpoint (INT3) instructions. They're conditionally jumping backwards by some amount.

Why in your belief is this? Please use your own words or a relevant direct quote to state your understanding of how a trapsled works.

colanderman commented on D4D4 nmichaels.org/musings/d4d... · Posted by u/csense

colanderman · 5 days ago

Hex D4xxxxxx is indeed (almost) BRK... on ARM64 [1].

Being ARM32, these should be BKPT (hex BExx). [2]

[1] https://developer.arm.com/documentation/ddi0602/2025-06/Base...

[2] https://developer.arm.com/documentation/ddi0597/2024-09/Base...

colanderman commented on D4D4 nmichaels.org/musings/d4d... · Posted by u/csense

colanderman · 5 days ago

You are misunderstanding the purpose of the initial jump in a trap sled. It is to redirect code which expects to flow through the sled past the traps, while leaving the traps for anything else which lands in that range.

The padding the article is talking about lives between functions. It is not meant to be executed, nothing is needed to jump over it. (The unconditional bx lr before it is the return at the end of the function.)

colanderman commented on D4D4 nmichaels.org/musings/d4d... · Posted by u/csense

JdeBP · 5 days ago

It's not exploitable. It's an exploit mitigation, in fact. It's not a bug; it's intentional that it works this way. And Nathan Michaels didn't think that if you want to find Theo de Raadt writing on some subject, better try OpenBSD discussion fora, not the LLVM mailing list. (-:

This was put into OpenBSD back in 2017. It's not "trap instructions". It's "trapsleds". The idea is to trap the sleds (a.k.a. slides) of NOP instructions that linkers used to put in between compiled code for alignment, and which could be exploited with "return-oriented programming" where an attacker could cause execution to jump to any address in the padding range (possibly needing the inexactitude because of constraints upon byte substitutions) and slide along all of the NOPs to the target function.

* https://undeadly.org/cgi?action=article;sid=20170622065629

* https://isopenbsdsecu.re/mitigations/trapsled/

colanderman · 5 days ago

The instructions have to be trap instructions for it to work.

The conditional branch-backward instruction it is is almost as bad as the series of NOPs, since it is still likely to redirect an attacker to functioning code. (If the attacker can clear the mi flag first, these are just NOPs!)

Hence yes, this is a broken exploit mitigation.

colanderman commented on Mostly dead influential programming languages (2020) hillelwayne.com/post/infl... · Posted by u/azhenley

vincent-manis · a month ago

There is one very BIG thing that Cobol pioneered: the requirement that not only the programs, but also the data, must be portable across machines. At a time when machines used different character codes, let alone different numeric formats, Cobol was designed to vastly reduce (though it did not completely eliminate) portability woes.

We take this for granted now, but at the time it was revolutionary. In part, we've done things like mandating Unicode and IEEE 754, but nowadays most of our languages also encourage portability. We think very little of moving an application from Windows on x86_64 to Linux on ARMv8 (apart from the GUI mess), but back when Cobol was being created, you normally threw your programs away (“reprogramming”) when you went to a new machine.

I haven't used Cobol in anger in 50 years (40 years since I even taught it), but for that emphasis on portability, I am very grateful.

colanderman · a month ago

Instead now, you throw everything away when moving to a new language ecosystem. Would love to see parts of languages become aligned in the same manner that CPUs did, so some constructs become portable and compatible between languages.

colanderman commented on Copper is Faster than Fiber (2017) [pdf] arista.com/assets/data/pd... · Posted by u/tanelpoder

deepsun · 2 months ago

What if it's something in between, say cross-section is not O-shaped, like in a hollow wire, but C-shaped or almost closed circle? Where one side is vacuum and another a dielectric.

Thinking about it I believe it would be one of three possibilities: 1 slow the signal to the slowest side, 2 increase circuit resistance, or 3 "smear" the wave, so a short sharp signal would arrive long and dull (increased reactance?).

colanderman · 2 months ago

(Having pondered this a day) this is a good question and I do not know! I think this would be straightforward to perform a waveguide simulation of though.

colanderman commented on What goes wrong when we write ghazals in English theparisreview.org/blog/2... · Posted by u/ishita159

Velorivox · 2 months ago

The show "boys over flowers" is translated from 花より男子, ostensibly a correct translation.

But 男子 (boys) is a homophone of 団子 (a sweet dumpling) and the entire phrase 花より団子 is an aphorism for preferring practicality over aesthetics.

Did you understand that? Of course. Yet, a joke that has to be explained loses something of itself.

Weirdly, I am fluent in Japanese, Urdu, and English. I believe that while translations have their value, they always fail to do justice – even when translated by the author! A poem is, like a joke, largely about what it affects in the audience, and such an evanescent quality is nigh impossible to preserve completely in translation, or even in a retelling.

This is why I was rather upset when Youtube began silently auto-translating audio for me with no indication of it not being the original audio (it's especially bad if you look at shorts and are multilingual...you could easily mistake what was a catchy Japanese song for English AI slop).

colanderman · 2 months ago

> translations […] always fail to do justice

I agree with you, yet sometimes, serendipity prevails, and a frying pan becomes a drying pan. [1]

[1] https://knowyourmeme.com/memes/ill-use-my-trusty-frying-pan-...

colanderman commented on Copper is Faster than Fiber (2017) [pdf] arista.com/assets/data/pd... · Posted by u/tanelpoder

deepsun · 2 months ago

What if I make the copper wire hollow inside, filled with vacuum? Will the signal travel at c?

colanderman · 2 months ago

Not what's within each wire, but what is between the pair of wires is what matters. (Assuming of course the wires conduct well, as BenjiWiebe points out.)

And yes, using air instead of dielectric results in signal velocity near c. (A good example of this is ladder-line.)