FreeBSD source tree https://cgit-dev.freebsd.org/src/atom?h=main 2023-08-16T17:54:11Z 2023-08-16T17:54:11Z Warner Losh imp@FreeBSD.org 2023-08-16T17:54:11Z urn:sha1:95ee2897e98f5d444f26ed2334cc7c439f9c16c6 Remove /^\s*\*\n \*\s+\$FreeBSD\$$\n/ 2022-06-28T07:51:57Z Roger Pau Monné royger@FreeBSD.org 2022-06-27T13:51:28Z urn:sha1:881c145431b7aa956b93f6d2e7b861fe00ecc892 Some tools (firecraker loader) only check for notes in PT_NOTE program headers, so make sure the notes added using the ELFNOTE macro end up in such header. Output from readelf -Wl for and amd64 kernel after the change: Elf file type is EXEC (Executable file) Entry point 0xffffffff8038a000 There are 11 program headers, starting at offset 64 Program Headers: Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align PHDR 0x000040 0xffffffff80200040 0x0000000000200040 0x000268 0x000268 R 0x8 INTERP 0x0002a8 0xffffffff802002a8 0x00000000002002a8 0x00000d 0x00000d R 0x1 [Requesting program interpreter: /red/herring] LOAD 0x000000 0xffffffff80200000 0x0000000000200000 0x189e28 0x189e28 R 0x200000 LOAD 0x18a000 0xffffffff8038a000 0x000000000038a000 0xe447e8 0xe447e8 R E 0x200000 LOAD 0xfce7f0 0xffffffff811ce7f0 0x00000000011ce7f0 0x6b955c 0x6b955c R 0x200000 LOAD 0x1800000 0xffffffff81a00000 0x0000000001a00000 0x000140 0x000140 RW 0x200000 LOAD 0x1801000 0xffffffff81a01000 0x0000000001a01000 0x1c8480 0x5ff000 RW 0x200000 DYNAMIC 0x1800000 0xffffffff81a00000 0x0000000001a00000 0x000140 0x000140 RW 0x8 GNU_RELRO 0x1800000 0xffffffff81a00000 0x0000000001a00000 0x000140 0x000140 R 0x1 GNU_STACK 0x000000 0x0000000000000000 0x0000000000000000 0x000000 0x000000 RW 0 NOTE 0x1687ae0 0xffffffff81887ae0 0x0000000001887ae0 0x0001c0 0x0001c0 R 0x4 Section to Segment mapping: Segment Sections... [...] 10 .note.gnu.build-id .note.Xen Reported by: cperciva Fixes: 1a9cdd373a6a ('xen: add PV/PVH kernel entry point') Fixes: 93ee134a24fa ('Integrate support for xen in to i386 common code.') Sponsored by: Citrix Systems R&D Reviewed by: emaste Differential revision: https://reviews.freebsd.org/D35611 2021-04-02T12:41:51Z Konstantin Belousov kib@FreeBSD.org 2021-03-31T21:04:55Z urn:sha1:aa3ea612be3659881392251e91912682b038ce78 Reviewed by: jhb Sponsored by: The FreeBSD Foundation Differential revision: https://reviews.freebsd.org/D29529 2020-09-01T21:19:39Z Mateusz Guzik mjg@FreeBSD.org 2020-09-01T21:19:39Z urn:sha1:ed83a56181ae1994e038e75b086e4a193e8419e5 2019-11-12T15:56:27Z Konstantin Belousov kib@FreeBSD.org 2019-11-12T15:56:27Z urn:sha1:006269f469d7ecb5e0247f009668b8327f2c5b37 Save the address of the trap frame in %ebp on kernel entry. This automatically provides it in struct i386_frame.f_frame to unwinder. While there, more accurately handle the terminating frames, Reviewed by: avg, markj Sponsored by: The FreeBSD Foundation MFC after: 1 week Differential revision: https://reviews.freebsd.org/D22321 2018-06-02T04:25:09Z Bruce Evans bde@FreeBSD.org 2018-06-02T04:25:09Z urn:sha1:dbe3061729e3b1b0a56370d529b4a3f90543a0c3 kernel profiling remains broken). memmove() was broken using ALTENTRY(). ALTENTRY() is only different from ENTRY() in the profiling case, and its use in that case was sort of backwards. The backwardness magically turned memmove() into memcpy() instead of completely breaking it. Only the high resolution parts of profiling itself were broken. Use ordinary ENTRY() for memmove(). Turn bcopy() into a tail call to memmove() to reduce complications. This gives slightly different pessimizations and profiling lossage. The pessimizations are minimized by not using a frame pointer() for bcopy(). Calls to profiling functions from exception trampolines were not relocated. This caused crashes on the first exception. Fix this using function pointers. Addresses of exception handlers in trampolines were not relocated. This caused unknown offsets in the profiling data. Relocate by abusing setidt_disp as for pmc although this is slower than necessary and requires namespace pollution. pmc seems to be missing some relocations. Stack traces and lots of other things in debuggers need similar relocations. Most user addresses were misclassified as unknown kernel addresses and then ignored. Treat all unknown addresses as user. Now only user addresses in the kernel text range are significantly misclassified (as known kernel addresses). The ibrs functions didn't preserve enough registers. This is the only recent breakage on amd64. Although these functions are written in asm, in the profiling case they call profiling functions which are mostly for the C ABI, so they only have to save call-used registers. They also have to save arg and return registers in some cases and actually save them in all cases to reduce complications. They end up saving all registers except %ecx on i386 and %r10 and %r11 on amd64. Saving these is only needed for 1 caller on each of amd64 and i386. Save them there. This is slightly simpler. Remove saving %ecx in handle_ibrs_exit on i386. Both handle_ibrs_entry and handle_ibrs_exit use %ecx, but only the latter needed to or did save it. But saving it there doesn't work for the profiling case. amd64 has more automatic saving of the most common scratch registers %rax, %rcx and %rdx (its complications for %r10 are from unusual use of %r10 by SYSCALL). Thus profiling of handle_ibrs_exit_rs() was not broken, and I didn't simplify the saving by moving the saving of these registers from it to the caller. 2018-05-23T16:31:46Z Konstantin Belousov kib@FreeBSD.org 2018-05-23T16:31:46Z urn:sha1:3ae6b51919a6a11f1aa387312b5cf1066b6d5250 Tested by: pho Sponsored by: The FreeBSD Foundation MFC after: 1 week Differential revision: https://reviews.freebsd.org/D15522 2018-05-22T13:45:40Z Konstantin Belousov kib@FreeBSD.org 2018-05-22T13:45:40Z urn:sha1:82a4284d4bc2814ddadc13573f12cb7521d50c20 Discussed with: bde Sponsored by: The FreeBSD Foundation MFC after: 1 week 2018-05-22T13:30:56Z Konstantin Belousov kib@FreeBSD.org 2018-05-22T13:30:56Z urn:sha1:a3c7cd11d21b5dae55c9731995cb166c14c1a484 kernel entry from userspace vm86. Sponsored by: The FreeBSD Foundation MFC after: 1 week 2018-05-12T11:06:59Z Konstantin Belousov kib@FreeBSD.org 2018-05-12T11:06:59Z urn:sha1:a9c53bbb248b7995c95492a0f498b274dee93689 is executed on the right stack already. No copy from the entry stack to the kstack must be performed for vm86 bios call code to function. To access the pcb flags on kernel entry, unconditionally switch to kernel address space if vm86 mode is detected. This fixes very early vm86 bios calls, typically done when boot is performed by boot2 without loader, and kernel falls back to BIOS calls to get SMAP. Reported by: bde Sponsored by: The FreeBSD Foundation