I feel very stupid asking this question, since originally I thought that I just have to enable a config statement and afterwards it runs smoothly. But I do not find the correct settings.
I have an embedded system and build a rootfs, linux kernel, u-boot, etc. using builtroot.
Now I want to implement remote attestation. Therefore I want the different steps during the boot process to extend the pcrs of my TPM 2.0 with the hash values of the next step.
I can run commands on the TPM using tpm2-tools when the system is booted.
I thought that u-boot, the kernel, etc. all got their tpm driver, so it should not be a problem for them to extend the pcr.
But how do I enable this?
Thank you so much for your answer.
I answer my question by myself in case there is someone with a similar problem.
The problem is solved by creating a U-Boot patch. To boot the operating system, uBoot run several steps. These are extended by my patch.
I copy the rootfs into memory, hash over it and extend a pcr with it. The following commands are needed:
$ tpm2 init // init the tpm
$ tpm2 start TPM2_SU_CLEAR // start the tpm
$ mmc read $loadaddr 0x800 0x80000 //read your rootfs
$ hash sha256 $loadaddr *0x10000000 // hash over it
$ tpm2 pcr_extend 4 0x10000000 // extend a pcr with the hashed value
Hopefully someone find it helpful. In case you find an error pls comment.
EDIT: added missing asterisk
Related
I built a certain driver as module (m) for Linux, the spi-imx by NXP. Nontheless, Linux probes this driver when booting. I'm struggling to find out what process/other module/driver requests this spi-imx driver. A depmod does not show any dependencies between the spi-imx an other modules (except for the spidev as submodule).
After some research, I found out that Linux automatically (?) calls modprobe when it detects a new device. So does Linux actually call modprobe because the ecSPI'S status in the device tree as "okay"? If so, how can I prevent this? I would like to dynamically load the spi-imx from a user space application via modprobe. The story behind it: a coprocessor uses this SPI line in parallel to the Linux boot process. This interferes of course and interrupts the coprocessor's use of the SPI line. When the coprocessor has finished its transfer via SPI (a boot mechanism as well), it should hand over the SPI line to Linux.
I'm very thankful for any kind of tips, links, hints and comments on this.
Thanks a lot for the answers. As you guys mentioned, I also found out that Linux itself probes the device if present ("okay").
One possible solution is to complete cut off the modprobe call via an entry like "install spi-imx /bin/false" in the *.conf file. But that makes it impossible to load the driver via modprobe, for Linux and for user space.
"blacklist spi-imx" inside a *.conf located at /etc/modprobe.d/ is the way to prevent Linux from probing the driver when booting. After that, a modprobe from user space can successfully load the driver afterwards.
Thanks again & best regards
I'm studying OS development and I use brokenthorn resource but with a little bit different tool, namely, I use CentOS, NASM and Qemu as a test/dev environment. I've been facing some issues while creating bootable img file with secondary loader.
I've got two files:
1. bootloader.bin which is first stage loader.
2. stage2.bin which is secondary loader.
In order to create bootable img file I do the following:
dd if=/dev/zero of=floppy.iso bs=1024 count=1440 -- Creating empty file
mkfs.vfat -F 12 floppy.iso --Creating file system in the file
dd if=../bin/bootloader.bin of=floppy.iso bs=512 count=1 conv=notrunc --Writing first loader to the boot sector
sudo mount -o loop floppy.iso /mnt/floppy/ -- Try to mount file system to write secondary loader using previously create FAT-12 files system.
In the last step I'm getting the following error:
mount: /dev/loop0 is write-protected, mounting read-only
mount: wrong fs type, bad option, bad superblock on /dev/loop0,
missing codepage or helper program, or other error
In some cases useful info is found in syslog - try
dmesg | tail or so.
Can you please help me to understand what I'm doing wrong and what other ways I can use to accomplish creating bootable img with file system on board.
Thanks!
I once stumbled upon the similar problem and this answer may be of help to you.
However I would strongly recommend you switching to bootloader like Grub and spend time and effort developing the actual OS of yours. For that I would reccomend grub resque as it's simple to use and allows to to quickly create ISO that you can either burn or feed to virtual machine. Otherwise, you may just drown in all these minor things like enabling protected mode, loading your stages and so on.
I'm currently busy with my masters project which involves setting up comms on UART between a Raspberry Pi Model 2 B V1.1 and a Pixhawk Flight Controller using Mavlink protocol.
The first step is, of course, to get the UART set up and working. I'm not one to run after help at the first sign of a problem. I have been struggling with this for days and it's forced me to doubt the purpose of my existence more than once. I feel stupid and frustrated. Please see if you can provide any assistance.
My first resource was this tutorial, which should be relatively straight forward:
http://ardupilot.org/dev/docs/raspberry-pi-via-mavlink.html
The tutorial simply installs all the necessary packages and dependencies, as well as sets up the UART. I followed the steps to disable OS use of the serial port through raspi-config, however after attempting to test the connection I get an error:
[Errno 2] No such file or directory: '/dev/ttyAMA0'
Which is very strange. So after disabling and enabling OS use of serial port through rasp-config a few times and checking, every time I disable it, the /dev/ttyAMA0 file disappears. Now how the hell is anything supposed to work on the UART if disabling OS use of the UART removes that file!? Nevertheless I powered through. I enabled OS use of the serial port, which leaves the ttyAMA0 file right where it is and followed another suggestion, which is to change the /boot/cmdline.txt and remove all reference to ttyAMA0, as shown in the following link:
http://www.raspberry-projects.com/pi/pi-operating-systems/raspbian/io-pins-raspbian/uart-pins
This seemed to work alright. I could now initiate comms between the RPi and the Pixhawk flight controller and get some information that looked correct. Then the black magic started. The next day I tested the connection and it consistently spat out complete rubbish. But Nothing changed since the previous day. Somewhere I must be missing something. I followed all the same tutorials and steps attempting to get the more positive results I got the previous day. However that only led to more erratic behaviour. When connecting the serial lines to my Pixhawk Flight Controller, the keyboard/mouse seems to get interrupted momentarily every now and then. Everything just went backwards. I have already reinstalled Raspbian Jessie in a desperate attempt to get things to work.
Here are a few things I suspect could possibly contribute to the problems:
Baud rate not correct (to communicate with my Flight Controller baud rate needs to be 57600). Best way I've found to set this baud rate is to append "init_uart_baud=57600" to /boot/config.txt/. I have also read about other ways such as appending a line to /etc/crontab. Any suggestions?
Pixhawk miraculously and sporadically refused to communicate back with RPi.
Any assistance will be appreciated. Thank you.
SOLVED:
Looks like a known bug in the latest raspbian, easy to fix though.
These need to be done as the root user.
Disable "serial console" through GUI-preferences or "sudo raspi-config." Then reboot the pi.
Then change the following line in the file /boot/config.txt at the bottom of the file from:
enable_uart=0
to
enable_uart=1
Disable the ModemMonitor service by running the following command as root:
systemctl disable ModemManager.service
Then add youself to the dialout group, just to be sure you have the required permissions on the serial port:
adduser pi dialout
That should give you unrestricted proper access to the serial port.
Resources:
[url]https://www.raspberrypi.org/forums/viewtopic.php?f=66&t=148515[/url]
and
[url]https://www.raspberrypi.org/forums/viewtopic.php?f=28&t=82779[/url]
I had researched this for days now and troubleshooting all the readings listed on Google sites. I solved the serial UART settings for connecting my RPi3 Model B (typed at command line the following:
`cat /proc/cpuinfo`
to find my Pixhawk hardware info.)
FYI: You must be root when working with mavproxy so, sudo su
or sudo -s
Also, you must be a member of the dialout group, so do this at CMD line:
sudo usermod -a -G dialout root (enable root user!)
Do all the RPi regular stuff:
sudo apt-get update && sudo apt-get upgrade and sudo rpi-update.
Did all as outlined in the Ardupilot website. I did NOT use the
"apsync-rpi". (I used the 2017-03-02-raspbian-jessie.img.) at here
On my RPi3, using $uname -a: results--> Linux raspberrypi 4.4.50-v7+
My $sudo nano /boot/config.txt file has one change at bottom of file;
THIS statement: enable_uart=1 (has a good side effect of forcing the
core_freq to 250 which reduces poor signal frequency)
Important discovery: so the articles state that RPI3 UART and tty settings have changes. (link here)
What I have discovered after much ado is this for my sudo nano /boot/cmdline.txt file:
dwc_otg.lpm_enable=0 console=tty1 root=/dev/mmcblk0p2 rootfstype=ext4 etc.,.
-Notice I am not using ttyS0 in the /boot/cmdline.txt file. I tried the ttyS0 a dozen times and it never worked properly. For some reason, I am not able to explain it at this time, although the console=/dev/tty1 works if written in the /boot/cmdline.txt file.
Make sure you have the wiring correct between your RPi and the Pixhawk.
Telem 2. Also set the correct parameters in Mission Planner as I
have;
Go to CONFIGTUNING->STANDARD PARAMS; (my settings)
-The Serial0 baud rate(SERIALO_PROTOCOL) is: 115200
-The Console protocol selection(SERIAL0_PROTOCOL) is: MAVlink1
-Telem1 baud rate(SERIAL1_BAUD) is at: 115200
-Telem1 protocol selection(SERIAL1_PROTOCOL) IS MAVlink2
-Telemtry 2 Baud rate(SERIAL2_BAUD) is 921600
-Telemetry 2 protocol selection(SERIAL2_PROTOCOL) is MAVlink1
The RPi and pixhawk communicate at 921600 baud rate.
-Once I get the RPi3 powered up with it's own +5/VCC source and connect to my MP with a 3.0 USB cable from my PC-Windows10PRo, (okay, I have Arch and Debian Linux distros and Apple OSes too!) I enter:
`mavproxy.py --master=/dev/ttyS0 --baudrate 921600 --aircraft Plane`
It works for me!
Happy experimenting and flying!
I find if you create a compute engine (CentOS or Debian) machine and using gsutil to download (cp) a tgz file will cause a crcmod error...
$ gsutil cp gs://mybucket/data.tgz .
Copying gs://mybucket/data.tgz...
CommandException:
Downloading this composite object requires integrity checking with CRC32c, but
your crcmod installation isn't using the module's C extension, so the the hash
computation will likely throttle download performance. For help installing the
extension, please see:
$ gsutil help crcmod
To download regardless of crcmod performance or to skip slow integrity checks,
see the "check_hashes" option in your boto config file.
Currently I use "check_hashes = never" to bypass the check...
$ vi /etc/boto.cfg
[GSUtil]
default_project_id = 429100748693
default_api_version = 2
check_hashes = never
...
But, what is the root cause? and is there any good solution to solve the problem?
The object you're trying to download is a composite object, which basically means it was uploaded in parallel chunks. gsutil automatically does this when uploading objects larger than 150M (a configurable threshold), to provide better performance.
Composite objects only have a crc32c checksum (no MD5), so in order to validate data integrity when downloading composite objects, gsutil needs to perform a crc32c checksum. Unfortunately, the libraries distributed with Python don't include a compiled crc32c implementation, so unless you install a compiled crc32c, gsutil will use a non-compiled Python implementation of crc32c that's quite slow. That warning is printed to let you know there's a way to fix that performance problem: Please run:
gsutil help crcmod
and follow the instructions there for installing a compiled crc32c. It's pretty easy to do it, and worth the effort.
One other note: I strongly recommend against setting check_hashes = never in your boto config file. That will disable integrity checking, which means it's possible your download could get corrupted and you wouldn't know it. You want data integrity checking enabled to ensure you're working with correct data.
I am trying to make a 'dual core' RaspberryPi for a project I am working on. I had followed this tutorial by Simon Cox. Unfortunately I could not get the two RasPi to talk to each other. (This was using Hydra as the process manager)
After looking more carefully at the MPICH installers guide, which can be found here, I tried to use the -phrase to pass the passphrase I had created. However I could not find it as part of the hydra commands. So I re-installed with smpd and after many compiling attempts. I configured with:
/configure -prefix=/home/pi/mpich-install --with-pm=smpd --with-pmi=smpd
I also had to install libbsl-dev to get the MD5 that smpd requires. I also exported the path that the commands mpiexec and mpicc are in. After setting the passphrase I copied the image to a second SD card and put it in a second RasPi. I then set up the passphrase using ssh-keygen.
I was able to run the cpi program on the master Pi and the slave Pi individually but when I tried to run multiple processes on both at the same time I got the error
Fatal error in MPI_Init: Other MPI error, error stack:
MPIR_Init``_thread(392).................:
MPID_Init(139)........................: channel initialization failed
MPIDI_CH3_Init(38)....................:
MPID_nem_init(196)....................:
MPIDI_CH3I_Seg_commit(366)............:
MPIU_SHMW_Hnd_deserialize(324)........:
MPIU_SHMW_Seg_open(863)...............:
MPIU_SHMW_Seg_create_attach_templ(637): open failed - No such file or directory
Can someone please suggest how I can either fix this problem or get the RaspberryPis to communicate using MPICH?
Thanks
E.Lee
If anyone else has this problem make sure your hosts don't have the same name!
You can change it by following this tutorial http://raspi.tv/2012/how-to-change-the-name-of-your-raspberry-pi-new-hostname