* Re: PATCH to access old-style FAT fs
From: H. Peter Anvin @ 2004-01-26 19:38 UTC (permalink / raw)
To: linux-kernel
In-Reply-To: <20040126173949.GA788@frodo.local>
Followup to: <20040126173949.GA788@frodo.local>
By author: Frodo Looijaard <frodol@dds.nl>
In newsgroup: linux.dev.kernel
>
> Hi folks,
>
> I have created and attached a new version of my old-style FAT filesystem
> patch, this time for the 2.6.0 kernel. It can also be found on
> http://debian.frodo.looijaard.name/.
>
> Some old implementation of the FAT standard mark the end of the
> directory file index by inserting a filename beginning with a byte 00.
> All entries after it should be ignored, even though they are not marked
> as deleted. At least some EPOC releases (an OS used on Psion PDAs, for
> example) still use this policy.
>
It's not just "old implementations" -- it's the spec.
After reaching a filename beginning with 00, no further data should be
assumed to be in that filesystem. MS-DOS itself would only do that
when formatting the filesystem, so *all* the subsequent entries would
be assumed to start with 00, but that doesn't really seem to be to
spec.
-hpa
^ permalink raw reply
* Re: two eth devices ...
From: Ray Olszewski @ 2004-01-26 19:35 UTC (permalink / raw)
To: linux-newbie
In-Reply-To: <4011C87400000704@mail-bcm02.alestra.net.mx>
At 12:29 PM 1/26/2004 -0600, rgomez@bancomer.com wrote:
>Hi, I've been assigned a PC with two eth devices, What utility can I give
>them? or is better if i unplug one, my network is configured
>to assign an IP address via dhcp.
>
>As you can see I'm a Linux newbie in network thems...
>TKS
I cannot know for certain what is installed on your system. The usual
command for checking eth* interfaces (not "devices") is
ifconfig -a
Some newer, or stripped down, Linux systems may lack this command. In that
case, see if you have the command "ip" on your system. If you do, the command
ip link show
should give you information about the interfaces.
I am assunming here that your Linux kernel has in it, or loads modules that
provide, support for the actual NICs in your system. If not, you don't have
the eth* interfaces, and you'll need to do something to create them. I
cannot say what without knowing a few more things, namely ...
what sorts of NICs they are (you may have to open the case to find
out, or the command "lspci" may tell you)
what Linux distrubution and version you are using
what Linux kernel ("uname -a") you are running, and whether it is
a stock or a custom-compiled kernel.
You should be logged on as root to execute any of the commands I listed above.
As to whether you should "unplug" one ... it depends on unreported details
of your setup. Again, approaches vary a lot from one Linux distro to
another, but newer versions are tending to use /etc/network/interfaces as
the config file for the eth* (and some other) network interfaces. You might
see if you have such a file and, if you do, what it says about setup of
eth0 and eth1. Which of them (or are both) is set up here to get an IP
address via DHCP?
And am I correct in inferring that both eth* interfaces are connected to
the *same* network (the same LAN, probably)?If they are, you probably want
to ask the sysadmin if the network is setup to allow the interfaces to be
bridged, so they can work together to double your connection speed. If they
are not, advising you as to what you should do depends enough on what they
are connected to that no advice can make sense without your providing more
information.
-
To unsubscribe from this list: send the line "unsubscribe linux-newbie" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.linux-learn.org/faqs
^ permalink raw reply
* Re: [PATCH] 2.6.2-rc2 - MPT Fusion driver 3.00.02 update
From: Christoph Hellwig @ 2004-01-26 19:34 UTC (permalink / raw)
To: James Bottomley; +Cc: Moore, Eric Dean, SCSI Mailing List
In-Reply-To: <1075136727.2290.48.camel@mulgrave>
On Mon, Jan 26, 2004 at 11:05:26AM -0600, James Bottomley wrote:
> > I had avoided it due the comments in the code
> > from sralston and pdelaney about sg interface
> > gererating wrong direction in some cases.
>
> If you find a problem, I'll fix the generic code...
I think it's just very old comments. We had such a problem in early 2.4
kernels, but it has been fixed for ages. If it wasn't most of the scsi
drivers would have a big problem.
^ permalink raw reply
* Gentoo SELinux LiveCD
From: Chris PeBenito @ 2004-01-26 19:34 UTC (permalink / raw)
To: SELinux Mail List
[-- Attachment #1: Type: text/plain, Size: 1022 bytes --]
Announcing the Gentoo SELinux LiveCD
The Hardened Gentoo SELinux team has put out an experimental SELinux
LiveCD (108MB). This is primarily meant for Gentoo users to install
SELinux from scratch, but also it can be used to try out SELinux. I
have been able to successfully boot the CD in enforcing. The main
requirement is at least a pentium pro machine, since it is compiled with
-march=i686. Please keep in mind its experimental, and if you find bugs
please report them to me, or Gentoo bugzilla (bugs.gentoo.org). The
only issue I know of is some denials with dhcpcd.
http://gentoo.oregonstate.edu/experimental/x86/livecd/gentoo-selinux-2004.0-i686-20040125.iso
MD5:
a4ae323152948633082f5ddf9272f677 gentoo-selinux-2004.0-i686-20040125.iso
--
Chris PeBenito
<pebenito@gentoo.org>
Developer,
Hardened Gentoo Linux
Embedded Gentoo Linux
Public Key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE6AF9243
Key fingerprint = B0E6 877A 883F A57A 8E6A CB00 BC8E E42D E6AF 9243
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* PNP depends on ISA ? (2.6.2-rc2
From: Micha Feigin @ 2004-01-26 19:31 UTC (permalink / raw)
To: lkml
I was wondering why pnp depends on isa being selected in 2.6.2-rc2, is
pnp really only relevant to isa? What happens with pci etc. ?
This may explain why using pnpbios locks up my machine (at least as of 2.6.0-test9).
^ permalink raw reply
* Re: [OmniBook] Re: Solved: atkbd w 2.6.2rc1 : HowTo for extra (inet) keys ?
From: Nigel Cunningham @ 2004-01-26 19:29 UTC (permalink / raw)
To: Andries Brouwer; +Cc: P. Christeas, Vojtech Pavlik, lkml, omnibook
In-Reply-To: <20040124193708.A4005@pclin040.win.tue.nl>
[-- Attachment #1: Type: text/plain, Size: 923 bytes --]
There is an Omnibook module on Sourceforge that contains all the key
information for a variety of models. Furthermore, utilities such as
hotkeys will let you use the keys from within X with very little
configuration. No hacking required there either.
Regards,
Nigel
On Sun, 2004-01-25 at 07:37, Andries Brouwer wrote:
> On Sat, Jan 24, 2004 at 04:28:30AM +0200, P. Christeas wrote:
>
> > Download and hack the 'console-tools' package (from sourceforge, project
> > "lct") so that 'setkeycodes' does accept keycodes >127.
>
> It sounds as if you think that the kbd setkeycodes does not handle keycodes
> above 127, but it does. No hacking required.
>
> _______________________________________________
> OmniBook mailing list
> OmniBook@zurich.csail.mit.edu
> http://zurich.csail.mit.edu/mailman/listinfo/omnibook
--
My work on Software Suspend is graciously brought to you by
LinuxFund.org.
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* think this might be a bug
From: Justin Walters @ 2004-01-26 13:29 UTC (permalink / raw)
To: linux-kernel
Linux Kernel 2.6.1
Probelm Pentax Optio S4 Digital Camera
here all i get in dmesg , when i turn the camera on
ehci_hcd 0000:00:02.2: GetStatus port 6 status 001803 POWER sig=j CSC CONNECT
hub 1-0:1.0: port 6, status 501, change 1, 480 Mb/s
hub 1-0:1.0: debounce: port 6: delay 100ms stable 4 status 0x501
ehci_hcd 0000:00:02.2: port 6 full speed --> companion
ehci_hcd 0000:00:02.2: GetStatus port 6 status 003001 POWER OWNER sig=se0 CONNECT
it not giving a Device nod or nothing , i dont know if its my probelm or your guys... thanks later
^ permalink raw reply
* RE: RE: preparing toshiba_acpi driver release
From: Brown, Len @ 2004-01-26 19:29 UTC (permalink / raw)
To: Ducrot Bruno; +Cc: John Belmonte, acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f
> Wait. I take video, not hotkey :)
Yes, I just mentioned hotkeys because that is the other part of the
platform dependent drivers which need a more generic solution.
> > I think video brightness control will be a very popular and visible
> > feature -- no pun intended;-)
>
> ATM I much prefer _CST though, even if there is no visible
> effect other
> than people may notice that their laptop will run longer on battery,
> and if they don't have some usb driver loaded.
I was thinking about ergonomics rather than power-savings -- though
probably brightness control has some power savings benefits too -- maybe
somebody on the list has numbers for screen power consumption?
> > In the back of my head I'm also wondering if we've got a
> missing piece
> > of the suspend/resume puzzle here too -- and I'd hate for
> ACPI to be the
> > "missing link" to get that key feature working.
>
> IMHO, there is a need at first to glue devices in the ACPI
> namespace and the
> devices enumerated by OS a la pnpbios...
For suspend/resume, or for something else?
PNP is only for ISA devices, yes? Is it really still used?
When we were working on interrupts somebody suggested that we ask the
ISA bus driver about what ISA interrupts where taken rather than using a
table inside the ACPI code containing "conventions". The conventions
are simple, and so far seem to be functional -- though one could argue
such heuristics are sort of a hack.
-Len
-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
^ permalink raw reply
* Re: [2.4 patch] fix via-ircc.c .text.exit error
From: Jean Tourrilhes @ 2004-01-26 19:28 UTC (permalink / raw)
To: Adrian Bunk; +Cc: Marcelo Tosatti, irda-users, linux-kernel, jgarzik, linux-net
In-Reply-To: <20040125004030.GE6441@fs.tum.de>
On Sun, Jan 25, 2004 at 01:40:30AM +0100, Adrian Bunk wrote:
> On Fri, Jan 16, 2004 at 12:11:58PM -0200, Marcelo Tosatti wrote:
> >...
> > Summary of changes from v2.4.25-pre5 to v2.4.25-pre6
> > ============================================
> >...
> > Jean Tourrilhes:
> >...
> > o VIA IrDA driver
> >...
>
> I got the following link error in 2.4.25-pre7 when trying to compile
> drivers/net/irda/via-ircc.c statically into the kernel:
>
> <-- snip -->
>
> ...
> -o vmlinux
> local symbol 0: discarded in section `.text.exit' from drivers/net/irda/irda.o
> make: *** [vmlinux] Error 1
>
> <-- snip -->
>
>
> The patch below fixes this issue. It does:
> - remove __init/__exit from function prototypes (not needed)
> - __init -> __devinit
> - __exit -> __devexit
> - __devexit_p for via_remove_one
>
>
> cu
> Adrian
Thanks you Adrian. Yes, I must confess that I never test
non-modular build (because it doesn't work).
Marcelo, would you mind including Adrian's patch in your next
kernel (added again below). I tested his patch successfully with
modular and static compile. Sorry for it...
Jean
----------------------------------------------------------------
--- linux-2.4.25-pre7-full/drivers/net/irda/via-ircc.c.old 2004-01-24 20:19:32.000000000 +0100
+++ linux-2.4.25-pre7-full/drivers/net/irda/via-ircc.c 2004-01-24 20:23:16.000000000 +0100
@@ -79,7 +79,7 @@
/* Some prototypes */
static int via_ircc_open(int i, chipio_t * info, unsigned int id);
-static int __exit via_ircc_close(struct via_ircc_cb *self);
+static int via_ircc_close(struct via_ircc_cb *self);
static int via_ircc_setup(chipio_t * info, unsigned int id);
static int via_ircc_dma_receive(struct via_ircc_cb *self);
static int via_ircc_dma_receive_complete(struct via_ircc_cb *self,
@@ -107,8 +107,8 @@
void hwreset(struct via_ircc_cb *self);
static int via_ircc_dma_xmit(struct via_ircc_cb *self, u16 iobase);
static int upload_rxdata(struct via_ircc_cb *self, int iobase);
-static int __init via_init_one (struct pci_dev *pcidev, const struct pci_device_id *id);
-static void __exit via_remove_one (struct pci_dev *pdev);
+static int via_init_one (struct pci_dev *pcidev, const struct pci_device_id *id);
+static void via_remove_one (struct pci_dev *pdev);
/* Should use udelay() instead, even if we are x86 only - Jean II */
void iodelay(int udelay)
@@ -137,7 +137,7 @@
.name = VIA_MODULE_NAME,
.id_table = via_pci_tbl,
.probe = via_init_one,
- .remove = via_remove_one,
+ .remove = __devexit_p(via_remove_one),
};
@@ -146,7 +146,7 @@
*
* Initialize chip. Just find out chip type and resource.
*/
-int __init via_ircc_init(void)
+int __devinit via_ircc_init(void)
{
int rc;
@@ -168,7 +168,7 @@
}
-static int __init via_init_one (struct pci_dev *pcidev, const struct pci_device_id *id)
+static int __devinit via_init_one (struct pci_dev *pcidev, const struct pci_device_id *id)
{
int rc;
u8 temp,oldPCI_40,oldPCI_44,bTmp,bTmp1;
@@ -288,7 +288,7 @@
* Close all configured chips
*
*/
-static void __exit via_ircc_clean(void)
+static void __devexit via_ircc_clean(void)
{
int i;
@@ -301,7 +301,7 @@
}
}
-static void __exit via_remove_one (struct pci_dev *pdev)
+static void __devexit via_remove_one (struct pci_dev *pdev)
{
#ifdef HEADMSG
DBG(printk(KERN_INFO "via_remove_one : ......\n"));
@@ -310,7 +310,7 @@
}
-static void __exit via_ircc_cleanup(void)
+static void __devexit via_ircc_cleanup(void)
{
#ifdef HEADMSG
@@ -326,7 +326,7 @@
* Open driver instance
*
*/
-static __init int via_ircc_open(int i, chipio_t * info, unsigned int id)
+static __devinit int via_ircc_open(int i, chipio_t * info, unsigned int id)
{
struct net_device *dev;
struct via_ircc_cb *self;
@@ -460,7 +460,7 @@
* Close driver instance
*
*/
-static int __exit via_ircc_close(struct via_ircc_cb *self)
+static int __devexit via_ircc_close(struct via_ircc_cb *self)
{
int iobase;
^ permalink raw reply
* Re: [patch] udevd - cleanup and better timeout handling
From: Greg KH @ 2004-01-26 19:28 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <20040125200314.GA8376@vrfy.org>
On Mon, Jan 26, 2004 at 08:11:10PM +0100, Kay Sievers wrote:
> On Mon, Jan 26, 2004 at 10:22:34AM -0800, Greg KH wrote:
> > On Sun, Jan 25, 2004 at 09:03:14PM +0100, Kay Sievers wrote:
> > > 1. We are much too slow.
> > > We want to exec the real udev in the background, but a 'remove'
> > > is much much faster than a 'add', so we have a problem.
> > > Question: is it neccessary to order events for different devpath's?
> > > If no, we may wait_pid() for the exec only if we have another udev
> > > working on the same devpath.
> >
> > But how will we keep track of that? It's probably easier just to wait
> > for each one to finish, right?
>
> We leave the message in the queue until we reach the SIGCHLD for this
> pid. So we can search the queue if we are already working on this devpath,
> and delay the new exec until the former exec comes back.
Ok, if that isn't too much trouble.
> Is it feasible to run in parallel for different paths, or can you think
> of any problem?
I can't think of any problem with that.
> > > We may want threads for this, but klibc doesn't support it.
> > > Nevermind, the ipc stuff is also not supported :)
> > > Any idea?
> >
> > Heh, I can easily add the ipc stuff to klibc.
> > I'm not a experienced enough userspace programmer to discuss the merits
> > of either option here. Anyone else?
>
> IPC is from the 70's :) It's not refcounted so we may leave messages in the
> kernel without any process using it. Sockets are nicer, we easily recognize,
> if the daemon isn't running. But we need threads for this to implement it
> without doing things like I/O multiplex or use of shared memory, cause
> all tasks need to work on the same global queue.
>
> So if we can get threads in klibc, I would prefer to switch to sockets.
> IPC isn't really a option for a todays program, but it works for us and
> sockets don't solve any big problem we have.
Where would we need threads to do this? In udevsend? Can't we just
send the message to the socket and forget about it there?
In udevd can't we just read the socket if any data is available?
I really, really want to stay away from threads.
No, I do not think klibc will ever support them, and state machines are
much nicer than multi threaded apps (for the most part.)
If sockets don't really help much, I'll go add support to klibc for
ipc...
thanks,
greg k-h
-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
^ permalink raw reply
* Re: [patch] Re: Kernels > 2.6.1-mm3 do not boot. - SOLVED
From: Eric @ 2004-01-26 19:26 UTC (permalink / raw)
To: Andrew Morton, John Stoffel
Cc: ak, Valdis.Kletnieks, bunk, cova, linux-kernel
In-Reply-To: <20040125220027.30e8cdf3.akpm@osdl.org>
On Monday 26 January 2004 00:00, Andrew Morton wrote:
> "John Stoffel" <stoffel@lucent.com> wrote:
> > Sure, the darn thing wouldn't boot, it kept Oopsing with the
> > test_wp_bit oops (that I just posted more details about).
>
> Does this fix the test_wp_bit oops?
Yes, it fixes my test_wp_bit oops. But NOW, when booting 2.6.2-rc1-mm3 (which
i pathed removing -funit-at-a-time and the wp_but oops patch) I get an oops
derefrencing null pointer in blkdev_reread_part.
I booted normal and with vga=ask acpi=off
Here is a close approxamation of what I wrote down by hand.
raid1: raid set md1 active..(blah blah)
Unable to handle null dereference at virtual address 0000008c025b893
*pde = 00000000
oops = 0000 [#1]
PREEMPT SMP
CPU: 0
EIP: 0060 Not Tainted VLI
EIP is at blkdev_reread_part+0x13/0x80
Trace
[<c025bdfe>] blkdev_ioctl+0x30e/0x3b5
[<co17f426>] wake_up_inode+0x6/0x30 (might be 0xb.. cant read my writing)
[<co1bb696>] io_ctl_by_bdev+0x26/0x40
[<c0307e53>] do_md_run+0x493/0x5c0
.....trace continues about 20-30 functions
Let me know if you need more (or more accurate) debugging info. I am very
sorry if I have copied something down incorrectly. If I have, I guess its a
great time to learn how to set a up serial console :)
-------------------------
Eric Bambach
Eric at cisu dot net
-------------------------
^ permalink raw reply
* [parisc-linux] semid64_ds compiled on a 32-bit system has wrong expected size for sem_ctime
From: Carlos O'Donell @ 2004-01-26 19:27 UTC (permalink / raw)
To: parisc-linux
pa,
If anyone has been looking at his recently, please be kind enough to
explain how this compat shim works :)
Note the following things:
o semid64_ds.sem_ctime is of type __kernel_time_t
o In a 32-bit build this is an int.
o Generic code expects this to be a long.
o For a 32-bit build long == int.
linux-2.6/include/asm-parisc/sembuf.h
---
#ifndef _PARISC_SEMBUF_H
#define _PARISC_SEMBUF_H
/*
* The semid64_ds structure for parisc architecture.
* Note extra padding because this structure is passed back and forth
* between kernel and user space.
*
* Pad space is left for:
* - 64-bit time_t to solve y2038 problem
* - 2 miscellaneous 32-bit values
*/
struct semid64_ds {
struct ipc64_perm sem_perm; /* permissions .. see ipc.h */
#ifndef __LP64__
unsigned int __pad1;
#endif
__kernel_time_t sem_otime; /* last semop time */
#ifndef __LP64__
unsigned int __pad2;
#endif
__kernel_time_t sem_ctime; /* last change time */
unsigned int sem_nsems; /* no. of semaphores in array */
unsigned int __unused1;
unsigned int __unused2;
};
#endif /* _PARISC_SEMBUF_H */
---
linux-2.6/ipc/sem.c
---
1299 if(sma) {
1300 len += sprintf(buffer + len, "%10d %10d
%4o %10lu %5u %5u %5u %5u %10lu %10lu\n",
1301 sma->sem_perm.key,
1302 sem_buildid(i,sma->sem_perm.seq),
1303 sma->sem_perm.mode,
1304 sma->sem_nsems,
1305 sma->sem_perm.uid,
1306 sma->sem_perm.gid,
1307 sma->sem_perm.cuid,
1308 sma->sem_perm.cgid,
1309 sma->sem_otime,
1310 sma->sem_ctime);
1311 sem_unlock(sma);
1312
1313 pos += len;
1314 if(pos < offset) {
1315 len = 0;
1316 begin = pos;
1317 }
1318 if(pos > offset + length)
1319 goto done;
1320 }
---
Note that sem.c looks to have ctime as an unsigned long?
Does this mean that we should change the definition of our
posix_types.h?
linux-2.6/include/asm-parisc/posix_types.h
---
22 /* Note these change from narrow to wide kernels */
23 #ifdef __LP64__
24 typedef unsigned long __kernel_size_t;
25 typedef long __kernel_ssize_t;
26 typedef long __kernel_ptrdiff_t;
27 typedef long __kernel_time_t;
28 #else
29 typedef unsigned int __kernel_size_t;
30 typedef int __kernel_ssize_t;
31 typedef int __kernel_ptrdiff_t;
32 typedef int __kernel_time_t;
33 #endif
---
Should the last __kernel_time_t definition be replaced with "unsigned
long," or does the generic code *really* want the ctime to be 64-bits
regardless (see the padding in the semid64_ds structure) so that we
don't have rollover time in 2038 as noted by the comment. I think a
change in the position of sem_nsems would violate ABI, so perhaps it's
best to leave it and have the posix_types.h value change to "unsigned
long."
Thoughts or comments?
c.
^ permalink raw reply
* Re: [patch] udevinfo - now a real program :)
From: Greg KH @ 2004-01-26 19:23 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <20040126014901.GA9078@vrfy.org>
On Mon, Jan 26, 2004 at 02:49:01AM +0100, Kay Sievers wrote:
> I want to make udevinfo the standard query interface, so all the user
> features of the main udev are copied in here. It is now capable to:
>
> o query the database for a given value
> o dump the whole database
> o extract all possible device attributes for a sysfs_device
Very nice, I've applied this.
> Greg, I want to move the program out of extras/udevinfo to the root
> folder and include it in the install target. Then we may remove the
> user mode code from the main udev program and update the man page.
> What do you think?
Great idea, I just did that and checked all of the changes in.
thanks again.
greg k-h
-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
^ permalink raw reply
* Has something changed on Dan Walsh's site?
From: Mark Shakespeare @ 2004-01-26 19:22 UTC (permalink / raw)
To: selinux
I tried a fresh install of SeLinux on top of a new Fedora build.
Using Dan Walsh's selUpgrade script.....used to work a week ago.
Now I get many errors....
error: Failed dependencies:
glibc-headers = 2.3.3 is needed by glibc-devel-2.3.3-1
db4 = 4.2.52 is needed by pam-0.77-24
libproc.so.2.0.17 is needed by rusers-server-0.17-34.sel
libtcl8.4.so is needed by setools-gui-1.1.1-1
libtk8.4.so is needed by setools-gui-1.1.1-1
glibc = 2.3.2 is needed by ( installed ) glibc-headers-2.3.2-101
it then down loads the newest 2.6.1-1.141 kernel......
starts to build the kernel...
then fails......
./selUpgrade: line 55: cd: /etc/security/selinux/src/policy/domains:
no such file or directory
cp: cannot stat `program/unused/*': no such file or directory
rm: cannot remove `program/dpkg*': no such file or directory
rm: cannot remove `program/qmail*': no such file or directory
rm: cannot remove `program/gatekeeper*': no such file or directory
cp: cannot stat `misc/unused/*': no such file or directory
./selUpgrade: line 65: cd: /etc/security/selinux/src/policy: no such
file or directory
make: *** no targets specified and no makefile found. Stop.
Any help would be greatly appreciated.
I had this working fine a week ago....
Now it is broke. Looks like the SeLinux directory is not being created.
Mark
--
******************************************
* Mark Shakespeare *
* Engineering Computer Operations Team *
* Lawrence Livermore National Laboratory *
* 7000 East Ave L-130 *
* Livermore,Ca 94550 *
* 925-423-9922 mshakes@llnl.gov *
******************************************
--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.
^ permalink raw reply
* Re: 2.6.1: media change check fails for busy unplugged device
From: Andrey Borzenkov @ 2004-01-26 19:16 UTC (permalink / raw)
To: Mike Anderson; +Cc: linux-kernel, linux-scsi, James Bottomley
In-Reply-To: <20040119233641.GA1859@beaverton.ibm.com>
On Tuesday 20 January 2004 02:36, Mike Anderson wrote:
> Andrey Borzenkov [arvidjaar@mail.ru] wrote:
> > If we unplug busy device (consider mounted USB stick) media change check
> > always returns true (no media change happened). It happens because
> >
> > - device state is set to SDEV_DEL and scsi_prep_fn silently kills any
> > request including TEST_UNIT_READY sent by sd_media_changed without
> > propagating any information back to caller
>
> The silently kill would appear to be the issue. The addition of any
> number of additional checks prior to calling scsi_ioctl would not ensure
> that as soon as the last check is done the device state has not changed.
>
But why sdev->online remains set after device has been deleted? It is
definitely cannot accept any command after that point?
Is it possible to clear sdev->online in scsi_remove_device? That would solve
the problem.
thank you
-andrey
> We need a change in scsi_wait_req to differentiate that we where not woken
> up from scsi_wait_done, but from end_that_request_last.
>
> One way would be to check if rq_status == RQ_SCSI_DONE. I did not see
> anything on the request to indicate it was BLKPREP_KILL'd.
>
> James has worked more on the scsi_prep_fn so maybe he has another
> suggestion.
>
> -andmike
> --
> Michael Anderson
> andmike@us.ibm.com
^ permalink raw reply
* Re: RE: preparing toshiba_acpi driver release
From: Ducrot Bruno @ 2004-01-26 19:14 UTC (permalink / raw)
To: Brown, Len; +Cc: John Belmonte, acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f
In-Reply-To: <BF1FE1855350A0479097B3A0D2A80EE0CC8A51-N2PTB0HCzHJF3Yvz3xaN/VDQ4js95KgL@public.gmane.org>
On Mon, Jan 26, 2004 at 01:54:38PM -0500, Brown, Len wrote:
>
> > > Note that the strategy going forward is to create a generic
> > acpi/video
> > > extensions driver that works on all platforms. When it is
> > available, we
> > > should remove the video functionality from toshiba_extras and
> > > asus_extras.
> > > http://bugzilla.kernel.org/show_bug.cgi?id=1944
> > >
> > > If anybody is excited about doing this, I'd be happy to work with a
> > > volunteer.
> > >
> >
> > ATM I'm more excited with the support of processor _CST (with a patch
> > I already send to you and Dominik for first testing purpose), but
> > if nobody else want to volunteer, why not?
>
> Cool. Go ahead and "ACCEPT" the bug to let others know you're looking
> at it.
>
> I think it would be good to get acpi video standardized to defuse the
> need for more platform-specific code... Indeed, the next piece of the
> puzzle it to figure out how to properly do hot-keys correctly. Surely
> Windows doesn't have a driver for each OEM's buttons...
Wait. I take video, not hotkey :)
> I think video brightness control will be a very popular and visible
> feature -- no pun intened;-)
ATM I much prefer _CST though, even if there is no visible effect other
than people may notice that their laptop will run longer on battery,
and if they don't have some usb driver loaded.
> In the back of my head I'm also wondering if we've got a missing piece
> of the suspend/resume puzzle here too -- and I'd hate for ACPI to be the
> "missing link" to get that key feature working.
IMHO, there is a need at first to glue devices in the ACPI namespace and the
devices enumearted by OS a la pnpbios...
Cheers,
--
Ducrot Bruno
-- Which is worse: ignorance or apathy?
-- Don't know. Don't care.
-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
^ permalink raw reply
* Old udev.init.lfs in udev-014?
From: Ilja Honkonen @ 2004-01-26 19:14 UTC (permalink / raw)
To: linux-hotplug
Hi,
I just downloaded udev-014 and took a look at udev.init.lfs which appears to be
same as in udev-013. Didn't the patched version make it into udev-014 or
didn't anyone apply that first broken patch by hand, like Real Men do with all
patches? :) Well here is the verion I got from it, works well for me (I
dunno what diff command to use (plz tell) so here is my whole udev.init.lfs script):
#!/bin/sh
#
# LinuxFromScratch udev init script
# derived from original RedHat udev init script
# 2003, 2004 by Michael Buesch <mbuesch@freenet.de>
#
source /etc/sysconfig/rc
source $rc_functions
source /etc/udev/udev.conf
sysfs_dir="/sys"
bin="/sbin/udev"
run_udev ()
{
# handle block devices and their partitions
for i in ${sysfs_dir}/block/*; do
# add each drive
export DEVPATH=${i#${sysfs_dir}}
$bin block &
# add each partition, on each device
for j in $i/*; do
if [ -f $j/dev ]; then
export DEVPATH=${j#${sysfs_dir}}
$bin block &
fi
done
done
# all other device classes
for i in ${sysfs_dir}/class/*; do
for j in $i/*; do
if [ -f $j/dev ]; then
export DEVPATH=${j#${sysfs_dir}}
CLASS=`echo ${i#${sysfs_dir}} | \
cut --delimiter='/' --fields=3-`
$bin $CLASS &
fi
done
done
return 0
}
case "$1" in
start)
echo "Creating initial udev device nodes ..."
if [ ! -d $sysfs_dir ]; then
echo "sysfs_dir $sysfs_dir does not exist!"
print_status failure
exit 1
fi
if [ ! -d $udev_root ]; then
mkdir $udev_root
if [ $? -ne 0 ]; then
print_status failure
exit 1
fi
fi
# propogate /udev from /sys - we only need this while we do not
# have initramfs and an early user-space with which to do early
# device bring up
export ACTIONd
run_udev
evaluate_retval
;;
stop)
echo "Removing udev device nodes ..."
export ACTION=remove
run_udev
evaluate_retval
;;
reload)
# nothing to do here
;;
restart)
$0 stop
sleep 1
$0 start
;;
status)
if [ -d $udev_dir ]; then
echo "the udev device node directory exists"
else
echo "the udev device node directory does not exist"
fi
;;
*)
echo "Usage: $0 {start|stop|restart|status}"
exit 1
;;
esac
exit 0
Please cc any responces, thank you.
Ilja
-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
^ permalink raw reply
* Re: [patch] udevd - cleanup and better timeout handling
From: Kay Sievers @ 2004-01-26 19:11 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <20040125200314.GA8376@vrfy.org>
On Mon, Jan 26, 2004 at 10:22:34AM -0800, Greg KH wrote:
> On Sun, Jan 25, 2004 at 09:03:14PM +0100, Kay Sievers wrote:
> > 1. We are much too slow.
> > We want to exec the real udev in the background, but a 'remove'
> > is much much faster than a 'add', so we have a problem.
> > Question: is it neccessary to order events for different devpath's?
> > If no, we may wait_pid() for the exec only if we have another udev
> > working on the same devpath.
>
> But how will we keep track of that? It's probably easier just to wait
> for each one to finish, right?
We leave the message in the queue until we reach the SIGCHLD for this
pid. So we can search the queue if we are already working on this devpath,
and delay the new exec until the former exec comes back.
Is it feasible to run in parallel for different paths, or can you think
of any problem?
> > We may want threads for this, but klibc doesn't support it.
> > Nevermind, the ipc stuff is also not supported :)
> > Any idea?
>
> Heh, I can easily add the ipc stuff to klibc.
> I'm not a experienced enough userspace programmer to discuss the merits
> of either option here. Anyone else?
IPC is from the 70's :) It's not refcounted so we may leave messages in the
kernel without any process using it. Sockets are nicer, we easily recognize,
if the daemon isn't running. But we need threads for this to implement it
without doing things like I/O multiplex or use of shared memory, cause
all tasks need to work on the same global queue.
So if we can get threads in klibc, I would prefer to switch to sockets.
IPC isn't really a option for a todays program, but it works for us and
sockets don't solve any big problem we have.
thanks,
Kay
-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
^ permalink raw reply
* Re: Is source in CVS broken, or is it just me?
From: Jaroslav Kysela @ 2004-01-26 19:10 UTC (permalink / raw)
To: Justin Turner Arthur; +Cc: ALSA Development
In-Reply-To: <40155FCB.10302@verizon.net>
On Mon, 26 Jan 2004, Justin Turner Arthur wrote:
> 5. "make bzImage"
>
> Upon execution of that last command I get a few warnings about implicit
> declarations regarding class_simple_device_*, then in the end I get the
> following error:
Use latest 2.6.2-rc kernels.
Jaroslav
-----
Jaroslav Kysela <perex@suse.cz>
Linux Kernel Sound Maintainer
ALSA Project, SuSE Labs
-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
^ permalink raw reply
* Re: dxs_support detection or feature broken?
From: jgotts @ 2004-01-26 19:08 UTC (permalink / raw)
To: Takashi Iwai; +Cc: alsa-devel
In-Reply-To: <s5hr7xnufbz.wl@alsa2.suse.de>
In message <s5hr7xnufbz.wl@alsa2.suse.de>, Takashi Iwai writes:
>At Fri, 23 Jan 2004 23:40:18 -0500,
>John Gotts wrote:
>> I have an ASUS A7V8X motherboard with a VIA VT8233 audio controller equipped
>> with SPDIF. I have a set of digital speakers and use the SPDIF out for
>> everything possible. (The speakers will fall back to analog if there is no
>> digital signal present.)
>> 00:11.5 Multimedia audio controller: VIA Technologies, Inc. VT8233 AC97 Audi
>o Controller (rev 50)
>> For a long time (through 1.0.0rc1) I had been using plug:spdif as my audio
>> device and aplay had no problems playing 22,050 Hz WAV files:
>> aplay -D plug:spdif <filename>.wav
>> But with 1.0.1 my speakers started playing 22,050 Hz WAV files at 48,000 Hz.
>> After reading the following thread:
>> http://www.mail-archive.com/alsa-devel@lists.sourceforge.net/msg10448.html
>> I added the following line to my /etc/modules.conf:
>> options snd-via82xx dxs_support=3
>> and plug:spdif is working again. One message says "By default snd-via82xx u
>ses
>> dxs_support=3 (except for certain known motherboards)." Either my motherboa
>rd
>> should become unknown or this feature is not working correctly.
>well, the dxs_support detection is correct.
>the problem is that spdif doesn't support 22.5kHz but the via82xx
>driver doesn't restrict the sample rates for spdif.
>i guess 44.1khz sample can be played correctly even without "plug".
>ok, this bug should be fixed in the future...
>a workaround is to define your own pcm such as
>pcm.myspdif {
> type plug
> slave {
> pcm "spdif"
> rate 48000
> }
>}
>and
> % apaly -Dmyspdif 22500hz.wav
Thanks for the workaround. Believe it or not, I used it first, but I thought
disabling dxs_support was the better workaround. Now that I know dxs_support
works I'll define pcm.fspdif (for functional SPDIF) in my /etc/asound.conf
until the bug is fixed.
By the way, congratulations on getting version 1 out the door. I'm glad ALSA
is now a standard Linux component. Your hard work has not gone unappreciated.
Thanks,
John
--
John GOTTS <jgotts@linuxsavvy.com> http://linuxsavvy.com/staff/jgotts
-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
^ permalink raw reply
* Re: Encrypted Filesystem
From: Mark Borgerding @ 2004-01-26 19:06 UTC (permalink / raw)
To: Michael A Halcrow, linux-kernel
In-Reply-To: <OFA97B290B.67DE842E-ON87256E27.0061728C-86256E27.0061BB0E@us.ibm.com>
It sounds like you've got a nice methodical approach: gathering
requirements and thinking about it before diving headlong into hacking.
Iterative development works well for a lot of things (obviously), but I
think that crypto work requires a little bit of Cathedral-esque
architecture in order to be secure. It would pay off to think long and
hard about feedback modes, IVs, key management, salting, etc. ; before
doing any coding.
Posting explanations in sci.crypt would find a good deal more scrutiny
(read: paranoia) than in lkml. Bounce kernel & fs ideas off the kernel
hackers. Bounce crypto ideas off the cryptographers.
Some random thoughts:
Have you given any thought to journalling? fscking? Can directory
contents be encrypted? If so, what does the dir look like to others
(e.g. backup utils)
Per-file signatures will severely affect random access performance.
Changing 1 byte in a 1 GB file would require the whole thing to be reread.
Why tackle versioning? If you want encrypted cvs, you could run cvs in
file mode with the repository and/or modules in encrypted files.
CTR mode (or any stream cipher) would be more susceptible to bit
twiddling than CBC. If sigs are not integral to fs, this would be a problem.
Adding the functionality to a well known fs like ext3 or reiserfs might
be a good path to faster acceptance. It would get a lot more people
looking at the code. It would also allow people to start using the new
features on existing partitions just by patching the kernel.
I'd love to help out. I have some exp with crypto, and a teensy bit of
exp with linux filesystems. How much time I may actually have to
contribute depends on far too many factors to guess.
- Mark Borgerding
Michael A Halcrow wrote:
>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>I have some time this year to work on an encrypted filesystem for
>Linux. I have surveyed various LUG's, tested and reviewed code for
>currently existing implementations, and have started modifying some
>of them. I would like to settle on a single approach on which to
>focus my efforts, and I am interested in getting feedback from the
>LKML community as to which approach is the most feasible.
>
>This is the feature wish-list that I have compiled, based on personal
>experience and feedback I have received from other individuals and
>groups:
>
> - Seamless application to the root filesystem
> - Layered over the entire root filesystem
> - Unencrypted pass-through mode with minimal overhead
> - Files are marked as ``encrypted'' or ``unencrypted'' and treated
> accordingly by the encryption layer
> - Key->file association
> - As opposed to key->blkdev or key->directory granularity
> - No encryption metafiles in directories, instead placing that
> information into Extended Attributes
> - May break some backup utilities that are not EA-aware; may require
> another mode where encryption metadata is stored in a header block
> on the encrypted file
> - Directories can be flagged as ``encrypted-only'', where any new
> files created in that directory are, by default, encrypted, with
> the key and permissions defined in the directory's metadata
> - Processes may have encryption contexts, whereby any new files they
> create are encrypted by default according to the process'
> authentication
> - Make as much metadata about the file as confidential as possible
> (filesize, executable bit, etc.)
> - Pluggable encryption (I wouldn't mind using a block cipher in CTR
> mode)
> - Authentication via PAM
> - pam_usb
> - Bluetooth
> - Kerberos
> - PAM checks for group membership before allowing access to certain
> encrypted files
> - Rootplug-based LSM to provide key management (necessary to use
> LSM?)
> - Secret splitting and/or (m,n)-threshold support on the keys
> - Signatures on files flagged for auditing in order to detect
> attempts to circumvent the encryption layer (via direct
> modifications to the files themselves in the underlying filesystem)
> - Ad-hoc groups for access to decrypted versions of files
> - i.e., launch web browser, drop group membership by default (like
> capability inheritance masks) so that the browser does not have
> access to decrypted files by default; PAM module checks for group
> membership before allowing access (explicit user authorization on
> application access requests)
> - Userland utilities to support encrypted file management
> - Extensions to nautilus and konqueror to be able to use these
> utilities from a common interface (think: right-click, encrypted)
> - Distro installation integration
> - Transparent shredding, where the underlying filesystem supports it
> - Versioning and snapshots (CVS-ish behavior)
> - Design to work w/ SE Linux
>
>These are features that have been requested, but are not necessarily
>hard requirements for the encrypted filesystem. They are just
>suggestions that I have received, and I am not convinced that they are
>all feasible.
>
>There are several potential approaches to an encrypted filesystem with
>these features, all with varying degrees of modification to the kernel
>itself, each with its own set of advantages and disadvantages.
>
>Options that I am aware of include:
>
> - NFS-based (CFS, TCFS)
> - CFS is mature
> - Performance issues
> - Violates UNIX semantics w/ hole behavior
> - Single-threaded
>
> - Userland filesystem-based (EncFS+FUSE, CryptoFS+LUFS)
> - Newer solutions, not as well accepted or tested as CFS
> - KDE team is using SSHFS+FUSE
>
> - Loopback (cryptoloop) encrypted block device
> - Mature; in the kernel
> - Block device granularity; breaks most incremental backup
> applications
>
> - LSM-based
> - Is this even possible? Are the hooks that we need there?
>
> - Modifications to VFS (stackable filesystem, like NCryptfs)
> - Very low overhead claimed by Erez Zadok
> - Full implementation not released
> - Key->directory granularity
> - Evicts cleartext pages from the cache on process death
> - Uses dcache to store attaches
> - Other niceties, but it's not released...
>
>My goal is to develop an encrypted filesystem ``for the desktop'',
>where a user can right-click on a file in konqueror or nautilus and
>check the ``encrypted'' box, and all subsequent accesses by any
>processes to that file will require authentication in order for the
>file to be decrypted. I have already made some modifications to CFS
>to support this functionality, but I am not sure at this moment
>whether or not CFS is the best route to go for this.
>
>I have had requests to write a kernel module that, when loaded,
>transparently starts acting as the encryption layer on top of whatever
>root filesystem is mounted. For example, an ext3 partition may have
>encrypted files strewn about, which are accessible only after loading
>the module (and authenticating, etc.).
>
>Any advise or direction that the kernel community could provide would
>be very much appreciated.
>
>Thanks,
>Mike
>.___________________________________________________________________.
> Michael A. Halcrow
> Security Software Engineer, IBM Linux Technology Center
>GnuPG Fingerprint: 05B5 08A8 713A 64C1 D35D 2371 2D3C FDDA 3EB6 601D
>-----BEGIN PGP SIGNATURE-----
>Version: GnuPG v1.0.6 (GNU/Linux)
>Comment: For info see http://www.gnupg.org
>
>iD8DBQFAFU9wLTz92j62YB0RAkOfAKClVMzKIhw6JtyGvKf8+iFp4e12AwCdFARU
>uAhpA7wVjvPMdDQtKSnFzzI=
>=TM5Y
>-----END PGP SIGNATURE-----
>-
>To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>the body of a message to majordomo@vger.kernel.org
>More majordomo info at http://vger.kernel.org/majordomo-info.html
>Please read the FAQ at http://www.tux.org/lkml/
>
>
^ permalink raw reply
* Re: [2.6.2-rc2] bttv oops
From: Bernd Schubert @ 2004-01-26 19:06 UTC (permalink / raw)
To: linux-kernel
In-Reply-To: <87wu7evalw.fsf@bytesex.org>
On Mon, Jan 26, 2004 at 07:16:43PM +0100, Gerd Knorr wrote:
> Bernd Schubert <bernd-schubert@web.de> writes:
>
> > Hello,
> >
> > on loading the bttv driver I get the following messages:
> >
> > EIP is at i2c_master_recv+0xc3/0x110 [i2c_core]
>
> The debug printk's in i2c_core dereferences pointers without checking
> them first ...
>
> Workaround: Disable the i2c debug config options.
>
Ah thanks a lot, thats pretty simple and works fine.
Best regards,
Bernd
^ permalink raw reply
* Re: 2.2 kernel and ext3 filesystems
From: Andre Tomt @ 2004-01-26 19:04 UTC (permalink / raw)
To: linux-kernel; +Cc: campbell
In-Reply-To: <20040126145633.GA26983@helium.inexs.com>
Chuck Campbell wrote:
>>It was written for 2.2, and then forward-ported.
^^^^^^
> Interesting. I looked at the system running 2.2, and there are no ext3
> options in the running config file. It may have been later than 2.2.22...
"written for" is not the same as "included in" ;-)
> All of this made me remember that an ext3 filesystem can be mounted as ext2,
> so I got done what I really needed anyway.
Good :-)
^ permalink raw reply
* Encrypted Filesystem
From: Hans Reiser @ 2004-01-26 19:02 UTC (permalink / raw)
To: Nikita Danilov, mahalcro, linux-kernel, edward
In-Reply-To: <16405.24299.945548.174085@laputa.namesys.com>
I would encourage you to look at reiser4's encryption plugin. It is
currently able to perform most of the actions required to compile a
kernel without crashing.;-) Edward can provide more details. Note that
we encrypt and compress not with every write, but with every flush to
disk, and this makes it reasonable to compress and encrypt everything
routinely.
Probably it will be working soon, and definitely it could use another
person working on it. Note that the same framework also provides file
compression, and we are hoping that on machines with a good ratio of CPU
power to disk bandwidth we can actually increase performance as a result
of using it.
Current reiser4 benchmarks without it are at
www.namesys.com/benchmarks.html, and reiser4 is described at www.namesys.com
Hans
Nikita Danilov wrote:
>
> -------------------------
>
> Subject:
> Encrypted Filesystem
> From:
> Michael A Halcrow <mahalcro@us.ibm.com>
> Date:
> Mon, 26 Jan 2004 11:46:29 -0600
> To:
> linux-kernel@vger.kernel.org
>
>
> I have some time this year to work on an encrypted filesystem for
> Linux. I have surveyed various LUG's, tested and reviewed code for
> currently existing implementations, and have started modifying some
> of them. I would like to settle on a single approach on which to
> focus my efforts, and I am interested in getting feedback from the
> LKML community as to which approach is the most feasible.
>
> This is the feature wish-list that I have compiled, based on personal
> experience and feedback I have received from other individuals and
> groups:
>
> - Seamless application to the root filesystem
> - Layered over the entire root filesystem
> - Unencrypted pass-through mode with minimal overhead
> - Files are marked as ``encrypted'' or ``unencrypted'' and treated
> accordingly by the encryption layer
> - Key->file association
> - As opposed to key->blkdev or key->directory granularity
> - No encryption metafiles in directories, instead placing that
> information into Extended Attributes
> - May break some backup utilities that are not EA-aware; may require
> another mode where encryption metadata is stored in a header block
> on the encrypted file
> - Directories can be flagged as ``encrypted-only'', where any new
> files created in that directory are, by default, encrypted, with
> the key and permissions defined in the directory's metadata
> - Processes may have encryption contexts, whereby any new files they
> create are encrypted by default according to the process'
> authentication
> - Make as much metadata about the file as confidential as possible
> (filesize, executable bit, etc.)
> - Pluggable encryption (I wouldn't mind using a block cipher in CTR
> mode)
> - Authentication via PAM
> - pam_usb
> - Bluetooth
> - Kerberos
> - PAM checks for group membership before allowing access to certain
> encrypted files
> - Rootplug-based LSM to provide key management (necessary to use
> LSM?)
> - Secret splitting and/or (m,n)-threshold support on the keys
> - Signatures on files flagged for auditing in order to detect
> attempts to circumvent the encryption layer (via direct
> modifications to the files themselves in the underlying filesystem)
> - Ad-hoc groups for access to decrypted versions of files
> - i.e., launch web browser, drop group membership by default (like
> capability inheritance masks) so that the browser does not have
> access to decrypted files by default; PAM module checks for group
> membership before allowing access (explicit user authorization on
> application access requests)
> - Userland utilities to support encrypted file management
> - Extensions to nautilus and konqueror to be able to use these
> utilities from a common interface (think: right-click, encrypted)
> - Distro installation integration
> - Transparent shredding, where the underlying filesystem supports it
> - Versioning and snapshots (CVS-ish behavior)
> - Design to work w/ SE Linux
>
> These are features that have been requested, but are not necessarily
> hard requirements for the encrypted filesystem. They are just
> suggestions that I have received, and I am not convinced that they are
> all feasible.
>
> There are several potential approaches to an encrypted filesystem with
> these features, all with varying degrees of modification to the kernel
> itself, each with its own set of advantages and disadvantages.
>
> Options that I am aware of include:
>
> - NFS-based (CFS, TCFS)
> - CFS is mature
> - Performance issues
> - Violates UNIX semantics w/ hole behavior
> - Single-threaded
>
> - Userland filesystem-based (EncFS+FUSE, CryptoFS+LUFS)
> - Newer solutions, not as well accepted or tested as CFS
> - KDE team is using SSHFS+FUSE
>
> - Loopback (cryptoloop) encrypted block device
> - Mature; in the kernel
> - Block device granularity; breaks most incremental backup
> applications
>
> - LSM-based
> - Is this even possible? Are the hooks that we need there?
>
> - Modifications to VFS (stackable filesystem, like NCryptfs)
> - Very low overhead claimed by Erez Zadok
> - Full implementation not released
> - Key->directory granularity
> - Evicts cleartext pages from the cache on process death
> - Uses dcache to store attaches
> - Other niceties, but it's not released...
>
> My goal is to develop an encrypted filesystem ``for the desktop'',
> where a user can right-click on a file in konqueror or nautilus and
> check the ``encrypted'' box, and all subsequent accesses by any
> processes to that file will require authentication in order for the
> file to be decrypted. I have already made some modifications to CFS
> to support this functionality, but I am not sure at this moment
> whether or not CFS is the best route to go for this.
>
> I have had requests to write a kernel module that, when loaded,
> transparently starts acting as the encryption layer on top of whatever
> root filesystem is mounted. For example, an ext3 partition may have
> encrypted files strewn about, which are accessible only after loading
> the module (and authenticating, etc.).
>
> Any advise or direction that the kernel community could provide would
> be very much appreciated.
>
> Thanks,
> Mike
> .___________________________________________________________________.
> Michael A. Halcrow
> Security Software Engineer, IBM Linux Technology Center
> GnuPG Fingerprint: 05B5 08A8 713A 64C1 D35D 2371 2D3C FDDA 3EB6 601D
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply
* RE: RE: preparing toshiba_acpi driver release
From: Brown, Len @ 2004-01-26 18:54 UTC (permalink / raw)
To: Ducrot Bruno; +Cc: John Belmonte, acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f
> > Note that the strategy going forward is to create a generic
> acpi/video
> > extensions driver that works on all platforms. When it is
> available, we
> > should remove the video functionality from toshiba_extras and
> > asus_extras.
> > http://bugzilla.kernel.org/show_bug.cgi?id=1944
> >
> > If anybody is excited about doing this, I'd be happy to work with a
> > volunteer.
> >
>
> ATM I'm more excited with the support of processor _CST (with a patch
> I already send to you and Dominik for first testing purpose), but
> if nobody else want to volunteer, why not?
Cool. Go ahead and "ACCEPT" the bug to let others know you're looking
at it.
I think it would be good to get acpi video standardized to defuse the
need for more platform-specific code... Indeed, the next piece of the
puzzle it to figure out how to properly do hot-keys correctly. Surely
Windows doesn't have a driver for each OEM's buttons...
I think video brightness control will be a very popular and visible
feature -- no pun intened;-)
In the back of my head I'm also wondering if we've got a missing piece
of the suspend/resume puzzle here too -- and I'd hate for ACPI to be the
"missing link" to get that key feature working.
Thanks,
-Len
-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.