Re: Debian initramfs/initrd, was Re: stack smashing detected
On Wed, 2023-02-08 at 10:39 -0700, Stan Johnson wrote: > On 2/7/23 4:20 PM, Finn Thain wrote: > > > > On Tue, 7 Feb 2023, Stan Johnson wrote: > > ... > > Preventing pointless key generation would be beneficial for all Macs, > > Amigas, Ataris, emulators etc. and measuring the performance of one model > > of Mac versus that of another model seems a bit irrelevant to me. > > > > Sure, but unless Debian unsupported What do you mean by »Debian unsupported«? You mean »Debian Ports«? > is willing to manage config files for the various systems, then it's > not likely to happen. I currently use separate config files for the > following Macs, to build kernels with no initrd, no modules, and only > minimal network and video support: > > 1) 68030 8 MiB, no network (PB-170) > 2) 68030 >8 MiB (SE/30, IIci, IIfx, Centris LC III, etc.) > 3) 68040 (Centris 650, PB 550c, etc.) Debian supports different kernel configuration per architecture, the concept is called »flavors«. We could certainly add a »-lean« or »-light« flavor for smaller systems. > If the stack smashing is caused by a kernel bug that is hidden by > Debian's choice of config options, then it would still be useful to > identify the bug. If there is something missing from my config files > that is causing the problem, then that would still be a kernel bug in > its sanity checking of options. Your script will be helpful if it > becomes necessary to identify specific offending options. FWIW, I haven't seen this issue on my Amiga although I haven't run a dist-upgrade for a while now. I guess, I am going to do that in the near future. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: Debian initramfs/initrd, was Re: stack smashing detected
On Wed, 2023-02-08 at 10:20 +1100, Finn Thain wrote: > Preventing pointless key generation would be beneficial for all Macs, > Amigas, Ataris, emulators etc. and measuring the performance of one model > of Mac versus that of another model seems a bit irrelevant to me. Feel free to suggest a kernel configuration update for the m68k Debian kernel or even a new kernel flavor such as a »-light« one. I am planning to create a new »-virt« kernel anyway. Maybe we can make the main m68k kernel flavor leaner and only enable all the »slow« stuff on the »-virt« flavor. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: Debian initramfs/initrd, was Re: stack smashing detected
On 2/9/23 2:22 AM, John Paul Adrian Glaubitz wrote: > On Wed, 2023-02-08 at 10:39 -0700, Stan Johnson wrote: >> On 2/7/23 4:20 PM, Finn Thain wrote: >>> >>> On Tue, 7 Feb 2023, Stan Johnson wrote: >>> ... >>> Preventing pointless key generation would be beneficial for all Macs, >>> Amigas, Ataris, emulators etc. and measuring the performance of one model >>> of Mac versus that of another model seems a bit irrelevant to me. >>> >> >> Sure, but unless Debian unsupported > > What do you mean by »Debian unsupported«? You mean »Debian Ports«? Yes, I mean Debian Ports. > >> is willing to manage config files for the various systems, then it's >> not likely to happen. I currently use separate config files for the >> following Macs, to build kernels with no initrd, no modules, and only >> minimal network and video support: >> >> 1) 68030 8 MiB, no network (PB-170) >> 2) 68030 >8 MiB (SE/30, IIci, IIfx, Centris LC III, etc.) >> 3) 68040 (Centris 650, PB 550c, etc.) > > Debian supports different kernel configuration per architecture, the concept > is called »flavors«. We could certainly add a »-lean« or »-light« flavor > for smaller systems. In that case, a "flavor" for small-memory, slower systems would be great. For example, it wouldn't need keys or certificates, or any of the things that aren't relevant for early 1990s Macs (USB, Firewire, wireless, etc.). > >> If the stack smashing is caused by a kernel bug that is hidden by >> Debian's choice of config options, then it would still be useful to >> identify the bug. If there is something missing from my config files >> that is causing the problem, then that would still be a kernel bug in >> its sanity checking of options. Your script will be helpful if it >> becomes necessary to identify specific offending options. > > FWIW, I haven't seen this issue on my Amiga although I haven't run a > dist-upgrade for a while now. I guess, I am going to do that in the > near future. > > Adrian > ok, thanks -Stan
Re: stack smashing detected
Hi Michael, On 2/8/23 8:41 PM, Michael Schmitz wrote: > ... > > Following the 040 code a bit further, I suspect that happens in the 040 > writeback handler, so this may be a red herring. > >> I'll try and log such accesses caught by exception tables on 030 to see >> if they are rare enough to allow adding a kernel log message... > > Looks like this kind of event is rare enough to not trigger in a normal > boot on my 030. Have you seen the error using my modified config file? Perhaps I'm not including something that's causing (or revealing) the problem. > Please give the attached patch a try so we can confirm > (or rule out) that user space access faults from kernel mode are to > blame for your stack smashes. > ... With "0001-m68k-debug-exception-handling-data-faults-on-030.patch", Kernel Stack-Smashing 6.2.0-rc7 (no patch) 4, 3, 3 (from earlier test) 6.2.0-rc7 (new patch) 6, 2, 0 The earlier patch is not applied. Serial console log is attached. thanks -Stan maciici_02092023.txt.xz Description: Binary data
Re: stack smashing detected
Hi Stan, Am 10.02.2023 um 13:24 schrieb Stan Johnson: Hi Michael, On 2/8/23 8:41 PM, Michael Schmitz wrote: ... Following the 040 code a bit further, I suspect that happens in the 040 writeback handler, so this may be a red herring. I'll try and log such accesses caught by exception tables on 030 to see if they are rare enough to allow adding a kernel log message... Looks like this kind of event is rare enough to not trigger in a normal boot on my 030. Have you seen the error using my modified config file? Perhaps I'm not including something that's causing (or revealing) the problem. I haven't seen these stack smashing errors ever, but that's with a really ancient user space and a kernel config for Atari that only includes the bare minimum. Please give the attached patch a try so we can confirm (or rule out) that user space access faults from kernel mode are to blame for your stack smashes. ... With "0001-m68k-debug-exception-handling-data-faults-on-030.patch", Kernel Stack-Smashing 6.2.0-rc7 (no patch) 4, 3, 3 (from earlier test) 6.2.0-rc7 (new patch) 6, 2, 0 The earlier patch is not applied. Serial console log is attached. Without Al's patch, I doubt even in case a uaccess fault happens with signal pending we'd return -1 from send_fault_sig() (the no_context path isn't taken and do_page_fault() returns without error). No kernel messages expected in that case. But none seen otherwise either which indicates exception handling in uaccess isn't a problem. Not sure it's worth the hassle to retry with both patches applied... Thanks, Michael thanks -Stan
