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  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, 3 Feb 2016 09:51:36 -0800
From:	Tom Herbert <tom@...bertland.com>
To:	Sowmini Varadhan <sowmini.varadhan@...cle.com>
Cc:	"David S. Miller" <davem@...emloft.net>,
	Linux Kernel Network Developers <netdev@...r.kernel.org>,
	Kernel Team <kernel-team@...com>
Subject: Re: [PATCH net] net: Allow flow dissector to handle non 4-byte
 aligned headers

On Wed, Feb 3, 2016 at 9:31 AM, Sowmini Varadhan
<sowmini.varadhan@...cle.com> wrote:
> On (02/03/16 09:07), Tom Herbert wrote:
>> > Kernel unaligned access at TPC[9150dc] ipv4_neigh_lookup+0x38/0x170
>>
>> Sowmini,
>>
>> This doesn't look like a hard crash to me. Instead of trying to fix
>> all the alignment issues for Sparc, can we just take the trap, fix up
>> the load, and continue without any further fuss? Performance might
>> suffer, but it doesn't seem like the bad alignments are happening in
>> critical paths.
>>
>
> None of these things is a hard crash, but they are
>
> (a) quite noisy

Try disabling the crash dump. That will improve performance.

> (b) I'm able to generate alignment falls merely by configuring
>     tunnels, and it gets worse when I disable RSS and use RFS/RPS
>     instead. So "critical path" might need some definition.

But as we said it's only for tunnels that specifically encapsulate an
ethernet header with aligning it. Many other encapsulations (e.g.
IPIP, GUE, EtherIP,IP/GRE) should be fine. We could take this to IETF
and point out that alignment is still relevant in protocol
development. We can't fix this for GRE or VXLAN at this point, but
maybe there's still hope for VXLAN-GPE or Geneve...

> (c) a perf risk for other platforms as well, even when they dont
>     complain noisily about it.
>
Right, but there is a big difference between a performance degradation
and a hard failure. It would at least be nice to know what the
performance hit actually is, if it's acceptable then this would be a
far simpler and much less invasive fix than the alternatives.

Thanks,
Tom

> --Sowmini

Powered by blists - more mailing lists