linux-kernel - Re: [PATCH] x86_64: fix problems due to use of "outb" to port 80 on some AMD64x2 laptops, etc.

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]

Message-ID: <4763442A.5020507@reed.com>
Date:	Fri, 14 Dec 2007 22:04:10 -0500
From:	"David P. Reed" <dpreed@...d.com>
To:	Alan Cox <alan@...rguk.ukuu.org.uk>
CC:	"H. Peter Anvin" <hpa@...or.com>, Pavel Machek <pavel@....cz>,
	Ingo Molnar <mingo@...e.hu>,
	Thomas Gleixner <tglx@...utronix.de>,
	linux-kernel@...r.kernel.org, Ingo Molnar <mingo@...hat.com>,
	Rene Herman <rene.herman@...access.nl>
Subject: Re: [PATCH] x86_64: fix problems due to use of "outb" to port 80
 on some AMD64x2 laptops, etc.

Just a thought for a way to fix the "very early" timing needed to set up 
udelay to work in a way that works on all machines.  Perhaps we haven't 
exploited the BIOS enough:  The PC BIOS since the PC AT (286)  has 
always had a standard "countdown timer" way to delay for n microseconds, 
which as far as I know still works.   This can be used to measure the 
speed of a delay loop, without using ANY in/out instructions directly 
(the ones in the BIOS are presumably correctly delayed...).

So first thing in the boot sequence, one can calibrate a timing loop 
using this technique, and save the value to be used for all the "early" 
stuff.

Here's skeleton code from old ASM code I found lying around in my 
archives to use BIOS to measure how many unrolled short jumps can 
execute in 10 msec.  Note that it can run without knowing anything 
whatsoever about port timing.

haltbyte db 0

calibrate:
    les bx,haltbyte ; address of halt flag into es:bx
    mov ax,8300h
    sub cx,cx
    mov dx,10000 ; 10 msec. in cx:dx
    int 15h
    jc bad
    sub dx,dx
    sub cx,cx ; decrement counter in dx:cx
tloop:
    jmp short $+2 ; 10 short jmps
    jmp short $+2
    jmp short $+2
    jmp short $+2
    jmp short $+2
    jmp short $+2
    jmp short $+2
    jmp short $+2
    jmp short $+2
    test haltbyte
    loopz tloop
    jnz done
    dec dx
    jnz tloop

" overflowed 32 bits ... never happens, cancel BIOS event wait.
    mov ax,8301h
    int 15h
    jmp error
 
done:
    mov ax,cx
    negl
" here dx:ax contains 32 bit loop count corresponding to 10 msec.
    ret ; return 32-bit value


Doc on function 83h of int 15h should be available online.
   

Alan Cox wrote:
> On Fri, 14 Dec 2007 14:13:46 -0800
> "H. Peter Anvin" <hpa@...or.com> wrote:
>
>   
>> Pavel Machek wrote:
>>     
>>> On Fri 2007-12-14 10:02:57, H. Peter Anvin wrote:
>>>       
>>>> Ingo Molnar wrote:
>>>>         
>>>>> wow, cool fix! (I remember that there were other systems as well that are 
>>>>> affected by port 0x80 muckery - i thought we had removed port 0x80 
>>>>> accesses long ago.)
>>>>> how about the simpler fix below, as a first-level approach? We can then 
>>>>> remove the _p in/out sequences after this.
>>>>>           
>>>> I believe this will suffer from the issue that was raised: this will use 
>>>> udelay() long before loop calibration (and no, we can't just "be 
>>>> conservative" since there is no "conservative" value we can use.)
>>>>         
>>> ?? Just initialize bogomips to 6GHz equivalent... and we are fine
>>> until 6GHz cpus come out.
>>>       
>> How long will that take to boot on a 386?
>>     
>
> Well the dumb approach to fix that would seem to be to initialise it to
>
> 	cpu->family   3 -> 50MHz 4 -> 300Mhz 5-> etc...
>
> Alan
>
>   
--
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/