LineageOS, Current status : 16.0 Test Builds

[Polaris 423]

16 minutes ago, silversolver said:

Personally I'm not worried about band 66 unless VaZeline is planning to turn off 4, and if not, that additional 25MHz is unlikely to mean much to you, as you've indicated that EVDO is enough to meet your needs. Is supporting it something that could be deployed later through an update, or is the radio incapable of using that frequency? Also, was the Droid 4 never available on GSM networks like Always Toil and Trouble/Trouble Mobile? 😮 I thought it was, but might have been wrong. I guess I could have moved to Canada.......fortunately, Pro1 saved me the trouble. 🙂

They couldn't ever turn off 4 because 66 encompasses all of 4 plus the extra 25 Mhz, so all good there.  However, a Verizon engineer (from my local NOC) told me that in AWS reliant areas (like mine) it's only a matter of time before they heavily populate with 66 sites.

It won't mean much to me (or any of us) this year, but ONLY because CDMA is still working.  However, there is no denying we are on the clock.  If everything holds, by Jan 2021 that'll be the end of it!

Good question about it possibly being enabled via a firmware update.  I don't know the answer to that as I'm not familiar with which radio is in the phone (yet another reason to open it up upon receipt, lol).  There are older phones which aren't capable of 66 and never will be, I hope this isn't the case here.

AFAIK the Droid 4 was NEVER able to be used on any US GSM networks, period.  It uses an MDM6600 chipset and was neutered to lockout full ranges of US assigned MCC & MNC combinations.

Edited December 2, 2019 by Polaris

[tdm 2,322]

Quick update:

 

I found the issue with vbmeta. Unfortunately, it looks like fixing it will take another day or two.

 

I'm going to go ahead and (try to) switch lineage to FBE for the next build so that we can ditch FDE without looking back.

 

I also started work on plumbing in make shift mac addrs for WiFi and BT. Neither fxtec nor the OEM seem to have valid OUI blocks assigned so I'm going to steal an unassigned block.

 

Finally, I am in the process of building a full factory package. Once that is complete, we can have a discussion about custom partitioning.

[Polaris 423]

1 minute ago, tdm said:

Quick update:

 

I found the issue with vbmeta. Unfortunately, it looks like fixing it will take another day or two.

 

I'm going to go ahead and (try to) switch lineage to FBE for the next build so that we can ditch FDE without looking back.

 

I also started work on plumbing in make shift mac addrs for WiFi and BT. Neither fxtec nor the OEM seem to have valid OUI blocks assigned so I'm going to steal an unassigned block.

 

Finally, I am in the process of building a full factory package. Once that is complete, we can have a discussion about custom partitioning.

You are THE man!  Thank you so much for all your hard work!  From personal experience, I know how much time and effort is involved tackling something this complex.

[tdm 2,322]

Oh, the one issue with switching to FBE is TWRP. If stock uses FDE and custom ROMs use FBE, there may be a need to hack something up to support both.

And speaking of TWRP, if a good version doesn't appear by the time I've got a reasonably stable lineage build, I'll do that also. Which kind of sounds strange, as I'm the lineage recovery maintainer... 😛

 

[Polaris 423]

1 minute ago, tdm said:

Oh, the one issue with switching to FBE is TWRP. If stock uses FDE and custom ROMs use FBE, there may be a need to hack something up to support both.

I had been wondering about this, and if it was going to pose a problem.  Thanks again for everything, your plate certainly is full.

[david 929]

1 hour ago, tdm said:

I'm going to go ahead and (try to) switch lineage to FBE for the next build so that we can ditch FDE without looking back.

I am curious what you see as the main benefits of using file based encryption instead of full disk encryption?  And any idea why fxtec went with FDE?

[tdm 2,322]

1 hour ago, david said:

I am curious what you see as the main benefits of using file based encryption instead of full disk encryption?  And any idea why fxtec went with FDE?

I'm not familiar with all the pros and cons. But I do know that you get partial functionality with FBE at boot, and the boot process is not interrupted half way through with a PIN entry screen.

 

Given what I know about the development of the device, it's probably FDE because that is the BSP default and nobody took note and told the OEM to switch. But that's just my guess.

 

[SteffenWi 139]

9 hours ago, tdm said:

I also started work on plumbing in make shift mac addrs for WiFi and BT.

Why not just use the addresses provided by the hardware? Even if they aren't part of an assigned block, they should still be unique amongst all the Pro1 devices?

 

@Polaris I would have totally understood (and apologized) if you would have been offended by the way I wrote the first version of that post - that is my point. Yes some people have a thicker skin, others don't. If one aims to word their thoughts so that non-thick-skinned-people are comfortable reading it, everyone benefits. That is my point.

 

As for FBS vs. FDE here are some interesting reads on the topic:

• From 2016: What are the diffs of FBE and FDE and why do both suck on Android, just in different ways when compared to iOS/iPhone encryption? https://blog.cryptographyengineering.com/2016/11/24/android-n-encryption/
• From 2018: Ways to break into an encrypted device depending on vendor and encryption method. https://blog.elcomsoft.com/2018/05/demystifying-android-physical-acquisition/
• In that article there is a linked PDF that describes FDE and FBE and how susceptible FBE is to some FDE attack vectors. Also towards the end there are some recommendations regarding security of smartphones (re-locking the bootloader once you are done with changing your system, using a restrictive bootloader to make it harder on attacker to get into the system etc.). If someone knows of a more recent study on this please post it. https://www.delaat.net/rp/2016-2017/p45/report.pdf

From reading through all of this, I'm gathering that FBE is more secure in terms of preventing someone from copying data from the device, if it is properly implemented. In the PDF it is mentioned that ext4 (a linux filesystem) is used in case of FBE and that ext4's own encryption method is used but that there are a bunch of TODOs in the source code. Since the study was done several kernel versions ago, I would imagine that most if not all of those are done by now. What kernel version does LineageOS use?

Edited December 3, 2019 by SteffenWi

[Gigadoc2 54]

2 hours ago, SteffenWi said:

From reading through all of this, I'm gathering that FBE is more secure in terms of preventing someone from copying data from the device, if it is properly implemented.

From reading through the articles I got the impression that FBE would be more secure if Android were to evict some of the keys on device lock, which it currently does not. So, right now the advantage of FBE would only be that the phone can boot up some services before the passphrase input?

I wonder, if Android ever introduces the "lock on device lock" FBE category, whether App developers would actually make use of it. Also, I suspect that App developers can choose files to be "device encrypted", in which case FDE may be indirectly more secure than FBE as it will encrypt all user data with a passphrase-derived key as only those selected by the App developers. Maybe my experience with x86 Linux software is clouding my judgement here, but I'd expect most developers to opt for the least secure option by default, as it is usually the easiest ("sure, we could save your credentials in the secrets service, but then we would have to talk dbus and not be portable anymore, so let's just write it out to some file in $HOME").

2 hours ago, SteffenWi said:

In the PDF it is mentioned that ext4 (a linux filesystem) is used in case of FBE and that ext4's own encryption method is used but that there are a bunch of TODOs in the source code. Since the study was done several kernel versions ago, I would imagine that most if not all of those are done by now. What kernel version does LineageOS use?

I think the kernel version is not really chosen by LineageOS, but dependent on the chipset manufacturer, as it has to be compatible with their closed source drivers.

Those kernel versions tend to be very old, I have a Galaxy A5 2017 here with a 3.18.14 kernel; in 2017 upstream was already somewhere past 4.9...

But for LineageOS for the pro1, we can look up what tdm has in his repository, and it looks like 4.4.153: https://github.com/tdm/android_kernel_idealte_msm8998/blob/lineage-16.0/Makefile

Edited December 3, 2019 by Gigadoc2
typed "ever" twice by accident

[tdm 2,322]

3 hours ago, SteffenWi said:

Why not just use the addresses provided by the hardware? Even if they aren't part of an assigned block, they should still be unique amongst all the Pro1 devices?

Because there are none.

3 hours ago, SteffenWi said:

What kernel version does LineageOS use?

All Qualcomm devices use the kernel that Qualcomm provides in their BSP for the device.  In this case, Qualcomm provides kernel 4.4.x for msm8998 on Android 9.  I haven't looked at the BSP for Android 10 yet, but I suspect it is probably 4.9.x.

 

It is possible for third parties like Lineage to update to a newer kernel version.  However, given the extensive changes to the kernel sources by Qualcomm, this is a rather huge task and is very rarely done.

 

[tdm 2,322]

1 hour ago, Gigadoc2 said:

I think the kernel version is not really chosen by LineageOS, but dependent on the chipset manufacturer, as it has to be compatible with their closed source drivers.

Those kernel versions tend to be very old, I have a Galaxy A5 2017 here with a 3.18.14 kernel; in 2017 upstream was already somewhere past 4.9...

But for LineageOS for the pro1, we can look up what tdm has in his repository, and it looks like 4.4.153: https://github.com/tdm/android_kernel_idealte_msm8998/blob/lineage-16.0/Makefile

 

Yes, as I just noted, Qualcomm chooses the base kernel for its BSP on each platform.  There are no closed source drivers in the kernel (but literally many hundreds of closed source user space binaries!)  The reason that updating kernel versions is so difficult is simply the extensive source code changes done by Qualcomm.  I tried updating kernel versions for a device about 6 years ago.  It did not go well.  I have not tried since.

 

EDIT: And as for your concern about app developers and secure storage, my understanding is that encrypted storage is default and you must take action to use unencrypted storage.  But I have not developed apps in quite some time, so I don't know the exact details off the top of my head.

 

Edited December 3, 2019 by tdm

[SteffenWi 139]

1 hour ago, tdm said:

Because there are none.

Wait what? How does that even work? From my limited understanding a network device has to provide a MAC address - even if it isn't a 'real' one. Is that again one of those 'ARM is a broken platform' things?

 

1 hour ago, tdm said:

All Qualcomm devices use the kernel that Qualcomm provides

So, if Qualcomm decides to put a keylogger somewhere in their version of the kernel it would take ages before anyone found that due to all their changes? Wow...that seems really bad.

 

As for closed-source userspace binaries: That shouldn't prevent a kernel upgrade as the ABI towards the userspace is rarely changed and even if, it never breaks any prior stuff. That is a base rule of the kernel: Never break userspace. So the only issue is all those changes Qualcomm made.

 

Is it possible for a non-Android developer to get a hand of the Qualcomm kernel source? That thing still falls under the GPLv3, right?

 

[_DW_ 628]

7 minutes ago, SteffenWi said:

Wait what? How does that even work? From my limited understanding a network device has to provide a MAC address - even if it isn't a 'real' one. Is that again one of those 'ARM is a broken platform' things?

 

It has to exist for the network stack to work but doesn't mean it's unique to the device, could be all zero's for instance

[SteffenWi 139]

12 minutes ago, _DW_ said:

It has to exist for the network stack to work but doesn't mean it's unique to the device, could be all zero's for instance

correct, but that would still mean that there is an address. That is different from nothing at all being returned. Maybe that is what tdm meant though. ANd at least in my case the MAC address that was visible in stock Androids settings looked made up, but wasn't something like 11:11:11:11:11:11. Unless stock Android generated a MAC.

Edited December 3, 2019 by SteffenWi

[VaZso 1,998]

16 minutes ago, SteffenWi said:

Wait what? How does that even work? From my limited understanding a network device has to provide a MAC address - even if it isn't a 'real' one. Is that again one of those 'ARM is a broken platform' things?

I don't know how does it working here but for the LAN interface of STM32, I have to provide an appropriate MAC address (there are no own address built-in). I am currently using a pre-written EEPROM for this purpose (because I only need a few addresses) and another one generated in appropriate range as a fallback (if EEPROM was not soldered to board).

Basically, these addresses are sold by ranges and, in theory, they have to be unique.

So one option to buy an own range and use that for this purpose (expensive), other option is to buy it from someone (like I did with that EEPROM) and another one is to generate a locally administrated one based on one of the device identifiers.

[_DW_ 628]

19 minutes ago, VaZso said:

I don't know how does it working here but for the LAN interface of STM32, I have to provide an appropriate MAC address (there are no own address built-in). I am currently using a pre-written EEPROM for this purpose (because I only need a few addresses) and another one generated in appropriate range as a fallback (if EEPROM was not soldered to board).

Basically, these addresses are sold by ranges and, in theory, they have to be unique.

So one option to buy an own range and use that for this purpose (expensive), other option is to buy it from someone (like I did with that EEPROM) and another one is to generate a locally administrated one based on one of the device identifiers.

I guess with SOC they have to pass the buck (Each chip is identical) and it's the OEM that has to provide the unique MAC address via the system rom or something.  I am quite sure @tdm knows a lot more than me never delve into embedded devices.

[VaZso 1,998]

23 minutes ago, _DW_ said:

I guess with SOC they have to pass the buck (Each chip is identical) and it's the OEM that has to provide the unique MAC address via the system rom or something.  I am quite sure @tdm knows a lot more than me never delve into embedded devices.

Just like in STM32. However, there may be an unique identifier of the device itself, that is not uncommon (this is up to the manufacturer and not related to anything else).

MAC is another thing as it is universally unique among manufacturers, so it is not as simple (see my comment above).

[Polaris 423]

6 hours ago, SteffenWi said:

 

@Polaris I would have totally understood (and apologized) if you would have been offended by the way I wrote the first version of that post - that is my point. Yes some people have a thicker skin, others don't. If one aims to word their thoughts so that non-thick-skinned-people are comfortable reading it, everyone benefits. That is my point.

 

Right, point taken, and my point was that if one aims to also not be so thin skinned then everyone benefits.  Again, these aren't mutually exclusive points.  However, I think it's time to shelf this and get onto the LOS goodies! 👍

[Polaris 423]

3 hours ago, tdm said:

It is possible for third parties like Lineage to update to a newer kernel version.  However, given the extensive changes to the kernel sources by Qualcomm, this is a rather huge task and is very rarely done.

Right, and with so much yet to be done, this is not something that, at this point, should be given any priority.

[tdm 2,322]

2 hours ago, SteffenWi said:

Wait what? How does that even work? From my limited understanding a network device has to provide a MAC address - even if it isn't a 'real' one. Is that again one of those 'ARM is a broken platform' things?

 

The MAC addrs are read from different places depending on the wlan chipset (the wlan chip is not part of the soc proper).  The qcom wlan chip which is in the pro1 by default reads its MAC addrs from /persist/wlan_mac.bin.  You should have a copy of that file and it should match the MAC addr that you see in your system settings.  But the BSP spits out a default wlan_mac.bin with bogus addrs by default.  The OEM is responsible for changing this file at factory programming time.  Nobody bothered to do this on the pro1.  It is a similar story for BT.

 

Also of note, nearly every OEM has their own unique and different way of reading the wlan MAC addrs.  Nobody actually uses /persist/wlan_mac.bin because that would be too simple and logical.  😄  For example, OnePlus uses an NVRAM item.  ZTE used /persist/wifimac.dat on the axon7.  And so on.

 

Quote

 

So, if Qualcomm decides to put a keylogger somewhere in their version of the kernel it would take ages before anyone found that due to all their changes? Wow...that seems really bad.

 

While theoretically possible, it won't happen.  Qcom has too much invested to do this themselves.  And keep in mind that Google ships phones with Qcom chips and would surely detect something like this, even if nobody else did.

 

Not to feed the tinfoil hat crowd, but it would be much more covert to place spyware in the modem side of things which is entirely closed source.  Either in the modem code proper or the user space blobs that drive it.  There are several hundreds of megabytes of closed source user space blobs in modern platforms which have direct access to things like the modem, trustzone, etc.

 

Quote

 

As for closed-source userspace binaries: That shouldn't prevent a kernel upgrade as the ABI towards the userspace is rarely changed and even if, it never breaks any prior stuff. That is a base rule of the kernel: Never break userspace. So the only issue is all those changes Qualcomm made.

 

That is a nice thought.  Unfortunately, it is not true once the kernel leaves kernel.org.  Qcom breaks their own kernel-user ABI with nearly every release.  But that isn't really relevant to upgrading the kernel version.  You pull in the relevant qcom and oem bits on top of the new kernel version so that whatever ABI existed in the OEM kernel also exists in the new kernel.  The problem is making the qcom bits build and run with the new kernel version.

 

EDIT: I may have misread what you meant.  Yes, the core kernel ABI does stay the same so that the basic syscalls will still work with the new kernel version.  So in that sense you are correct.  The real fun comes in taking the closed-source userspace binaries and making them run on a newer Android version, which is something that Lineage does regularly with older devices.  Google has, on many occasions, broken their ABIs for things like libstdc++ and other common utility libraries.  The Lineage folks then need to figure out how to make the closed source binaries work again, or steal updated binaries from devices that have been updated to the new Android version.

 

Quote

 

Is it possible for a non-Android developer to get a hand of the Qualcomm kernel source? That thing still falls under the GPLv3, right?

 

 

Yes, Qcom releases kernel sources.  GPLv2, of course, not GPLv3.  The pro1 uses this tree:

 

https://source.codeaurora.org/quic/la/kernel/msm-4.4/

 

idealte made remarkably few changes compared to other OEMs that I've seen.  Just the stuff required for the device to run, really.

 

Edited December 3, 2019 by tdm

[tdm 2,322]

A bit of news on MAC addrs.  The OEM writes /persist/wlan_mac.bin on boot using the binary /vendor/bin/macplugin.  They checked this binary into their device tree without any source, so I don't know the exact algorithm.  i'm in the process of reverse engineering it.  It seems to generate 02:aa:xx:xx:xx:xx where "xx" is random.  The kernel driver picks this up and strips the private bit so you get 00:aa:xx:xx:xx:xx.  So there you go -- each device gets a unique, random, bogus MAC address.  😄

 

I'll investigate BT at some point soon.  I would not be surprised if that got skipped entirely.

 

[Polaris 423]

1 hour ago, tdm said:

So there you go -- each device gets a unique, random, bogus MAC address.  😄

My wife uses an Android (I think Nougat) tablet for her work and it does the same thing with the WiFi adapter address.  Completely crazy as it gets a different address every time it boots.  I have our home LAN setup with a MAC white list (no this isn't the only security, lol, and I know it doesn't do much for someone in the know) so it was a pain in the butt as I had to make sure it had the same MAC every time to authenticate.  These kinds of things can make a sane person crazy, lol.

[VaZso 1,998]

1 minute ago, Polaris said:

My wife uses an Android (I think Nougat) tablet for her work and it does the same thing with the WiFi adapter address.  Completely crazy as it gets a different address every time it boots.  I have our home LAN setup with a MAC white list (no this isn't the only security, lol, and I know it doesn't do much for someone in the know) so it was a pain in the butt as I had to make sure it had the same MAC every time to authenticate.  These kinds of things can make a sane person crazy, lol.

Ouch.

That case the DHCP pool table of your router can be a bit long if you reboot your phone very often. 🙂
However, that solution of generating MAC address is really crazy.

[tdm 2,322]

6 minutes ago, Polaris said:

My wife uses an Android (I think Nougat) tablet for her work and it does the same thing with the WiFi adapter address.  Completely crazy as it gets a different address every time it boots.  I have our home LAN setup with a MAC white list (no this isn't the only security, lol, and I know it doesn't do much for someone in the know) so it was a pain in the butt as I had to make sure it had the same MAC every time to authenticate.  These kinds of things can make a sane person crazy, lol.

The Pro1 WiFi mac should be persistent and (fairly) unique, so long as you don't nuke that file. But it's definitely bogus.

 

[tdm 2,322]

Got some help with vbmeta so that should be solved for now. I still want to build and install the vendor partition for lineage but that's no longer top priority.

 

Last thing before test2 is switching to FBE, if I can manage that tomorrow.