GrapheneOS
Removable eUICC Confuses GrapheneOS eSIM Support
The sysmoEUICC1-C2G confuses GrapheneOS's eSIM support; specifically, it seems to take the place of the internal eUICC as far as GrapheneOS's management tooling goes.
On this Pixel 8 Pro, the internal eSIM was provisioned first with the GrapheneOS LPA, then the sysmoEUICC1 was inserted and provisioned with EasyEUICC. With the sysmoEUICC1 inserted, GrapheneOS only displays the eID of the inserted eUICC (manufactured by Kigen, as the beginning of the eID shows; Google uses another vendor).
The physical SIM slot should not override the internal part, and both should probably be surfaced for management separately if a removable eUICC is inserted.
Screenshot is from GrapheneOS 2025100301.
cc @laf0rge
The line provisioned in the internal eUICC does not display an eID in Settings - SIMs - (SIM name).
The line provisioned in the removable eUICC does display the eID in the same place.
Replacing the Pixel LPA with OpenEUICC, which explicitly supports multiple eUICCs, might resolve this issue.
I agree that multiple eUICCs is a valid scenario, whether or not any of them are removable. The Android APIs around UICC access support this, and the OpenEUICC (aka EasyEUICC) LPA supports this. I cannot comment on the Pixel LPA, as I've never used it.
Replacing the Pixel LPA with OpenEUICC, which explicitly supports multiple eUICCs, might resolve this issue.
@no-usernames-left OpenEUICC is licensed under the GPLv3 and thus can't be used in GrapheneOS https://grapheneos.org/faq#:~:text=In%20some%20cases%2C%20licensing,in%20locked%20down%20devices
OpenEUICC also heavily uses memory unsafe languages and isn't appropriate for inclusion in GrapheneOS for that reason too. We don't want an approach that's much less secure than Google's one.
I'm not sure about this, as far as I can see, it's mostly Java/Kotlin, at least in the main repo.
@andromxda It's based on https://github.com/estkme-group/lpac which is fully written in C.
OpenEUICC also heavily uses memory unsafe languages and isn't appropriate for inclusion in GrapheneOS for that reason too. We don't want an approach that's much less secure than Google's one.
If compile lpac to WebAssembly (use Emscripten) and using a pure Java-based WebAssembly runtime meet the memory safe requirements of GrapheneOS?
OpenEUICC also heavily uses memory unsafe languages and isn't appropriate for inclusion in GrapheneOS for that reason too. We don't want an approach that's much less secure than Google's one.
If compile lpac to WebAssembly (use Emscripten) and using a pure Java-based WebAssembly runtime meet the memory safe requirements of GrapheneOS?
If Java is acceptable, you could also consider using https://github.com/Truphone/LPAd_SM-DPPlus_Connector as a basis. This is native java code and is what tey used by the UI https://github.com/Truphone/LPAdesktop
Getting back to the original issue and considering less drastic options than a complete replacmenet of the LPA: Where can the LPA sourec code of grapheneOS be found? Any related bugs or shortcomings should ideally be fixed there, instead of replacing it with something completely else.
If compile lpac to WebAssembly (use Emscripten) and using a pure Java-based WebAssembly runtime meet the memory safe requirements of GrapheneOS?
WebAssembly doesn't make the code running inside of it memory safe. Code execution can be gained through memory corruption bugs in the memory unsafe code regardless of whether it's native code execution on the CPU. WebAssembly also weakens exploit protections substantially compared to actual native code on GrapheneOS. It's only useful for running the code in a strict sandbox which would not be the case for this.
If Java is acceptable
Java/Kotlin is what this should be written in since there's little reason for any of it to be written in Rust and the FFI from the application layer would only complicated things. It doesn't make that a high enough quality or complete enough implementation to use it.
Getting back to the original issue and considering less drastic options than a complete replacmenet of the LPA: Where can the LPA sourec code of grapheneOS be found? Any related bugs or shortcomings should ideally be fixed there, instead of replacing it with something completely else.
On Pixels, we use the Pixel one. On a Qualcomm device, it's likely part of what we would get from them. It's part of the per-device hardware support layer rather than part of the portable GrapheneOS code. We would like to have an open source app we could include in the portable portion of GrapheneOS but there isn't one we can use right now. Any code for inclusion in the device independent GrapheneOS code needs to be open source. The firmware and userspace code for supporting the hardware which comes from the hardware contains proprietary parts in practice. In the long term we want to avoid those but in the short term it's completely acceptable and not a big deal, especially considering we can easily read the code for any of it that's written in Java like this rather than investing time understanding assembly code or reversing it to a form of C via advanced tools.
I think, Infineon LPA able to meet the requirements.
The is mirror repo, https://github.com/CursedHardware/infineon-lpa-mirror
Orignal Publish link: https://softwaretools.infineon.com/tools/com.ifx.tb.tool.infineonandroidlpa
Latest Version 4.2.0 not provide direct download, may be needs NDA or license
It is recommended to maintain the system based on version 4.1.0; unmodified versions will not be usable.
Reference queally branch codebase is good first starts, CC @BeRealQueally