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: <DCDC804F-4025-4B9D-8727-2DBA40DD3598@infradead.org>
Date: Thu, 01 Aug 2024 22:10:08 +0100
From: David Woodhouse <dwmw2@...radead.org>
To: Thomas Gleixner <tglx@...utronix.de>, mikelley@...rosoft.com,
 kvm <kvm@...r.kernel.org>
CC: bp@...en8.de, dave.hansen@...ux.intel.com, decui@...rosoft.com,
 haiyangz@...rosoft.com, kys@...rosoft.com, linux-hyperv@...r.kernel.org,
 linux-kernel@...r.kernel.org, lirongqing@...du.com, mingo@...hat.com,
 seanjc@...gle.com, wei.liu@...nel.org, x86@...nel.org
Subject: Re: [PATCH] clockevents/drivers/i8253: Do not zero timer counter in shutdown

On 1 August 2024 22:07:25 BST, Thomas Gleixner <tglx@...utronix.de> wrote:
>On Thu, Aug 01 2024 at 16:22, David Woodhouse wrote:
>> On Thu, 2024-08-01 at 10:00 +0100, David Woodhouse wrote:
>>  bool __init pit_timer_init(void)
>>  {
>> -	if (!use_pit())
>> +	if (!use_pit()) {
>> +		if (!hypervisor_is_type(X86_HYPER_NATIVE)) {
>> +			/*
>> +			 * Don't just ignore the PIT. Ensure it's stopped,
>> +			 * because VMMs otherwise steal CPU time just to
>> +			 * pointlessly waggle the (masked) IRQ.
>> +			 */
>> +			raw_spin_lock(&i8253_lock);
>> +			outb_p(0x30, PIT_MODE);
>> +
>> +			/*
>> +			 * It's not entirely clear from the datasheet, but some
>> +			 * virtual implementations don't stop until the counter
>> +			 * is actually written.
>> +			 */
>> +			if (i8253_clear_counter_on_shutdown) {
>> +				outb_p(0, PIT_CH0);
>> +				outb_p(0, PIT_CH0);
>> +			}
>> +			raw_spin_unlock(&i8253_lock);
>> +		}
>>  		return false;
>> +	}
>
>That's just wrong. What we want is to have the underlying problem
>fixed in the driver and then make:
>  
>>  	clockevent_i8253_init(true);
>
>bool clockevent_i8253_init(bool enable, bool oneshot);
>
>so it can invoke the shutdown sequence instead of registering the pile:
>
>   if (!enable) {
>      shutdown();
>      return false;
>   }
>   ...
>   return true;
>
>and the call site becomes:
>
>    if (!clockevent_i8253_init(use_pit(), true))
>    	return false;
>
>No?

Yes. Well, kind of. The way I actually did it was by exposing the shutdown function instead of an "init" function which optionally did the opposite. But yes,  I left the hardware-bashing in precisely once place, in the driver.


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ