| Message ID | 1583303947-49858-1-git-send-email-zhe.he@windriver.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | x86/mce: Add compat_ioctl assignment to make it compatible with 32-bit system | expand |
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, > }; >
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, > > }; > > >
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, >>> }; >>>
> 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, >>> }; >>> >
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.
>> 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
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
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
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, };