[PATCH] x86/mce: Add compat_ioctl assignment to make it compatible with 32-bit system

[PATCH] x86/mce: Add compat_ioctl assignment to make it compatible with 32-bit system

[zhe.he]

From: He Zhe <zhe.he@windriver.com>

32-bit user-space program would get errors like the following from ioctl
syscall due to missing compat_ioctl.
MCE_GET_RECORD_LEN: Inappropriate ioctl for device

compat_ptr_ioctl is provided as a generic implementation of .compat_ioctl
file operation to ioctl functions that either ignore the argument or pass
a pointer to a compatible data type.

Signed-off-by: He Zhe <zhe.he@windriver.com>
---
 arch/x86/kernel/cpu/mce/dev-mcelog.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/x86/kernel/cpu/mce/dev-mcelog.c b/arch/x86/kernel/cpu/mce/dev-mcelog.c
index 7c8958d..6c9b91b7 100644
--- a/arch/x86/kernel/cpu/mce/dev-mcelog.c
+++ b/arch/x86/kernel/cpu/mce/dev-mcelog.c
@@ -328,6 +328,7 @@ static const struct file_operations mce_chrdev_ops = {
 	.write			= mce_chrdev_write,
 	.poll			= mce_chrdev_poll,
 	.unlocked_ioctl		= mce_chrdev_ioctl,
+	.compat_ioctl		= compat_ptr_ioctl,
 	.llseek			= no_llseek,
 };
 
-- 
2.7.4

Re: [PATCH] x86/mce: Add compat_ioctl assignment to make it compatible with 32-bit system

[He Zhe]

Can this be considered for the moment?

Thanks,
Zhe

On 3/4/20 2:39 PM, zhe.he@windriver.com wrote:
> From: He Zhe <zhe.he@windriver.com>
>
> 32-bit user-space program would get errors like the following from ioctl
> syscall due to missing compat_ioctl.
> MCE_GET_RECORD_LEN: Inappropriate ioctl for device
>
> compat_ptr_ioctl is provided as a generic implementation of .compat_ioctl
> file operation to ioctl functions that either ignore the argument or pass
> a pointer to a compatible data type.
>
> Signed-off-by: He Zhe <zhe.he@windriver.com>
> ---
>  arch/x86/kernel/cpu/mce/dev-mcelog.c | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/arch/x86/kernel/cpu/mce/dev-mcelog.c b/arch/x86/kernel/cpu/mce/dev-mcelog.c
> index 7c8958d..6c9b91b7 100644
> --- a/arch/x86/kernel/cpu/mce/dev-mcelog.c
> +++ b/arch/x86/kernel/cpu/mce/dev-mcelog.c
> @@ -328,6 +328,7 @@ static const struct file_operations mce_chrdev_ops = {
>  	.write			= mce_chrdev_write,
>  	.poll			= mce_chrdev_poll,
>  	.unlocked_ioctl		= mce_chrdev_ioctl,
> +	.compat_ioctl		= compat_ptr_ioctl,
>  	.llseek			= no_llseek,
>  };
>  

Re: [PATCH] x86/mce: Add compat_ioctl assignment to make it compatible with 32-bit system

[Luck, Tony]

On Thu, Apr 16, 2020 at 04:40:31PM +0800, He Zhe wrote:
> Can this be considered for the moment?
> 
> Thanks,
> Zhe
> 
> On 3/4/20 2:39 PM, zhe.he@windriver.com wrote:
> > From: He Zhe <zhe.he@windriver.com>
> >
> > 32-bit user-space program would get errors like the following from ioctl
> > syscall due to missing compat_ioctl.
> > MCE_GET_RECORD_LEN: Inappropriate ioctl for device
> >
> > compat_ptr_ioctl is provided as a generic implementation of .compat_ioctl
> > file operation to ioctl functions that either ignore the argument or pass
> > a pointer to a compatible data type.

I'm not super-familiar with the compat ioctl bits.  But this looks plausible.

All three of the ioctl's for this driver have a "pointer to integer" for the
"return" value.  And "int" is a compatible type between i386 and x86_64.

I don't have a system setup to build a 32-bit binary to test the theory,
but I assume that you have built something that tests all three:

	MCE_GET_RECORD_LEN
	MCE_GET_LOG_LEN
	MCE_GETCLEAR_FLAGS

So I guess:

Acked-by: Tony Luck <tony.luck@intel.com>

> >
> > Signed-off-by: He Zhe <zhe.he@windriver.com>
> > ---
> >  arch/x86/kernel/cpu/mce/dev-mcelog.c | 1 +
> >  1 file changed, 1 insertion(+)
> >
> > diff --git a/arch/x86/kernel/cpu/mce/dev-mcelog.c b/arch/x86/kernel/cpu/mce/dev-mcelog.c
> > index 7c8958d..6c9b91b7 100644
> > --- a/arch/x86/kernel/cpu/mce/dev-mcelog.c
> > +++ b/arch/x86/kernel/cpu/mce/dev-mcelog.c
> > @@ -328,6 +328,7 @@ static const struct file_operations mce_chrdev_ops = {
> >  	.write			= mce_chrdev_write,
> >  	.poll			= mce_chrdev_poll,
> >  	.unlocked_ioctl		= mce_chrdev_ioctl,
> > +	.compat_ioctl		= compat_ptr_ioctl,
> >  	.llseek			= no_llseek,
> >  };
> >  
> 

Re: [PATCH] x86/mce: Add compat_ioctl assignment to make it compatible with 32-bit system

[He Zhe]

On 4/28/20 2:19 AM, Luck, Tony wrote:
> On Thu, Apr 16, 2020 at 04:40:31PM +0800, He Zhe wrote:
>> Can this be considered for the moment?
>>
>> Thanks,
>> Zhe
>>
>> On 3/4/20 2:39 PM, zhe.he@windriver.com wrote:
>>> From: He Zhe <zhe.he@windriver.com>
>>>
>>> 32-bit user-space program would get errors like the following from ioctl
>>> syscall due to missing compat_ioctl.
>>> MCE_GET_RECORD_LEN: Inappropriate ioctl for device
>>>
>>> compat_ptr_ioctl is provided as a generic implementation of .compat_ioctl
>>> file operation to ioctl functions that either ignore the argument or pass
>>> a pointer to a compatible data type.
> I'm not super-familiar with the compat ioctl bits.  But this looks plausible.
>
> All three of the ioctl's for this driver have a "pointer to integer" for the
> "return" value.  And "int" is a compatible type between i386 and x86_64.
>
> I don't have a system setup to build a 32-bit binary to test the theory,
> but I assume that you have built something that tests all three:
>
> 	MCE_GET_RECORD_LEN
> 	MCE_GET_LOG_LEN
> 	MCE_GETCLEAR_FLAGS
>
> So I guess:
>
> Acked-by: Tony Luck <tony.luck@intel.com>

Thanks, and yes, I had tested all three.

Zhe

>
>>> Signed-off-by: He Zhe <zhe.he@windriver.com>
>>> ---
>>>  arch/x86/kernel/cpu/mce/dev-mcelog.c | 1 +
>>>  1 file changed, 1 insertion(+)
>>>
>>> diff --git a/arch/x86/kernel/cpu/mce/dev-mcelog.c b/arch/x86/kernel/cpu/mce/dev-mcelog.c
>>> index 7c8958d..6c9b91b7 100644
>>> --- a/arch/x86/kernel/cpu/mce/dev-mcelog.c
>>> +++ b/arch/x86/kernel/cpu/mce/dev-mcelog.c
>>> @@ -328,6 +328,7 @@ static const struct file_operations mce_chrdev_ops = {
>>>  	.write			= mce_chrdev_write,
>>>  	.poll			= mce_chrdev_poll,
>>>  	.unlocked_ioctl		= mce_chrdev_ioctl,
>>> +	.compat_ioctl		= compat_ptr_ioctl,
>>>  	.llseek			= no_llseek,
>>>  };
>>>  

Re: EDAC list as Trojan Horse distribution ??

[Hermann Ruckerbauer]

> Hello *,
==> one more time as plain text.. 
>
>
> quite some tiem ago i sent a question to the EDAC list..
> I never receveived an answer.
>  
> today i got an answer with my original question quoted  and a .zip
> file attached:
>
> ======================================
>
> from:      nikolay.temizov@bpchargemaster.com
>
> Hello,
>
> Sorry, for my late reply to your question. Attached is the document
> you need.
>
> *Thank you*,
>
> ========================================
>
> I assume this is just to install a trojan horse when opening the
> attached zip (also I assume most of you will work on linux and it
> might not be a Problem for you anyhow   ;-) .
>
>  Virus total reports a Trojan horse, but only for with 2 out of 61
> virus scan engines (and I have to admit, I did not knew K7AntiVirus
> and Qihoo-360 before, all other engines reported the file as
> clean!!!!!!! ).
>
> So be careful when you get some feedback to old requests from this list
>
> Hermann
>
>
> -- 
> Our next Events:
>    Online Seminar: Open the Black Box of Memory
>        Date: 01.03 - 05.03.2021 (5 times 9:00 - 13:00) 
>
> EKH - EyeKnowHow 
> Signal Quality - Made in Bavaria
> Hermann Ruckerbauer
> www.EyeKnowHow.de
> Hermann.Ruckerbauer@EyeKnowHow.de
> Itzlinger Strasse 21a
> 94469 Deggendorf
> Tel.:	+49 (0)991 / 29 69 29 05
> Mobile:	+49 (0)176  / 787 787 77
> Fax:	+49 (0)991 / 98158793
> Hello,
>
>
>
>
>
> Am 16.04.2020 um 10:40 schrieb He Zhe:
>> Can this be considered for the moment?
>>
>> Thanks,
>> Zhe
>>
>> On 3/4/20 2:39 PM, zhe.he@windriver.com wrote:
>>> From: He Zhe <zhe.he@windriver.com>
>>>
>>> 32-bit user-space program would get errors like the following from ioctl
>>> syscall due to missing compat_ioctl.
>>> MCE_GET_RECORD_LEN: Inappropriate ioctl for device
>>>
>>> compat_ptr_ioctl is provided as a generic implementation of .compat_ioctl
>>> file operation to ioctl functions that either ignore the argument or pass
>>> a pointer to a compatible data type.
>>>
>>> Signed-off-by: He Zhe <zhe.he@windriver.com>
>>> ---
>>>  arch/x86/kernel/cpu/mce/dev-mcelog.c | 1 +
>>>  1 file changed, 1 insertion(+)
>>>
>>> diff --git a/arch/x86/kernel/cpu/mce/dev-mcelog.c b/arch/x86/kernel/cpu/mce/dev-mcelog.c
>>> index 7c8958d..6c9b91b7 100644
>>> --- a/arch/x86/kernel/cpu/mce/dev-mcelog.c
>>> +++ b/arch/x86/kernel/cpu/mce/dev-mcelog.c
>>> @@ -328,6 +328,7 @@ static const struct file_operations mce_chrdev_ops = {
>>>  	.write			= mce_chrdev_write,
>>>  	.poll			= mce_chrdev_poll,
>>>  	.unlocked_ioctl		= mce_chrdev_ioctl,
>>> +	.compat_ioctl		= compat_ptr_ioctl,
>>>  	.llseek			= no_llseek,
>>>  };
>>>  
>

Re: EDAC list as Trojan Horse distribution ??

[Borislav Petkov]

On Tue, Mar 16, 2021 at 06:55:19PM +0100, Hermann Ruckerbauer wrote:
> > quite some tiem ago i sent a question to the EDAC list..
> > I never receveived an answer.
> >  
> > today i got an answer with my original question quoted  and a .zip
> > file attached:

Nothing new - just the next spammer attempt.

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette

RE: EDAC list as Trojan Horse distribution ??

[Luck, Tony]

>> Nothing new - just the next spammer attempt. 

> But this was a new class of Spam. So far i got only mass mailing... This was personalized based on my previous e-Mail (did not include this part in my mail)

Somewhat new - combining trawling of public mailing lists for addresses with
a phishing attack trying to get you to open a (presumably) malicious payload.

I haven't personally seen that ... probably my company's e-mail filters blocked it.

-Tony

Re: EDAC list as Trojan Horse distribution ??

[Enrico Weigelt, metux IT consult]

On 16.03.21 20:51, Luck, Tony wrote:
>>> Nothing new - just the next spammer attempt.
> 
>> But this was a new class of Spam. So far i got only mass mailing... This was personalized based on my previous e-Mail (did not include this part in my mail)
> 
> Somewhat new - combining trawling of public mailing lists for addresses with
> a phishing attack trying to get you to open a (presumably) malicious payload.

I'm getting those kind of spam for aeons, just another one today.


--mtx

-- 
---
Hinweis: unverschlüsselte E-Mails können leicht abgehört und manipuliert
werden ! Für eine vertrauliche Kommunikation senden Sie bitte ihren
GPG/PGP-Schlüssel zu.
---
Enrico Weigelt, metux IT consult
Free software and Linux embedded engineering
info@metux.net -- +49-151-27565287

Trojan horses on various lists was Re: EDAC list as Trojan Horse distribution ??

[Pavel Machek]

[-- Attachment #1: Type: text/plain, Size: 697 bytes --]

Hi!

> > I assume this is just to install a trojan horse when opening the
> > attached zip (also I assume most of you will work on linux and it
> > might not be a Problem for you anyhow   ;-) .
> >
> >  Virus total reports a Trojan horse, but only for with 2 out of 61
> > virus scan engines (and I have to admit, I did not knew K7AntiVirus
> > and Qihoo-360 before, all other engines reported the file as
> > clean!!!!!!! ).
> >
> > So be careful when you get some feedback to old requests from this
> > list

Happened to me, too, on different list on two different email
addresses. Did not reoccur.

Best regards,
								Pavel

-- 
http://www.livejournal.com/~pavelmachek

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]