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: <3fd01af5-c665-6dbb-4ed4-dfc39109d63a@amd.com>
Date:   Mon, 2 May 2022 20:28:47 -0700
From:   Smita Koralahalli <Smita.KoralahalliChannabasappa@....com>
To:     Borislav Petkov <bp@...en8.de>
Cc:     x86@...nel.org, linux-edac@...r.kernel.org,
        linux-kernel@...r.kernel.org, Tony Luck <tony.luck@...el.com>,
        "H . Peter Anvin" <hpa@...or.com>,
        Yazen Ghannam <yazen.ghannam@....com>
Subject: Re: [PATCH v4 1/2] x86/mce: Check for writes ignored in MCA_STATUS
 register

On 4/24/2022 3:32 PM, Borislav Petkov wrote:
> On Thu, Apr 21, 2022 at 12:10:07PM -0700, Smita Koralahalli wrote:
>> Also, should we move this slightly before? In inj_bank_set() after we check
>> for sw injection and before reading IPID value?
> If anything, the proper place for this would be to do the check in
> flags_write() where you set the injection type and bail out if one of
> the !sw types is chosen.
>
> However, you must do the prepare_mca_status() dance first in order to do
> the check.
>
> Which means, you'd have to poke at the STATUS MSR of some bank and
> carefully restore it to its original value so that you leave no changes
> after the check. And I thought about it but it sounded kinda yucky, thus
> the setting of hw_injection_possible at injection time.
>
> That doesn't mean you can't check that variable in flags_write() *after*
> the first injection has happened and it has been set properly, but the
> first injection needs to get attempted first.
>
> At least this is my idea, maybe you have a better one...

I'm bit more inclined towards your previous approach of 
hw_injection_possible
check in do_inject(). This seems better than doing it in flags_write().

Suppose for example, the user just writes different bank numbers for 
subsequent
error injections and does not modify any other fields including flags, 
then this
method might not be helpful. So I think keeping it in inj_bank_set() or
do_inject() is more reasonable.

I was kind of figuring out the best location to place the check inside 
inj_bank_set()
and doing it before IPID check seemed the better one. But it doesn't make
much of a difference though.. So just keeping it where you suggested before.

Thanks,
Smita
>
> Btw, we'd need some error messaging when the hw injection fails:
>
> ---
> diff --git a/arch/x86/kernel/cpu/mce/inject.c b/arch/x86/kernel/cpu/mce/inject.c
> index 0fd1eea2f754..5ea1d603b124 100644
> --- a/arch/x86/kernel/cpu/mce/inject.c
> +++ b/arch/x86/kernel/cpu/mce/inject.c
> @@ -345,6 +345,9 @@ static int __set_inj(const char *buf)
>   
>   	for (i = 0; i < N_INJ_TYPES; i++) {
>   		if (!strncmp(flags_options[i], buf, strlen(flags_options[i]))) {
> +			if (i > SW_INJ && !hw_injection_possible)
> +				continue;
> +
>   			inj_type = i;
>   			return 0;
>   		}
> @@ -382,7 +385,11 @@ static ssize_t flags_write(struct file *filp, const char __user *ubuf,
>   
>   	err = __set_inj(__buf);
>   	if (err) {
> -		pr_err("%s: Invalid flags value: %s\n", __func__, __buf);
> +		pr_err("%s: Invalid flags value%s: %s\n", __func__,
> +			(!hw_injection_possible
> +			  ? " (SW-only injection possible on this platform)"
> +			  : ""),
> +			__buf);
>   		return err;
>   	}
>   


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ