linux-kernel - Re: [PATCH 0/3] Fix a misaligned load inside ptrace

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:	Fri, 1 May 2015 11:19:21 +0200
From:	Peter Zijlstra <peterz@...radead.org>
To:	Palmer Dabbelt <palmer@...belt.com>
Cc:	mingo@...hat.com, oleg@...hat.com, akpm@...ux-foundation.org,
	richard@....at, paulmck@...ux.vnet.ibm.com, bobby.prani@...il.com,
	vdavydov@...allels.com, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 0/3] Fix a misaligned load inside ptrace_attach()

On Thu, Apr 30, 2015 at 09:19:54PM -0700, Palmer Dabbelt wrote:
> I ran across what I believe is a bug in some asm-generic code while
> working on the RISC-V Linux port.  Essentially the problem is that
> wait_on_bit() takes a void *, but then perfroms long-aligned
> operation.  As far as I can tell, this bug could manifest on any other
> architecture that doesn't support misaligned operations and uses this
> particular asm-generic implementation.
> 
> The patch set is split into three parts:
> 
> * #1 fixes the bug by making task_struct.jobctl an unsigned long,
>    which ensures wait_on_bit() always ends up with a long-aligned
>    argument.
> 
> * #2 changes the prototype of wait_on_bit() and friends to take a
>    "unsigned long *" instead of a "void *", with the intent of
>    ensuring these problems don't happen again.
> 
> * #3 is a bit more intrusive: it goes and changes all uses of
>    task_struct.jobctl from int to long.
> 
> I'm not sure if #3 has gone too far, but I think #1 and #2 are sane.
> The cost is making task_struct larger on machines where
> sizeof(long)>sizeof(int), but since it's so big already this isn't too
> much cost.  I thought about making test_bit() perform byte-aligned
> accesses to avoid this cost, but since there are very similar looking
> atomic functions I thought that would be too odd.

Fair enough. Thanks!
--
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/