On 14 Nov 00 at 2:04, David Schleef wrote:
> On Tue, Nov 14, 2000 at 09:59:22AM +0100, Olaf Kirch wrote:
> > On Tue, Nov 14, 2000 at 12:06:32AM +0100, Michal Zalewski wrote:
> > > Maybe I am missing something, but at least for me, modprobe
> > > vulnerabilities are exploitable via privledged networking services,
> > > nothing more.
> >
> > Maybe not. ncpfs for instance has an ioctl that seems to allow
> > unprivileged users to specify a character set (codepage in m$speak)
> > that's requested via load_nls(), which in turn does a
> Then it looks like the driver is broken, not modutils.
Well, you can use this ioctl only before ncp filesystem gets to life,
but yes, as this call is always done by mount process, I'll add
if (!capable(CAP_SYS_ADMIN))
return -EPERM;
here. But I still do not see any problem, as ncpfs limits charset/codepage
length to 20 chars (+ NUL terminator), and nobody told me that it is
not possible to use " or - in codepage name ;-)
Best regards,
Petr Vandrovec
[email protected]
Hi Petr,
You probably noticed this already but I just wanted to bring it to your
attention that /usr/bin/vmware-config.pl script needs updating since the
flags in /proc/cpuinfo is now called "features" so it otherwise fails
complaining that my 2xP6 has no tsc. Trivial change but still worthy of
propagating into your latest .tar.gz file for 2.4.x
Regards,
Tigran
On 15 Nov 00 at 1:59, Tigran Aivazian wrote:
> You probably noticed this already but I just wanted to bring it to your
> attention that /usr/bin/vmware-config.pl script needs updating since the
> flags in /proc/cpuinfo is now called "features" so it otherwise fails
> complaining that my 2xP6 has no tsc. Trivial change but still worthy of
> propagating into your latest .tar.gz file for 2.4.x
Oh. I did not compiled 11-test5, as G450 finally arrived ;-) OK,
I'll release patch for vmware, as I cannot stop kernel developers
from changing field names :-)
Thanks for reporting,
Petr Vandrovec
[email protected]
On 15 Nov 00 at 17:47, Petr Vandrovec wrote:
> On 15 Nov 00 at 1:59, Tigran Aivazian wrote:
>
> > You probably noticed this already but I just wanted to bring it to your
> > attention that /usr/bin/vmware-config.pl script needs updating since the
> > flags in /proc/cpuinfo is now called "features" so it otherwise fails
> > complaining that my 2xP6 has no tsc. Trivial change but still worthy of
> > propagating into your latest .tar.gz file for 2.4.x
>
> Oh. I did not compiled 11-test5, as G450 finally arrived ;-) OK,
^ Matrox G450 for innocents
> I'll release patch for vmware, as I cannot stop kernel developers
> from changing field names :-)
Petr Vandrovec
[email protected]
On Wed, 15 Nov 2000, Petr Vandrovec wrote:
> On 15 Nov 00 at 1:59, Tigran Aivazian wrote:
>
> > You probably noticed this already but I just wanted to bring it to your
> > attention that /usr/bin/vmware-config.pl script needs updating since the
> > flags in /proc/cpuinfo is now called "features" so it otherwise fails
> > complaining that my 2xP6 has no tsc. Trivial change but still worthy of
> > propagating into your latest .tar.gz file for 2.4.x
>
> Oh. I did not compiled 11-test5, as G450 finally arrived ;-) OK,
> I'll release patch for vmware, as I cannot stop kernel developers
> from changing field names :-)
Actually, I know of at least one other shipping commercial product
(Sitraka's JProbe Java Profiler) that will require patching because of
this change. It seems unwise to be changing field names in commonly
used /proc files like cpuinfo at this point in time.
Scott
--
=============================================================================
Scott Murray email: [email protected]
http://www.interlog.com/~scottm ICQ: 10602428
-----------------------------------------------------------------------------
"Good, bad ... I'm the guy with the gun." - Ash, "Army of Darkness"
Followup to: <[email protected]>
By author: Scott Murray <[email protected]>
In newsgroup: linux.dev.kernel
> >
> > Oh. I did not compiled 11-test5, as G450 finally arrived ;-) OK,
> > I'll release patch for vmware, as I cannot stop kernel developers
> > from changing field names :-)
>
> Actually, I know of at least one other shipping commercial product
> (Sitraka's JProbe Java Profiler) that will require patching because of
> this change. It seems unwise to be changing field names in commonly
> used /proc files like cpuinfo at this point in time.
>
The problem with "flags" is that it no longer contains quite the same
information. Since the semantics of the field changed slightly,
changing the field name is sometimes more correct.
Also, if a piece of software needs raw CPUID information (unlike the
"cooked" one provided by recent kernels) it should use
/dev/cpu/*/cpuid.
-hpa
--
<[email protected]> at work, <[email protected]> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt
On Wed, Nov 15, 2000 at 12:12:15PM -0800, H. Peter Anvin wrote:
> Also, if a piece of software needs raw CPUID information (unlike the
> "cooked" one provided by recent kernels) it should use
> /dev/cpu/*/cpuid.
Is it also OK to use the cpuid opcode in userspace ? (after checking
for its presence with the 0x200000 eflags bit)
--
Michel "Walken" LESPINASSE
Of course I think I'm right. If I thought I was wrong, I'd change my mind.
Michel LESPINASSE wrote:
>
> On Wed, Nov 15, 2000 at 12:12:15PM -0800, H. Peter Anvin wrote:
> > Also, if a piece of software needs raw CPUID information (unlike the
> > "cooked" one provided by recent kernels) it should use
> > /dev/cpu/*/cpuid.
>
> Is it also OK to use the cpuid opcode in userspace ? (after checking
> for its presence with the 0x200000 eflags bit)
>
Only on single-CPU systems. What /dev/cpu/*/cpuid gives you is the
ability to direct the CPUID request to a particular CPU.
-hpa
--
<[email protected]> at work, <[email protected]> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt
On 15 Nov 00 at 12:12, H. Peter Anvin wrote:
> Also, if a piece of software needs raw CPUID information (unlike the
> "cooked" one provided by recent kernels) it should use
> /dev/cpu/*/cpuid.
There are two problems, first breaking procfs field name for no good reason
(you can name x86 features as 'flags' and amd/cyrix/...
as you named... There is certainly fewer apps which search 'flags'
for AMD feature than apps which search 'flags' for x86 feature;
you can also emulate old flags field by merging all features together,
but I'm not asking for this).
Second problem is that I know no system which has /dev/cpu/*/* file.
Maybe it is just my problem...
But if you could modify cpuid/msr registration interface so that they'll
appear on my /devfs, it would be much nicer. Currently there is only
'microcode' and 'mtrr' in /devfs/cpu, and no 0,1 subdirectories...
Thanks,
Petr Vandrovec
[email protected]
>> Actually, I know of at least one other shipping commercial
>> product (Sitraka's JProbe Java Profiler) that will require
>> patching because of this change. It seems unwise to be
>> changing field names in commonly used /proc files like
>> cpuinfo at this point in time.
>
> The problem with "flags" is that it no longer contains quite
> the same information. Since the semantics of the field changed
> slightly, changing the field name is sometimes more correct.
The data sure looks like flags to me. If "flags" referred
to some specific Intel register, it could be just hex.
Anyway, breaking apps to make /proc pretty is just bad.