Tags give the ability to mark specific points in history as being important
-
-
4.9.337-12
19b39b20 · · -
4.9.337-138
19b39b20 · · -
4.9.337-33
19b39b20 · · -
4.9.337-92
19b39b20 · · -
-
-
perf_urgent_for_v6.5_rc2
27c68c21 · ·- Fix a lockdep warning when the event given is the first one, no event group exists yet but the code still goes and iterates over event siblings
-
objtool_urgent_for_v6.5_rc2
719a937b · ·- Mark copy_iovec_from_user() __noclone in order to prevent gcc from doing an inter-procedural optimization and confuse objtool - Initialize struct elf fully to avoid build failures
-
sched_urgent_for_v6.5_rc2
aff03707 · ·- Remove a cgroup from under a polling process properly - Fix the idle sibling selection
-
-
x86_urgent_for_6.5_rc2
535d0ae3 · ·Fix kCFI/FineIBT weaknesses The primary bug Alyssa noticed was that with FineIBT enabled function prologues have a spurious ENDBR instruction: __cfi_foo: endbr64 subl $hash, %r10d jz 1f ud2 nop 1: foo: endbr64 <--- *sadface* This means that any indirect call that fails to target the __cfi symbol and instead targets (the regular old) foo+0, will succeed due to that second ENDBR. Fixing this lead to the discovery of a single indirect call that was still doing this: ret_from_fork(), since that's an assembly stub the compmiler would not generate the proper kCFI indirect call magic and it would not get patched. Brian came up with the most comprehensive fix -- convert the thing to C with only a very thin asm wrapper. This ensures the kernel thread boostrap is a proper kCFI call. While discussing all this, Kees noted that kCFI hashes could/should be poisoned to seal all functions whose address is never taken, further limiting the valid kCFI targets -- much like we already do for IBT. So what was a 'simple' observation and fix cascaded into a bunch of inter-related CFI infrastructure fixes.
-
x86_urgent_for_6.5_rc1
535d0ae3 · ·Fix kCFI/FineIBT weaknesses The primary bug Alyssa noticed was that with FineIBT enabled function prologues have a spurious ENDBR instruction: __cfi_foo: endbr64 subl $hash, %r10d jz 1f ud2 nop 1: foo: endbr64 <--- *sadface* This means that any indirect call that fails to target the __cfi symbol and instead targets (the regular old) foo+0, will succeed due to that second ENDBR. Fixing this lead to the discovery of a single indirect call that was still doing this: ret_from_fork(), since that's an assembly stub the compmiler would not generate the proper kCFI indirect call magic and it would not get patched. Brian came up with the most comprehensive fix -- convert the thing to C with only a very thin asm wrapper. This ensures the kernel thread boostrap is a proper kCFI call. While discussing all this, Kees noted that kCFI hashes could/should be poisoned to seal all functions whose address is never taken, further limiting the valid kCFI targets -- much like we already do for IBT. So what was a 'simple' observation and fix cascaded into a bunch of inter-related CFI infrastructure fixes.
-
-
-
-
-
-
-