[ROM] [OFFICIAL] LineageOS 14.X for Oneplus2 | Android 7.X Nougat

[smasher007]

You linked the wrong one.. That's is for general qcom 8994.

Oneplus 2 is currently at 77% https://cve.lineageos.org/android_kernel_oneplus_msm8994

Ouch, that's scary!

 

[fuser1337]

You linked the wrong one.. That's is for general qcom 8994.

Oneplus 2 is currently at 77% https://cve.lineageos.org/android_kernel_oneplus_msm8994

Please read Ozzy's post. He said we have an issue with our phone's CVE tracker showing false results because the tool used to update it is broken so he cannot update it.

We have the same CVE completion as General qcom 8994.

 

[Seferi]

Krack is patched.

 

[Claudiu1]

Is there any chance to have hal3 enabled now that the ROM is stable enough? I remember ozzy said he would have worked on it in the future. Thanks in advance for the reply

 

[anupritaisno1]

please don't trust cve tracker. our cve state is always like kernel qcom_msm8994. i don't update oneplus2 because there is a tool should copy state from one kernel into another but it's broken. i wait for someone to fix.

No

You must go back and verify that each cve is applied

Why? Because you picked a 2 year old commit over a fairly recent kernel and carried over some really old code without even paying attention to what you're doing (I mean you literally did a cherry-pick instead of any code cleanup)

You really can't call your current kernel "secure". It's not secure at all the way you've applied those patches

 

[Ing Giuseppe Developer]

I have installed the last lineage rom for the first time on this phone. Setting profile audio to mute, when i receive a call or sms, the audio turn back on. Why?

 

[anupritaisno1]

Please read Ozzy's post. He said we have an issue with our phone's CVE tracker showing false results because the tool used to update it is broken so he cannot update it.

We have the same CVE completion as General qcom 8994.

This is how a manufacturer writes kernel code
#ifdef VENDOR_EDIT (if defined VENDOR_EDIT)
Modified code
else (-DVENDOR_EDIT not specified)
Original code
#endif

Now let's say CAF changed something in the original code, the modified code has to be modified too to match the change otherwise the compiler will not compile the patched stuff at all

What the maintainer did was just add the modified code back on top of a secure kernel. You want to call that secure? Nice. Just live with your false sense of security

 

[Ozzy2403]

This is how a manufacturer writes kernel code
#ifdef VENDOR_EDIT (if defined VENDOR_EDIT)
Modified code
else (-DVENDOR_EDIT not specified)
Original code
#endif

Now let's say CAF changed something in the original code, the modified code has to be modified too to match the change otherwise the compiler will not compile the patched stuff at all

What the maintainer did was just add the modified code back on top of a secure kernel. You want to call that secure? Nice. Just live with your false sense of security

you just don't know what i really did. maybe there are one or two cves got overwritten but most of the cves don't affect your device and can be send to trash. there are only a couple of cve that are really needed, rest is nice to have.

if you find any example you can tell me and i will fix. but searching for only one mismerge will be more pain than the security hole is worth.

 

[anupritaisno1]

you just don't know what i really did. maybe there are one or two cves got overwritten but most of the cves don't affect your device and can be send to trash. there are only a couple of cve that are really needed, rest is nice to have.

if you find any example you can tell me and i will fix. but searching for only one mismerge will be more pain than the security hole is worth.

And how could anyone give you an example? Nobody is going to sort 10,000 commits to find, say 20-30% of stuff that might be broken

But you can't go and mark every cve on the tracker as fixed either because there's a lot of stuff that might not be patched

This is just seriously way more messed up

And it's not just one commit, I've seen many of these over time

---------- Post added at 17:38 ---------- Previous post was at 17:34 ----------

"most CVEs do not apply for our device" @Ozzy2403 and how do you know which cve applies and which doesn't? Have you personally read the compile log of the kernel? I guess not

Maybe this is worth a read
https://forum.xda-developers.com/an...rence-how-to-upstream-android-kernel-t3626913

A lot of naysayers will say a lot of the patches from upstream are irrelevant to the architecture of most phones (arm/arm64) or are for drivers we don't have; while that may be true, there are several patches that are relevant and as Greg said in the above video, if you think you can sort through what is relevant, good luck. He later says not to try that in a talk he gave at Kernel Recipes 2017, stating "Changes to parts of the kernel that you do not build/run are fine and can cause no problems to your system. To try and filter out only the changes you run will cause a kernel tree that will be impossible to merge correctly with future upstream...". I personally don't think I am better than the professionals that push this stuff for free, thus I add it all. Greg's been sponsored by Google to do this for Google's kernel/common (3.18, 4.4, and 4.9). He's helping the Google Pixel kernel team upstream the kernel for Android O, as evident by the android-msm-marlin-3.18-o-preview-3 branch. Lastly, Greg committed to extending long term support (LTS) to SIX years from his normal two years for certain kernels that Android devices ship with. If this were a pointless process, why would Google and Greg even be investing time and energy into promoting adding upstream and changing their architecture and routine to support this?

Happy reading

 

[Ozzy2403]

And how could anyone give you an example? Nobody is going to sort 10,000 commits to find, say 20-30% of stuff that might be broken

But you can't go and mark every cve on the tracker as fixed either because there's a lot of stuff that might not be patched

This is just seriously way more messed up

And it's not just one commit, I've seen many of these over time

---------- Post added at 17:38 ---------- Previous post was at 17:34 ----------

"most CVEs do not apply for our device" @Ozzy2403 and how do you know which cve applies and which doesn't? Have you personally read the compile log of the kernel? I guess not

Maybe this is worth a read
https://forum.xda-developers.com/an...rence-how-to-upstream-android-kernel-t3626913


Happy reading

Maybe you don't know the difference between upstream and cve. All upstream patches are included Laos kernel. But what i won't merge are cve patches to drivers we don't use. It wouldn't make sense to apply cve for bmhdcd wireless driver because it will never be compiled for our device because we don't have this hardware. And i can say it is not compiled because i write the defconfig.
Maybe you need this because of a ****ed defconfig resulting in including drivers shouldn't be present.
This is the behaviour all Laos kernels and also these of reaponsible devs are maintained.

 

[anupritaisno1]

Maybe you don't know the difference between upstream and cve. All upstream patches are included Laos kernel. But what i won't merge are cve patches to drivers we don't use. It wouldn't make sense to apply cve for bmhdcd wireless driver because it will never be compiled for our device because we don't have this hardware. And i can say it is not compiled because i write the defconfig.
Maybe you need this because of a ****ed defconfig resulting in including drivers shouldn't be present.
This is the behaviour all Laos kernels and also these of reaponsible devs are maintained.

Okay bcm whatever broadcom WiFi driver
Alright we don't use that

What about the numerous patches the sound drivers had to be patched with? You're saying you remember ~60-70 patches from 2015?
Oh wait what about camera driver. You're telling me you picked commits from 2 years ago and it just works without any cve being reverted?
This is nitpicking but you aren't even following Google's kernel hardening docs

There is a lot of other stuff you can't just add without updating. Have you really checked your kernel?

---------- Post added at 17:53 ---------- Previous post was at 17:52 ----------

Just don't want to discuss this further
End of discussion

 

[Ozzy2403]

Okay bcm whatever broadcom WiFi driver
Alright we don't use that

What about the numerous patches the sound drivers had to be patched with? You're saying you remember ~60-70 patches from 2015?
Oh wait what about camera driver. You're telling me you picked commits from 2 years ago and it just works without any cve being reverted?
This is nitpicking but you aren't even following Google's kernel hardening docs

There is a lot of other stuff you can't just add without updating. Have you really checked your kernel?

---------- Post added at 17:53 ---------- Previous post was at 17:52 ----------

Just don't want to discuss this further
End of discussion

Saying you need to go trough 10.000 patches to see if a cve was edited tells me you don't know my kernel. You don't know the base and what is included.
Broadcom wifi is only one thing. There are several others...
And like i said maybe you find one reverted cve but that won't change anything. Only a couple of them are really "dangerous".

 

[aviraxp]

If you really have something good, contribute on gerrit. If not, shut up please.

 

[anupritaisno1]

If you really have something good, contribute on gerrit. If not, shut up please.

Not possible if the kernel is rebased every other day

 

[salanet]

Not possible if the kernel is rebased every other day

I agree with aviraxp. Again it is not fair you come on this thread to promote your rom and to complain on the thread topic. You should be moderated...

Inviato dal mio ONE A2003 utilizzando Tapatalk

 

[Ozzy2403]

Not possible if the kernel is rebased every other day

Well it was needed because i did something you maybe can't believe. I went through the old oneplus patches and review every single change in code. It needed some days and also maybe i missed something but i believe it was worth.

Other devs like boeffla always asked me if i'm finished before they rebase in my kernel. So if you would do i might hav
e told you to wait aome days. But now rebase is over for 14.1.

 

[Shreesha.Murthy]

Well it was needed because i did something you maybe can't believe. I went through the old oneplus patches and review every single change in code. It needed some days and also maybe i missed something but i believe it was worth.

Other devs like boeffla always asked me if i'm finished before they rebase in my kernel. So if you would do i might hav
e told you to wait aome days. But now rebase is over for 14.1.

You don't have to defend yourself for the rebase. You're the maintainer of OP2 and you have all right to do anything with the kernel. If someone is not happy with your work, they can simply do their thing.

ALSO, thread hijacking is not allowed in here. If someone is found promoting their "work" without the consent or approval of OP, it is considered hijacking.

If someone finds any flaw with the source, they have two options

1. Inform about it to the maintainer politely and ask him take care of it
2. Ignore and fix it yourself if you think the maintainer won't listen to you.

Just complaining about something and not contributing/suggesting fix is a douche bag move. What about users? They contribute by providing logs and clear cut info about the bug and its method of reproducing.

This is just trying to pick up fights which doesn't look good in front of entire OP2 community.

 

[nicesoni_ash]

If you really have something good, contribute on gerrit. If not, shut up please.

Not possible if the kernel is rebased every other day

Then shut up please, this is stretched way too long.

Sent from my "1+2" powered by Unofficial RR 7.x.x
Compiled by myself

 

[Valneo]

Well to contrast with all the drama going on lately :
Amazing weekly, great battery life especially in deepsleep (it used to drain a lot in my case), smooth UI except when in lockscreen notifications : when they are more than 10 notification it's sluggish but it's not a huge bug, just kernel optimisation I think. Snapchat also crash a lot but I'm pretty sure it's because of the VERY talented Snapchat developers hum hum
So yeah now 14.1 is now very stable so appart from some kernel optimisation to get that buttery smooth experience ! Work on 15.0 can begin/continue !
Thank you for all your hard work and dedication !

 

[neelsolanki]

@oozy2403 you are more than polite dude!! ?