lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [day] [month] [year] [list]
Message-Id: <200802181120.55117.mathewss@nutech.com>
Date:	Mon, 18 Feb 2008 11:20:54 -0800
From:	sean mathews <mathewss@...ech.com>
To:	linux-kernel@...r.kernel.org, zarniwhoop@...world.com
Subject: RE: init wont start on VIA EPIA 5000 500mhz board and randomely wont start on VIA EPIA MII 10000

Ken thanks for your insight. 

 You were correct that I was chasing multiple problems.

I still ended up crashing on boot after dealing with the processor issue. 

As it turns out a bug in bash 3.2 was the cause. As bash initializes before 
loading any script it calls a built in version of getcwd() that has a memcpy()
that reads out of bounds and may read across the stack and touch kernel
memory resulting in a fault. In my case patch bash32-11 triggered the bug
as this patch causes my build to force the use of this version of getcwd() 
and not the one built into libc.

The handling of kernel memory faults for process id 1 needs some work imho. 

As process ID 1 is not kernel or user some special conditions have been 
made in the kernel to deal with situations like this. The case of a SEGFAULT
into kernel memory for process ID 1 is not handled so you end up with an
infinite loop in the kernel trying to deal with the fault and the boot process
hangs with no visual indication as to what is wrong.

 Regards
  Sean Mathews

struct SoftwareProfessional {
   double salary;
   long   lunches;
   float  jobs;
   char   unstable;
   void   work;
   short  tempers;
};

On Jan 5, 7:30 pm, Ken Moffat <zarniwh...@...world.com> wrote:
> 
>  As always, this is intended to be helpful, but treat it with a
> grain of salt, I could well be talking out of a different orifice
> than my mouth.  My last experience with aviaprocessor was a 1.2GHz
> beastie which certainly understood all i686 instructions, but
> managed to make snails look fast, and wasn't as power-frugal as
> expected, so I might be prejudiced.
> 
>  If you think your own toolchain is compiled for i586, you could try
> downloading one of the distros which definitely is built for i586 or
> i486 - if that works, it's a userspace compile problem.  Or, perhaps,
> the kernel actually needs to be built for i486 - I doubt that, but I
> don't have the hardware.
> 
> Ken
> --
> das eine Mal als Tragödie, das andere Mal als Farce
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@...r.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ