From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28731 invoked by alias); 21 Mar 2015 22:29:03 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 28697 invoked by uid 89); 21 Mar 2015 22:29:03 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.2 required=5.0 tests=BAYES_00,SPF_HELO_PASS,SPF_SOFTFAIL autolearn=no version=3.3.2 X-HELO: bigwig.baldwin.cx Received: from bigwig.baldwin.cx (HELO bigwig.baldwin.cx) (96.47.65.170) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (CAMELLIA256-SHA encrypted) ESMTPS; Sat, 21 Mar 2015 22:29:01 +0000 Received: from John-Baldwins-MacBook-Pro.local (d-69-161-105-82.cpe.metrocast.net [69.161.105.82]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 25C49B946; Sat, 21 Mar 2015 18:28:59 -0400 (EDT) Message-ID: <550DF0AA.9070707@FreeBSD.org> Date: Sat, 21 Mar 2015 22:29:00 -0000 From: John Baldwin User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Mark Kettenis CC: palves@redhat.com, gdb-patches@sourceware.org Subject: Re: [PATCH] Add support for the x86 XSAVE extended state on FreeBSD/x86. References: <2672674.t3ZJOKnpzU@ralph.baldwin.cx> <5509D93A.5030707@redhat.com> <550DC328.40800@FreeBSD.org> <201503212018.t2LKI3jm000615@glazunov.sibelius.xs4all.nl> In-Reply-To: <201503212018.t2LKI3jm000615@glazunov.sibelius.xs4all.nl> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2015-03/txt/msg00696.txt.bz2 On 3/21/15 4:18 PM, Mark Kettenis wrote: >> That could be reused for the core read_description callback as >> well as the native ones. This could also be reused by other >> systems that grow XSAVE support in the future. > > Probably a good idea. I'm working on XSAVE support in the OpenBSD > kernel, so I'll eventually need this as well. > > I have no real objection to adding the ptrace-specific bits to the > generic BSD native code like your diff is doing. I'll probably try to > use the same interface for my OpenBSD implementation. I have one > concern about that code though. The _supply_xsave() and > _collect_xsave() functions don't accept a length, so they can't do any > bounds checking. Therefore, 'xstat_bv' as returned by the kernel must > be set correctly (i.e. not have bits sets that imply state beyond > x86_save_len is present. Does the FreeBSD kernel guarantee that? FreeBSD determines a system-wide xsave mask during boot and then leaves %xcr0 unchanged. The x86_xstate_len returned by PT_GETXSTATE_INFO is also determined at boot time and doesn't change after that. The kernel does assume that xsave/xsaveopt do not store any bits in xstate_bv that aren't set in %xcr0. Attempts to restore a saved state via PT_SETXSTATE that set a bit in xstate_bv that isn't set in %xcr0 results in PT_SETXSTATE failing. Those should ensure that xstate_bv does not return an invalid length. However, we could do additional bounds checking in the routines in *bsd-nat.c by making them compare X86_XSTATE_SIZE(xstate_bv) against x86_xstate_len and fail if x86_xstate_len is too small. > Oh, and please rename x86_xsave_len into amd64bsd_xsave_len and > i386bsd_xsave_len to keep the "namesapce" clean. Will do. -- John Baldwin