Hacker News new | past | comments | ask | show | jobs | submit | signa11's comments login

perchance you mean hidden control flow ?

Not quite, it's a bit more than that.

and here the actual presentation to go along with it: https://www.youtube.com/watch?v=FNi1-x4pojs


yeah, here is the message on lkml [https://lore.kernel.org/lkml/20240828211117.9422-1-wedsonaf@...]

'''

Hey folks,

This is as short a series as one can be: just removing myself as maintainer of the Rust for Linux project.

I am retiring from the project. After almost 4 years, I find myself lacking the energy and enthusiasm I once had to respond to some of the nontechnical nonsense, so it's best to leave it up to those who still have it in them.

To the Rust for Linux team: thank you, you are great. It was a pleasure working with you all; the times we spent discussing technical issues, finding ways to address soundness holes, etc. were something I always enjoyed and looked forward to. I count myself lucky to have collaborated with such a talended and friendly group.

I wish all the success to the project.

I truly believe the future of kernels is with memory-safe languages. I am no visionary but if Linux doesn't internalize this, I'm afraid some other kernel will do to it what it did to Unix.

Lastly, I'll leave a small, 3min 30s, sample for context here: https://youtu.be/WiPp9YEBV0Q?t=1529 -- and to reiterate, no one is trying force anyone else to learn Rust nor prevent refactorings of C code.

Thanks, -Wedson

'''


Having listened to the audio clip mentioned in their resignation, I can't blame him for getting fed up, certainly if that's a representative sample of how the effort has been treated.

Having another maintainer completely shut down your talk by somewhat angrily shouting out irrelevant and fundamentally incorrect complaints and comparisons is incredibly disrespectful.


I find that the Rust Kernel maintainer in that video was the only one that stayed professional during the "attacks" (it was ad hominem at some point). You could really hear how people got agitated and emotional while saying things like:

"You're not gonna force all of us to use Rust!"


I am not a kernel developer and I do find the discussion somewhat frustrating and I largely agree with your analysis.

However, I do think that the "other side" also raises a valid point in that they can not reasonably be expected to maintain the semantics on the C side so that the Rust bindings (which does make assumptions in order to create clean and powerful bindings to use the Rust type system) do not break. Pre-Rust, the onus is indeed on them to ensure that the entire codebase conforms with any semantic changes, but now, if we say get a new filesystem entirely written in Rust that relies on the bindings, who is responsible and how will the coordination happen?

Again, I am not a kernel developer and only a mediocre (at best) systems programmer. Thus, I could have misunderstood the discussion.


My understanding is that no one's asking them to take on that burden. What seems to be being asked is for them to explain the current semantics of the API, because it's unclear what they actually are.

From the sounds of it, some of them consider this request unreasonable.


That's all fine, I am just talking about the emotional part of the debate and the ad hominems.

They are uncalled and should not be tolerated.

We had a colleague in my last job that was good technician but nobody wanted to talk to him or ask for help or anything because frankly, he was an asshole.


I listened to 3 min of it. And I don't see any emotional part of it.

They simply have a fundamental difference of opinion. And I actually understand the C person is suggesting. Although may be he wasn't clear in explaining it. It is not the responsibility of C maintainer to spend additional time to explain their code. Especially in a way that Rust people understands. And may be in order for them to do that, without all the Rust context, they might as well learn Rust. And if Rust blinding is even set as a priority then all C maintainers would now have obligations, one way or another to work well with rust. Which neither does the C maintainers want to spend time on or have the interest to spend time on.

The Rust people on the other hand saw their move as common good and want everyone to work together. Unfortunately most developers would only discover very late in their carrier, you can only make that happen when everyone 's interest are aligned.


holy crap. who is the guy malding at 26:50? dude should never have been given a mic.


reminds me of classic mitch-hedberg quip “here, you throw this away”, when some hands you a flyer on the street.


can someone please post an archive link to this article ? thank you !



oh this

''' However, cross-cluster latencies are high compared to prior generations. At nearly 200 ns, cross-cluster latencies aren’t far off from cross-socket latencies on a server platform. '''

is not so good


fta we have this:

''' Nissim and Okupski note that exploiting the bug would require hackers to already have obtained relatively deep access to an AMD-based PC or server, but that the Sinkclose flaw would then allow them to plant their malicious code far deeper still. '''

and then this:

''' To take advantage of the vulnerability, a hacker has to already possess access to a computer's kernel, the core of its operating system. '''

so it is click-bait ?


It enables persistence (the part about it being unfixable seems click baity though):

“any machine with one of the vulnerable AMD chips, the IOActive researchers warn that an attacker could infect the computer with malware known as a “bootkit” that evades antivirus tools and is potentially invisible to the operating system, while offering a hacker full access to tamper with the machine and surveil its activity. For systems with certain faulty configurations in how a computer maker implemented AMD's security feature known as Platform Secure Boot—which the researchers warn encompasses the large majority of the systems they tested—a malware infection installed via Sinkclose could be harder yet to detect or remediate, they say, surviving even a reinstallation of the operating system.


Since the code would then run at ring -2, would it be possible to decrypt the microcode of the CPU, or load custom microcode?


> ... but whenever IMO is brought up, a caveat should be put out: medals are awarded to 50% of the participants (high school students), with 1:2:3 ratio between gold, silver and bronze. That puts all gold and silver medalists among the top 25% of the participants.

yes, it is true, but getting to the country specific team is itself an arduous journey, and involves brutal winnowing every step of the way f.e. regional math-olympiad, and then national math-olympiad etc.

this is then followed by further trainings specifically meant for this elite bunch, and maybe further eliminations etc.

suffice it to say, that qualifying to be in a country specific team is imho a big deal. getting a gold/silver from amongst them is just plain awesome !


Some countries pull these kids out of school for an entire year to focus on training for it, while guaranteeing them entry into their nation's top university.

Source: a friend who got silver on the IMO


umm this is kinda tongue-in-cheek

```

#include <time.h>

#include <stdio.h>

int main(int argc, char argv[]) { int i = 0; time_t timep;

        /*
         * ok so now we are printing something
        **/
        printf("Greetings!\n");

        /*
         * this is a for loop from 0..9
        **/
        for(i=0; i<10; i++) {
                time(&timep);
                localtime(&timep);
        }

        printf("Godspeed, dear friend!\n");
        return 0;
}

```

now, the canonical

```

$> gcc tz-test.c -o obj/tz-test

```

now do this

```

$> unset TZ

$> strace -ff ./obj/tz-test 2>&1 | grep 'local' | wc

     10      77     851
$> export TZ=:/etc/localtime

$> strace -ff ./obj/tz-test 2>&1 | grep 'local' | wc

      1       5      59

```

moral, always set TZ to avoid localtime(3) from stat'ing /etc/localtime :o)


lol never knew about this thanks. Has this actually slowed down someone's code?


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: