James Bottomley

254 Followers
15 Following
213 Posts

Linux Kernel developer at Microsoft.

Technical blog at https://blog.hansenpartnership.com

IM via matrix @jejb:hansenpartnership.com

bloghttps://blog.hansenpartnership.com
githttps://git.kernel.org/pub/scm/linux/kernel/git/jejb/

CFP for LPC 2026 is open!

Important dates:
Thursday, April 23, 2026: Deadline to submit proposals to host a microconference
Sunday, June 28, 2026: Deadline to submit LPC Refereed Track Presentations Proposals and Kernel Summit Presentations Proposals.

Please use the following to access the full CFP and submit your proposal!

https://lpc.events/event/20/abstracts/

Linux Plumbers Conference 2026

The Linux Plumbers Conference (LPC) is a developer conference for the open source community. The LPC brings together the top developers working on the plumbing of Linux - kernel subsystems, core libraries, windowing systems, etc. - and gives them three days to work together on core design problems. The conference is divided into several working sessions focusing on different plumbing topics, as well as a general paper track.

Indico
As my account has been removed, it's now official: I am no longer a FOSDEM organiser.

This was my choice. I wish the organisation all the best for the future, and if time and money allow, might come again as a mere visitor, for the first time in 22 (!) years.

Talking about #TPM2 again at a new venue #scale23x

https://www.socallinuxexpo.org/scale/23x/presentations/enhancing-tpm-security-linux-kernel

I don't think they record but I promise to do a blog post really soon about how to use the exported null name to verify the #TPM in your booted OS is secure.

Enhancing TPM security in the Linux Kernel | SCALE

The Southern California Linux Expo (SCALE) is North America’s largest community-run open source conference.

And for completeness, here's a pointer to my #FOSDEM talk in the #kernel track taking a modern look at secure boot

https://fosdem.org/2026/schedule/event/XVLRTK-a_modern_look_at_secure_boot/

Apologies again, for taking too long with the explanations and running out of time to do the demo.

FOSDEM 2026 - A Modern Look at Secure Boot

My Main track talk at #FOSDEM has now published it's video:

https://fosdem.org/2026/schedule/event/9QVUEC-strategy_for_trusting_your_employer_in_open_source_a_historical_approach/

As ever, I really enjoyed my time at the conference and can't thank the organisers enough for allowing me to present somewhat controversial (but hopefully interesting) viewpoints that don't get traction at other conferences.

FOSDEM 2026 - Strategy for Trusting your Employer in Open Source: a Historical Approach

3. You will likely pop the main board connector (just below the battery terminal). You need to put this back before the phone will turn on
5. Hairdryers don't work. You need a focussed source of heat like a rework gun (although I did have some success with an air fryer).

Successfully replaced the battery in a pixel-3! I'd like to say it was easy, but it's not. This was also my second attempt. We had a pixel 3 that died and I never threw away, so I tried that first ... and broke the back glass getting it off. The second attempt was on my dev phone.

Things to know are:
1. Metal pry tools are necessary ... the plastic plectrums are only really useful as wedges
2. You can test the new battery without reconnecting the fingerprint sensor by turning on the phone.

Adding Two Factor Authentication to Android (LineageOS)

I really like the idea of using biometrics to add extra security, but have always hated the idea that simply touching the fingerprint sensor would unlock your entire phone, so in my version of LineageOS the touch to unlock feature is disabled but I still use second factor biometrics for the security of various apps. Effectively the android unlock policy is Fingerprint OR PIN/Pattern/Password and I simply want that OR to become an AND.

The problem

The idea of using two factor authentication (2FA) was pioneered by GrapheneOS but since I like the smallness of the Pixel 3 that’s not available to me (plus it only seems to work with pin and fingerprint and my preferred unlock is pattern). However, since I build my own LineageOS anyway (so I can sign and secure boot it) I thought I’d look into adding the feature … porting from GrapheneOS should be easy, right? In fact, when looking in the GrapheneOS code for frameworks/base, there are about nine commits adding the feature:

a7a19bf8fb98 add second factor to fingerprint unlock
5dd0e04f82cd add second factor UI
9cc17fd97296 add second factor to FingerprintService
c92a23473f3f add second factor to LockPattern classes
c504b05c933a add second factor to TrustManagerService
0aa7b9ec8408 add second factor to AdaptiveAuthService
62bbdf359687 add second factor to LockSettingsStateListener
7429cc13f971 add second factor to LockSettingsService
6e2d499a37a2 add second factor to DevicePolicyManagerService

And a diffstat of over 3,000 lines … which seems a bit much for changing an OR to an AND. Of course, the reason it’s so huge is because they didn’t change the OR, they implemented an entirely new bouncer (bouncer being the android term in the code for authorisation gateway) that did pin and fingerprint in addition to the other three bouncers doing pattern, pin and password. So not only would I have to port 3,000 lines of code, but if I want a bouncer doing fingerprint and pattern, I’d have to write it. I mean colour me lazy but that seems way too much work for such an apparently simple change.

Creating a new 2FA unlock

So is it actually easy? The rest of this post documents my quest to find out. Android code itself isn’t always easy to read: being Java it’s object oriented, but the curse of object orientation is that immediately after you’ve written the code, you realise you got the object model wrong and it needs to be refactored … then you realise the same thing after the first refactor and so on until you either go insane or give up. Even worse when many people write the code they all end up with slightly different views of what the object model should be. The result is what you see in Android today: model inconsistency and redundancy which get in the way when you try to understand the code flow simply by reading it. One stroke of luck was that there is actually only a single method all of the unlock types other than fingerprint go through KeyguardSecurityContainerController.showNextSecurityScreenOrFinish() with fingerprint unlocking going via a listener to the KeyguardUpdateMonitorCallback.onBiometricAuthenticated(). And, thanks to already disabling fingerprint only unlock, I know that if I simply stop triggering the latter event, it’s enough to disable fingerprint only unlock and all remaining authentication goes through the former callback. So to implement the required AND function, I just have to do this and check that a fingerprint authentication is also present in showNext.. (handily signalled by KeyguardUpdateMonitor.userUnlockedWithBiometric()). The latter being set fairly late in the sequence that does the onBiometricAuthenticated() callback (so I have to cut it off after this to prevent fingerprint only unlock). As part of the Android redundancy, there’s already a check for fingerprint unlock as its own segment of a big if/else statement in the showNext.. code; it’s probably a vestige from a different fingerprint unlock mechanism but I disabled it when the user enables 2FA just in case. There’s also an insanely complex set of listeners for updating the messages on the lockscreen to guide the user through unlocking, which I decided not to change (if you enable 2FA, you need to know how to use it). Finally, I diverted the code that would call the onBiometricAuthenticated() and instead routed it to onBiometricDetected() which triggers the LockScreen bouncer to pop up, so now you wake your phone, touch the fingerprint to the back, when authenticated, it pops up the bouncer and you enter your pin/pattern/password … neat (and simple)!

Well, not so fast. While the code above works perfectly if the lockscreen is listening for fingerprints, there are two cases where it doesn’t: if the phone is in lockdown or on first boot (because the Android way of not allowing fingerprint only authentication for those cases is not to listen for it). At this stage, my test phone is actually unusable because I can never supply the required fingerprint for 2FA unlocking. Fortunately a rooted adb can update the 2FA in the secure settings service: simply run sqlite3 on /data/system/locksettings.db and flip user_2fa from 1 to 0.

The fingerprint listener is started in KeyguardUpdateMonitor, but it has a fairly huge set of conditions in updateFingerprintListeningState() which is also overloaded by doing detection as well as authentication. In the end it’s not as difficult as it looks: shouldListenForFingerprint needs to be true and runDetect needs to be false. However, even then it doesn’t actually work (although debugging confirms it’s trying to start the fingerprint listening service); after a lot more debugging it turns out that the biometric server process, which runs fingerprint detection and authentication, also has a redundant check for whether the phone is encrypted or in lockdown and refuses to start if it is, which also now needs to return false for 2FA and bingo, it works in all circumstances.

Conclusion

The final diffstat for all of this is

5 files changed, 55 insertions(+), 3 deletions(-)

So I’d say that is way simpler than the GrapheneOS one. All that remains is to add a switch for the setting (under the fingerprint settings) in packages/apps/Settings and it’s done. If you’re brave enough to try this for yourself you can go to my github account and get both the frameworks and settings commits (if you don’t want fingerprint unlock disable when 2FA isn’t selected, you’ll have to remove the head commit in frameworks). I suppose I should also add I’ve up-ported all of my other security stuff and am now on Android-15 (LineageOS-22.2).

#2fa #android #lineageos #twoFactorUnlock

2-factor fingerprint unlock feature is now fully implemented - GrapheneOS Discussion Forum

GrapheneOS discussion forum

GrapheneOS Discussion Forum
Returning from @linuxplumbersconf via Zürich, in order to avoid Russian airspace we flew a directly polar route through the Bering Straits. So it went from sunny afternoon in Tokyo to Polar long night and now, coming back down over Greenland, we're chasing the last rays of sunset over Europe. All in all, quite spectacular (except the Aurora activity I was hoping for didn't materialise)

LPC 2025 is coming soon!

We have created LPC style slides template. Dear LPC speakers, please consider using them in your presentations.

For more details, please check out our latest blog post.

https://lpc.events/blog/current/index.php/2025/11/20/slides-templates-available/

Linux Plumbers Conference

The Linux Plumbers Conference (LPC) is a developer conference for the open source community. The LPC brings together the top developers working on the plumbing of Linux - kernel subsystems, core libraries, windowing systems, etc. - and gives them three days to work together on core design problems. The conference is divided into several working sessions focusing on different plumbing topics, as well as a general paper track.