u-boot VS wuffs

coreboot just initializes the hardware, the logo is something that the payload displays: https://www.coreboot.org/Payloads

The most typically used payload is u-boot: https://docs.u-boot.org/en/latest/

u-boot supports specifying splash screens via "splashfile", but it seems only bmp and maybe some raw image format are supported: https://github.com/u-boot/u-boot/blob/2f0282922b2c458eea7f85...

In other words, no support for png, which this exploit uses :). That doesn't mean that coreboot/u-boot aren't written in C though which is a language known for its vulnerabilities.

Probably a better example than WiFi would be the on-chip SDRAM controller. It's always somebody's IP and there's a blob in the boot firmware that's just binary register settings. Like so:

https://github.com/u-boot/u-boot/blob/master/arch/riscv/dts/...

Hello, It's my understanding that the following OSS software is used in the AtGames Legends family of products. Specifically: "Das U-Boot" https://github.com/u-boot/u-boot GPL-2.0+ Linux Kernel https://github.com/torvalds/linux GPL-2.0 The AtGames website at https://www.atgames.us/pages/credits does not contain the source code used in these products. Specifically, the GPL requires that if any modifications are made to GPL code, you must make the source code available to the users of the program as described in the GPL, and they must be allowed to redistribute and modify it as described in the GPL. Any modification to u-boot or the Linux Kernel adding the ability to boot a device must be made available to users of the program. Please see the following links regarding acceptable use of GPL software: https://www.gnu.org/licenses/gpl-faq.en.html#GPLRequireSourcePostedPublic https://www.gnu.org/licenses/gpl-faq.en.html#WhyDoesTheGPLPermitUsersToPublishTheirModifiedVersions https://www.gnu.org/licenses/gpl-faq.en.html#GPLCommercially https://www.gnu.org/licenses/gpl-faq.en.html#GPLInProprietarySystem https://www.gnu.org/licenses/gpl-faq.en.html#DistributingSourceIsInconvenient Please let this request serve as written notice of a request for source code for the OSS software used in the following products: HA2810, HA2811, HA2812 AtGames Legends Core Puck HA2819 AtGames Legends Core Max HA8800, HA8801, HA8802 AtGames Legends Ultimate HA8810, HA8812 AtGames Legends Ultimate Mini HA8819, HA8819C AtGames Legends Pinball (Model unknown) AtGames Legends Pinball Micro At this point in time, AtGames is in violation of the GPL and should work to return to compliance by publishing the requested source code and making it available to users of the products.

Upstream u-boot also supports quite a lot of boards: https://github.com/u-boot/u-boot/tree/master/arch/arm/dts

git clone https://github.com/u-boot/u-boot make smdk5250_defconfig Makefile:40: *** missing operator. Stop.

Hey everyone, if this question is off-topic I apologize in advance and if you can redirect me into correct channel or any other source where I can ask question I would happily do, for now I think this is the best place to ask. I daily drive arch and wanted to run freeBSD/riscv64 image on qemu following this https://wiki.freebsd.org/riscv#QEMU_Emulator and u-boot guide: https://github.com/u-boot/u-boot/blob/master/doc/board/emulation/qemu-riscv.rst However it seems I'm doing something wrong and compilation results in error here is all additional info: https://pastebin.com/72shccGa

The normal way this is done is the DDR training blob is just embedded into the bootloader like any other data, and the bootloader loads it into the PMU. Same exact end result, minus involving a Cortex-M4 core for no reason and minus sticking the blob in external flash for no reason. Here, this is how U-Boot does it on every other platform:

https://github.com/u-boot/u-boot/blob/master/drivers/ddr/imx...

Same code, just running on the main CPU because it is absolutely pointless running it on another core, unless you're trying to obfuscate things to appease the FSF. And then the blob gets appended to the U-Boot image post-build:

https://github.com/u-boot/u-boot/blob/master/tools/imx8m_ima...

Purism went out of their way and wasted a ton of engineering hours just to create a more convoluted process with precisely the same end result, because somehow all these extra layers of obfuscation made the blob not a blob any more in the FSF's eyes.

The RK3399 LPDDR4 training code is open-source (albeit rather impenetrable to read) - implementations exist in coreboot, u-boot, and levinboot, so closed source firmware isn't required. I'm afraid I don't know answers to the other questions.

Maybe this is what you are looking for:

https://github.com/google/wuffs

"Wuffs is a memory-safe programming language (and a standard library written in that language) for Wrangling Untrusted File Formats Safely."

It could author its format parsers in https://github.com/google/wuffs, and make them BSD-like open source to maximize adoption.

An even bigger change: It could allow users to choose their iMessage client freely. Why not open up the protocol? I’m sure a security focused client would be popular and in the grand scheme of things easy to author.

Perhaps they could open up more of the OS and apps. Perhaps their claims about the security of users and the App Store is kind of BS.

This is one of the reasons I'm a big fan of wuffs[0] - it specifically targets dealing with formats like pictures, safely, and the result drops in to a C codebase to make the compat/migration story easy.

[0] https://github.com/google/wuffs

There are already huffman-decoding and some parts of webp algorithms in https://github.com/google/wuffs (language that finds missing bounds checks during compilations). In contrary, according to readme, this language allows to write more optimized code (compared to C). WEBP decoding is stated as a midterm target in the roadmap.

Specifically, since performance is crucial for this type of work, it should be written in WUFFS. WUFFS doesn't emit bounds checks (as Java does and as Rust would where it's unclear why something should be in bounds at runtime) it just rejects programs where it can't see why the indexes are in-bounds.

https://github.com/google/wuffs

You can explicitly write the same checks and meet this requirement, but chances are since you believe you're producing a high performance piece of software which doesn't need checks you'll instead be pulled up by the fact the WUFFS tooling won't accept your code and discover you got it wrong.

This is weaker than full blown formal verification, but not for the purpose we care about in program safety, thus a big improvement on humans writing LGTM.

> parsing encoded files tends to introduce vulnerabilities

If we are talking about binary formats, now there are systematic solutions like https://github.com/google/wuffs that protect against vulnerabilities. But SQLite is not just a format - it's an evolving ecosystem with constantly added features. And the most prominent issue was not even in core, it was in FTS3. What will SQLite add next? More json-related functions? Maybe BSON? It is useful, but does not help in this situation.

Regarding traces, there are many forensics tools and even books about forensic analysis of SQLite databases. In well-designed format such tools should not exist in the first place. This is hard requirement: if it requires rewriting the whole file - then so be it.

I agree that Wuffs [1] would have been a very good alternative! If it can be made more generally. AFAIK Wuffs is still very limited, in particular it never allows dynamic allocation. Many formats, including those supported by Wuffs the library, need dynamic allocation, so Wuffs code has to be glued with unverified non-Wuffs code [2]. This only works with simpler formats.

[1] https://github.com/google/wuffs/blob/main/doc/wuffs-the-lang...

[2] https://github.com/google/wuffs/blob/main/doc/note/memory-sa...

There are efforts to do that, notably https://github.com/google/wuffs

RLBox is another interesting option that lets you sandbox C/C++ code.

I think the main reason is that security is one of those things that people don't care about until it is too late to change. They get to the point of having a fast PDF library in C++ that has all the features. Then they realise that they should have written it in a safer language but by that point it means a complete rewrite.

The same reason not enough people use Bazel. By the time most people realise they need it, you've already implemented a huge build system using Make or whatever.

I finally have time to try out wuffs (https://github.com/google/wuffs), which I first heard about here on HN. I want to develop a low-level tokenizer for SDF files, a small-molecule structure file format which started in the 1970s, with lots of, let's call it 'heritage'. Wuffs' ability to process near the data, with a coroutine-like interface, seems like a good fit.

I got the "hello-wuffs-c" example to work, which took some tinkering (see wuffs issue #24). That reads a single string and returns an unsigned int. Despite looking at the example implementations for json parsing, I can't figure out how to go from that example to something which handles multiple input buffer blocks, with string tokens that might straddle two buffers.

Nor could I find third-party examples of people using wuffs-the-language beyond basic experimentation for simple binary data. The handful of non-trivial examples I found only used wuffs-the-library, as a vendored component in a larger project.

The lack of wuffs-the-language use after several years seems a strong sign that I shouldn't look to wuffs for my project. Given the 'workarounds' in #24 are still present after 3 years, it doesn't even seem that widely internally at Google.

Does anyone here have experience to share, or pointers to related projects?

Here's an off-topic answer.

Depends on what you want your toy language to do and what sort of runtime support you'd like to lean on.

JVM is pretty good for a lot of script-y languages, does impose overhead of having a JVM around. Provides GC, Threads, Reflection, consistent semantics. Tons of tools, libraries, support.

WebAssembly is constrained (for running-in-a-browser safety reasons) but then you get to run your code in a browser, or as a service, etc, and Other People are working hard on the problem of getting your WA to go fast. That used to be a big reason for using JVM, but it turns out that Security Is Darn Hard.

I have used C in the (distant) past as an IL, and that works up to a point, implementing garbage collection can be a pain if that's a thing that you want. C compilers have had a lot of work on them over the years, and you also have access to some low-level stuff, so if you were E.G. trying to come up with a little language that had super-good performance, C might be a good choice. (See also, [Wuffs](https://github.com/google/wuffs), by Nigel Tao et al at Google).

A suggestion, if you do target C -- don't work too hard to find isomorphisms between C's data structures and YourToyLang's data structures. Back around 1990, I did my C-generating compiler for Modula-3, and a friend at Xerox PARC used C as a target for Cedar Mesa, and Hans used it in a lower-level way (so I was mapping between M-3 records and C structs, for example, Hans was not) and the lower-level way worked better -- i.e., I chose poorly. It worked, but lower-level worked better.

If you are targeting a higher-level language, Rust and Go both seem like interesting options to me. Both have the disadvantage that they are still changing slightly but you get interesting "services" from the underlying VM -- for Rust, the borrow checker, plus libraries, for Go, reflection, goroutines, and the GC, plus libraries.

Rust should get you slightly higher performance, but I'd worry that you couldn't hide the existence of the borrow checker from your toy language, especially if you wanted to interact with Rust libraries from YTL. If you wanted to learn something vaguely publishable/wider-interesting, that question right there ("can I compile a TL to Rust, touch the Rust libraries, and not expose the borrow checker? No+what-I-tried/Yes+this-worked") is not bad.

I have a minor conflict of interest suggesting Go; I work on Go, usually on the compiler, and machine-generated code makes great test data. But regarded as a VM, I am a little puzzled why it hasn't seen wider use, because the GC is great (for lower-allocation rates than Java however; JVM GC has higher throughout efficiency, but Go has tagless objects, interior pointer support, and tiny pause times. Go-the-language makes it pretty easy to allocate less.) Things Go-as-a-VM currently lacks:

- tail call elimination (JVM same)