linux-kernel - Re: [PATCH][RFC] exception processing in early boot

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>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 30 Aug 2006 14:18:45 +0200
From:	Willy Tarreau <w@....eu>
To:	Andi Kleen <ak@...e.de>
Cc:	Riley@...liams.Name, davej@...hat.com, pageexec@...email.hu,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH][RFC] exception processing in early boot

On Wed, Aug 30, 2006 at 11:51:39AM +0200, Andi Kleen wrote:
> Willy Tarreau <w@....eu> writes:
> 
> > Hi,
> > 
> > PaX Team has sent me this patch for inclusion. Basically, during early
> > boot on x86, the exception handler does not make a special case for
> > exceptions which push an error code onto the stack, leading to a return
> > to a wrong address. Two patches were proposed, one which would add a
> > special case for all exceptions using the return code, and this one. The
> > former was of no use in its form because the return from the exception
> > handler would get back to the faulting exception, causing it to loop.
> > 
> > This one should be better as it effectively hangs the system using HLT
> > to prevent CPU from burning.
> 
> Looks good.
> 
> [I'm glad this particular ward in x86 was fixed in x86-64 ...]

good.

> > If nobody has any objections, I will merge it. In this case, I would also
> > like someone to check if 2.6 needs it and to port it in this case.
> 
> I don't think you should merge anything like this before 2.6 does. Otherwise
> we just end up with the mad situation again that an old release has 
> more bugs fixed or more features than the new release.

Unfortunately, this situation is even more difficult for me, because it's
getting very hard to track patches that get applied, rejected, modified or
obsoleted, which is even more true when people don't always think about
sending an ACK after the patch finally gets in. I already have a few pending
patches in my queue waiting for an ACK that will have to be tracked if the
persons do not respond, say, within one week. Otherwise I might simply lose
them.

I think that the good method would be to :
  - announce the patch
  - find a volunteer to port it
  - apply it once the volunteer agrees to handle it

This way, no code gets lost because there's always someone to track it.

> -Andi

Regards,
Willy

-
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/