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.
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.
I want to create a javacard applet which could not be installed more than once at the same time. It means if I instantiate applet once, It could not be possible to install another instance of that applet. However, if I delete the first instance, it should be possible to reinstall it.
If the package AID is always the same the installations should fail during the loading process automatically.
If the package and instance AIDs are using some pattern like an increasing last digit you could use JCSystem.lookupAID and try to iterate over the possible AIDs and fail if another instance is found.
If you are taking into account that the AIDs are flexible you are out of luck on standard smart cards, what you need then is a global kind of data unique for all applets. When using an UICC e.g you could create a file in the file system and if your applet is part of the MNO's security domain you can check this file for existence.
Maybe you also protect the installation process, e.g. by using a personalization process. After the installation a personalization server has to approve the applet. The applet could use some random token and if this is not known by the personalization server the applet will never unlock some features to make it useful. This approach should always work.
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
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.
I have 2 cardlets Java Card on the same smart card that I want to make communicate.
I could select an applet then send the corresponding APDU and then deselect it and select the other one and etc... I am wondering if it is possible to do it
more properly
with logical channels ? I mean with a method that could allow me to not select/deselect each applet for each APDU command ?
Thank you in advance :)
Yes it's possible.
You need a card that supports additional logical channels.In that case, you can select more than one applet simultaneously.(One applet per each channel) Fortunately current cards support some additional logical channels.
But remember that if you want to select (at least) two applets of a single package simultaneously, you must implement MultiSelectable interface in both applets (and also in all the other applets of that package).
If your applets are not from a single package, you don't need to implement this interface.
After that, you can open 2 logical channel using MANAGE CHANNELS command and select App1 in channel 0, and App2 in channel 1 (For example). For the next commands, you specify which channel (and therefore which applet) is the target of the incoming command using the low nibble in the CLA section of that APDU commands.
Note that SELECT APDU command is an alternative for MANAGE CHANNELS-Open command.(So you actually don't even need to use MANAGE CHANNELS command)
You should read more about: Applet Firewall, Sharable Objects and Inter-Applet Communication. These are standard Javacard features that are (also but not only) designed for this purpose.