"We are happy to tell you that we accept your proposal "RISC-V devroom" as a devroom at FOSDEM." Woop, woop! @fosdem

@stefanha the early boot stuff is all pretty board specific, so there's a decent chance you're going to need some code changes as well to make it work.
Spike doesn't look at all like any real systems, so the early boot stuff is going to be a bit clunky.

I'd just try and use the virt board in QEMU, it's much more realistic and widely used.

The secret to conferences (but you did not hear this from me) is not attending the sessions

Failing is OK. We can learn a lot when we fail. https://inbox.sourceware.org/libc-alpha/cf4a8045-c824-6f1c-ffd1-e433aa45ef2c@redhat.com/T/#u

Just sent a large number of patches to support the Qcom Snapdragon 8 Gen 3 in mainline #Linux :-)
=> https://lore.kernel.org/all/?q=sm8650

PSA: we have seen the vague viral reports alleging a Signal 0-day vulnerability.

After responsible investigation *we have no evidence that suggests this vulnerability is real* nor has any additional info been shared via our official reporting channels.

I had an amazing time last week at @KernelRecipes 10th edition. This marked my fifth year speaking at the most unique Linux kernel conference in the world. I'm thrilled to have been a part of this incredible event for half of its life so far. Thank you folks!🐧🙂

@juliank Makes sense, there's at least arm64 hardware that has the necessary bits to be secure by the time it gets to u-boot.

I might be wrong here, but I don't know of any RISC-V hardware that can be configured to verify the first code that gets loaded from off chip. So as long as the thread model allows for messing around with a SPI flash (or wherever that code is loaded from), then we've got other problems that would require more of a HW-oriented fix.

Still a good fix and all, as we'll get there eventually and landing these backports in time can be a ton of work.

@juliank I'm not sure how to post on that issue, but I also don't know of any RISC-V systems that support this secure boot flavor (or really any proper secure boot, for that matter). It's not my area of expertise so I might be missing something, but IIUC there's still a bunch of work we'd need to make this all fit together.

@jarkko IIRC I'm using something pretty similar, but mostly Will just told me what to do because he'd just set it all up. That was a few years ago, though...

Trimmed diffstat of v6.6-rc1 pull request ARM SoC changes from @arnd - the most active platforms for v6.6:

18.9% arch/arm64/boot/dts/qcom/
0.6% arch/arm/boot/dts/qcom/
1.0% drivers/soc/qcom/
...
9.6% arch/arm64/boot/dts/freescale/
3.6% arch/arm/boot/dts/nxp/imx/
0.7% arch/arm/boot/dts/nxp/ls/
0.9% arch/arm/boot/dts/nxp/mxs/
...
8.1% arch/arm/boot/dts/aspeed/
...
8.2% arch/arm64/boot/dts/ti/
0.5% arch/arm/boot/dts/ti/
...
6.6% arch/arm64/boot/dts/nvidia/
...
6.3% arch/arm64/boot/dts/rockchip/

Way to go Qualcomm SoC community!
Source: https://lore.kernel.org/all/4f60d13e-f060-491a-88c7-6f25323a48f8@app.fastmail.com/

Here is a hopefully-useful notice about Linux kernel security issues, as it seems like this knowledge isn't distributed very widely based on the number of emails I get on a weekly basis:

- The kernel security team does not have any "early notice"
announcement list for security fixes for anyone, as that would only
make things more insecure for everyone.

- The kernel community does not assign CVEs, nor do we deal with them
at all. This is documented in the kernel's security policy, yet we
still have a number of people asking for CVE numbers even after
reading that policy. See my longer "CVEs are dead..." talk for full
details about how the CVE process is broken for projects like Linux:
https://kernel-recipes.org/en/2019/talks/cves-are-dead-long-live-the-cve/

- You HAVE to take all of the stable/LTS releases in order to have a
secure and stable system. If you attempt to cherry-pick random
patches you will NOT fix all of the known, and unknown, problems,
but rather you will end up with a potentially more insecure system,
and one that contains known bugs. Reliance on an "enterprise"
distribution to provide this for your systems is up to you, discuss
it with them as to how they achieve this result as this is what you
are paying for. If you aren't paying for it, just use Debian, they
know what they are doing and track the stable kernels and have a
larger installed base than any other Linux distro. For embedded,
use Yocto, they track the stable releases, or keep your own
buildroot-based system up to date with the new releases.

- Test all stable/LTS releases on your workload and hardware before
putting the kernel into "production" as everyone runs a different %
of the kernel source code from everyone else (servers run about
1.5mil lines of code, embedded runs about 3.5mil lines of code, your
mileage will vary). If you can't test releases before moving them
into production, you might want to solve that problem first.

- A fix for a known bug is better than the potential of a fix causing a
future problem as future problems, when found, will be fixed then.

I think I need to give another talk about this issue to go into the above in more detail. So much for me giving a technical talk at Kernel Recipes this year...

PSA: don't get COVID. It sucks.

Introducing Bark! Low-latency multi-receiver live-sync lossless audio streaming for local networks. It's like Sonos, but open source, so nobody can brick your devices remotely. It's also written in Rust :)

It sends 48khz uncompressed float32 data over UDP multicast. It can achieve playback sync to within hundreds of microseconds in ideal conditions, and usually to within a millisecond.

I've been working on it in my spare time over the past week, and I'm pretty happy with how it's shaped up. I have three receivers setup and it works remarkably well at keeping everything in sync as I walk around my house. For now it only really works on Linux, and supports Pipewire (and Pulse in theory), but there's no huge impediment to making it truly cross-platform.

It also features a fancy live stats subcommand, which can used on any computer in the same multicast domain to watch the status of the stream cluster:

What do y'all think of non-code contributions, in particular for open source projects?

(E.g. documentation, testing, tooling, bug reproduction, advocacy ... just to list a few!)

Please boost for reach <3

(Answers edited to be shorter and show correctly on all devices.)

The best way to truly support my work on #curl, is to make your company pay for a support contract: https://curl.se/support.html

I work full time on #curl for wolfSSL. Support customers make me get paychecks. Paychecks let me buy food. Food makes my family happy. A happy family lets me do more #curl. More #curl benefits ... well, you.

@llvm I get it backwards like 90% of the time, and end up with a new branch on the remote named $HASH with my staged stuff in it ;)

@conor I guess if you're trying to ship it that's probably best? That, or just replace it with something sane ;)

GCC 14 is still in development, but it has a wonderful new feature in its static analyzer (-fanalyzer).

It can now draw beautiful Unicode diagrams showing exactly how you went out-of-bounds.

See https://inbox.sourceware.org/gcc-patches/20230531180630.3127108-1-dmalcolm@redhat.com/ too.

Thank you to the wonderful David Malcolm for implementing this - who also does a tonne of work with mentoring for GCC's GSoC programme, and working on docs to help new people get into GCC: https://gcc-newbies-guide.readthedocs.io/en/latest/index.html.

@gnutools