[OnePlus 3 & 3T Cross Device Development] anupritaisno1:
A few changes also did occur at glassrom:

Files on the server now use fs verity. This should prevent accidental file corruption on the server side

Glassrom now has a public DNS server. DOT is at dns.glassrom.pw and DOH is at https://dns.glassrom.pw

Use standard DNS? Put 217.61.104.90 as your ipv4 dns

Dnscrypt and Android private dns support are on the way, we also have a paid DNS over wireguard/adblocking option

Glassrom has moved away from cloudflare authoritative DNS. We now use 1984 dns as our authoritative dns resolver. I did initially consider hosting my own but soon realised how stupid the idea was especially if the server went down and now users saw a "no such domain exists" error

As part of a new rule glassrom will recommend but not require maintainers to disable apex packages on Q

Glassrom on Q uses automatic stack initialization using a pattern. All devices with a kernel newer than or at least 4.14 can enable this feature for the kernel too

Explanation:

#include <stdio.h>
int main(int argc, char *argv[]) {
(void) argc;
(void) argv;
int a;
printf("%d", a);
}

You can compile and run this program with:

clang filename.c

Execute it as such:

./a.out

A random value will be printed out every time

If you're somewhat technically oriented you might have seen a few textbooks using the term "garbage value" but it's important to understand a little here

The "garbage value" is actually memory that was used by another program and freed after it exited. In some cases it could disclose sensitive data and in some cases an attacker can control this data to change the behaviour of your program

Now pass this to clang:

clang -ftrivial-auto-var-init=pattern filename.c

Now for some reason the value returned is a constant instead of a random value

This is because clang automatically initialises the stack to 0xAAAAAA.... which when read by the program becomes the constant you see

Automatic variable initialization can only protect programs that were compiled with it. In other words the system is protected but individual programs are not

Can we protect programs though?

Yes. First one is hardening the memory allocator which grapheneos does the second is this:

On archlinux or gentoo install the linux-hardened package

Make sure page poisoning and slub debugging are off or set slub_debug=F

Check your dmesg after booting the kernel

dmesg | grep -i "byref"

Stack initialization should say byref_all, init_on_alloc and init_on_free must be enabled

Run the program and it will always return 0

This means the kernel can be patched to protect every program, not just the system

Currently protecting anything other than the system is not implemented on glassrom Q. Newer devices released 2-3 years later might have this feature

There are reasons for not protecting the entire system however:

Some programs rely on this undefined behaviour. They scan for memory segments that are the same and try to merge them together. This almost always leads to a crash. A noteworthy example happens to be the linux kernel itself!

The performance hit is very huge. About 12-18% and can be as high as 30% in some cases

Why is this called a pattern? Well both the number AAAAAA and the binary equivalent 101010101010.... are patterns

Why is this constant negative? Probably because the sign bit is set. Look at the binary equivalent above

Lineage updater will no longer be shipped by default. It is still up to the maintainer to use it

On A/B devices maintaining compatibility with twrp is no longer required. On A devices this was never a requirement in the first place as the recovery was on a separate partition

Glassrom plans to port the entirety of the Android hardening patchset rather than picking just a few patches for Q and newer. Only time will tell how successful this is

News:

Recently a bunch of people decided to flash an unofficial leaked build of a certain developer's kernel on the a device. The leaked kernel uploaded all their data to a server and then bricked the device

The leaked build was actually source built by the scammer and as such had no connection whatsoever to original developer

This should serve as a reminder to not flash "leak builds" of any kind that haven't officially been confirmed by the developer. They might not even be built by them. You are almost always safer if you review and build the code yourself

Since the malicious builds are still in circulation and also for privacy reasons the name of the developer and the device name has been removed so that people don't accidentally find these builds