From owner-svn-src-head@FreeBSD.ORG Tue Jun 7 13:52:51 2011 Return-Path: Delivered-To: svn-src-head@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 119141065672; Tue, 7 Jun 2011 13:52:51 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id DD82B8FC08; Tue, 7 Jun 2011 13:52:50 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 7B80146B2D; Tue, 7 Jun 2011 09:52:50 -0400 (EDT) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 0F5DD8A027; Tue, 7 Jun 2011 09:52:50 -0400 (EDT) From: John Baldwin To: "Jung-uk Kim" Date: Tue, 7 Jun 2011 09:52:49 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110325; KDE/4.5.5; amd64; ; ) References: <201106062303.p56N3cjs053024@svn.freebsd.org> In-Reply-To: <201106062303.p56N3cjs053024@svn.freebsd.org> MIME-Version: 1.0 Message-Id: <201106070952.49563.jhb@freebsd.org> Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Tue, 07 Jun 2011 09:52:50 -0400 (EDT) Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org Subject: Re: svn commit: r222795 - head/sys/dev/atkbdc X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jun 2011 13:52:51 -0000 On Monday, June 06, 2011 7:03:38 pm Jung-uk Kim wrote: > Author: jkim > Date: Mon Jun 6 23:03:37 2011 > New Revision: 222795 > URL: http://svn.freebsd.org/changeset/base/222795 > > Log: > Validate INT 15h and 16h vectors more strictly. Traditionally these entry > points are fixed addresses and (U)EFI CSM specification also mandated that. > Unfortunately, (U)EFI CSM specification does not specifically mention this > is to call service routine via interrupt vector table or to jump directly > to the entry point. As a result, some CSM seems to install two routines > and acts differently, depending on how it was executed, unfortunately. > When INT 15h is used, it calls a function pointer (which is probably a UEFI > service function). When it jumps directly to the entry point, it executes > a simple and traditional INT 15h service routine. Therefore, actually there > are two possible fixes, i. e., this fix or jumping directly to the fixed > entry point. However, we chose this fix because a) keyboard typematic > support via BIOS is becoming extremely rarer and b) we cannot support random > service routine installed by a firmware or a boot loader. This should fix > Lenovo X220 laptop, specifically. So we really think that all valid BIOSes ever produced for x86 use these exact entry points for these two interrupts? Actually, my desktop here at work (a modern i5 system) fails this test: > sudo dd if=/dev/mem bs=4 iseek=0x15 count=2 | hd 00000000 9a e9 00 f0 2e e8 00 f0 |........| Here INT 15 uses the (perfectly valid and not from an option ROM) entry point of 0xf000:e99a. Note that EFI is not a spec for all BIOSen, just a limited subset of very recent BIOS implementations. I have another machine (1U server from a few years ago): CPU: Intel(R) Xeon(R) CPU 5160 @ 3.00GHz (2992.51-MHz K8-class CPU) Origin = "GenuineIntel" Id = 0x6f6 Family = 6 Model = f Stepping = 6 Features=0xbfebfbff Features2=0x4e3bd AMD Features=0x20100800 AMD Features2=0x1 TSC: P-state invariant Cores per package: 2 And it has these entry points: > sudo dd if=/dev/mem bs=4 iseek=0x15 count=2 | hd 00000000 59 f8 00 f0 09 3f fb e5 |Y....?..| Note that INT 16 is 0xfbe5:3f09. This is also in the valid BIOS ROM range (0xf0000 - 0xfffff). You might as well just turn the check off on all machines at this point rather than using completely arbitrary tests that are only valid on a small fraction of the x86 universe. I would favor adding logic to the loader to query these values and pass them into the kernel as metadata instead as we do for SMAP. -- John Baldwin