Date: Wed, 6 Jul 2005 04:58:33 +1000 (EST) From: Bruce Evans <bde@zeta.org.au> To: Peter Wemm <peter@wemm.org> Cc: cvs-src@freebsd.org, cvs-all@freebsd.org, src-committers@freebsd.org, Andrew Thompson <thompsa@freebsd.org>, Peter Grehan <grehan@freebsd.org> Subject: Re: cvs commit: src/sys/amd64/include _types.h src/sys/i386/include _types.h src/sys/net if_bridge.c src/sys/netinet ip_var.h src/sys/netinet6 ip6_var.h Message-ID: <20050706044025.I64745@delplex.bde.org> In-Reply-To: <200507051053.37195.peter@wemm.org> References: <200507022313.j62NDWYC028248@repoman.freebsd.org> <42C90419.8070509@freebsd.org> <200507051053.37195.peter@wemm.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 5 Jul 2005, Peter Wemm wrote: > On Monday 04 July 2005 02:40 am, Peter Grehan wrote: >>> Check the alignment of the IP header before passing the packet up >>> to the packet filter. This would cause a panic on architectures >>> that require strict alignment such as sparc64 (tier1) and ia64/ppc >>> (tier2). >> >> FYI, any modern ppc implementation doesn't require strict alignment >> for integer load/stores though there's a performance penalty for >> having to split the access into smaller ones. Anyway, it doesn't follow that it would cause a panic on arches that require strict alignment, since struct ip is bogusly declared as __packed so the arches that require strict alignment always split the load/stores for accesses to it. Panics only occur when accesses are made via dubious pointers (e.g., foo(&ipp->ip_src)). The compiler bug that the packed attribute is silently cast away makes such accesses too easy. > As an aside, I've been contemplating taking a shot at having the AC > (alignment checking) turned on for the amd64 kernel and see what > breaks. But rather than trying to do bit-shifting bcopys etc, I was > thinking about toggling it off/on around known offenders. Is this possible? PSL_AC doesn't do it since it has the same semantics as on i386's -- it only works when CPL == 3 (user mode in FreeBSD). > It could be interesting to allow userland to turn it on/off for its own > use as well. But I suspect that touching %cr0 on the fly at syscall > entry/exit could be a serious microcode cost. It's PSL_AC %rflags. We already always enable CR0_AM in %cr0. So userland has always been able to turn it on/off at some cost and the CR0_AM enable for it is effectively toggled on entry/exit whether we want it or not (but at no cost). Bruce
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20050706044025.I64745>