What a world we have built ... https://www.tomshardware.com/networking/three-million-malware-infected-smart-toothbrushes-used-in-swiss-ddos-attacks-botnet-causes-millions-of-euros-in-damages

Edit: there are suggestions out there that this story is not actually true. So sad, who ever heard of something not being true on the Internet? But does anybody doubt that something like this *will* be true in the near future?

@troglobit @kernellogger @torvalds The problem having just one LSM is that there's at least couple which have been invested a lot by companies. So thus next best thing is in my opinion the scope and constraint LSM better and "un-LSM" stuff that does not need to be LSM.

Having just one LSM is not something that we have privilege to decide anymore so better to work with the existing constrains.

@Fishwaldo @sdbbp I know by empirical fact that Segger's J-link series of probes have been successfully used with VisionFive2. It was mentioned in this article: https://sizeof.cat/post/starfive-visionfive-2/

From that same article I found the U-boot source for JTAG init: https://github.com/starfive-tech/u-boot/blob/ac0ac696256abf412826d74ee918dd417e207d7b/board/starfive/visionfive2/starfive_visionfive2.c#L354

Can one derive from that init code what kind of probe's are compatible?

@Fishwaldo @sdbbp Thanks for the remark. So: CkLink is.a proprietary extension for JTAG protocol?

@troglobit @kernellogger @torvalds Not totally disagreeing with that, I mean never used any of these LSM's in my own machines :-) Still e.g. in context where you have let's say bunch of nodes e.g. in a data center, it would probably make sense... The point I'm driving is that before you stack anything one should know what the thing is and also what it isn't. Otherwise you are destined to end up with a mess :-)

Have been sick today so could not have concentrated to LKML, thus spamming here so that I can recall my thoughts.

We have a monthly call organized by @securepaul and with bunch of key Linux security contributors like @kees for instance, and at least one person I think from almost all major companies contributing to Linux. I think this topic should definitely end up to the next call's agenda.

@sdbbp OK thanks a bunch for sharing this info :-)

@sdbbp Thanks, are these different probes expected to be compatible? Is the JTAG protocol always the same same and does it have like standardized wiring (e.g. like RS-232 TX/RX/GND)?

I'm familiar with OpenOCD. I use it at the university for prototype SoC (https://sochub.fi/). I plan to develop exactly scripts for it that I can develop and test with my SBC and then tune them to work with the SoC once I get them working on off-the-shelf hardware...

@kernellogger @torvalds @troglobit Have been thinking about this and I’m aligning myself based on constraints that do exist.

Multiple LSMs do exist and since the major LSM’s are also used commercially there must be good reasons to pick one rather than another. Also there is probably bunch of real-world applications where container does not share the same LSM as the host.

The key problem in my opinion with stacking is that LSM is not well-defined entity enough. In order to being one it should be defined preferably in the kernel documentation what is NOT an LSM. If that had a great definition then I would support it.

It is not just about making that kind of constrain to the documentation but also refactoring some features out of the LSM cage. E.g. stacking Yama or POSIX capabilities does not have any meaning in that would make any sense to me. They really should be just plain kernel features.

If stacking involved only “actual” LSM’s then it could be actually useful feature. E.g. I could imagine applications that benefit the user base and does not turn out to be a freaking mess.

If i recall correctly there was yet another LSM in the queue. I’d consider blocking any new LSM’s up until this whole mess has been properly sorted. I still am puzzled about POSIX capabilities “LSM”, i.e. how it ended up to upstream because documentation does not provide any answer on its practical usefulness. On the contrary it gives good arguments of not keeping it inside LSM given that they are always on :-)

I'm not expert with #JTAG probes so no understanding how compatible probes from different vendors are with each other.

I've mostly used #Lauterbach probes in the past but not very often.

So anyway, I grabbed the info from Internet that with #VisionFive2 SBC Segger J-link family of probes are known to work. Are they my only choice or is there some good and perhaps cheaper but compatible options?

#riscv

I might have found a solution: https://www.schristiancollins.com/generaluser.php

Neither a big loss since best Roland emulations are made by other companies than Roland. For instance recent Alpha Juno 2 clone TAL-Pha (macOS/Linux/Windows CLAP/VST3) from ToguAudioLine is just great (and something I've waited for long time, Alpha Juno and Roland JD-800 are my favorite early 90s synths both have been lacking good emulations).

I wonder if anyone has made something to enable playing General #MIDI playback in #Bitwig? Like for e.g. game soundtrack type of stuff.

In #FLStudio there is a General MIDI soundset for #FLEX, which is sort of like a built-in rompler in that DAW. If you import a MIDI file let's say game music from 90s Sierra or Lucas Arts game FL will automatically use this soundset and pick the correct instruments.

Thought that FL part is worth of mentioning because it is not that common knowledge, e.g. I found it by accident :-) What happens in Bitwig is that you get the stock Organ instrument to every channel.

Sound Canvas SC-88 is the only plugin I've ever picked from #Roland it is total garbage. I've never got it run on any machine that I've owned (have had it for 1.5 years, and have occasionally tried it). Also the only plugin I've ever grabbed from Roland (unsurprisingly).

#BitwigStudio #audio #MusicProduction

Nice #article about nuts and bolts of #VisionFive2: https://sizeof.cat/post/starfive-visionfive-2/

I found this when searching for information on what pins I should use to enable #JTAG, which I think I can eventually sort out with some info from this article :-)

#riscv

📣 Attention all change-makers! Join our mission to protect online privacy and freedom by applying for one of our exciting open positions. You will contribute to a meaningful cause while growing professionally in a supportive and collaborative environment. 🚀💪 Don't miss out - apply now and be a part of something bigger than yourself! https://www.torproject.org/about/jobs/

@troglobit @kernellogger @torvalds I mean if you consider either POSIX capabilities and Yama both of them are only part of the "stacking problem" (two containers with different LSMs) only for the reason that they are implemented as LSM. Scaling down a problem to make it more manageable is usually the first step to more sane and healthy situation, right? :-)

@troglobit @torvalds @kernellogger IMHO, the first thing that should be done would be to detach all the code out of LSM framework that is not an optional security module. That would bring some clarity on its purpose because then it would be more logically constrained entity.

Even if that causes a few additional calls around the hooks call site, it removes abstraction shenanigans and other unnecessary boilerplate code, and thus makes reading and debugging kernel code overall more pleasing experience.

E.g. documentation [1] states that "the Linux capabilities modules will always be included" but really does not gives existential reason for abstracting it that way. Maybe there are legit reasons for doing that but they are undocumented and I get a feeling that i'm in a spaceship with a bunch of architecture astronauts :-) [2]

[1] https://www.kernel.org/doc/html/latest/admin-guide/LSM/index.html
[2] https://www.joelonsoftware.com/2001/04/21/dont-let-architecture-astronauts-scare-you/

@kernellogger @torvalds

I’ve understood by reading LKML and LWN that the problem that nested LSM’s is trying can be described as follows:

1. Host is using LSM A.
2. Container is using LSM B.

Given that the most of the popular LSM’s are made for the sake of SELinux being too tedious to configure I’ve sometimes wondered why they could not just convert their policy to SELinux policy, and not be kernel features in the first place 🤷

That said, LSM’s are not my area really, and could easily overlook some aspects that might make them useful as kernel features.

@kernellogger @torvalds Yama actually demonstrated the general problem in any possible framework: they can make blind on considering what the feature actually is and even "right feature" might go to a "wrong socket".

@kernellogger @torvalds Yama at least could just as well be config flag-enabled feature. It gains nothing for being an LSM but is useful security feature for most. Not really going to solve any of this but it is always good to start with the low-hanging fruit :-) Even if nested LSM's was beloved by everyone it still would not make sense as an LSM, and never has. Yama really should have been "CONFIG_PTRACE_RESTRICT_SCOPE" or similar and just a flagged feature with no connection to LSM's.

@troglobit Agree! I'll check that one out thank you :-)