Re: [openib-general] Re: [PATCH][RFC][0/4] InfiniBand userspace verbs implementation
Andy Isaacson <[EMAIL PROTECTED]> wrote: > On Wed, Apr 20, 2005 at 10:07:45PM -0500, Timur Tabi wrote: >> I don't know if VM_REGISTERED is a good idea or not, but it should be >> absolutely impossible for the kernel to reclaim "registered" (aka pinned) >> memory, no matter what. For RDMA services (such as Infiniband, iWARP, etc), >> it's normal for non-root processes to pin hundreds of megabytes of memory, >> and that memory better be locked to those physical pages until the >> application deregisters them. > > If you take the hardline position that "the app is the only thing that > matters", your code is unlikely to get merged. Linux is a > general-purpose OS. All userspace hardware drivers with DMA will require pinned pages (and some of them will require continuous memory). Since this memory may be scheduled to be accessed by DMA, reclaiming those pages may (aka. will) result in "random" memory corruption unless done by the driver itself. You can't even set a time limit, the driver may have allocated all DMA memory to queued transfers, and some media needs to get plugged in by the lazy robot. As soon as the robot arrives - boom. (For the same reason, this memory MUST NOT be freed if the application terminates abnormally, e.g. killed by OOM). In other words, you need to make this memory as unaccessible as the framebuffer on a graphic card. If that causes a lockup, you better had prevented that while allocating. > In a Linux context, I doubt that fullblown SA is necessary or > appropriate. Rather, I'd suggest two new signals, SIGMEMLOW and > SIGMEMCRIT. The userland comms library registers handlers for both. > When the kernel decides that it needs to reclaim some memory from the > app, it sends SIGMEMLOW. The comms library then has the responsibility > to un-reserve some memory in an orderly fashion. If a reasonable [1] > time has expired since SIGMEMLOW and the kernel is still hungry, the > kernel sends SIGMEMCRIT. At this point, the comms lib *must* unregister > some memory [2] even if it has to drop state to do so; if it returns > from the signal handler without having unregistered the memory, the > kernel will SIGKILL. Choosing Data loss vs. finitely stalled system may sometimes be a bad decision. If I designes an application that might get a "gimme memory or die", I'd reserve an extra bunch of memory with the only purpose of being released in this situation. If the kernel had done that instead, this part of memory could have been used e.g. as a read-only disk cache in the meantime (off cause provided somebody cared to implement that). > [2] Is there a way for the kernel to pass down to userspace how many > pages it wants, maybe in the sigcontext? Then you'd need only one signal. I think this interface is usefull, it would e.g. allow a picture viewer to cache as many decoded and scaled pictures as the RAM permits, freeing them if the RAM gets full and the swap would have to be used. -- "When the pin is pulled, Mr. Grenade is not our friend. -U.S. Marine Corps - 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/
Re: [PATCH 2.6.12-rc2] aoe [1/6]: improve allowed interfaces configuration
Ed L Cashin <[EMAIL PROTECTED]> wrote: > +++ b/Documentation/aoe/aoe.txt 2005-04-20 11:42:20.0 -0400 > + When the aoe driver is a module, use Is there any reason for this inconsistent behaviour? > + /sys/module/aoe/parameters/aoe_iflist instead of ^^^ Why does the module name need to be part of the attribute? That's redundant. That's redundant. > + There is a boot option for the built-in aoe driver and a > + corresponding module parameter, aoe_iflist. Without this option, > + all network interfaces may be used for ATA over Ethernet. Here is a > + usage example for the module parameter. > + > +modprobe aoe_iflist="eth1 eth3" ^ "aoe" -- Top 100 things you don't want the sysadmin to say: 63. Oracle will be down until 8pm, but you can come back in and finish your work when it comes up tonight. - 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/
Re: [RFC] FUSE permission modell (Was: fuse review bits)
Mike Waychison <[EMAIL PROTECTED]> wrote:
> Consider the following pseudo example:
>
> main():
> chdir("/");
> fd = open(".", O_RDONLY);
> clone(cloned_func, cloned_stack, CLONE_NEWNS, NULL);
>
> cloned_func:
> fchdir(fd);
> chdir("..");
>
> if main is run within a chroot where it's "/" is on the same vfsmount as
> it's "..", then the application can step out of the chroot using clone(2).
>
> Note: using chdir in a vfsmount outside of your namespace works, however
> you won't be able to walk off that vfsmount (to its parent or children).
IMO the '..' file descriptor should be attached to it's chroot domain.
This should avoid all chroot-escapes, even with fd-passing etc.
I wonder why nobody thought of that. Either it's too obvious or too stupid.
--
Funny quotes:
7. You have the right to remain silent. Anything you say will be misquoted,
then used against you.
-
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/
Re: Kernel page table and module text
Allison <[EMAIL PROTECTED]> wrote: > I want to find where each module is loaded in memory by traversing the > module list . Once I have the address and the size of the module, I > want to read the bytes in memory of the module and hash it to check > it's integrity. JFTR: This may work against random memory corruption, but it will fail for detecting attacks. -- Top 100 things you don't want the sysadmin to say: 54. Uh huh.."nu -k $USER".. no problemsure thing... - 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/
Re: [PATCH x86_64] Live Patching Function on 2.6.11.7
Takashi Ikebe <[EMAIL PROTECTED]> wrote: > systr_pmem_read() and systr_pmem_write() just calls ptrace > PTRACE_PEEKTEXT/DATA repeatedly In this case we need to *stop* target > process whenever patch modules is loading You'll have to do that anyway, since you'll need to atomically store two machine words. At least you'll have to lock access to the corresponding memory page(s). -- Error, no keyboard -- press F1 to continue. Friß, Spammer: [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] - 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/
Re: [RFC] FUSE permission modell (Was: fuse review bits)
Eric Van Hensbergen <[EMAIL PROTECTED]> wrote: > On 4/11/05, Miklos Szeredi <[EMAIL PROTECTED]> wrote: >> >> 1) Only allow mount over a directory for which the user has write >> access (and is not sticky) >> >> 2) Use nosuid,nodev mount options [...] > Do these solve all the security concerns with unprivileged mounts, or > are there other barriers/concerns? Should there be ulimit (or rlimit) > style restrictions on how many mounts/binds a user is allowed to have > to prevent users from abusing mount privs? Definitively. Mountpoints use kernel space, the users could DoS the machine. The per-Machine-limit isn't fine-grained enough, since the users may DoS each other. You'll have to avoid users capturing system daemons in D state or in slowed-down artificial directory-forests, too. I think namespaces will do most the trick. > I was thinking about this a while back and thought having a user-mount > permissions file might be the right way to address lots of these > issues. Essentially it would contain information about what > users/groups were allowed to mount what sources to what destinations > and with what mandatory options. Users being able to mount random fs containing suid or device nodes are root whenever they want to. If you want to mount with dev or suid, use sudo and restrict the mount to a limited set of images/devices/whatever. -- Anger, fear, aggression. The Dark Side of the Force are they. Once you start down the Dark Path, forever will it dominate your destiny. -- Jedi Master Yoda - 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/
Re: Coredump when program run as root?
Ralf Hildebrandt <[EMAIL PROTECTED]> wrote: > Most UNIX variants disable core dumps in programs that have changed their > uid or euid during operation. This includes Solaris and Linux. > > Well, squid does exactly that. How can I still get a coredump? I really > need one. Kernel 2.6.11.7 It cannot change the (e)uid if it is run as user. Maybe this helps. -- Top 100 things you don't want the sysadmin to say: 78. Do you smell something? - 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/
Re: [SATA] status reports updated
Bodo Eggert <[EMAIL PROTECTED]> wrote: > Tomasz Chmielewski <[EMAIL PROTECTED]> wrote: >> Is there a way to check what firmware a drive has > > The obvious one: hdparm Or, since hdparm doesn't work for SCSI devices, cat /sys/block/sd$n/device/rev (might depend on the vendor) -- Funny quotes: 21. Support bacteria - they're the only culture some people have. Friß, Spammer: [EMAIL PROTECTED] [EMAIL PROTECTED] - 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/
Re: intercepting syscalls
Richard B. Johnson <[EMAIL PROTECTED]> wrote: > LD_PRELOAD some custom 'C' runtime library functions, grab open() > read(), write(), etc. This will work wonderfully with static binaries. -- "Bravery is being the only one who knows you're afraid." -David Hackworth - 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/
Re: [SATA] status reports updated
Tomasz Chmielewski <[EMAIL PROTECTED]> wrote: > Is there a way to check what firmware a drive has The obvious one: hdparm -- "Just because you are paranoid, do'nt mean they're not after you." -- K.Cobain Friß, Spammer: [EMAIL PROTECTED] [EMAIL PROTECTED] - 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/
Re: encrypted swap (was Re: [PATCH encrypted swsusp 1/3] core functionality)
Andy Isaacson <[EMAIL PROTECTED]> wrote: > * the key is automatically regenerated every 2 hours (or whatever); as >pages encrypted under the old key age out, it can be freed eventually Changing the key would not help, since if you can get the swap pages on a running system, you can also get the keys, and if you are using a limited set of keys (you obviously want that), using more than one key will just add a small linear factor to cracking the whole swap data of an offline system. -- Field experience is something you don't get until just after you need it. Friß, Spammer: [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] - 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/
Re: [2.6 patch] sound/oss/rme96xx.c: fix two check after use
Al Viro <[EMAIL PROTECTED]> wrote: > On Wed, Apr 13, 2005 at 04:17:42AM +0200, Adrian Bunk wrote: >> This patch fixes two check after use found by the Coverity checker. > > Bullshit. ->private_data is set by rme96xx_open() to guaranteed non-NULL > and never changed elsewhere. Same comment about reading the fscking > source, BUG_ON(), etc. If there are checks, they should be there for a purpose, and any sane reader will asume these checks to be nescensary. If they are dead code, you can say that, but please don't flame Adrian for fixing obviously buggy code in a way that is sane and at least more correct than the original without using several days of his lifetime to analyze the whole driver. Instead, you could provide the correct fix. -- Funny quotes: 33. If lawyers are disbarred and clergymen defrocked, doesn't it follow that electricians can be delighted, musicians denoted, cowboys deranged, models deposed, tree surgeons debarked, and dry cleaners depressed? - 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/
RE: Digi Neo 8: linux-2.6.12_r2 jsm driver
Kilau, Scott <[EMAIL PROTECTED]> wrote: > However, neither IBM nor Digi wants this thread's patch to be applied, > and yet Christoph wants to do it, completely out of spite, to break our > out-of-tree open source driver. > > This is the problem that I have. I think you should supply a patch that makes the in-kernel driver print a short notice about your other driver. E.g. The foo driver is a stripped-down version of the bar driver. To get the additional configuration and diagnosis infrastructure, see the instructions on url. -- Top 100 things you don't want the sysadmin to say: 49. What's this switch for anyways...? - 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/
Re: [INFO] Kernel strict versioning
Franco "Sensei" <[EMAIL PROTECTED]> wrote: > Krzysztof Halasa wrote: >> It isn't enough. The same compiler and the same .config - yes. But that >> means you'd have no progress within, say, 2.6. Only bug fixes. >> There _is_ a tree like that - 2.6.11.Xs are only bugfixes. > > Ok, this adds a new information. Let me explain what I understand now. > > When a new component is added to the kernel, let's say support for a new > file system, a .config entry is created (CONFIG_MYFS=y|m). Why is this > entry breaking compatibility? I mean, symbols still remains the same. > The addition of symbols is not a breaking point. A kernel feature may require a different (bigger, slower, ...) internal data structure, which isn't desired unless you use that feature. Or it will change the semantics of some functions, e.g. functions being a noop (and optimized away) for uniprocessor with no highmem will do some important task on a SMP machine with 4 GB. >> Asking for one modules dir only is similar to asking for only one >> /boot/vmlinuz-2.6 kernel file. > > Quite the same, yes. You can still have different kernels of course! By > the way, another stupid curiosity is why /lib/modules instead of /boot? Boot vs. bootloader. The same reason that allows lilo.conf to be in /etc See http://www.pathname.com/fhs/ , too -- Top 100 things you don't want the sysadmin to say: 81. The drive ate the tape but that's OK, I brought my screwdriver. Friß, Spammer: [EMAIL PROTECTED] [EMAIL PROTECTED] - 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/
Re: snd-ens1371 (alsa) & joystick woes
Patrick McFarland <[EMAIL PROTECTED]> wrote: > Speaking of which... is there anyone out > there with a ens1371 that actually works right with joysticks? Yes, I'm using the oss driver. -- Airstrikes always overshoot the target, artillery always falls short. - 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/
RE: non-free firmware in kernel modules, aggregation and unclear copyright notice.
David Schwartz <[EMAIL PROTECTED]> wrote: >>Copyright law only _explicitly_ grants a monopoly on preparation of >>derivative works. However, it is trivial, and overwhelmingly common, >>for a copyright owner to grant a license to create a derivative work >>that is conditional on how the licensee agrees to distribute (or not >>distribute) the derivative work. > > This would, of course, only make sense if you *had* to agree to the license > to *create* the derivative work. If you were able to create the derivative > work under first sale or fair use rights, then the restrictions in the > contract would not apply to you. If you buy a W*nd*ws install CD, you can create a derived work, e.g. an image of your installation, under the fair use rights (IANAL). Can you distribute that image freely? -- Friendly fire isn't. Friß, Spammer: [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] - 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/
Re: [RFC] FUSE permission modell (Was: fuse review bits)
Jamie Lokier <[EMAIL PROTECTED]> wrote: > Miklos Szeredi wrote: >> 4) Access should not be further restricted for the owner of the >> mount, even if permission bits, uid or gid would suggest >> otherwise > > Why? Surely you want to prevent writing to files which don't have the > writable bit set? A filesystem may also create append-only files - > and all users including the mount owner should be bound by that. That will depend on the situation. If the user is mounting a tgz owned by himself, FUSE should default to being a convenient hex-editor. >> 5) As much of the available information should be exported via the >> filesystem as possible > > This is the root of the conflict. You are trying to overload the > permission bits and uid/gid to mean something different than they > normally do. > > While it's convenient to see some "remote" information such as the > uid/gid in a tar file, are you sure it's a good idea to break the unix > permissions model - which will break some programs? (For example, try > editing a file with the broken semantics in an editor which checks the > uid/gid of the file against the current user). The editor will try to keep the original permissions, and saving will be less effective. >> 1) Only allow mount over a directory for which the user has write >> access (and is not sticky) > > Seems good - but why not sticky? Mounting a user filesystem in > /tmp/user-xxx/my-mount-point seems not unreasonable - provided the > administrator can delete the directory (which is possible with > detachable mount points). I once mounted a filesystem in ~/tmp after forgetting about it being a symlink to /tmp/$me/tmp, and I had to promise never to do that again. Ng zvqavtug, gur pyrnahc-grzc-fpevcg xvpxrq va. >> 5) The filesystem daemon is free to fill in all file attributes to >> any (sane) value, and the kernel won't modify these. > > Dangerous, because an administrative program might actually trust the > attributes to mean what they normally mean in the unix permissions model. The same risk applies to smbmounted file systems. Sane daemons will do no check besides matching the owner of a file in the user's home against the expected UID and checking the permission mask, since you can't trust users not to mess with files in directories they own. The "best" they can do should be shoothing their own feet. (If the user doesn't own the directory, FUSE shouldn't mount.) -- Top 100 things you don't want the sysadmin to say: 80. I cleaned up the root partition and now there's LOTS of free space. Friß, Spammer:[EMAIL PROTECTED]@whitedoc.info - 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/
