access() says EROFS even for device files if /dev is mounted RO
While doing some hdparm hacking, after booting with init=/bin/sh, I noticed
that open(1) doesn't work when / is mounted read only. It complains that it
"Cannot open /dev/tty2 read/write"...
I straced it:
execve("/usr/bin/open", ["open"], [/* 13 vars */]) = 0
...
brk(0x804c000) = 0x804c000
open("/dev/tty", O_RDWR)= -1 ENXIO (No such device or address)
open("/dev/tty0", O_RDWR) = 4
ioctl(4, KDGKBTYPE, 0xbcdb) = 0
ioctl(4, VT_GETSTATE, 0xbda4) = 0
ioctl(4, VT_OPENQRY, 0xbd90)= 0
open("/dev/tty2", O_RDWR) = 5
close(5)= 0
access("/dev/tty2", R_OK|W_OK) = -1 EROFS (Read-only file system)
write(2, "Cannot open /dev/tty2 read/write"..., 57) = 57
_exit(5)= ?
However, this is wrong. You _can_ write to device files on read-only
filesystems. (open shouldn't bother calling access(), but the kernel should
definitely give the right answer!) Running
(bash < /dev/tty2 &>/dev/tty2 &)
will work (but for reasons unknown to me it won't do job control or handle
^C, etc.)
I'm pretty sure the problem is in linux/fs/open.c, in sys_access():
...
int res = -EINVAL;
...
dentry = namei(filename);
res = PTR_ERR(dentry);
if (!IS_ERR(dentry)) {
res = permission(dentry->d_inode, mode);
/* SuS v2 requires we report a read only fs too */
if(!res && (mode & S_IWOTH) && IS_RDONLY(dentry->d_inode))
res = -EROFS;
dput(dentry);
}
...
return res;
I think the if( !res ... ) line is the problem. I think the fix is to
add a check that the file is not a device file, socket, named pipe, or a
symlink to a file on a non-readonly FS (unless permission already follow
links? There's probably some file type I didn't think of that needs to get
checked, too.).
I'm don't know what macro to use, since I don't have much kernel hacking
experience (yet ;), so I'll leave the fix for someone who knows what
they're doing :->
BTW, this is in a 2.2.17 kernel on an IA32 machine.
Please CC me on any replies, since I'm not subscribed to the list.
--
#define X(x,y) x##y
Peter Cordes ; e-mail: X([EMAIL PROTECTED] , ns.ca)
"The gods confound the man who first found out how to distinguish the hours!
Confound him, too, who in this place set up a sundial, to cut and hack
my day so wretchedly into small pieces!" -- Plautus, 200 BCE
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: access() says EROFS even for device files if /dev is mounted RO
On Mon, Nov 27, 2000 at 01:42:51PM +0100, Andries Brouwer wrote:
> On Sun, Nov 26, 2000 at 11:35:22PM -0400, Peter Cordes wrote:
>
> > While doing some hdparm hacking, after booting with init=/bin/sh, I noticed
> > that open(1) doesn't work when / is mounted read only.
>
> Already long ago open(1) was renamed to openvt(1), so it may be that
> have a very old version. See a recent kbd or console-tools.
In the Debian package, on my Woody system, open is a symlink to openvt.
I've got console-tools 0.2.3. The source uses access here:
/* Maybe we are suid root, and the -c option was given.
Check that the real user can access this VT.
We assume getty has made any in use VT non accessable */
if (access(vtname, R_OK | W_OK) < 0)
{
fprintf(stderr, _("Cannot open %s read/write (%s)\n"), vtname,
strerror(errno));
return (5);
}
That code could be "fixed" to work with the current kernel behaviour by
checking that errno != EROFS. I thought access was supposed to tell you
whether open will work, except for directories, where you do different
things to write to them. (I've seen your messages up to Tue, 28 Nov 2000
22:37:21 +0100, but I'm replying to this one, so you don't have to repeat
your arguments for me :)
> > access("/dev/tty2", R_OK|W_OK) = -1 EROFS (Read-only file system)
>
> > However, this is wrong. You _can_ write to device files on read-only
> > filesystems. (open shouldn't bother calling access(), but the kernel should
> > definitely give the right answer!)
>
> You misunderstand the function of access(). The standard says
>
> [EROFS] write access shall fail if write access is requested
> for a file on a read-only file system
>
> It does not look at whether you ask write access to a directory
> or a special device file (and whether the filesystem was mounted nodev or not).
In the case of a directory, "writing" to it is creating or deleting files
in it: the list of filename:inode changes. If the dir is on a read-only FS,
you can't write, so access() should fail. Writing to a device file doesn't
change anything stored with the file, so it works even if the file is on a
read-only FS.
> So, probably you found a flaw in openvt: the use of access is almost always
> a bug - it doesnt tell you what you want to know. You may send me a patch
> if you want to.
What do you think access is for then? Is it defined by the standard in
such a way that it isn't useful for anything?
I'm of the opinion that Linux should work in the way that is most useful,
as long as that doesn't stop us from running stuff written for other unices.
Unix is mostly good, but parts of it suck. There's no reason to keep the
parts that suck, except when needed for compatibility. Changing the
behaviour of access here would not introduce security holes in anything, so
I think it should be changed to the more sensible way.
(That last paragraph is purely my opinion. I'm pretty sure not everyone
shares it!)
--
#define X(x,y) x##y
Peter Cordes ; e-mail: X([EMAIL PROTECTED] , ns.ca)
"The gods confound the man who first found out how to distinguish the hours!
Confound him, too, who in this place set up a sundial, to cut and hack
my day so wretchedly into small pieces!" -- Plautus, 200 BCE
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Oopses with heavy disk activity with 2.4 on VIA Apollo (VT82C586B)
This is a bug report about the VIA IDE driver. I'm forwarding it here because [EMAIL PROTECTED] bounced. - Forwarded message from Mail Delivery System <[EMAIL PROTECTED]> - [EMAIL PROTECTED] SMTP error from remote mailer after RCPT TO:<[EMAIL PROTECTED]>: host mail.linux-ide.org [24.219.123.215]: 550 5.7.1 Unable to relay for [EMAIL PROTECTED] -- This is a copy of the message, including all the headers. -- Return-path: <[EMAIL PROTECTED]> Received: from peter by llama.nslug.ns.ca with local (Exim 3.22 #1 (Debian)) id 15Ajcp-0005Jz-00 for <[EMAIL PROTECTED]>; Thu, 14 Jun 2001 23:46:19 -0300 Date: Thu, 14 Jun 2001 23:46:19 -0300 To: [EMAIL PROTECTED] Subject: oopses with heavy disk activity with 2.4 on VIA Apollo (VT82C586B) Message-ID: <[EMAIL PROTECTED]> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.15i From: Peter Cordes <[EMAIL PROTECTED]> I rescued a P5BV3+ (a super 7) mobo with a VIA MVP3 chipset from the trash (I know the guy who was tossing it, and he didn't say anything about it being damaged, just old). I moved my disks over from my old system, and compiled myself a kernel for it. It's got an AMD k6-2 at 350MHz, and the memory bus is running at 100MHz. I've run memtest86 for a long time (several complete passes, one with "extended tests") and found no errors. The problem is that all the 2.4 kernels I've tried oops under heavy disk load. A couple typical ones are like this: ksymoops 2.4.1 on i586 2.2.19-idepci. Options used -v /usr/src/linux/vmlinux (specified) -K (specified) -l /proc/modules (default) -o /lib/modules/2.4.5 (specified) -m /boot/System.map-2.4.5 (specified) No modules in ksyms, skipping objects No ksyms, skipping lsmod Jun 12 02:11:40 yeti kernel: Unable to handle kernel paging request at virtual address 848d Jun 12 02:11:40 yeti kernel: c010fb03 Jun 12 02:11:40 yeti kernel: *pde = Jun 12 02:11:40 yeti kernel: Oops: Jun 12 02:11:40 yeti kernel: CPU:0 Jun 12 02:11:40 yeti kernel: EIP:0010:[__wake_up+51/168] Jun 12 02:11:40 yeti kernel: EFLAGS: 00010017 Jun 12 02:11:40 yeti kernel: eax: c123fe10 ebx: 8491 ecx: c8b6a6e4 edx: c123fdf8 Jun 12 02:11:40 yeti kernel: esi: c8b6a6e4 edi: 8489 ebp: c8b87ef4 esp: c8b87ed8 Jun 12 02:11:40 yeti kernel: ds: 0018 es: 0018 ss: 0018 Jun 12 02:11:40 yeti kernel: Process bonnie++ (pid: 329, stackpage=c8b87000) Jun 12 02:11:40 yeti kernel: Stack: c123fdf4 c8b6a6e4 c123fdcc c123fdf8 0001 0282 0003 20e9 Jun 12 02:11:40 yeti kernel:c0125481 c01e2134 c01e2304 0002 c0126b34 c01e2134 Jun 12 02:11:40 yeti kernel:c01e230c c13bee48 c0126c11 c01e2300 0002 0001 Jun 12 02:11:40 yeti kernel: Call Trace: [reclaim_page+969/1016] [__alloc_pages_limit+108/148] [__alloc_pages+181/584] [generic_file_write+843/1336] [sys_write+142/196] [system_call+51/64] Jun 12 02:11:40 yeti kernel: Code: 8b 4f 04 8b 1b 8b 01 85 45 fc 74 51 31 c0 9c 5e fa c7 01 00 Using defaults from ksymoops -t elf32-i386 -a i386 Code; Before first symbol <_EIP>: Code; Before first symbol 0: 8b 4f 04 mov0x4(%edi),%ecx Code; 0003 Before first symbol 3: 8b 1b mov(%ebx),%ebx Code; 0005 Before first symbol 5: 8b 01 mov(%ecx),%eax Code; 0007 Before first symbol 7: 85 45 fc test %eax,0xfffc(%ebp) Code; 000a Before first symbol a: 74 51 je 5d <_EIP+0x5d> 005d Before first symbol Code; 000c Before first symbol c: 31 c0 xor%eax,%eax Code; 000e Before first symbol e: 9cpushf Code; 000f Before first symbol f: 5epop%esi Code; 0010 Before first symbol 10: facli Code; 0011 Before first symbol 11: c7 01 00 00 00 00 movl $0x0,(%ecx) Jun 12 04:06:20 yeti kernel: Unable to handle kernel paging request at virtual address 45bd Jun 12 04:06:20 yeti kernel: c010fb03 Jun 12 04:06:20 yeti kernel: *pde = 075d6067 Jun 12 04:06:20 yeti kernel: Oops: Jun 12 04:06:20 yeti kernel: CPU:0 Jun 12 04:06:20 yeti kernel: EIP:0010:[__wake_up+51/168] Jun 12 04:06:20 yeti kernel: EFLAGS: 00010017 Jun 12 04:06:20 yeti kernel: eax: c123fe10 ebx: 45c1 ecx: c8b6a6e4 edx: c111edf8 Jun 12 04:06:20 yeti kernel: esi: c111edf4 edi: 45b9 ebp: c13c3f94 esp: c13c3f78 Jun 12 04:06:20 yeti kernel: ds: 0018 es: 0018 ss: 0018 Jun 12 04:06:20 yeti kernel: Process kswapd (pid: 3, stackpage=c13c3000) Jun 12 04:06:20 yeti kernel: Stack: c111edcc c111edf4 c111edf8 0001 028
Re: [PATCH 1/4] [x86] Add command line option to enable/disable hyper-threading.
(I'm not subscribed to the list, so this message looks like a normal reply, but it isn't. I didn't try to hack up an In-Reply-To: header...) On Dec 1 2006, Linus Torvalds wrote: >On Fri, 1 Dec 2006, Arjan van de Ven wrote: >> >> I would suggest you drop the patch; openssl has been long fixed, and it >> was only a theoretical attack in the first place... >> I'm not saying the attack isn't something that should be addressed.. but >> it is, and disabling hyperthreading is not the right fix. > >I concur. A lot of these "timing attacks" may be slightly easier on HT >CPU's than other CPU's, but they are still pretty damn theoretical (the >more recent branch predictor one is even more so, since it apparently >requires access to the branch predictor state itself, which you need >CPL0 to get - and once you have CPL0, why the hell bother with the branch >predictors at all, since you might as well just read the state directly >from the process..) I recently read the paper by Aciicmez, Koc, and Seifert. http://eprint.iacr.org/2006/351 (full text PDF available; It's a fairly interesting read, with some background and overview of this kind of attack). They have a clever method for gathering information about the branch predictor state, to attack one particular branch in the RSA code, which is taken or not depending on the key bit. - RSA and the attacker thread run on the same physical CPU. - The attacker thread runs a loop that contains enough branches to ensure the branch being attacked is flushed from the branch target buffer. Thus the CPU has to speculate that it's not taken. If that's the case, then nothing special happens. - If the branch is taken, then one of the attack loop's branches is evicted from the BTB. When the attack loop hits that misprediction, it causes a cascade of mispredictions and BTB evictions, leading to a change in loop execution time greater than the noise. They have plots showing some good runs and some noisier runs... - That gives them enough resolution to get most of the key bits in a single run, so they don't have to average over multiple runs with the same input data. - They attacked 512bit keys on OpenSSL 0.9.7e, with some modifications to make it simpler. It's unclear from their wording whether they attacked both their simplified and the original, or if both their versions (with and without a balanced Montgomery powering ladder) were the result of modifying OpenSSL. >So I think people have blown those SSL timing attacks _way_ out of >proportion, just because it sounds technical and cool. I think this attack is technical and cool, regardless of whether it's useful in the real world. Obviously it requires running custom code on the same machine as the process under attack, which can't happen in a lot of server applications. It could be effective against SSH on a multi-user machine, though. >Besides, most of the time you can disable HT in the BIOS, which is better >anyway if you don't want it. If someone is trying to find a way to turn off HT, for security or performance, it's better if they have to do it in a way that doesn't hurt performance. I don't like options that look useful but when you read the fine print turn out to be non-optimal. If there was support for actually setting up the CPU the same way BIOSes do when you HT is disabled that way, that would be cool. It's always nice to be able to change things without walking down to the machine room to get a console on our cluster that doesn't have remote access to the BIOS setup. -- #define X(x,y) x##y Peter Cordes ; e-mail: X([EMAIL PROTECTED] , des.ca) "The gods confound the man who first found out how to distinguish the hours! Confound him, too, who in this place set up a sundial, to cut and hack my day so wretchedly into small pieces!" -- Plautus, 200 BC - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
