I have board with arm-proccessor, that uses u-boot to load firmwares. I load firmware as Squashfs, but I want to make sure, that no one would be able to load their own firmwares, so I want to some how sign my squashfs file and check its signature in u-boot.
Are there any standart ways to do it? Does squashfs supports signatures "out-of-box"? Or can I add my signature to the end of squshfs-file?
A solution to this would be to leverage the verified boot functionality of FIT images, and have your squashfs be contained with the FIT image, along with the kernel and device tree files. Then you can ensure they have the signatures that you want before booting, and also disable support for booting unsigned images.
Related
I cannot extend the default U-Boot EFI functionality provided by the default configurations files x86_app64_defconfig or x86_payload64_defconfig with for example CONFIG_EFI_LOADER, CONFIG_EFI_SECURE_BOOT, CONFIG_CMD_NVEDIT_EFI, etc.
I'm simply not allowed to add them. Trying to work my way around the problem by modifying some kconfig files just end up in failed builds.
Seems like it is possible with the corresponding 32-bit default configuration files x86_app32_defconfig or x86_payload32_defconfig but that is not what I want.
Judging by the lib_v1.0.2 library, access to the file system is implemented in Toit. May be can give some simple examples, which would include:
Create a file,
Writing data to file,
Reading data from a file,
Deleting a file,
Is there support for folders, and if so, what is the nesting level and how to get a list of files in the folder?
Update 2022-12-20: the host package's filesystem functionality (host.file and host.directory) is now supported for sdcards.
The filesystem libraries are not supported on ESP32 devices. They were implemented for host machines (like Linux), but that version isn't released.
The libraries will likely move soon and then not be accessible anymore.
If you want to store data on the device, maybe the device flashstore works for you:
import device
main:
store := device.FlashStore
store.set "key" "data"
I want to boot a distro with my board where the package manager controls extlinux.conf and ships dtb file for my board but I also have an extension board so I'll need an overlay to enable some features.
Previously I would just write a boot.scr file that applies the overlay and then boots the kernel. But the kernel's and initramfs' filenames change between versions so managing the boot.scr would be tedious.
Luckily it also ships with extlinux.conf that points to the new versions but I'm having a hard time finding a way to apply an fdt overlay that way.
Is that even possible?
The Syslinux syntax used in extlinux.conf files read by U-Boot does not include a keyword to apply fdt overlays, so you're out of luck here.
It is possible to use the localboot keyword to have U-Boot execute a custom command instead of loading the kernel image specified with the kernel keyword. If a label contains the localboot keyword followed by a non-negative number, e.g.:
label mycustomboot
localboot 0
U-Boot when booting the entry executes the commands contained in the localcmd environment variable. So in theory you could put in your localcmd environment variable the series of commands you need to execute at boot (load the kernel, the fdt and the overlay, apply the overlay, and boot the kernel). But I guess this would defeat the purpose of using extlinux.conf in the first place, and wouldn't be much different from how you do things with your boot.scr file...
I want to upgrade my systems in the field using the uboot FIT images.
My system is a custom firmware, booted by uboot. So far the FIT filesystem works very good. It provides a shasum verified upload. I am using uboot scripts to update stuff on the target.
One intriguing type defined in uboot docs is type "filesystem". The actual content could be several things, like maybe tar'ed bunch of files, or an actual collection of separate individual files in one chunk in the FIT.
In another FIT question, Tom Rini implied that a filesystem is really just a binary blob. What goes into it is my problem and that uboot could then just mmc write ... or usb write ... to create the new filesystem on some partition. Is this really the case?
How can I build a filesystem (say FAT), on a host build computer for packaging with FIT?
Thanks, Steve
The creation of a filesystem image will depend on the filesystem itself. In many cases, build systems such as OpenEmbedded or buildroot can help you here as they will create the images for you.
I am working at an OS independent file manager, in C. I managed to copy files, links and directories, but I am not sure how to copy devices. I would appreciate any help.
To create a device file, use the mknod(2) syscall. The struct stat structure will give you the major and minor device numbers for an existing device in st_rdev.
Having said that, there is little value in "copying" a device because a device doesn't contain anything useful. The major and minor numbers are specific to the OS on which they exist.
It's not really a useful feature, IMHO. tar(1) needs to be able to do it as part of backing up a system, and setup programs need to be able to create them for you when setting up your system, but few people need to deal directly with device files these days.
Also, modern Linux systems are going to dynamic device files, created on the fly. You plug in a device and the device files appear; you unplug it and they disappear. There is really no use in being able to copy these dynamic files.
dd is your friend (man dd)
dd if=/dev/sda1 of=/some_file_or_equally_sized_partition bs=8192
if you want to copy the device-file itself, do this:
cp -p device-filename new-filename
e.g.:
cp -p /dev/sda1 /tmp/sda1
those are both equivalent device files, and can be used to access the device.
If you're want to do this from C, use mknod() .. see "man 2 mknod"
This might be useful
cp -dpR devices /destination_directory
cp -dpR console /mnt/dev
You don't. Just filter them out of the view such that it can't be done.
Use the stat function to determine the file type.
Check if you've the udev package, if you do, chances are that devices are generated on the fly, from the package description:
udev - rule-based device node and kernel event manager
udev is a collection of tools and a daemon to manage events received from the
kernel and deal with them in user-space. Primarily this involves creating and
removing device nodes in /dev when hardware is discovered or removed from the
system.
Events are received via kernel netlink messaged and processed according to
rules in /etc/udev/rules.d and /lib/udev/rules.d, altering the name of the
device node, creating additional symlinks or calling other tools and programs
including those to load kernel modules and initialise the device.