@oleksandr @ljs For my defense, at the time when SGX was started I did not have a reference, and thus it was based on nothing :-) So it was a huge fight with mm to get it do something it was never designed for...

@katzenmann The main sponsors #Microsoft and #Google for Rust based kernel features have only the interest of closing ecosystems wherever they can. That power can be only mitigated by having defense in depth. Neither company has great history with Linux - except when you ask from their marketing people.

None of those help with governance. I don't think it is unstable and I neither care where it is hosted.

@ljs @oleksandr sgx took me over 40 revisions ;-)

@ssundell @bestest @anuko @iju Se on ollut halvin vaihtoehto kaljatilauksissa, ja paras. DHL on ollut taas kallein ja huonoin.

@pinkforest very nice :-)

I think AI might be death of social engineering at least because its odds/risks ratio is worse.

One idea for fully legal #ransomware alike software that could exploit #AI code generation:

1. Do the initial research where the code is scavenged for the ML consumption.
2. Do the initial research on how generate meaningless code with the property that it has a signature that could be detected.
3. Create automatically and in volumes malicious and meaningful Git repositories or fake profiles that contain seemingly legit projects but actually are not.
4. License projects with GPL3.
5. Create a framework for scanning binaries from which you can detect your signature.
6. Sue all the parties with conflict with the licensing.

Some steps have open holes but I think this pattern could potentially made to work in some form.

The future of #malware lies strongly in conning the AI. Why bother with social engineering (e.g. calling to the company) and risking yourself when you can just con the AI through the Internet. AI does not only make producing bad quality code easier - it also makes hacking systems factors easier.

Another angle would be to con AI to pick a pattern that leaves a backdoor to the implementation. People who rely on Copilot are not that likely to review the generated code, I'd guess.

#infosec

Glad to finally have #Zstd compression enabled for #AlpineLinux's linux-firmware package exactly half a year (minus a few hours) after originally opening the merge request during our post-Fosdem #postmarketOS hackathon!

If you're running Alpine (or postmarketOS) and have all linux-firmware packages installed, the on-disk space will go down from around a gigabyte to around half a gigabyte or so, which I think is pretty decent.

@ljs cograts!

LOL, apparently toml is in the title already

I've used a tool call yq for some time. It is like jq but parses also the document types that I have actually use for such as CSV, XML and yaml (not sure about toml):

https://github.com/mikefarah/yq

I've never used jq because I haven't parsed a single JSON file in my lifetime so cannot really compared to that.

Wondering how #Bevy implements the parameter discovery for e.g. add_systems.

#rust #rustlang

The first job interview was today of many that I'm going to have after the holidays. It included also live coding but since I did not expect it I passed it ;-)

If I had knew it, I would probably have failed. I'm really bad dealing with that type of stress even tho can stand a lot of pressure in IRL situatation.

@argv_minus_one Especially AI stealing code has raised the importance of copyleft licenses and we should rely more heavily in them in core components of Internet. Then you have a chance to sue a company if it contains provably GPL'd code (AI putting it there does not matter). Great example of governance.

@argv_minus_one Because it will allow to compile kernel with a compiler with proprietary changes. It is permissive but not self-governing.

You can still obviously do that for Linux but it is limited useful given that you would have to build that compiler from scratch.

@pinkforest LOL, I don't still think that completely renders out my point ;-)

#BUSL would be great for #audio #plugins ;-) .

https://lwn.net/Articles/984249/

I don't think #Rust should have any business in any core features of #Linux #kernel before there is GPL licensed toolchain for it. #rustlang

After working with RISC-V CPU's produced by SocHub, and CVA6 running on FPGA and projects like Keystone Enclave during my "industry sabbatical", here's my thoughts on the topic enumerated in random and chaotic order:

1. Specifications are ambiguous and sometimes plain incomplete. WFI opcode is a great example of ambiguity. The lack of ability to define caching properties (like MTRR on x86 ) for physical memory is a great example of incompleteness.
2. IRQ handling is worst I've seen in any modern CPU architecture. It is slow and badly engineered.
2. CPU's behave quite differently depending on vendor, especially cache. For this reason I spent almost two months fixing trivial page table boostrapping code for Keystone Enclave (on CVA6).
3. Commercial CPU's are proprietary as hell given that the "openness" means that companies just fork and tailor and obviously do not publish any changes back to the community.
4. There is neither shared repository for hardware definition in VHDL nor Verilog.
5. There's no open source community. There is only corporate body called OpenHW Group. It is all about companies doing together an open hardware brand, not individuals making together great things.

To have actually open hardware the design and HDL should be copyleft licensed. Not sure if that is commercially realistic but otherwise it is all just as fake as having a BIOS based on Tianocore, and claiming that BIOS is open source.

It is more open to have a proprietary vendor that either sells CPU's (Intel) or licenses the spec (ARM). It is also better for individual because you have an entity that talks you back if you are a customer of them.

#riscv #hardware #opensource #sifive #arm #intel