After the OTA update is successful, AOSP marks the target slot B to active. Now, when the next boot happens, the device boots from slot B. Now my question is how does the bootloader or android come to know it has to boot from that active slot?
Does it read from any ro property or from something else?
This is manufacturer/vendor specific and not specified by Android. A vendor has to provide an implementation of the android.hardware.boot#1.0 HAL in which he has to decide how to implement the setActiveBootSlot call coming from the update_engine.
The bootloader (also provided by the vendor) then has to implement means to get the active boot slot.
A vendor could for example decide to store the current active boot slot in the /misc partition
See https://source.android.com/devices/tech/ota/ab/ab_implement.html
Related
I would like to use Simics to test out Intel Atom Verified Boot & Measured Boot with Boot Guard without potentially breaking my development hardware (which would be a permanent breakage if I mis-fuse it). I believe that the initial boot block (IBB) verification and fused-key usage is done by the CSME. Is it possible to test whether the tamper-proofing of the IBB is working correctly, or will I only be able to test the main x86-side portion within Simics?
(I think also maybe if the CSME portion is not emulated then perhaps the handoff of trusted key hashes won't happen, so even the IBB won't be able to verify subsequent stages and thus it wouldn't be able to simulate Boot Guard in Simics?)
The current public Simics Quick-Start Platform model does not include the CSME or other secure boot features. It is a model limitation.
If I have Codesys project with CANopen manager and I add a CANopen slave node to the CAN with node id 19, the system is clear to me, but if I add two same sensor devices with same factory preset nodeid 19, how do I change the nodeID of either of two? I do not have any idea. Devices support LSS but i dont have idea how to implement nodeid change with or without it. Should I code it or should the canopen manager change the nodeid somehow. Any ideas are welcome. Of course I could change it by adding first device to the CANand change it and after that I could add the second one to the CAN bus. But I want to change the dynamically when both are in the CAN bus same time so it should be same situation as in future production line.
You can either write a small program in CODESYS that changes the ID, or if you have a USB to CAN tool you can send the commands to change the ID.
This is normally done in a 2 step process.
1- Set the parameter
2- Save the parameter (usually with some "magic word).
The message to change the ID will depend on the manufacturer.
Sometimes this is in the EDS file, so it might be worth it to have a look in there.
Building a firmware using EDK2, what is the programmatic way to provide a default boot order? I want the default option to be boot from SD card. I have an bootx64.efi image stored in the SD card.
Every time when I build the EDK2 image and flash it on the target, I need to enter boot maintenance manager option and add SD card as boot option and change the boot order.
I looked into the code and read the specifications of Boot manager. I understood that I need to modify Boot Order variable but I don't get how to add SD card option in the source code.
I am looking into the QemubootOrder.c file but I don't understand where I need to add the path to SD card .
Well, first of all, if your UEFI port considers that SD card a "removable media", which is should - it should automatically load it if it is placed in \EFI\BOOT\ on the FAT-formatted EFI System Partition.
BootOrder comes in if you want to be able to support multiple options. But BootOrder itself only consists of a list of the numerical part of the available Boot#### options, in order of preference.
You can learn more about these mechanisms from the UEFI Specification. Current version is 2.6, and the most relevant bit for this topic is section 3.1 Firmware Boot Manager.
There are two case when working on an embedded system.
Embedded system have limited resources like as ARM Cortex M0 Microcontroller with 12 K Flash.
Case 1 :
Common function/module usage for Bootloader and Firmware :
Bootloader and Firmware may need to use same module and function to prevent code duplication. Otherwise, same code will be included both Firmware and Bootloader twice.
We can prevent this by specify the function address and call this function by calling functions by addresses. This is one of the solutions.
Is there any smart method to provide common function usage?
Case 2 :
Sometimes, we need to upgrade firmware. One of the duties of bootloader is firmware upgrades. We can easily upgrade the firmware by overwrite the old one.
As we saw, two case can be implemented separately. But when we merge they, some problems are appeared.
Question :
Bootloader's are generally static objects but firmware's are can be modified. Therefore, common functions are generally located at Bootloaders. But when we need update a common module/function, how can we do?
What are the general or smart approaches which bootloader, firmware structured embedded systems? In Addition, for limited resources.
To discrete common modules/functions, Can one or more additional areas solve this problems.
Firmware, Bootloader and Library(New Area)?
I want to learn general approaches. Is there any paper, book and source about advanced Firmware management?
Thanks
If you share code between your bootloader and your mainline firmware application, then your bootloader will be using this code when it flashes the application space. In order to prevent this condition you must sacrifice the ability to update the common code, otherwise your bootloader will crash.
With only 12k of flash, it's pretty ambitious to expect a bootloader and mainline application to fit. You might consider writing the bootloader in assembly (gasp!). Some Cortex M0 parts (such as the NXP LPC11xx family) have an additional boot ROM which stores some useful functions and help alleviate some of the memory constraints.
Your question states the problem correctly - you cannot have your cake and eat it. Either:
1. You go for a small memory footprint and do not include firmware upgrade logic in the bootloader (i.e bootloader might just validate application image CRC etc but nothing more complicated). Here you could share functions to save space. OR
2. The bootloader has firmware upgrade functionality. Here you have to have shared functions compiled both into app and bootloader. The shared functions should be small - probably not a huge overhead but you need the space that this would take - if you dont have it then you need to go for more memory.
There is no way to share functionality and do firmware upgrade from bootloader reliably.
In lights of the current discussion about security in the firmware update process I would like to add the following for clarification:
Sharing code between the bootloader and the app will open yet another door for the potential attack, so you really want to avoid that.
The bootloader part is the part you actually do not want to change ever, this should be as static as possible. If the bootloader is broken, in-the-field-updates become nearly impossible or at least insecure.
Having said that, you might want to use a different approach.
You could create a maintenance mode for your device.
This mode opens the JTAG interface and allows direct access to memory. Than the service technician could apply the update.
Now you "only" need to secure the activation of the maintenance mode.
The following could work:
Use a UART interface to communicate the activation.
Maintenance system sends its own id and requests maintenance mode via UART
The id of the maintenance system, a random number and a unique system id are sent back to the maintenance system.
The maintenance system sends this id-sequence to your certification server.
If the unique system id and the maintenance systems id is correct, the server will create a signature of the information received and send it back to the maintenance system.
Your system now will receive the signature via UART
Your system verifies the signature against the previously send id-string with a public key stored during production
On a successfull verification maintenance mode is entered
To add security, you definitely want to put some effort into the maintenance systems id following a similar scheme. The ID should basically depend on MAC-address or another unique hardware id and a signature of the same. The ID should be created in a secure environment during production process of the maintenance system. The unique hardware id should be something visible to the outside world, so the server could actually verify, whether the ID received matches with the maintenance system communicating with the server.
This whole setup would give you a secure firmware update without a bootloader.
To have secure firmware updates, common understanding is, that you need a authentication system based on asymmetric encryption like RSA. If you need the verification code anyway, the above will exchange a bootloader capable of accepting updates with a simple UART interface, saving some resources in the process.
Is this something you were looking for?
A commercial bootloader in my experience uses between 4 and 8k of flash memory depending on flash algorithm and a couple of other things. I have been sticking with the same vendor throughout my carreer, so this might vary from your experience.
A digital signature system optimized for embedded systems uses approximately 4.5kByte in flash memory (for an example, see here: https://www.segger.com/emlib-emsecure.html ) and no more RAM than the stack.
You see, that 12k is really really low in terms of having a system which can be updated securely in the field. And even more so, if you want the system to be updated using a bootloader.
I`m currently developing a gwt application on a embedded device (linux with touchscreen) the server and client is started on the device.
I want my client to detect if it`s on the device or not. Because some screen are not available when connecting remotely
You can make a call to the server first and check there if it was made from remote or local address. A response from server should indicate if show screen "A" or not. Hope this helps.
Deferred binding might be the answer. GWT MobileWebApp sample app uses it to discern the form factor of the target in FormFactor.gwt.xml. In essence you define a property and write a provider which determines its value. You then read the property and deliver the appropriate View (in the MVP sense).
BTW I am developing an app for a similar scenario and I'm thinking of reimplementing my solution: reading a URL query parameter which is only present in the browser on the embedded device. Not too awesome. The aforementioned example should allow better hiding of the embedded platform identifier.