Backport Intel Mutual Authentications - FCC Lock

[Atlas Yu]

[ Impact ]

There exist no formal API to do the FCC unlock procedure[1] in the latest version of the modemmanger.

But there is a merged commit[2] that provide this functionality for intel WWAN cards in the upstream project.

Lenovo have several laptops using the Fibocom WWAN cards (Intel XMM 7560), and Lenovo are struggling to give a decent way to run the FCC unlock service without this.

Until the device is unlocked, the end users are not able to use the SIM cards, and some of the affected devices have already been shipped. The end users now have to go to the Lenovo support website and download a few scripts and binaries to unlock the device to make their SIM cards work.

The Lenovo wants this patch to be included in jammy, then they can provide the FCC unlock service and manage it in OEM-archive, so the end users can use SIM cards as soon as they receive the laptop.

[ Test Plan ]

OEM enablement engineers and Lenovo engineers will help to test if the FCC unlock would work on certain laptops with the help of a custom package[1] provided by Lenovo which contains the FCC unlock script.

[ Where problems could occur ]

This is a completely new feature to support Intel WWAN cards mutal authentication, which does not affect other existing features.

But the feature itself might have bugs and glitches since it is a brand new one and is not widely tested by the laptop vendors, still it is better than nothing.

[ Other Info ]

[1] FCC unlock procedure: https://modemmanager.org/docs/modemmanager/fcc-unlock/
[2] intel-mutual-authentication: new service, fcc-lock: https://gitlab.freedesktop.org/mobile-broadband/libmbim/-/merge_requests/157
  - when the device is first shipped or comes out of the factory,
    it should be protected with a lock till the device reaches
    the end user. This FCC lock feature will ensure the device
    is secured till its unlocked.

[Atlas Yu (pseudoc)]

Here is the debdiff with the upstream patch.

[Ubuntu Foundations Team Bug Bot (crichton)]

The attachment "libmbim_1.28.0-1~ubuntu20.04.2.debdiff" seems to be a debdiff. The ubuntu-sponsors team has been subscribed to the bug report so that they can review and hopefully sponsor the debdiff. If the attachment isn't a patch, please remove the "patch" flag from the attachment, remove the "patch" tag, and if you are member of the ~ubuntu-sponsors, unsubscribe the team.

[This is an automated message performed by a Launchpad user owned by ~brian-murray, for any issue please contact him.]

[Atlas Yu (pseudoc)]

I uploaded the modified version to my PPA:
https://launchpad.net/~pseudoc/+archive/ubuntu/ppa/+packages

You may install the libmbim from it:
sudo add-apt-repository ppa:pseudoc/ppa
sudo apt update
sudo apt install libmbim

[Atlas Yu (pseudoc)]

refined debdiff (delete obsolete attachment)

[Sebastien Bacher (seb128)]

The fix is available in newer Ubuntu serie, SRU uploaded to J serie now

[Atlas Yu (pseudoc)]

Hi @seb128, this is not the same as Bug #1950282, this is for Fibocom L860-GL-16.

[Sebastien Bacher (seb128)]

Talking to Atlas he misunderstood that the 'fix released' status was applying to the current Ubuntu serie and not jammy which is targetted there. Changing back to fixed for the current version

[Sebastien Bacher (seb128)]

Sorry but apparently I was wrong there and misunderstood where the fix landed, it's not in the current version so we will need to also upload to mantic and lunar

[Lucas Kanashiro (lucaskanashiro)]

I added tasks for Jammy, Lunar and Mantic (devel). I also took a look at the debdiff and you could also close this bug in the changelog via "LP: #2014954". Moreover, you could improve the patch DEP-3 headers and add the Bug-Ubuntu field with a link to this bug.

[Atlas Yu (pseudoc)]

for lunar (delete obsolete attachment)

[Atlas Yu (pseudoc)]

for mantic (delete obsolete attachment)

[Atlas Yu (pseudoc)]

for jammy (delete obsolete attachment)

[Atlas Yu (pseudoc)]

Thanks Lucas and Seb, I re-uploaded the debdiff patch file for theses 3 series.

[Łukasz Zemczak (sil2100)]

An upload of libmbim to jammy-proposed has been rejected from the upload queue for the following reason: "Bug provides a newer SRU debdiff for this upload.".

[Christian Ehrhardt  (paelzer)]

This in your changelog is a Debian keyword
  Closes: #2014954
To work on launchpad that needs to be
  LP: #2014954

I hope that helps and gives you a few minor things to fix.

I feel too much out of my comfort zone to fully sponsor this anyway :-/
But I wondered about one more thing to ask you, given that you say this is "the feature itself might have bugs and glitches since it is a brand new one and is not widely tested by the laptop vendors" wouldn't you think it might be better to wait until upstream https://gitlab.freedesktop.org/mobile-broadband/libmbim/-/tags tags 1.30 - then at least we'd have the testing of the developers there and all the code they tested it with.

[Sebastien Bacher (seb128)]

@Lukasz, could you reconsider the rejection? The version which was in the 22.04 queue was correct, it's basically me who fixed the wrong bug reference to use a lp: syntax

[Atlas Yu (pseudoc)]

Hi @Christian, thanks for the comment, I thought "Closes" and "LP" are the same thing.
The Lenovo wants to ship their new laptop products with "Fibocom L860-GL" (uses MBIM protocol) and needs this patch to do the FCC unlock. Their aim is that the SIM card can work properly once end user receives the device.

[Atlas Yu (pseudoc)]

mantic: replace "Closes => LP"

[Atlas Yu (pseudoc)]

lunar: replace "Closes => LP"

[Atlas Yu (pseudoc)]

jammy: replace "Closes => LP"

[Paride Legovini (paride)]

Hi, I have some comments/questions.

## debdiffs

- The d/changelog entries target unstable and not Ubuntu releases
- The lunar version string is wrong, the suffix should be ubuntu0.1.
- The d/changelog entry is not clear.
  For example: it begins with "This service". Which service?
- Nit: when adding new patches it is nice to mention it in d/changelog:

 * d/p/intel-mutual-authentication.patch:
   upstream cherry-pick to enable the XYZ feature

## dep-3 headers

"Origin": please specify if "upstream" or "backport", see [1]. It may be "upstream" for some Ubuntu releases and "backport" for others, if the patch had to be modified to apply cleanly.

Also: normally the link is to the individual cherry-picked commit, not to the PR/MR.

"Applied-Upstream": not needed in this case I believe. AIUI that's for when the patch originates from Ubuntu/Debian and then has been applied upstream. In this case it's the other way around.

"Reviewed-by": that's specific to the Ubuntu patch, do not put upstream contributions there: they are not involved with the Ubuntu packaging.

## general questions

It is not clear to me (and may not be clear to the SRU team) what the actual impact of this issue. Is the hardware unusable without this feature? In other words: please improve the [Impact] section. Which issue will users encounter because of this bug? (What does it mean that the device is "secured" until unlocked?)

Like Christian mentioned, it would be better to wait for 1.30 to be tagged by upstream before going ahead with the backporting. Would the libmbim release schedule align with the hardware release dates?

[1] https://dep-team.pages.debian.net/deps/dep3/

[Atlas Yu (pseudoc)]

Thanks you Paride for the comment with the detailed explanation. I will check the urgency of this bug later on.

By the time I proposed this bug, the WWAN card is totally unusable, but by far Lenovo have provide a workaround: https://pcsupport.lenovo.com/jp/en/products/laptops-and-netbooks/thinkpad-x-series-laptops/thinkpad-x1-yoga-7th-gen-type-21cd-21ce/21cd/downloads/driver-list/component?name=Networking%3A%20Wireless%20WAN&id=49B19606-BEF8-41DD-BE7F-95B570C212C8

So, to me, I think it is actually okay to wait for 1.30.

[Dave Jones (waveform)]

Unsubscribing ~ubuntu-sponsors; please re-subscribe once Paride's comments (from 21) are addressed. I'm not setting to incomplete as it appears a decision is pending regarding waiting for the 1.30 release and I'm not sure what the schedule on that is.

[Nitin Joshi (nitin-joshi)]

Hello All ,

May I know , if there is update of backporting this changes in Ubuntu 22.04 ?
As per above comment , it will be helpful if you can update in which Ubuntu version 1.30 will be released ?

Thank you !

Thanks & Regards,
Nitin Joshi

[Atlas Yu (pseudoc)]

Hi Nitin,

Our next LTS release 24.04[1] will be based on debian's trixie/sid[2], and this patch is contained since 1.29.1[3]. The libmbim packages in trixie/sid is based on the upstream tag 1.30.0[4]. So, I suppose it would be available in our next LTS release (Ubuntu 24.04).

Reference:
1. base-files/os_release:
https://git.launchpad.net/ubuntu/+source/base-files/tree/etc/os-release?h=applied/ubuntu/noble
2. base-files/debian_version:
https://git.launchpad.net/ubuntu/+source/base-files/tree/etc/debian_version?h=applied/ubuntu/noble
3. the related git commit:
https://gitlab.freedesktop.org/mobile-broadband/libmbim/-/commit/910db9cb2b6fde303d3b4720890cf6dc6fc00880
4. libmbin versions in debian:
https://packages.debian.org/search?suite=all&searchon=names&keywords=libmbim

[Nitin Joshi (nitin-joshi)]

Hello Atlas,

Thank you for your comment.
Yes, i can understand that Ubuntu 24.04 will have this changes but i think Ubuntu 22.04 LTS end of life is till 2027.
May I know, if there is any concern backporting this changes in Ubuntu 22.04 LTS ?
Regarding this feature - We are currently using AT mechanism and its working fine. If this patch is backported then we can use MBIM mechanism and since mbim mechanism is safer . So , Intel has suggested us earlier to use it.
As of now , i haven't receive any issue like AT port occupied issue etc with AT mechanism but just to be cautious, we had requested it long back.

Thank you !!

[Atlas Yu (pseudoc)]

Nitin and I have an agreement to not backport this patch on jammy after a discussion on an email thread, since the current AT command solution could work and switching to libmbim way would take a lot of effort.

[Brian Murray (brian-murray)]

Ubuntu 23.04 (Lunar Lobster) has reached end of life, so this bug will not be fixed for that specific release.