LIO - the broken iSCSI target implementation
This is not a technical point of view. This is a more or less political and user point of view. And for any replies, I'm not subscribed (haven't been now for years). As a user, I was in need for an iSCSI target. Actually, I needed to export a SAS tape device (Ultrium 5) - which is one of the devices still sufficiently expensive to go the iSCSI target way) - well, not any disks (cheap enough, NFS available) or CD/DVD writers (I'd call these penny targets nowadays). Thus, lio (http://www.linux-iscsi.org/) seemed to be the politically and technically favoured solution. Except: it simply doesn't work, userspace utilities are seemingly not maintained, the web site is - simply put - sales talk and when one tries to write manually to configfs the results are kernel panics. A little bit more detail: The mentioned website doesn't have any usable documentation on how to use the provided utilities. It does, however, include lots of sales pointers for a certain company. Looking at http://www.risingtidesystems.com/git/ the latest changes are older than 3 months. And this userspace stuff is full of bugs. Whatever tool I tried - either the tools complained or there were easily detectable bugs that were never fixed. Oh, well, maybe I do expect too much when a certain commercial institution calls LIO "the standard open-source storage Target". Maybe one should not expect typical hardware to be supported except, maybe, when a commercial contract exists... Though the only chance to get the LIO target working for me was to try to write hopefully proper values to configfs manually. Without any usable documentation, that is. The result was: kernel panics (@hch: don't ask me how to repeat - hire some apes hacking at LIO configfs, that's whats required, apes need no documentation, either). The fun part of it was that I finally ended up using SCST - which was refrained from kernel inclusion for technical reasons beyond my knowledge. What makes me prefer SCST is quite simple: It works, it is sufficiently documented and it is maintained. And, @hch: Beautiful in kernel code first needs to work without producing kernel panics (3.7.x) and it needs to be accompanied by working and sufficiently documented user space utilities or, it needs to have a well documented API (documentation needs to include a variety of examples, not the old IBM way of simply documenting every flag without any overview). As long as LIO userspace is a not maintained and instead seemingly a sales playground and as long as LIO kernel code causes panics by simple writes to configfs LIO seems to me worse than any alpha quality code. It is simply useless. Maybe I'm the first to state this but for sure I'm not the first to detect this. Finally, I'm not willing to take part nor am I intending to start a flame war. I'm just stating how things are with regards to LIO from a user's point of view. It is up to other powers to decide, when and if stuff gets fixed. It is, however, clear from a user's perspective that LIO should be marked as *BROKEN* as long as it stays as unusable as it is. @hch - Remember: Implement, then *document* and *test*. Otherwise you produce or review dead code - maybe even infradead code. -- Andreas Steinmetz SPAMmers use robot...@domdv.de -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: mss to pmtu clamping partially broken?
Jan Engelhardt wrote: > Do you really need clamping? It's a hack, since TCP should do MSS negotiation > itself. (Of course it may happen that some routers are broken.) But usually > not > for incoming packets. You never know when you hit ICMP blackholes, broken routers and other evil things. Better safe than sorry so clamping is the way to go for me. -- Andreas Steinmetz SPAMmers use [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: mss to pmtu clamping partially broken?
Patrick McHardy wrote: > Its possible that one of your ISPs is doing clamping. You could > check on ppp0 if thats the case. Or maybe for some reason the > PMTU value for the internal host is smaller than 1500. You can > check that by doing "ip route get ". > > Oh well, thew fun with ISPs. Same provider, clamping on one line but not the other. This is fun :-( -- Andreas Steinmetz SPAMmers use [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: mss to pmtu clamping partially broken?
Patrick McHardy wrote: > Andreas Steinmetz wrote: >> Patrick McHardy wrote: >> >>> - assuming you have ethernet internally, the PMTU from your router >>> to the internal hosts is 1500, so it won't do any clamping. >>> >> >> Yep, internal PMTU is 1500, still the incoming packets are clamped to >> 1452 on the one line and not clamped on the other. >> >> >>> Does that explain it? >>> >>> A useful thing for TCPMSS for routers would be to clamp to the >>> minimum of the PMTU of both directions. But thats not supported >>> so far. >>> >> >> I wonder, as somteimes it gets clamped. If it would never have been >> clamped I wouldn't have asked. > > > Its possible that one of your ISPs is doing clamping. You could This would be fun as it is the same ISP for both lines. I'll check next week as the lines are located 40km away. > check on ppp0 if thats the case. Or maybe for some reason the > PMTU value for the internal host is smaller than 1500. You can > check that by doing "ip route get ". > No. Unmodified internal network in both test cases. > -- Andreas Steinmetz SPAMmers use [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: mss to pmtu clamping partially broken?
Patrick McHardy wrote: > Andreas Steinmetz wrote: >> Patrick McHardy wrote: >> >>> Andreas Steinmetz wrote: >>> >>>> [...] >>>> The tcpdump on the client shows that the mss of the incoming syn reply >>>> packet is *NOT* clamped to the ppp interface mtu. >>> >>> You forgot to mention *how* you're clamping the MSS. Using >>> TCPMSS? Do you have a rule for incoming packets? >>> >> >> The relevant iptables commands I do use for masquerading and clamping are: >> >> iptables -t nat -A POSTROUTING -o ppp0 -j MASQUERADE >> iptables -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS \ >> --clamp-mss-to-pmtu > > > Two things here: > > - tcpdumps on ppp0 will show unclamped packets since they haven't > been forwarded yet > That is true, I know this. > - assuming you have ethernet internally, the PMTU from your router > to the internal hosts is 1500, so it won't do any clamping. > Yep, internal PMTU is 1500, still the incoming packets are clamped to 1452 on the one line and not clamped on the other. > Does that explain it? > > A useful thing for TCPMSS for routers would be to clamp to the > minimum of the PMTU of both directions. But thats not supported > so far. > I wonder, as somteimes it gets clamped. If it would never have been clamped I wouldn't have asked. -- Andreas Steinmetz SPAMmers use [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: mss to pmtu clamping partially broken?
Patrick McHardy wrote: > Andreas Steinmetz wrote: >> There seems to be a problem with mss to pmtu clamping for incoming syn >> packets on reply to an outgoing connection on a ppp interface. The mss >> of the outgoing syn packets is always always clamped to the pmtu, I did >> check this with a target host I do have access to. The incoming syn >> reply to such a packet, however, is mss clamped only sometimes and this >> seems to depend on the DSL line used. >> >> The kernels tested were 2.6.20.1, 2.6.20.3 and 2.6.22rc6. >> >> Test setup: Two DSL lines, otherwise identical setup (same masquerading >> linux gateway, same DSL account, same DSL modem, same DSL line provider, >> same target host, request from and tcpdump on the same client). >> >> Linux Client<->Masquerading Linux Gateway<->DSL Modem<->DSL Line<->... >> >> DSL line 1, working: >> >> 22:26:39.319281 IP (tos 0x0, ttl 64, id 22377, offset 0, flags [DF], >> length: 48 >> ) 192.168.0.253.1164 > 64.34.165.170.80: S [tcp sum ok] >> 1465827859:1465827859(0) >> win 5840 >> 22:26:39.459314 IP (tos 0x0, ttl 51, id 0, offset 0, flags [DF], >> length: 48) 64 >> .34.165.170.80 > 192.168.0.253.1164: S [tcp sum ok] >> 3667852791:3667852791(0) ack >> 1465827860 win 5840 >> >> The tcpdump on the client shows that the mss of the incoming syn reply >> packet is clamped to the ppp interface mtu. >> >> DSL line 2, not working: >> >> 22:03:57.725998 IP (tos 0x0, ttl 64, id 55984, offset 0, flags [DF], >> length: 48 >> ) 192.168.0.253.1600 > 64.34.165.170.80: S [tcp sum ok] >> 36968258:36968258(0) win >> 5840 >> 22:03:57.866966 IP (tos 0x0, ttl 51, id 0, offset 0, flags [DF], >> length: 48) 64 >> .34.165.170.80 > 192.168.0.253.1600: S [tcp sum ok] >> 2226854208:2226854208(0) ack >> 36968259 win 5840 >> >> The tcpdump on the client shows that the mss of the incoming syn reply >> packet is *NOT* clamped to the ppp interface mtu. > > > You forgot to mention *how* you're clamping the MSS. Using > TCPMSS? Do you have a rule for incoming packets? > The relevant iptables commands I do use for masquerading and clamping are: iptables -t nat -A POSTROUTING -o ppp0 -j MASQUERADE iptables -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS \ --clamp-mss-to-pmtu -- Andreas Steinmetz SPAMmers use [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/
mss to pmtu clamping partially broken?
There seems to be a problem with mss to pmtu clamping for incoming syn packets on reply to an outgoing connection on a ppp interface. The mss of the outgoing syn packets is always always clamped to the pmtu, I did check this with a target host I do have access to. The incoming syn reply to such a packet, however, is mss clamped only sometimes and this seems to depend on the DSL line used. The kernels tested were 2.6.20.1, 2.6.20.3 and 2.6.22rc6. Test setup: Two DSL lines, otherwise identical setup (same masquerading linux gateway, same DSL account, same DSL modem, same DSL line provider, same target host, request from and tcpdump on the same client). Linux Client<->Masquerading Linux Gateway<->DSL Modem<->DSL Line<->... DSL line 1, working: 22:26:39.319281 IP (tos 0x0, ttl 64, id 22377, offset 0, flags [DF], length: 48 ) 192.168.0.253.1164 > 64.34.165.170.80: S [tcp sum ok] 1465827859:1465827859(0) win 5840 22:26:39.459314 IP (tos 0x0, ttl 51, id 0, offset 0, flags [DF], length: 48) 64 .34.165.170.80 > 192.168.0.253.1164: S [tcp sum ok] 3667852791:3667852791(0) ack 1465827860 win 5840 The tcpdump on the client shows that the mss of the incoming syn reply packet is clamped to the ppp interface mtu. DSL line 2, not working: 22:03:57.725998 IP (tos 0x0, ttl 64, id 55984, offset 0, flags [DF], length: 48 ) 192.168.0.253.1600 > 64.34.165.170.80: S [tcp sum ok] 36968258:36968258(0) win 5840 22:03:57.866966 IP (tos 0x0, ttl 51, id 0, offset 0, flags [DF], length: 48) 64 .34.165.170.80 > 192.168.0.253.1600: S [tcp sum ok] 2226854208:2226854208(0) ack 36968259 win 5840 The tcpdump on the client shows that the mss of the incoming syn reply packet is *NOT* clamped to the ppp interface mtu. -- Andreas Steinmetz SPAMmers use [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.20.3: kernel BUG at mm/slab.c:597 try#2
Andrew Morton wrote: > On Tue, 20 Mar 2007 00:25:02 +0100 > Andreas Steinmetz <[EMAIL PROTECTED]> wrote: > >> Mike Christie wrote: >>> Mike Christie wrote: >>>> James Bottomley wrote: >>>>> On Mon, 2007-03-19 at 12:49 -0500, Mike Christie wrote: >>>>>>> I can't even say if the tapes are written correctly as I can't read them >>>>>>> (one does not reboot production machines back to 2.4.x just to try to >>>>>>> read a backup tape - I don't have 2.6.x older than 2.6.20 on these >>>>>>> machines). >>>>>> Could you try this patch >>>>>> http://marc.info/?l=linux-scsi&m=116464965414878&w=2 >>>>>> I thought st was modified to not send offsets in the last elements but >>>>>> it looks like it wasn't. >>>>> Actually, there are two patches in the email referred to. If the >>>>> analysis that we're passing NULL to mempool_free is correct, it should >>>>> be the second one that fixes the problem (the one that checks >>>>> bio->bi_io_vec before freeing it). Which would mean we have a >>>>> nr_vecs==0 bio generated by the tar somehow. >>>>> >>>> I think we might only need the first patch if the problem is similar to >>>> what the lsi guys were seeing. I thought the problem is that we are not >>>> estimating how large the transfer is correctly because we do not take >>>> into account offsets at the end. This results in nr_vecs being zero when >>>> it should be a valid value. I thought Kai's patch: >>>> http://bugzilla.kernel.org/show_bug.cgi?id=7919 >>>> http://git.kernel.org/?p=linux/kernel/git/jejb/scsi-misc-2.6.git;a=commitdiff;h=9abe16c670bd3d4ab5519257514f9f291383d104 >>>> fixed the problem on st's side, >>> Oh, I noticed that the subject for the mail references 2.6.30.3 and the >>> patch for st in the bugzilla did not make into 2.6.20 and is not in .3. >>> Could we try the st patch in the bugzilla first? >> Ok, the st patch from bugzilla solves the problem (tested on both >> affected machines). > > > If you're referring to the below patch then it's already in mainline, and > has been for a month. > Yes, that's the patch I'm referring to. > Have you tested 2.6.21-rc4? If not, please do so. > Sorry, this is not possible on these machines. They are production servers and every problem on them that cannot be easily solved via remote access is a 40km (one way) drive in the middle of the night. > Perhaps we should merge this into 2.6.20.x? > I would suggest so. > > > commit 9abe16c670bd3d4ab5519257514f9f291383d104 > Author: Kai Makisara <[EMAIL PROTECTED]> > Date: Sat Feb 3 13:21:29 2007 +0200 > > [SCSI] st: fix Tape dies if wrong block size used, bug 7919 > > On Thu, 1 Feb 2007, Andrew Morton wrote: > > On Thu, 1 Feb 2007 15:34:29 -0800 > > [EMAIL PROTECTED] wrote: > > > > > http://bugzilla.kernel.org/show_bug.cgi?id=7919 > > > > > >Summary: Tape dies if wrong block size used > > > Kernel Version: 2.6.20-rc5 > > > Status: NEW > > > Severity: normal > > > Owner: [EMAIL PROTECTED] > > > Submitter: [EMAIL PROTECTED] > > > > > > > > > Most recent kernel where this bug did *NOT* occur: 2.6.17.14 > > > > > > Other Kernels Tested and Results: > > > > > > OK 2.6.15.7 > > > OK 2.6.16.37 > > > OK 2.6.17.14 > > > BAD 2.6.18.6 > > > BAD 2.6.18-1.2869.fc6 > > > BAD 2.6.19.2 + > > > BAD 2.6.20-rc5 > > > > > > NOTE: 2.6.18-1.2869.fc6 is a Fedora modified kernel, all others are > from kernel.org > > > > ... > > > Steps to reproduce: > > > Get a Adaptec AHA-2940U/UW/D / AIC-7881U card and a tape drive, > > > install a recent kernel > > > set the tape block size - mt setblk 4096 > > > read from or write to tape using wrong block size - tar -b 7 -cvf > /dev/tape foo > > > > Write does not trigger this bug because the driver refuses in fixed block > mode writes that are not a multiple of the block size. Read does trigger > it in my system. > > The bug is not associated with any specific HBA. st tries to
Re: [PATCH] slab: deal with NULL pointers passed to kmem_cache_free
Pekka J Enberg wrote:
> From: Pekka Enberg <[EMAIL PROTECTED]>
>
> This changes kmem_cache_free() to deal with NULL objects passed to it. The
> current behavior is inconsistent with kfree() so there are callers
> passing NULL to kmem_cache_free().
>
> Andreas, can you please confirm this fixes the oops you reported on
> linux-scsi?
>
Didn't test this as Mike Christie pointed me to a working fix for the st
driver.
> Cc: Andreas Steinmetz <[EMAIL PROTECTED]>
> Cc: Christoph Lameter <[EMAIL PROTECTED]>
> Signed-off-by: Pekka Enberg <[EMAIL PROTECTED]>
> ---
> mm/slab.c |5 +
> 1 file changed, 5 insertions(+)
>
> Index: 2.6/mm/slab.c
> ===
> --- 2.6.orig/mm/slab.c2007-03-19 10:18:52.0 +0200
> +++ 2.6/mm/slab.c 2007-03-19 10:19:42.0 +0200
> @@ -3741,6 +3741,8 @@ EXPORT_SYMBOL(__kmalloc);
> * @cachep: The cache the allocation was from.
> * @objp: The previously allocated object.
> *
> + * If @objp is NULL, no operation is performed.
> + *
> * Free an object which was previously allocated from this
> * cache.
> */
> @@ -3748,6 +3750,9 @@ void kmem_cache_free(struct kmem_cache *
> {
> unsigned long flags;
>
> + if (unlikely(!objp))
> + return;
> +
> BUG_ON(virt_to_cache(objp) != cachep);
>
> local_irq_save(flags);
--
Andreas Steinmetz SPAMmers use [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/
2.6.20.3 NFS: BUG at fs/nfs/pagelist.c:339
Got this from a nfs booted 2.6.20.3 x86 system (complete diskless boot): BUG: at fs/nfs/pagelist.c:339 nfs_scan_dirty() [] nfs_scan_dirty+0x17e/0x18a [] generic_writepages+0x224/0x2b6 [] nfs_wait_on_requests_locked+0x80/0x8e [] nfs_sync_mapping_wait+0x9d/0x14b [] __link_path_walk+0x854/0x943 [] nfs_sync_mapping_range+0x97/0xb6 [] nfs_getattr+0x3a/0x96 [] nfs_getattr+0x0/0x96 [] vfs_getattr+0x21/0x30 [] vfs_lstat_fd+0x2b/0x3d [] free_pgtables+0x7e/0x8a [] sys_lstat64+0xf/0x23 [] remove_vma+0x36/0x3b [] remove_vma_list+0x40/0x4a [] do_munmap+0xf3/0xff [] sys_munmap+0x30/0x35 [] syscall_call+0x7/0xb -- Andreas Steinmetz SPAMmers use [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.20.3: kernel BUG at mm/slab.c:597 try#2
Mike Christie wrote:
> James Bottomley wrote:
>> On Mon, 2007-03-19 at 12:49 -0500, Mike Christie wrote:
>>>> I can't even say if the tapes are written correctly as I can't read them
>>>> (one does not reboot production machines back to 2.4.x just to try to
>>>> read a backup tape - I don't have 2.6.x older than 2.6.20 on these
>>>> machines).
>>> Could you try this patch
>>> http://marc.info/?l=linux-scsi&m=116464965414878&w=2
>>> I thought st was modified to not send offsets in the last elements but
>>> it looks like it wasn't.
>> Actually, there are two patches in the email referred to. If the
>> analysis that we're passing NULL to mempool_free is correct, it should
>> be the second one that fixes the problem (the one that checks
>> bio->bi_io_vec before freeing it). Which would mean we have a
>> nr_vecs==0 bio generated by the tar somehow.
>>
>
> I think we might only need the first patch if the problem is similar to
> what the lsi guys were seeing. I thought the problem is that we are not
> estimating how large the transfer is correctly because we do not take
> into account offsets at the end. This results in nr_vecs being zero when
> it should be a valid value. I thought Kai's patch:
> http://bugzilla.kernel.org/show_bug.cgi?id=7919
> http://git.kernel.org/?p=linux/kernel/git/jejb/scsi-misc-2.6.git;a=commitdiff;h=9abe16c670bd3d4ab5519257514f9f291383d104
> fixed the problem on st's side, but I guess not so you are probably right.
>
> Here is a patch that dumps the sgl we are getting from st so we can see
> for sure what we are getting and can decide if we need the first patch,
> second patch or both.
>
Here's the patch output:
sg length 6 offset 0
sg length 12 offset 0
sg length 4096 offset 0
sg length 4096 offset 0
sg length 2048 offset 0
Please note (as replied in the other mail) that the bugzilla patch
solves the problem.
>
>
>
> diff --git a/drivers/scsi/scsi_lib.c b/drivers/scsi/scsi_lib.c
> index 5f95570..81005aa 100644
> --- a/drivers/scsi/scsi_lib.c
> +++ b/drivers/scsi/scsi_lib.c
> @@ -306,6 +306,10 @@ static int scsi_req_map_sg(struct reques
> struct bio *bio = NULL;
> int i, err, nr_vecs = 0;
>
> + for (i = 0; i < nsegs; i++)
> + printk(KERN_INFO "sg length %u offset %u\n", sgl[i].length,
> + sgl[i].offset);
> +
> for (i = 0; i < nsegs; i++) {
> page = sgl[i].page;
> off = sgl[i].offset;
--
Andreas Steinmetz SPAMmers use [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.20.3: kernel BUG at mm/slab.c:597 try#2
Mike Christie wrote: > Mike Christie wrote: >> James Bottomley wrote: >>> On Mon, 2007-03-19 at 12:49 -0500, Mike Christie wrote: >>>>> I can't even say if the tapes are written correctly as I can't read them >>>>> (one does not reboot production machines back to 2.4.x just to try to >>>>> read a backup tape - I don't have 2.6.x older than 2.6.20 on these >>>>> machines). >>>> Could you try this patch >>>> http://marc.info/?l=linux-scsi&m=116464965414878&w=2 >>>> I thought st was modified to not send offsets in the last elements but >>>> it looks like it wasn't. >>> Actually, there are two patches in the email referred to. If the >>> analysis that we're passing NULL to mempool_free is correct, it should >>> be the second one that fixes the problem (the one that checks >>> bio->bi_io_vec before freeing it). Which would mean we have a >>> nr_vecs==0 bio generated by the tar somehow. >>> >> I think we might only need the first patch if the problem is similar to >> what the lsi guys were seeing. I thought the problem is that we are not >> estimating how large the transfer is correctly because we do not take >> into account offsets at the end. This results in nr_vecs being zero when >> it should be a valid value. I thought Kai's patch: >> http://bugzilla.kernel.org/show_bug.cgi?id=7919 >> http://git.kernel.org/?p=linux/kernel/git/jejb/scsi-misc-2.6.git;a=commitdiff;h=9abe16c670bd3d4ab5519257514f9f291383d104 >> fixed the problem on st's side, > > Oh, I noticed that the subject for the mail references 2.6.30.3 and the > patch for st in the bugzilla did not make into 2.6.20 and is not in .3. > Could we try the st patch in the bugzilla first? Ok, the st patch from bugzilla solves the problem (tested on both affected machines). -- Andreas Steinmetz SPAMmers use [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/
2.6.20.3: kernel BUG at mm/slab.c:597 try#2
As posted to lkml and linux-scsi on 2007-03-15 without reply, see http://marc.info/?l=linux-kernel&m=117395128412313&w=2 for original post: It is not so nice when one can write backup tapes but the tapes cannot be read. I don't know if memory management or the st driver is the culprit, but this is a not so nice situation. I can't even say if the tapes are written correctly as I can't read them (one does not reboot production machines back to 2.4.x just to try to read a backup tape - I don't have 2.6.x older than 2.6.20 on these machines). -- Andreas Steinmetz SPAMmers use [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.20.3: kswapd page allocation failure
Mariusz Kozlowski wrote: > Hello, > >> Got the following from dmesg of one of my servers last night (happened >> during nightly backup over network): >> >> kswapd0: page allocation failure. order:3, mode:0x20 > > Take a look at this: > > http://lkml.org/lkml/2007/3/15/90 > > Regards, > > Mariusz Kozlowski Thanks, I'll test "echo 16384 > /proc/sys/vm/min_free_kbytes" and see what happens. -- Andreas Steinmetz SPAMmers use [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/
2.6.20.3: kswapd page allocation failure
[] wake_up_bit+0xb/0x16 [] dispose_list+0x88/0xa4 [] prune_icache+0x136/0x148 [] shrink_icache_memory+0x14/0x2b [] shrink_slab+0x135/0x18e [] balance_pgdat+0x1e6/0x2eb [] kswapd+0xf5/0xf7 [] autoremove_wake_function+0x0/0x33 [] __wake_up_common+0x35/0x56 [] autoremove_wake_function+0x0/0x33 [] kswapd+0x0/0xf7 [] kthread+0x72/0x97 [] kthread+0x0/0x97 [] kernel_thread_helper+0x7/0x10 === Mem-info: DMA per-cpu: CPU0: Hot: hi:0, btch: 1 usd: 0 Cold: hi:0, btch: 1 usd: 0 Normal per-cpu: CPU0: Hot: hi: 186, btch: 31 usd: 143 Cold: hi: 62, btch: 15 usd: 2 HighMem per-cpu: CPU0: Hot: hi: 42, btch: 7 usd: 40 Cold: hi: 14, btch: 3 usd: 2 Active:171834 inactive:59703 dirty:846 writeback:0 unstable:0 free:2311 slab:20911 mapped:4658 pagetables:765 DMA free:3536kB min:68kB low:84kB high:100kB active:5152kB inactive:1232kB present:16256kB pages_scanned:0 all_unreclaimable? no lowmem_reserve[]: 0 873 1000 Normal free:5448kB min:3744kB low:4680kB high:5616kB active:569208kB inactive:228308kB present:894080kB pages_scanned:0 all_unreclaimable? no lowmem_reserve[]: 0 0 1015 HighMem free:260kB min:128kB low:264kB high:400kB active:112976kB inactive:9272kB present:129988kB pages_scanned:0 all_unreclaimable? no lowmem_reserve[]: 0 0 0 DMA: 40*4kB 36*8kB 15*16kB 1*32kB 0*64kB 0*128kB 1*256kB 1*512kB 0*1024kB 1*2048kB 0*4096kB = 3536kB Normal: 152*4kB 491*8kB 45*16kB 0*32kB 1*64kB 1*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 5448kB HighMem: 1*4kB 18*8kB 1*16kB 1*32kB 1*64kB 0*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 260kB Swap cache: add 132, delete 132, find 0/0, race 0+0 Free swap = 16064704kB Total swap = 16064704kB Free swap: 16064704kB 262128 pages of RAM 32752 pages of HIGHMEM 3672 reserved pages 82110 pages shared 0 pages swap cached 846 pages dirty 0 pages writeback 4658 pages mapped 20911 pages slab 765 pages pagetables -- Andreas Steinmetz SPAMmers use [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/
2.6.20.3: kernel BUG at mm/slab.c:597
Got the following on executing "tar tpf /dev/st0l" on two different
systems (x86):
kernel BUG at mm/slab.c:597!
invalid opcode: [#1]
Modules linked in: sg st sym53c8xx netconsole tg3 e1000
CPU:0
EIP:0060:[]Not tainted VLI
EFLAGS: 00010246 (2.6.20.3-luna #1)
EIP is at kmem_cache_free+0x29/0x5a
eax: c180 ebx: f0ae12c0 ecx: c18f73c0 edx: c180
esi: c1919de0 edi: ebp: 1000 esp: f1fe7e14
ds: 007b es: 007b ss: 0068
Process tar (pid: 17153, ti=f1fe6000 task=f7106a70 task.ti=f1fe6000)
Stack: f0ae12c0 c1919de0 ffea c0137f97 f0ae12c0 c1919e20
c0168d45
f0ae12c0 1000 c0168fb9 c02a77e3 1000
c17bb6e0 1000 f1b38be8 0003 f54ac050
c1b9d6e8
Call Trace:
[] mempool_free+0x48/0x4c
[] bio_free+0x21/0x2c
[] bio_put+0x22/0x23
[] scsi_req_map_sg+0x150/0x19b
[] scsi_execute_async+0x96/0x175
[] st_do_scsi+0x14d/0x19f [st]
[] st_sleep_done+0x0/0x35 [st]
[] read_tape+0x11d/0x3ad [st]
[] st_read+0x1d7/0x2d6 [st]
[] vfs_read+0x8a/0x12f
[] sys_read+0x41/0x67
[] syscall_call+0x7/0xb
===
Code: 5f c3 57 89 c1 89 d7 8d 92 00 00 00 40 56 c1 ea 0c 53 c1 e2 05 03
15 40 5d
5a c0 8b 02 f6 c4 40 74 03 8b 52 0c 8b 02 a8 80 75 04 <0f> 0b eb fe 39
4a 18 74
04 0f 0b eb fe 9c 5e fa 8b 19 8b 03 3b
EIP: [] kmem_cache_free+0x29/0x5a SS:ESP 0068:f1fe7e14
BUG: at drivers/scsi/st.c:2516 st_int_ioctl()
[] st_int_ioctl+0x64/0x999 [st]
[] st_flush+0x253/0x26d [st]
[] dput+0x22/0x112
[] filp_close+0x32/0x54
[] close_files+0x46/0x55
[] put_files_struct+0x14/0x3c
[] do_exit+0x1c6/0x314
[] die+0x197/0x19f
[] do_trap+0x76/0xa2
[] do_invalid_op+0x0/0x99
[] do_invalid_op+0x90/0x99
[] kmem_cache_free+0x29/0x5a
[] wait_for_completion+0x69/0x93
[] default_wake_function+0x0/0xc
[] mempool_alloc+0x28/0xa4
[] blk_alloc_request+0x3c/0x5d
[] error_code+0x74/0x7c
[] kmem_cache_free+0x29/0x5a
[] mempool_free+0x48/0x4c
[] bio_free+0x21/0x2c
[] bio_put+0x22/0x23
[] scsi_req_map_sg+0x150/0x19b
[] scsi_execute_async+0x96/0x175
[] st_do_scsi+0x14d/0x19f [st]
[] st_sleep_done+0x0/0x35 [st]
[] read_tape+0x11d/0x3ad [st]
[] st_read+0x1d7/0x2d6 [st]
[] vfs_read+0x8a/0x12f
[] sys_read+0x41/0x67
[] syscall_call+0x7/0xb
===
[ cut here ]
kernel BUG at mm/slab.c:597!
invalid opcode: [#2]
Modules linked in: sg st sym53c8xx netconsole tg3 e1000
CPU:0
EIP:0060:[]Not tainted VLI
EFLAGS: 00010246 (2.6.20.3-luna #1)
EIP is at kmem_cache_free+0x29/0x5a
eax: c180 ebx: f0ae1cc0 ecx: c18f73c0 edx: c180
esi: c1919de0 edi: ebp: 1000 esp: f1fe7afc
ds: 007b es: 007b ss: 0068
Process tar (pid: 17153, ti=f1fe6000 task=f7106a70 task.ti=f1fe6000)
Stack: f0ae1cc0 c1919de0 ffea c0137f97 f0ae1cc0 c1919e20
c0168d45
f0ae1cc0 1000 c0168fb9 c02a77e3 1000
c17bb6e0 1000 f1b38be8 0003 f54ac050
c1b9d298
Call Trace:
[] mempool_free+0x48/0x4c
[] bio_free+0x21/0x2c
[] bio_put+0x22/0x23
[] scsi_req_map_sg+0x150/0x19b
[] scsi_execute_async+0x96/0x175
[] st_do_scsi+0x14d/0x19f [st]
[] st_sleep_done+0x0/0x35 [st]
[] st_int_ioctl+0x63b/0x999 [st]
[] st_flush+0x253/0x26d [st]
[] dput+0x22/0x112
[] filp_close+0x32/0x54
[] close_files+0x46/0x55
[] put_files_struct+0x14/0x3c
[] do_exit+0x1c6/0x314
[] die+0x197/0x19f
[] do_trap+0x76/0xa2
[] do_invalid_op+0x0/0x99
[] do_invalid_op+0x90/0x99
[] kmem_cache_free+0x29/0x5a
[] wait_for_completion+0x69/0x93
[] default_wake_function+0x0/0xc
[] mempool_alloc+0x28/0xa4
[] blk_alloc_request+0x3c/0x5d
[] error_code+0x74/0x7c
[] kmem_cache_free+0x29/0x5a
[] mempool_free+0x48/0x4c
[] bio_free+0x21/0x2c
[] bio_put+0x22/0x23
[] scsi_req_map_sg+0x150/0x19b
[] scsi_execute_async+0x96/0x175
[] st_do_scsi+0x14d/0x19f [st]
[] st_sleep_done+0x0/0x35 [st]
[] read_tape+0x11d/0x3ad [st]
[] st_read+0x1d7/0x2d6 [st]
[] vfs_read+0x8a/0x12f
[] sys_read+0x41/0x67
[] syscall_call+0x7/0xb
===
Code: 5f c3 57 89 c1 89 d7 8d 92 00 00 00 40 56 c1 ea 0c 53 c1 e2 05 03
15 40 5d
5a c0 8b 02 f6 c4 40 74 03 8b 52 0c 8b 02 a8 80 75 04 <0f> 0b eb fe 39
4a 18 74
04 0f 0b eb fe 9c 5e fa 8b 19 8b 03 3b
EIP: [] kmem_cache_free+0x29/0x5a SS:ESP 0068:f1fe7afc
<1>Fixing recursive fault but reboot is needed!
--
Andreas Steinmetz SPAMmers use [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: Recent and not-so problems with tifm_sd driver - one more
Brad Campbell wrote: > Alex, it's still hit and miss getting this card detected. I had to > insert/remove the card over 10 times with random driver load/unloads > until it created the device entries.. And for me it's still worse, no matter what I try with 2.6.20: speedy:~ # find /sys/devices | grep tifm /sys/devices/pci:00/:00:14.4/:03:09.3/tifm_sd0:3 /sys/devices/pci:00/:00:14.4/:03:09.3/tifm_sd0:3/mmc_host:mmc0 /sys/devices/pci:00/:00:14.4/:03:09.3/tifm_sd0:3/driver /sys/devices/pci:00/:00:14.4/:03:09.3/tifm_sd0:3/bus /sys/devices/pci:00/:00:14.4/:03:09.3/tifm_sd0:3/subsystem /sys/devices/pci:00/:00:14.4/:03:09.3/tifm_sd0:3/power /sys/devices/pci:00/:00:14.4/:03:09.3/tifm_sd0:3/power/wakeup /sys/devices/pci:00/:00:14.4/:03:09.3/tifm_sd0:3/uevent speedy:~ # find /sys/block | grep mmc speedy:~ # -- Andreas Steinmetz SPAMmers use [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.20] tifm_7xx1/mmc not working
Alex Dubov wrote: > I'm aware that there are some weird problems with a 2.6.20. I'm currently > looking into it. > > Besides, I wonder, are tifm and sdhci play nicely together? And then, we do > know that suspend is > totally broken in the older versions of the driver. So it may be desirable to > make a test with > sdhci unloaded and machine freshly rebooted (not resumed). > I tried exactly as described (fresh cold boot, sdhci never loaded), but the described problem remains. If there is anything I can do to help to trace this problem let me know. -- Andreas Steinmetz SPAMmers use [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/
[2.6.20] tifm_7xx1/mmc not working
Hi, I do have a problem with tifm_7xx1 and 2.6.20. First of all, the device is working with 2.6.18.2 and the out of tree tifm-0.6 release. In this case except for the first card insertion after suspend/reboot I do get the following messages: tifm_7xx1: sd card detected in socket 3 mmcblk0: mmc0:7d7f SD01G 1006080KiB mmcblk0: p1 With 2.6.20, however, I always do get only the following which is the same as for 2.6.18.2 on first card insert after reboot/suspend: tifm_7xx1: sd card detected in socket 3 Am I doing something wrong here or is there a problem? Relevant modules loaded with 2.6.20: mmc_block 7944 0 tifm_sd10824 0 tifm_7xx1 7296 0 sdhci 17548 0 tifm_core 7960 2 tifm_sd,tifm_7xx1 mmc_core 24096 3 mmc_block,tifm_sd,sdhci -- Andreas Steinmetz SPAMmers use [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/
[2.6.20] net/ieee80211/ieee80211_crypt_tkip.c spams kernel message buffer
net/ieee80211/ieee80211_crypt_tkip.c outputs tons of these which didn't happen with 2.6.18.2 (only one or two of these after enabling the ipw2200 with the kill switch): TKIP: replay detected: STA=00:0e:2e:94:84:c3 previous TSC 0200 received TSC 0002e560 printk: 19 messages suppressed. TKIP: replay detected: STA=00:0e:2e:94:84:c3 previous TSC 0200 received TSC 0002e574 printk: 19 messages suppressed. TKIP: replay detected: STA=00:0e:2e:94:84:c3 previous TSC 0200 received TSC 0002e588 printk: 18 messages suppressed. TKIP: replay detected: STA=00:0e:2e:94:84:c3 previous TSC 0200 received TSC 0002e59b printk: 19 messages suppressed. TKIP: replay detected: STA=00:0e:2e:94:84:c3 previous TSC 0200 received TSC 0002e5af printk: 19 messages suppressed. TKIP: replay detected: STA=00:0e:2e:94:84:c3 previous TSC 0200 received TSC 0002e5c3 printk: 19 messages suppressed. TKIP: replay detected: STA=00:0e:2e:94:84:c3 previous TSC 0200 received TSC 0002e5d7 printk: 19 messages suppressed. TKIP: replay detected: STA=00:0e:2e:94:84:c3 previous TSC 0200 received TSC 0002e5eb printk: 19 messages suppressed. TKIP: replay detected: STA=00:0e:2e:94:84:c3 previous TSC 0200 received TSC 0002e5ff printk: 16 messages suppressed. TKIP: replay detected: STA=00:0e:2e:94:84:c3 previous TSC 0200 received TSC 0002e612 printk: 17 messages suppressed. TKIP: replay detected: STA=00:0e:2e:94:84:c3 previous TSC 0200 received TSC 0002e626 -- Andreas Steinmetz SPAMmers use [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: oops in VMWARE vmnet, on 2.6.12.x
Grzegorz Piotr Jaskiewicz wrote: > I know that in general no one here is interested in vmware affairs, but in > hope that VMware folks are reading this list too, here's the oops: > It's the newest vmware5 for linux from vmware.com ftp://platan.vc.cvut.cz/pub/vmware/vmware-any-any-update93.tar.gz -- Andreas Steinmetz SPAMmers use [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: Wireless support
Lee Revell wrote: > On Mon, 2005-08-08 at 20:13 +0200, Andreas Steinmetz wrote: > >>I gave up on my laptop's built in Inprocomm IPN 2220 quite some time ago >>(one more reason not to like Cisco). In the rare cases I do really need >>wlan there is http://zd1211.sourceforge.net/ > > > Any idea how much hardware is out there that needs ndiswrapper to work? No real idea but an educated guess: too much... -- Andreas Steinmetz SPAMmers use [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: Wireless support
Arjan van de Ven wrote: > On Mon, 2005-08-08 at 13:48 -0400, Lee Revell wrote: > >>On Mon, 2005-08-08 at 09:31 +0300, Denis Vlasenko wrote: >> >>>On Monday 08 August 2005 03:39, Alejandro Bonilla Beeche wrote: >>> >>>>On Sun, 2005-08-07 at 15:22 -0400, Lee Revell wrote: >>>> >>>>>Is the Linksys WUSB 54GS wireless adapter (FCCID Q87-WUSB54GS) >>>>>supported? >>>> >>>>Normally, linksys doesn't care much about Linux and they won't even >>>>release info for a driver. Yeah, they have some open info for the WRT's >>>>but the adapters are normally usable with ndiswrapper or Linuxant >>>>driver. >>> >>>The more I read this, the more I think about usefulness of blacklisting >>>ndiswrapper. >> >>What's your reasoning? The technical aspect of the argument is obvious >>(incompatible with 4K stacks) but the political side seems insolvable. >>Wouldn't this leave thousands of users with non working hardware?\ > > > arguably it doesn't really work with ndiswrapper either; only most of > the time (due to windows having a 12kb stack)... and it's effectively a > binary only kernel module. > > it also provides a discentive for vendors to provide real linux > drivers > Oh well, I gave up on my laptop's built in Inprocomm IPN 2220 quite some time ago (one more reason not to like Cisco). In the rare cases I do really need wlan there is http://zd1211.sourceforge.net/ You can get it to work on x86_64. It currently has no wpa but I don't care, IPSec is a proven solution. The code looks ugly but time will show how it evolves. And about 40 EUR for the Longshine LCS-8170 802.11b/g and Bluetooth 1.2 combo adapter isn't really expensive. The only drawback is that it is another piece of external hardware to carry around as well as some more laptop built in crap. -- Andreas Steinmetz SPAMmers use [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.13-rc4: yenta_socket and swsusp
Andrew Morton wrote: > OK so we have one solid regression there. Are the other problems also new > since 2.6.11? > > Could you please retest 2.6.13-rc6 when it's out and if problems remain, > raise a bugzilla.kernel.org entry so we can keep track of the problem? > Thanks. After retesting with 2.6.13-rc6 quite some of the problems are gone. There are, however, still problems: 1. It is necessary to do the following or suspend will hang: cardctl eject killproc cardmgr remove all pcmcia modules In 2.6.11 it was sufficient to call 'cardctl eject'. I'll create a bug report. 2. The attached script can produce all sorts of pcmcia related problems if it is modified where stated - the attached version seems to work without problems if not modified. Do you want a bug report filed for this, too? -- Andreas Steinmetz SPAMmers use [EMAIL PROTECTED] pcmcia.sh Description: Bourne shell script
Re: amd64-agp vs. swsusp
Cal Peake wrote: > On Fri, 5 Aug 2005, Andreas Steinmetz wrote: > > >>AFAIK it works when agp is built into the kernel. You will get problems >>when it is built as a module. In the module case you may want to try if >>loading the module before resuming helps. > > > Strange. I've had it built as a module from day one and never had a > problem resuming. I guess it depends on what the BIOS does. -- Andreas Steinmetz SPAMmers use [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: amd64-agp vs. swsusp
Cal Peake wrote: > On Thu, 4 Aug 2005, Andrew Morton wrote: > > >>Michal Schmidt <[EMAIL PROTECTED]> wrote: >> >>>Does resuming from swsuspend work for anyone with amd64-agp loaded? >> >>It would seem not ;) > > > Must have missed the OP. Yes I can resume fine from swsusp with amd64-agp. > > System is an Averatec 3270 (Mobile Sempron(K8)). > > Not that this helps at all other than confirming it is possible ;) > > -cp > AFAIK it works when agp is built into the kernel. You will get problems when it is built as a module. In the module case you may want to try if loading the module before resuming helps. -- Andreas Steinmetz SPAMmers use [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/
2.6.13-rc4-git4: bluetooth oops on pcmcia shutdown
The attached bluetooth oops can be reliably reproduced on my x86_64
laptop. It happens when hciattach is still running while a sequence of
"cardctl eject" and then "killproc /sbin/cardmgr" is executed.
Though this seems to point to preempt I could manage to cause similar
oopses on non-preemptible kernels a while ago.
--
Andreas Steinmetz SPAMmers use [EMAIL PROTECTED]
Unable to handle kernel NULL pointer dereference at 0014 RIP:
{uart_flush_buffer+43}
PGD 0
Oops: 0002 [1] PREEMPT
CPU 0
Modules linked in: hci_usb serial_cs pcmcia yenta_socket rsrc_nonstatic
pcmcia_core ehci_hcd uhci_hcd parport_pc parport snd_via82xx_modem snd_seq_oss
snd_seq_midi_event snd_seq snd_pcm_oss snd_mixer_oss hfc_usb ipaq usbhid pl2303
usbserial usb_storage snd_via82xx gameport sd_mod snd_ac97_codec snd_pcm
snd_timer snd_page_alloc snd_mpu401_uart snd_rawmidi snd_seq_device hisax isdn
nls_iso8859_15 nls_cp850 ip_conntrack_ftp ipt_state ip_conntrack ipt_ULOG
iptable_filter ipt_REJECT ip_tables nfsd exportfs lockd sunrpc autofs4 cifs sbp2
Pid: 2995, comm: hciattach Not tainted 2.6.13-rc4-git4-gringo
RIP: 0010:[] {uart_flush_buffer+43}
RSP: 0018:81001c0b9b68 EFLAGS: 00010013
RAX: RBX: 810002208c80 RCX: 81001e6d3018
RDX: RSI: 81001c0b9b58 RDI: 0001
RBP: 81001e6d3000 R08: 81003f01ce98 R09: 0001
R10: R11: 0246 R12: 81003d76ba80
R13: 8052e6c0 R14: R15:
FS: 2af3edb0() GS:8061c800() knlGS:556d16b0
CS: 0010 DS: ES: CR0: 8005003b
CR2: 0014 CR3: 1b1a2000 CR4: 06e0
Process hciattach (pid: 2995, threadinfo 81001c0b8000, task
81001f94f4a0)
Stack: 0292 81003db82200 81001e6d3000 803567ac
81003db82200 81002614ac00 803567e4
8052e6c0 80356931
Call Trace:{hci_uart_flush+92}
{hci_uart_close+20}
{hci_uart_tty_close+49}
{release_dev+1805}
{free_hot_cold_page+239}
{free_pgd_range+1078}
{_atomic_dec_and_lock+38} {dput+35}
{tty_release+17} {__fput+178}
{filp_close+110}
{put_files_struct+115}
{do_exit+522} {__dequeue_signal+501}
{do_group_exit+269}
{get_signal_to_deliver+1515}
{do_signal+159} {thread_return+0}
{thread_return+220}
{lock_timer_base+49}
{del_timer+104}
{schedule_timeout+156}
{process_timeout+0}
{sysret_signal+28}
{ptregscall_common+103}
Code: c7 40 14 00 00 00 00 c7 40 10 00 00 00 00 ff 34 24 9d bf 01
RIP {uart_flush_buffer+43} RSP
CR2: 0014
<1>Fixing recursive fault but reboot is needed!
scheduling while atomic: hciattach/0x0001/2995
Call Trace:{schedule+122} {do_exit+246}
{do_unblank_screen+21}
{do_page_fault+1807}
{error_exit+0} {uart_flush_buffer+43}
{uart_flush_buffer+39}
{hci_uart_flush+92}
{hci_uart_close+20}
{hci_uart_tty_close+49}
{release_dev+1805}
{free_hot_cold_page+239}
{free_pgd_range+1078}
{_atomic_dec_and_lock+38}
{dput+35} {tty_release+17}
{__fput+178} {filp_close+110}
{put_files_struct+115} {do_exit+522}
{__dequeue_signal+501}
{do_group_exit+269}
{get_signal_to_deliver+1515}
{do_signal+159}
{thread_return+0} {thread_return+220}
{lock_timer_base+49} {del_timer+104}
{schedule_timeout+156}
{process_timeout+0}
{sysret_signal+28}
{ptregscall_common+103}
2.6.13-rc4: yenta_socket and swsusp
[now sending to lkml as sending to the pcmcia list without being subscribed seems to go to /dev/null] I do have problems with yenta_socket on my x86_64 laptop which appear when using swsusp (suspend to disk mode). 1. When I do not access any pcmcia device from initrd during boot I have to terminate cardmgr, otherwise suspend to disk hangs. For 2.6.11 it was sufficient to call 'cardctl eject'. 2. When I have to access a pcmcia device from initrd during boot (there's required crypto keys stored on a pcmcia flash disk) and I do not unload yenta_socket prior to suspend the laptop spontaneously reboots or just hangs on resume when swsusp has finished loading. 3. If I do not unload the pcmcia modules prior to suspend with rmmod -w unloading yenta_socket fails. 4. If I do unload the pcmcia modules in a loop with rmmod -w but no delay between unloading the modules it happens from time to time that yenta_socket unloading hangs with a use count of 2 when there is definitely no more user of the module. A delay of 50 msec after unload of each pcmcia module seems to cure this. 5. If I insert yenta_socket within the first few seconds after resume the laptop spontaneously reboots. A 5 second delay seems to cure this most of the time. BTW: Did I read this right? PCMCIA control ioctl (needed for pcmcia-cs [cardmgr, cardctl]) scheduled for removal in november *this* year? So a 3 month warning for everybody is sufficient? Probably only one kernel release? So much for sufficient backwards compatability. Especially as the tools stated to be required aren't even released as of today (hint: module-init-tools 3.2). Grrr. -- Andreas Steinmetz SPAMmers use [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: revert yenta free_irq on suspend
Dave Jones wrote: > On Mon, Aug 01, 2005 at 02:00:16AM +0200, Andreas Steinmetz wrote: > > > gringo:~ # fdisk -l /dev/hda > > > > Disk /dev/hda: 80.0 GB, 80026361856 bytes > > 255 heads, 63 sectors/track, 9729 cylinders > > Units = cylinders of 16065 * 512 = 8225280 bytes > > > >Device Boot Start End Blocks Id System > > /dev/hda11 244 1959898+ 83 Linux > > /dev/hda2 245 488 1959930 82 Linux swap / Solaris > > /dev/hda3 489 732 1959930 82 Linux swap / Solaris > > /dev/hda4 733 972972268402+ 5 Extended > > /dev/hda5 733 976 1959898+ 82 Linux swap / Solaris > > /dev/hda6 977 972970308441 88 Linux plaintext (*) > > > > (*) dm-crypt :-) > > Your swap partitions are outside of your lv's. Right, then this could be the problem you encountered. However the swap partitions are set up with dm-crypt including the partition I do resume from so I'm using device mapper to resume which is quite close to LVM. -- Andreas Steinmetz SPAMmers use [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: revert yenta free_irq on suspend
Dave Jones wrote: > On Sun, Jul 31, 2005 at 01:03:56AM -0400, Brown, Len wrote: > > > But that believe would be total fantasy -- supsend/resume is not > > working on a large number of machines, and no distro is currently > > able to support it. (I'm talking about S3 suspend to RAM primarily, > > suspend to disk is less interesting -- though Red Hat doesn't > > even support _that_) > > After the 'swsusp works just fine' lovefest at OLS, I spent a little > while playing with the current in-tree swsusp implementation last week. > > The outcome: I'm no more enthusiastic about enabling this in Red Hat > kernels than I ever was before. It seems to have real issues with LVM > setups (which is default on Red Hat/Fedora installs these days). > After convincing it where to suspend/resume from by feeding it > the major/minor of my swap partition, it did actually seem > to suspend. And resume (though it did spew lots of 'sleeping whilst > atomic warnings, but thats trivial compared to whats coming up next). > > I rebooted, and fsck found all sorts of damage on my / partition. > After spending 30 minutes pressing 'y', to fix things up, it failed > to boot after lots of files were missing. > Why it wrote anything to completely different lv to where I told it > (and yes, I did get the major:minor right) I have no idea, but > as it stands, it definitly isn't production-ready. > > I'll look into it again sometime soon, but not until after I've > reinstalled my laptop. (I'm just thankful I had the sense not to > try this whilst I was at OLS). Hmm, I'm using swsusp on my x86_64 laptop with lvm and dm-crypt. Works just fine except for nasty spontaneous reboots from time to time caused by yenta_socket (I do get these since I started to access my pcmcia flash disk from initrd to retrieve the dm-crypt swap key). It does work since at least 2.6.11 up to 2.6.13-rc4 and if the yenta_socket caused spontaneous reboots after resume could be fixed I'd call it production ready. gringo:~ # fdisk -l /dev/hda Disk /dev/hda: 80.0 GB, 80026361856 bytes 255 heads, 63 sectors/track, 9729 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes Device Boot Start End Blocks Id System /dev/hda11 244 1959898+ 83 Linux /dev/hda2 245 488 1959930 82 Linux swap / Solaris /dev/hda3 489 732 1959930 82 Linux swap / Solaris /dev/hda4 733 972972268402+ 5 Extended /dev/hda5 733 976 1959898+ 82 Linux swap / Solaris /dev/hda6 977 972970308441 88 Linux plaintext (*) (*) dm-crypt :-) gringo:~ # vgdisplay --- Volume group --- VG Name rootvg System ID Formatlvm2 Metadata Areas1 Metadata Sequence No 27 VG Access read/write VG Status resizable MAX LV0 Cur LV8 Open LV 8 Max PV0 Cur PV1 Act PV1 VG Size 67.05 GB PE Size 4.00 MB Total PE 17165 Alloc PE / Size 14464 / 56.50 GB Free PE / Size 2701 / 10.55 GB VG UUID oHluq0-H5Nd-90dU-psLn-ygNT-u4GJ-D8aJhG All filesystems are ext3 as I did have nasty experiences with reiserfs on lvm+raid on another 2.6 system without ever using swsusp there. -- Andreas Steinmetz SPAMmers use [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.13-rc4-mm1
Andrew Morton wrote: > Andreas Steinmetz <[EMAIL PROTECTED]> wrote: > >>Andrew Morton wrote: >> > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.13-rc4/2.6.13-rc4-mm1/ >> >> Andrew, >> the good news is I can access pcmcia devices with rc4-mm1 which I >> couldn't with at least rc3-mm1 on my x86_64 laptop. There is at least >> one more problem with yenta_socket. Please see the attached dmesg output >> and look for: >> >> Badness in __release_resource at kernel/resource.c:184 >> >> This happens when accessing pcmcia from an initrd to read keys from a >> pcmcia flash disk and removing the pcmcia modules afterwards. > > > hm, OK. That's brought to us by the below -mm-only debugging patch. Maybe > we should add more stuff to it to idenfify the child resources? > Well, could be. Unfortunately I have zero knowledge in this area of the kernel. Maybe Dominik can help? -- Andreas Steinmetz SPAMmers use [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.13-rc4-mm1
Andrew Morton wrote: > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.13-rc4/2.6.13-rc4-mm1/ Andrew, the good news is I can access pcmcia devices with rc4-mm1 which I couldn't with at least rc3-mm1 on my x86_64 laptop. There is at least one more problem with yenta_socket. Please see the attached dmesg output and look for: Badness in __release_resource at kernel/resource.c:184 This happens when accessing pcmcia from an initrd to read keys from a pcmcia flash disk and removing the pcmcia modules afterwards. -- Andreas Steinmetz SPAMmers use [EMAIL PROTECTED] Bootdata ok (command line is BOOT_IMAGE=2.6.13rc4mm hdb=none hdc=cdrom hdd=none elevator=cfq psmouse.rate=20 report_lost_ticks iommu=off root=/dev/ram0 init=/linuxrc rw) Linux version 2.6.13-rc4-mm1-gringo ([EMAIL PROTECTED]) (gcc version 3.4.4) #1 PREEMPT Sun Jul 31 15:11:12 CEST 2005 BIOS-provided physical RAM map: BIOS-e820: - 0009f800 (usable) BIOS-e820: 0009f800 - 000a (reserved) BIOS-e820: 000d8000 - 0010 (reserved) BIOS-e820: 0010 - 3ff7 (usable) BIOS-e820: 3ff7 - 3ff7a000 (ACPI data) BIOS-e820: 3ff7a000 - 3ff8 (ACPI NVS) BIOS-e820: 3ff8 - 4000 (reserved) BIOS-e820: fffe - 0001 (reserved) ACPI: RSDP (v000 PTLTD ) @ 0x000f6a60 ACPI: RSDT (v001 PTLTDRSDT 0x0604 LTP 0x) @ 0x3ff73fde ACPI: FADT (v002 AMDK8 PTLTW0x0604 PTL_ 0x000f4240) @ 0x3ff79e56 ACPI: SSDT (v001 PTLTD POWERNOW 0x0604 LTP 0x0001) @ 0x3ff79eda ACPI: MADT (v001 PTLTD APIC 0x0604 LTP 0x) @ 0x3ff79fb0 ACPI: DSDT (v001 VIA PTL_ACPI 0x0604 MSFT 0x010e) @ 0x On node 0 totalpages: 262000 DMA zone: 4096 pages, LIFO batch:1 Normal zone: 257904 pages, LIFO batch:31 HighMem zone: 0 pages, LIFO batch:1 ACPI: PM-Timer IO Port: 0x4008 ACPI: Local APIC address 0xfee0 ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled) Processor #0 15:4 APIC version 16 ACPI: LAPIC_NMI (acpi_id[0x00] high edge lint[0x1]) ACPI: IOAPIC (id[0x01] address[0xfec0] gsi_base[0]) IOAPIC[0]: apic_id 1, version 3, address 0xfec0, GSI 0-23 ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 high edge) ACPI: IRQ0 used by override. ACPI: IRQ2 used by override. ACPI: IRQ9 used by override. Using ACPI (MADT) for SMP configuration information Allocating PCI resources starting at 4000 (gap: 4000:bffe) Built 1 zonelists Initializing CPU#0 Kernel command line: BOOT_IMAGE=2.6.13rc4mm hdb=none hdc=cdrom hdd=none elevator=cfq psmouse.rate=20 report_lost_ticks iommu=off root=/dev/ram0 init=/linuxrc rw ide_setup: hdb=none ide_setup: hdc=cdrom ide_setup: hdd=none PID hash table entries: 4096 (order: 12, 131072 bytes) time.c: Using 3.579545 MHz PM timer. time.c: Detected 1801.073 MHz processor. time.c: Using PIT/TSC based timekeeping. Console: colour VGA+ 80x50 time.c: Lost 3 timer tick(s)! rip start_kernel+0xfd/0x1f0) Dentry cache hash table entries: 262144 (order: 9, 2097152 bytes) Inode-cache hash table entries: 131072 (order: 8, 1048576 bytes) Memory: 1023708k/1048000k available (3160k kernel code, 23596k reserved, 1340k data, 176k init) Calibrating delay using timer specific routine.. 3606.48 BogoMIPS (lpj=1803241) Security Framework v1.0.0 initialized SELinux: Initializing. SELinux: Starting in permissive mode selinux_register_security: Registering secondary module capability Capability LSM initialized as secondary Mount-cache hash table entries: 256 CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line) CPU: L2 Cache: 1024K (64 bytes/line) mtrr: v2.0 (20020519) CPU: AMD Athlon(tm) 64 Processor 3000+ stepping 0a time.c: Lost 85 timer tick(s)! rip acpi_os_write_port+0x1a/0x38) Using local APIC timer interrupts. Detected 12.507 MHz APIC timer. time.c: Lost 56 timer tick(s)! rip setup_boot_APIC_clock+0x112/0x120) testing NMI watchdog ... OK. checking if image is initramfs...it isn't (no cpio magic); looks like an initrd softlockup thread 0 started up. NET: Registered protocol family 16 ACPI: bus type pci registered PCI: Using configuration type 1 ACPI: Subsystem revision 20050408 ACPI: Interpreter enabled ACPI: Using IOAPIC for interrupt routing ACPI: PCI Root Bridge [PCI0] (:00) PCI: Probing PCI hardware (bus 00) ACPI: Assume root bridge [\_SB_.PCI0] segment is 0 Boot video device is :01:00.0 ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT] ACPI: PCI Interrupt Link [ALKA] (IRQs 16 17 18 19 20 21 22 23) *10, disabled. ACPI: PCI Interrupt Link [ALKB] (IRQs 16 17 18 19 20 21 22 23) *10, disabled. ACPI: PCI Interrupt Link [ALKC] (IRQs 22) *11, disabled. ACPI: PCI Interrupt Link [ALKD] (IRQs 21) *11, disabled. ACPI: PCI Interrupt Link [LNKA] (IRQs 3 4 5 7 9 12 14 15) *10 ACPI: PCI I
[PATCH] swsusp with dm-crypt mini howto
Pavel Machek wrote: > It looks good. Perhaps it should go into > Documentation/power/swsusp-dmcrypt.txt? Could you write you copyright > and GPL in there, sign it off, and cc: it to linux-kernel? > Pavel The attached patch contains a mini howto for using dm-crypt together with swsusp. Signed-off-by: Andreas Steinmetz <[EMAIL PROTECTED]> -- Andreas Steinmetz SPAMmers use [EMAIL PROTECTED] --- linux.orig/Documentation/power/swsusp-dmcrypt.txt 2003-09-24 00:19:32.0 +0200 +++ linux/Documentation/power/swsusp-dmcrypt.txt2005-07-30 19:03:56.0 +0200 @@ -0,0 +1,138 @@ +Author: Andreas Steinmetz <[EMAIL PROTECTED]> + + +How to use dm-crypt and swsusp together: + + +Some prerequisites: +You know how dm-crypt works. If not, visit the following web page: +http://www.saout.de/misc/dm-crypt/ +You have read Documentation/power/swsusp.txt and understand it. +You did read Documentation/initrd.txt and know how an initrd works. +You know how to create or how to modify an initrd. + +Now your system is properly set up, your disk is encrypted except for +the swap device(s) and the boot partition which may contain a mini +system for crypto setup and/or rescue purposes. You may even have +an initrd that does your current crypto setup already. + +At this point you want to encrypt your swap, too. Still you want to +be able to suspend using swsusp. This, however, means that you +have to be able to either enter a passphrase or that you read +the key(s) from an external device like a pcmcia flash disk +or an usb stick prior to resume. So you need an initrd, that sets +up dm-crypt and then asks swsusp to resume from the encrypted +swap device. + +The most important thing is that you set up dm-crypt in such +a way that the swap device you suspend to/resume from has +always the same major/minor within the initrd as well as +within your running system. The easiest way to achieve this is +to always set up this swap device first with dmsetup, so that +it will always look like the following: + +brw--- 1 root root 254, 0 Jul 28 13:37 /dev/mapper/swap0 + +Now set up your kernel to use /dev/mapper/swap0 as the default +resume partition, so your kernel .config contains: + +CONFIG_PM_STD_PARTITION="/dev/mapper/swap0" + +Prepare your boot loader to use the initrd you will create or +modify. For lilo the simplest setup looks like the following +lines: + +image=/boot/vmlinuz +initrd=/boot/initrd.gz +label=linux +append="root=/dev/ram0 init=/linuxrc rw" + +Finally you need to create or modify your initrd. Lets assume +you create an initrd that reads the required dm-crypt setup +from a pcmcia flash disk card. The card is formatted with an ext2 +fs which resides on /dev/hde1 when the card is inserted. The +card contains at least the encrypted swap setup in a file +named "swapkey". /etc/fstab of your initrd contains something +like the following: + +/dev/hda1 /mntext3 ro0 0 +none/proc proc defaults,noatime,nodiratime 0 0 +none/syssysfs defaults,noatime,nodiratime 0 0 + +/dev/hda1 contains an unencrypted mini system that sets up all +of your crypto devices, again by reading the setup from the +pcmcia flash disk. What follows now is a /linuxrc for your +initrd that allows you to resume from encrypted swap and that +continues boot with your mini system on /dev/hda1 if resume +does not happen: + +#!/bin/sh +PATH=/sbin:/bin:/usr/sbin:/usr/bin +mount /proc +mount /sys +mapped=0 +noresume=`grep -c noresume /proc/cmdline` +if [ "$*" != "" ] +then + noresume=1 +fi +dmesg -n 1 +/sbin/cardmgr -q +for i in 1 2 3 4 5 6 7 8 9 0 +do + if [ -f /proc/ide/hde/media ] + then +usleep 50 +mount -t ext2 -o ro /dev/hde1 /mnt +if [ -f /mnt/swapkey ] +then + dmsetup create swap0 /mnt/swapkey > /dev/null 2>&1 && mapped=1 +fi +umount /mnt +break + fi + usleep 50 +done +killproc /sbin/cardmgr +dmesg -n 6 +if [ $mapped = 1 ] +then + if [ $noresume != 0 ] + then +mkswap /dev/mapper/swap0 > /dev/null 2>&1 + fi + echo 254:0 > /sys/power/resume + dmsetup remove swap0 +fi +umount /sys +mount /mnt +umount /proc +cd /mnt +pivot_root . mnt +mount /proc +umount -l /mnt +umount /proc +exec chroot . /sbin/init $* < dev/console > dev/console 2>&1 + +Please don't mind the weird loop above, busybox's msh doesn't know +the let statement. Now, what is happening in the script? +First we have to decide if we want to try to resume, or not. +We will not resume if booting with "noresume" or any parameters +for init like "single" or "emergency" as boot parameters. + +Then we need to set up dmcrypt with the setup data from the +pcmcia flash disk. If this suc
Re: [swsusp] encrypt suspend data for
[EMAIL PROTECTED] wrote: > HI! IF I TEACH YOU HO TO DO RESUME FROM INITRD, WILL YOU TEST IT AND PROPERLY > DOCUMENT? :-) --P My Pleasure! I can test on x86_64 and I am willing to document. -- Andreas Steinmetz SPAMmers use [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: [swsusp] encrypt suspend data for easy wiping
Pavel Machek wrote: > Hi! > > >>>>2) An attacker breaks into your machine remotely while you're using >>>>it. He has access to all your RAM, which if you're actually using it, >>>>very likely including the same IPSEC, dm_crypt, and ssh-agent keys as >>>>are saved on suspend. Further, he can trivially capture your >>>>keystrokes and thus capture any keys you use from that point forward. >>>>This patch gets us very close to nothing. >>>> >>>>3) An attacker steals your unsuspended laptop. He has access to all >>>>your RAM, which in all likelihood includes your IPSEC, dm_crypt, and >>>>ssh-agent keys. Odds are good that he invokes swsusp by closing the >>>>laptop. This patch gets us very close to nothing. >>>> >>>>4) You suspend your laptop between typing your GPG key password and >>>>hitting enter, thus leaving your password in memory when it would >>>>otherwise be cleared. Then you resume your laptop and hit enter, thus >>>>clearing the password from RAM but leaving it on the suspend >>>>partition. Then an attacker steals your machine (without re-suspending >>>>it!) and manages to recover the swsusp image which contains the >>> >>>Why without resuspending it? Position of critical data in swap is >>>pretty much random. >> >>Typical swap partition sizes are about the same as RAM sizes. So the >>odds of any given thing in a previous suspend getting overwritten by >>the next one are high. > > > Well, if you suspend with 100MB of RAM used, then keep suspending half > a year with only 50MB of RAM used, you'll have that half-year-old data > in there. > > >>>What I'm worried is: attacker steals your laptop after you were using >>>swsusp for half a year. Now your swap partition contains random pieces >>>of GPG keys you were using for last half a year. That's bad. >> >>And it's incredibly unlikely. Suspending while a supposedly >>short-lived key is in RAM should be rare. Surviving on disk after half >>a year of swapping and suspending should be negligible probability. > > > Disagreed. > > >>It's not worth even thinking about when we have real suspended laptops >>getting stolen every day in REAL LIFE. Anyone who cares about your >>highly contrived case also cares about 1000 times more about the real >>life case of the stolen laptop. Otherwise they're fooling themselves. >> >>This code is bad. It attacks a very rare problem, gives its users (and >>apparently its authors) a false sense of security, reimplements >>dm_crypt functionality apparently without much attention to the >>subtleties of block device encryption and without serious review, and >>it stands in the way of doing things right. > > > Think about current code as really quick disk wiping method. Now, if > you feel that we are giving false sense of security... we should > not. Perhaps option should be renamed to CONFIG_SWSUSP_WIPE. Patches > would certainly be accepted and I believe Andreas is going to cook > some when he gets back online :-). I'd like to keep it there, because > it enables us to do it properly in future. Contrary to what you think, > I believe this is going to be part of a solution. Matt, this is really supposed to do wiping, nothing else. Maybe the reference to crypto may confuse a bit, but then crypto is the best way to wipe. The documentation I did send to Pavel some time ago for swsusp.txt does contain a big fat warning about that and starts with: -- Q: What is this 'Encrypt suspend image' for? A: First of all: it is not a replacement for dm-crypt encrypted swap. It cannot protect your computer while it is suspended. Instead it does protect from leaking sensitive data after resume from suspend. -- I'm still dreaming of using dm-crypt for encrypted swap on the one hand and wiping on resume from suspend on the other working together which would mean: You have an initrd that either prompts for a key or retrieves a key from an attached hardware device (pcmcia, usb, ...). The key is used for dmsetup to enable the encrypted swap partition. swsusp then resumes from the encrypted swap partition and wipes the suspend image. Unfortunately, as of 2.6.13rc3 I don't see any chance for this to work (excerpt from init/main.c): do_basic_setup(); if (sys_access((const char __user *) "/init", 0) == 0) execute_command = "/init"; else prepare_namespace(); do_basic_setup calls do_initcalls and swsusp is using late_initcall(). prepare_namespace calls initrd_load and friends. So there is currently no chance to use an initrd to setup any crypto key. This is really the missing link here. -- Andreas Steinmetz SPAMmers use [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: [PATCH] 2.6.13rc3: RLIMIT_RTPRIO broken
Lee Revell wrote: > On Sat, 2005-07-23 at 13:42 +0200, Andreas Steinmetz wrote: > >>RLIMIT_RTPRIO is supposed to grant non privileged users the right to use >>SCHED_FIFO/SCHED_RR scheduling policies with priorites bounded by the >>RLIMIT_RTPRIO value via sched_setscheduler(). This is usually used by >>audio users. >> >>Unfortunately this is broken in 2.6.13rc3 as you can see in the excerpt >>from sched_setscheduler below: > > > Please provide the Signed-Off-By line. Also I have cc'ed Matt Mackall, > the original author of the patch. Sorry, I do forget this all the time... Signed-off-by: Andreas Steinmetz <[EMAIL PROTECTED]> -- Andreas Steinmetz SPAMmers use [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/
[PATCH] 2.6.13rc3: RLIMIT_RTPRIO broken
RLIMIT_RTPRIO is supposed to grant non privileged users the right to use
SCHED_FIFO/SCHED_RR scheduling policies with priorites bounded by the
RLIMIT_RTPRIO value via sched_setscheduler(). This is usually used by
audio users.
Unfortunately this is broken in 2.6.13rc3 as you can see in the excerpt
from sched_setscheduler below:
/*
* Allow unprivileged RT tasks to decrease priority:
*/
if (!capable(CAP_SYS_NICE)) {
/* can't change policy */
if (policy != p->policy)
return -EPERM;
After the above unconditional test which causes sched_setscheduler to
fail with no regard to the RLIMIT_RTPRIO value the following check is made:
/* can't increase priority */
if (policy != SCHED_NORMAL &&
param->sched_priority > p->rt_priority &&
param->sched_priority >
p->signal->rlim[RLIMIT_RTPRIO].rlim_cur)
return -EPERM;
Thus I do believe that the RLIMIT_RTPRIO value must be taken into
account for the policy check, especially as the RLIMIT_RTPRIO limit is
of no use without this change.
The attached patch fixes this problem. I would appreciate it if the fix
would make it into 2.6.13.
--
Andreas Steinmetz SPAMmers use [EMAIL PROTECTED]
--- linux.orig/kernel/sched.c 2005-07-22 19:45:05.0 +0200
+++ linux/kernel/sched.c2005-07-22 19:45:42.0 +0200
@@ -3528,7 +3528,8 @@
*/
if (!capable(CAP_SYS_NICE)) {
/* can't change policy */
- if (policy != p->policy)
+ if (policy != p->policy &&
+ !p->signal->rlim[RLIMIT_RTPRIO].rlim_cur)
return -EPERM;
/* can't increase priority */
if (policy != SCHED_NORMAL &&
Re: amd64-agp vs. swsusp
Michal Schmidt wrote: > Hello, > > Does resuming from swsuspend work for anyone with amd64-agp loaded? > > On my system when I suspend with amd64-agp loaded, I get a spontaneous > reboot on resume. It reboots immediately after reading the saved image > from disk. > This is 100% reproducible. > > Athlon 64 FX-53, Asus A8V Deluxe, Linux 2.6.13-rc3-mm1. AMD Athlon(tm) 64 Processor 3000+, Acer Aspire Linux gringo 2.6.13-rc3-gringo #36 Sun Jul 17 15:57:17 CEST 2005 x86_64 unknown unknown GNU/Linux CONFIG_AGP=y CONFIG_AGP_AMD64=y swsusp works for me. Could it be mm, agp as a module or some speciality of your hardware? -- Andreas Steinmetz SPAMmers use [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: [swsusp] encrypt suspend data for easy wiping
Andrew Morton wrote:
> Pavel Machek <[EMAIL PROTECTED]> wrote:
>
>>To prevent data gathering from swap after resume you can encrypt the
>>suspend image with a temporary key that is deleted on resume. Note
>>that the temporary key is stored unencrypted on disk while the system
>>is suspended... still it means that saved data are wiped from disk
>>during resume by simply overwritting the key.
>
[snip]
> err, no. Please find a way to reduce the ifdeffery.
Andrew,
the attached patches are acked by Pavel and signed off by me. They apply
against 2.6.13-rc3 as well as 2.6.13-rc3-mm1 (with offsets) and are
tested against both kernels. Please consider for inclusion (Pavel
suggested that I could ask).
Note:
For 64 bit systems to work you need the following crypto fix for both
kernels stated above:
http://marc.theaimsgroup.com/?l=linux-kernel&m=112160294820624&w=2
--
Andreas Steinmetz SPAMmers use [EMAIL PROTECTED]
--- linux-2.6.13-rc3.orig/kernel/power/Kconfig 2005-07-17 16:03:26.0
+0200
+++ linux-2.6.13-rc3/kernel/power/Kconfig 2005-07-17 10:40:48.0
+0200
@@ -72,6 +72,18 @@
suspended image to. It will simply pick the first available swap
device.
+config SWSUSP_ENCRYPT
+ bool "Encrypt suspend image"
+ depends on SOFTWARE_SUSPEND && CRYPTO=y && (CRYPTO_AES=y ||
CRYPTO_AES_586=y || CRYPTO_AES_X86_64=y)
+ default ""
+ ---help---
+ To prevent data gathering from swap after resume you can encrypt
+ the suspend image with a temporary key that is deleted on
+ resume.
+
+ Note that the temporary key is stored unencrypted on disk while the
+ system is suspended.
+
config SUSPEND_SMP
bool
depends on HOTPLUG_CPU && X86 && PM
--- linux-2.6.13-rc3.orig/kernel/power/swsusp.c 2005-07-17 16:03:26.0
+0200
+++ linux-2.6.13-rc3/kernel/power/swsusp.c 2005-07-17 16:09:09.00000
+0200
@@ -31,6 +31,9 @@
* Alex Badea <[EMAIL PROTECTED]>:
* Fixed runaway init
*
+ * Andreas Steinmetz <[EMAIL PROTECTED]>:
+ * Added encrypted suspend option
+ *
* More state savers are welcome. Especially for the scsi layer...
*
* For TODOs,FIXMEs also look in Documentation/power/swsusp.txt
@@ -71,8 +74,16 @@
#include
#include
+#include
+#include
+#include
+
#include "power.h"
+#define CIPHER "aes"
+#define MAXKEY 32
+#define MAXIV 32
+
/* References to section boundaries */
extern const void __nosave_begin, __nosave_end;
@@ -103,7 +114,8 @@
#define SWSUSP_SIG "S1SUSPEND"
static struct swsusp_header {
- char reserved[PAGE_SIZE - 20 - sizeof(swp_entry_t)];
+ char reserved[PAGE_SIZE - 20 - MAXKEY - MAXIV - sizeof(swp_entry_t)];
+ u8 key_iv[MAXKEY+MAXIV];
swp_entry_t swsusp_info;
charorig_sig[10];
charsig[10];
@@ -129,6 +141,131 @@
static unsigned short swapfile_used[MAX_SWAPFILES];
static unsigned short root_swap;
+static int write_page(unsigned long addr, swp_entry_t * loc);
+static int bio_read_page(pgoff_t page_off, void * page);
+
+static u8 key_iv[MAXKEY+MAXIV];
+
+#ifdef CONFIG_SWSUSP_ENCRYPT
+
+static int crypto_init(int mode, void **mem)
+{
+ int error = 0;
+ int len;
+ char *modemsg;
+ struct crypto_tfm *tfm;
+
+ modemsg = mode ? "suspend not possible" : "resume not possible";
+
+ tfm = crypto_alloc_tfm(CIPHER, CRYPTO_TFM_MODE_CBC);
+ if(!tfm) {
+ printk(KERN_ERR "swsusp: no tfm, %s\n", modemsg);
+ error = -EINVAL;
+ goto out;
+ }
+
+ if(MAXKEY < crypto_tfm_alg_min_keysize(tfm)) {
+ printk(KERN_ERR "swsusp: key buffer too small, %s\n", modemsg);
+ error = -ENOKEY;
+ goto fail;
+ }
+
+ if (mode)
+ get_random_bytes(key_iv, MAXKEY+MAXIV);
+
+ len = crypto_tfm_alg_max_keysize(tfm);
+ if (len > MAXKEY)
+ len = MAXKEY;
+
+ if (crypto_cipher_setkey(tfm, key_iv, len)) {
+ printk(KERN_ERR "swsusp: key setup failure, %s\n", modemsg);
+ error = -EKEYREJECTED;
+ goto fail;
+ }
+
+ len = crypto_tfm_alg_ivsize(tfm);
+
+ if (MAXIV < len) {
+ printk(KERN_ERR "swsusp: iv buffer too small, %s\n", modemsg);
+ error = -EOVERFLOW;
+ goto fail;
+ }
+
+ crypto_cipher_set_iv(tfm, key_iv+MAXKEY, len);
+
+ *mem=(void *)tfm;
+
+ goto out;
+
+fail: crypto_free_tfm(tfm);
+out: return error;
+}
+
+static __inline__ void crypto_exit(void *mem)
+{
+ crypto_free_tfm((struct crypto_tfm *)mem);
+}
+
+static __inline__ int crypto_write(struct pbe *p, void *mem)
+{
+ int error = 0;
2.6.13rc3: crypto horribly broken on all 64bit archs
from include/linux/kernel.h:
#define ALIGN(x,a) (((x)+(a)-1)&~((a)-1))
from crypto/cipher.c:
unsigned int alignmask = ...
u8 *src = (u8 *)ALIGN((unsigned long)buffer, alignmask + 1);
...
unsigned int alignmask = ...
u8 *tmp = (u8 *)ALIGN((unsigned long)buffer, alignmask + 1);
...
unsigned int align;
addr = ALIGN(addr, align);
addr += ALIGN(tfm->__crt_alg->cra_ctxsize, align);
The compiler first does ~((a)-1)) and then expands the unsigned int to
unsigned long for the & operation. So we end up with only the lower 32
bits of the address. Who did smoke what to do this? Patch attached.
--
Andreas Steinmetz SPAMmers use [EMAIL PROTECTED]
--- linux.orig/crypto/cipher.c 2005-07-17 13:35:15.0 +0200
+++ linux/crypto/cipher.c 2005-07-17 14:04:00.0 +0200
@@ -41,7 +41,7 @@
struct scatter_walk *in,
struct scatter_walk *out, unsigned int bsize)
{
- unsigned int alignmask = crypto_tfm_alg_alignmask(desc->tfm);
+ unsigned long alignmask = crypto_tfm_alg_alignmask(desc->tfm);
u8 buffer[bsize * 2 + alignmask];
u8 *src = (u8 *)ALIGN((unsigned long)buffer, alignmask + 1);
u8 *dst = src + bsize;
@@ -160,7 +160,7 @@
unsigned int nbytes)
{
struct crypto_tfm *tfm = desc->tfm;
- unsigned int alignmask = crypto_tfm_alg_alignmask(tfm);
+ unsigned long alignmask = crypto_tfm_alg_alignmask(tfm);
u8 *iv = desc->info;
if (unlikely(((unsigned long)iv & alignmask))) {
@@ -424,7 +424,7 @@
}
if (ops->cit_mode == CRYPTO_TFM_MODE_CBC) {
- unsigned int align;
+ unsigned long align;
unsigned long addr;
switch (crypto_tfm_alg_blocksize(tfm)) {
Re: [PATCH 1/3] crypto: do not open-code be<->cpu
Denis Vlasenko wrote: > Patch replaces numerous be<->cpu and le<->cpu > conversions in crypto. Per lkml comments, > it is done with macros: > > block[i] = load_be64(ptr,i); > store_be64(out,i, block[i]); > > where i is an index: load_be64 will load i'th > big-endian value pointed by ptr (typically a char*). > Same for store. > > This results in smaller and cleaner code. > > Patch also adds BYTEn(x) macros for extracting n'th byte from > u32 and u64 memory operand. Currently used experssions like > ((K >> 40) & 0xff) are not optimal (gcc will load entire word > and then shift and/or mask it). > > Macros can be conditionally defined for different arches > for performance. Ones from this patch are found to be best > for i386. > > BYTEn macros are used only by next patches. Not good if you use a crypto private header as long as there's arch and device specific crypto which is left out cold this way. I'd suggest either some header in include/linux or, in my opinion better, open a crypto related include directory as include/crypto. The latter would make sense as there probably will be algorithm specific headers when the arch and driver specific versions will be harmonized, thus these headers need to be globally available to crypto sources but otherwise would pollute the common include directory. -- Andreas Steinmetz SPAMmers use [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: Linux 2.6.12-rc3: various swsusp problems
Pavel Machek wrote: > Hi! > Are they new or were they in -rc2, too? Some further backtracking: The nic problem is already present in 2.6.12-rc1. The pcmcia hang problem is not present in 2.6.12-rc1. -- Andreas Steinmetz SPAMmers use [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: Linux 2.6.12-rc3: various swsusp problems
Pavel Machek wrote: > Hi! > > >>there's some problems with swsusp in 2.6.12-rc3 (x86_64): > > > Are they new or were they in -rc2, too? > Fixed the rc2/rc3 IDE Oops myself today that prevented me to test rc2 earlier. It seems the IDE maintainer is currently not very responsive and I didn't have sufficient spare time to look into this before today :-( Yes, all problems are already in rc2. > >>1. Is it necessary to print the following message during regular boot? >> swsusp: Suspend partition has wrong signature? >> It is a bit annoying and I believe it will confuse some swsusp >> users. > > > Hmm, feel free to provide a patch. (I need something to try git on :-). I'll have a look over the weekend. > > >>2. PCMCIA related hangs during swsusp. >> swsusp hangs after freeing memory when either cardmgr is running >> or pcmcia cards are *physically* inserted. It is insufficient >> to do a 'cardctl eject' the cards must be removed, too, for >> swsusp not to hang. I do suspect some problem with the >> 'pccardd' kernel threads. > > > Did it work with any older kernel? Which driver is it? yenta? 2.6.11.2 works ok and, yes, its yenta. Some excerpt from lspci: 00:0b.0 CardBus bridge: Texas Instruments PCI7420 CardBus Controller 00:0b.1 CardBus bridge: Texas Instruments PCI7420 CardBus Controller > > >>3. Sometimes during the search for the suspend hang reason the system >> went during suspend into a lightshow of: >> eth0: Too much work at interrupt! >> and some line that ends in: >> release_console_sem+0x13d/0x1c0) >> The start of the line is not readable as it just flickers by in >> the eth0 message limbo. NIC is a built in RTL-8169 Gigabit Ethernet >> (rev 10). Oh, no chance for a serial console capture as there's no >> built in serial device in this laptop. > > > How repeatable is that? Will NIC work okay if you rmmod/insmod its driver? > Pavel Happens with a probability of about 10% to 20%. I did comment out the 'Too much work...' printk in r8169.c which results in the following effect: no more message from the network driver (expected), no other printk related to release_console_sem or anything else unusal, but write to disk in the case the problem seems to happen is suddenly quite slow and suspend eventually succeeds. As the nic driver is built into the kernel insmod/rmmod currently won't do:-) Nevertheless there doesn't seem to be any strange behaviour after resume though I didn't really try to use the nic then. There is, however, definitely no such problem with the nic in 2.6.11.2. -- Andreas Steinmetz SPAMmers use [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: Linux 2.6.12-rc3: various swsusp problems
Hi Pavel, there's some problems with swsusp in 2.6.12-rc3 (x86_64): 1. Is it necessary to print the following message during regular boot? swsusp: Suspend partition has wrong signature? It is a bit annoying and I believe it will confuse some swsusp users. 2. PCMCIA related hangs during swsusp. swsusp hangs after freeing memory when either cardmgr is running or pcmcia cards are *physically* inserted. It is insufficient to do a 'cardctl eject' the cards must be removed, too, for swsusp not to hang. I do suspect some problem with the 'pccardd' kernel threads. 3. Sometimes during the search for the suspend hang reason the system went during suspend into a lightshow of: eth0: Too much work at interrupt! and some line that ends in: release_console_sem+0x13d/0x1c0) The start of the line is not readable as it just flickers by in the eth0 message limbo. NIC is a built in RTL-8169 Gigabit Ethernet (rev 10). Oh, no chance for a serial console capture as there's no built in serial device in this laptop. -- Andreas Steinmetz SPAMmers use [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: Linux 2.6.12-rc3: Oops on IDE flash disk eject
The following patch fixes the Oops though I don't know if this is the
correct solution.
--- linux-2.6.12-rc3/drivers/ide/ide.c.ast
+++ linux-2.6.12-rc3/drivers/ide/ide.c
@@ -2082,7 +2082,8 @@
static int ide_drive_remove(struct device * dev)
{
ide_drive_t * drive = container_of(dev,ide_drive_t,gendev);
- DRIVER(drive)->cleanup(drive);
+ if(DRIVER(drive))
+ DRIVER(drive)->cleanup(drive);
return 0;
}
--
Andreas Steinmetz SPAMmers use [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: Linux 2.6.12-rc3: Oops on IDE flash disk eject
As already reported to lkml and IDE maintainer for 2.6.12-rc2: Oops on 'cardctl eject' of an IDE flash disk (Pretec ATA Flash 16MB). 2.6.11.2 works fine. System: Linux (none) 2.6.12-rc3-gringo #1 Thu Apr 21 15:45:08 CEST 2005 x86_64 unknown unknown GNU/Linux Kernel messages from startup to and including Oops as well as config are attached. -- Andreas Steinmetz SPAMmers use [EMAIL PROTECTED] Bootdata ok (command line is BOOT_IMAGE=2.6.12rc2 ro root=301 hdb=none hdc=cdrom hdd=none elevator=cfq psmouse.rate=20 report_lost_ticks iommu=off init=/bin/bash) Linux version 2.6.12-rc3-gringo ([EMAIL PROTECTED]) (gcc version 3.4.3) #1 Thu Apr 21 15:45:08 CEST 2005 BIOS-provided physical RAM map: BIOS-e820: - 0009f800 (usable) BIOS-e820: 0009f800 - 000a (reserved) BIOS-e820: 000d8000 - 0010 (reserved) BIOS-e820: 0010 - 3ff7 (usable) BIOS-e820: 3ff7 - 3ff7a000 (ACPI data) BIOS-e820: 3ff7a000 - 3ff8 (ACPI NVS) BIOS-e820: 3ff8 - 4000 (reserved) BIOS-e820: fffe - 0001 (reserved) ACPI: RSDP (v000 PTLTD ) @ 0x000f6a60 ACPI: RSDT (v001 PTLTDRSDT 0x0604 LTP 0x) @ 0x3ff73fde ACPI: FADT (v002 AMDK8 PTLTW0x0604 PTL_ 0x000f4240) @ 0x3ff79e56 ACPI: SSDT (v001 PTLTD POWERNOW 0x0604 LTP 0x0001) @ 0x3ff79eda ACPI: MADT (v001 PTLTD APIC 0x0604 LTP 0x) @ 0x3ff79fb0 ACPI: DSDT (v001 VIA PTL_ACPI 0x0604 MSFT 0x010e) @ 0x On node 0 totalpages: 262000 DMA zone: 4096 pages, LIFO batch:1 Normal zone: 257904 pages, LIFO batch:16 HighMem zone: 0 pages, LIFO batch:1 ACPI: Local APIC address 0xfee0 ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled) Processor #0 15:4 APIC version 16 ACPI: LAPIC_NMI (acpi_id[0x00] high edge lint[0x1]) ACPI: IOAPIC (id[0x01] address[0xfec0] gsi_base[0]) IOAPIC[0]: apic_id 1, version 3, address 0xfec0, GSI 0-23 ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 high edge) ACPI: IRQ0 used by override. ACPI: IRQ2 used by override. ACPI: IRQ9 used by override. Setting APIC routing to flat Using ACPI (MADT) for SMP configuration information Allocating PCI resources starting at 4000 (gap: 4000:bffe) Built 1 zonelists Kernel command line: BOOT_IMAGE=2.6.12rc2 ro root=301 hdb=none hdc=cdrom hdd=none elevator=cfq psmouse.rate=20 report_lost_ticks iommu=off init=/bin/bash console=tty0 ide_setup: hdb=none ide_setup: hdc=cdrom ide_setup: hdd=none Initializing CPU#0 PID hash table entries: 4096 (order: 12, 131072 bytes) time.c: Using 1.193182 MHz PIT timer. time.c: Detected 1801.076 MHz processor. time.c: Using PIT/TSC based timekeeping. Console: colour VGA+ 80x50 time.c: Lost 3 timer tick(s)! rip vfs_caches_init_early+0x0/0xa0) Dentry cache hash table entries: 262144 (order: 9, 2097152 bytes) Inode-cache hash table entries: 131072 (order: 8, 1048576 bytes) Memory: 1024468k/1048000k available (2958k kernel code, 22832k reserved, 1639k data, 164k init) Calibrating delay loop... 3547.13 BogoMIPS (lpj=1773568) Security Framework v1.0.0 initialized SELinux: Initializing. SELinux: Starting in permissive mode selinux_register_security: Registering secondary module capability Capability LSM initialized as secondary Mount-cache hash table entries: 256 CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line) CPU: L2 Cache: 1024K (64 bytes/line) CPU: AMD Athlon(tm) 64 Processor 3000+ stepping 0a time.c: Lost 86 timer tick(s)! rip acpi_os_write_port+0x1a/0x36) Using local APIC NMI watchdog using perfctr0 Using local APIC timer interrupts. Detected 12.507 MHz APIC timer. time.c: Lost 55 timer tick(s)! rip setup_boot_APIC_clock+0x112/0x120) NET: Registered protocol family 16 PCI: Using configuration type 1 mtrr: v2.0 (20020519) ACPI: Subsystem revision 20050309 ACPI: Interpreter enabled ACPI: Using IOAPIC for interrupt routing ACPI: PCI Root Bridge [PCI0] (:00) PCI: Probing PCI hardware (bus 00) PCI: Via IRQ fixup Boot video device is :01:00.0 ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT] ACPI: PCI Interrupt Link [ALKA] (IRQs 16 17 18 19 20 21 22 23) *10, disabled. ACPI: PCI Interrupt Link [ALKB] (IRQs 16 17 18 19 20 21 22 23) *10, disabled. ACPI: PCI Interrupt Link [ALKC] (IRQs 22) *11, disabled. ACPI: PCI Interrupt Link [ALKD] (IRQs 21) *11, disabled. ACPI: PCI Interrupt Link [LNKA] (IRQs 3 4 5 7 9 12 14 15) *10 ACPI: PCI Interrupt Link [LNKB] (IRQs 3 4 5 7 *10 12 14 15) ACPI: PCI Interrupt Link [LNKC] (IRQs 3 4 5 7 *11 12 14 15) ACPI: PCI Interrupt Link [LNKD] (IRQs 3 4 5 7 9 10 *11 12 14 15) ACPI: Embedded Controller [EC] (gpe 11) time.c: Lost 8 timer tick(s)! rip acpi_os_write_port+0x1a/0x36) time.c: Lost 8 timer tick(s)! rip acpi_os_write_port+0x1a/0x36) Linux Plug and Play Support v0.97 (c)
Re: Linux 2.6.12-rc3
Compile error on x86_64: CC [M] drivers/usb/image/microtek.o drivers/usb/image/microtek.c: In function `mts_scsi_abort': drivers/usb/image/microtek.c:338: error: `FAILURE' undeclared (first use in this function) drivers/usb/image/microtek.c:338: error: (Each undeclared identifier is reported only once drivers/usb/image/microtek.c:338: error: for each function it appears in.) make[3]: *** [drivers/usb/image/microtek.o] Error 1 make[2]: *** [drivers/usb/image] Error 2 make[1]: *** [drivers/usb] Error 2 make: *** [drivers] Error 2 -- Andreas Steinmetz SPAMmers use [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/
Need AES benchmark on Intel 64 bit
Hi, can anybody help out? I don't have access to Intel 64 bit CPUs and need some microbenchmark results on Intel 64 bit. Usage guide for the attached archive: 'ref' contains the current generic AES implementation 'new' contains the 64 bit AES assembler implementation Do 'make' in both directories and run the resulting 'aes' on an otherwise idle system without any cpufreq (speedstep) stuff active. Preferrably do multiple runs to assert that the results are usable (a few ticks difference between runs are ok). The microbenchmark is set up to produce somewhat real life results with hot caches, thus the same data block is processed all the time. -- Andreas Steinmetz SPAMmers use [EMAIL PROTECTED] microbench.tgz Description: application/tar-gz
Re: [RFC][PATCH 2/4] AES assembler implementation for x86_64
Denis Vlasenko wrote:
> On Monday 18 April 2005 12:01, Andreas Steinmetz wrote:
>
>>Denis Vlasenko wrote:
>>
>>>On Sunday 17 April 2005 22:20, Andreas Steinmetz wrote:
>>>
>>>
>>>>The attached patch contains Gladman's in-kernel code for key schedule
>>>>and table generation modified to fit to my assembler implementation,
>>>>--
>>>>Andreas Steinmetz SPAMmers use [EMAIL PROTECTED]
>>>
>>>
>>>Patch contains a mix of several coding styles:
>>>
>>>+/*
>>>+ * #define byte(x, nr) ((unsigned char)((x) >> (nr*8)))
>>>+ */
>>>+inline static u8
>>>+byte(const u32 x, const unsigned n)
>>>+{
>>>+ return x >> (n << 3);
>>>+}
>>>
>>>what does const do here?
>>
>>Taken 'as is' from current kernel sources, i,e, crypto/aes.c
>
>
> "It's a cut-n-paste" is not a good argument here. You
> are adding a _new file_ with your patch, it's okay to clean
> it up while doing this. IOW: do not dup the mess.
>
> OTOH, if _exactly the same file_ exist in i384 arch, then
> you should not duplicate it at all. Find a way to use one file
> for both arches.
>
> Note that this is only my view, I can be wrong.
> --
> vda
>
I'll wait for Herbert Xu's review and his opinion on this.
--
Andreas Steinmetz SPAMmers use [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][PATCH 0/4] AES assembler implementation for x86_64
Jörn Engel wrote: > On Mon, 18 April 2005 03:50:32 -0400, James Morris wrote: > >>Please cc Herbert Xu on kernel crypto patches, he's the frontline >>maintainer of it now. > > > Care to sign off this patch (or create a similar one)? No problem, will do after the review by Herbert Xu is done (I guess there will be some changes required). -- Andreas Steinmetz SPAMmers use [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][PATCH 0/4] AES assembler implementation for x86_64
Andi Kleen wrote: > On what CPUs did you benchmark? I suppose results will vary a lot > between AMD and Intel x86-64 CPUs. AMD. I don't have any Intel around. -- Andreas Steinmetz SPAMmers use [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][PATCH 0/4] AES assembler implementation for x86_64
James Morris wrote: > Please cc Herbert Xu on kernel crypto patches, he's the frontline > maintainer of it now. > > > - James Already done on request by Herbert Xu himself. -- Andreas Steinmetz SPAMmers use [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][PATCH 2/4] AES assembler implementation for x86_64
Denis Vlasenko wrote:
> On Sunday 17 April 2005 22:20, Andreas Steinmetz wrote:
>
>>The attached patch contains Gladman's in-kernel code for key schedule
>>and table generation modified to fit to my assembler implementation,
>>--
>>Andreas Steinmetz SPAMmers use [EMAIL PROTECTED]
>
>
> Patch contains a mix of several coding styles:
>
> +/*
> + * #define byte(x, nr) ((unsigned char)((x) >> (nr*8)))
> + */
> +inline static u8
> +byte(const u32 x, const unsigned n)
> +{
> + return x >> (n << 3);
> +}
>
> what does const do here?
Taken 'as is' from current kernel sources, i,e, crypto/aes.c
>
> +static inline u32 ror32(u32 word, unsigned int shift)
> +{
> + return (word >> shift) | (word << (32 - shift));
> +}
> +
> +static inline u8 __init
> +f_mult (u8 a, u8 b)
> +{
> + u8 aa = log_tab[a], cc = aa + log_tab[b];
> +
> + return pow_tab[cc + (cc < aa ? 1 : 0)];
> +}
>
> Can you stick to either
> type f()
> or
> type
> f()
> style, but not both at once?
As above.
>
> +#define ls_box(x) \
> +( aes_fl_tab[0][byte(x, 0)] ^ \
> + aes_fl_tab[1][byte(x, 1)] ^ \
> + aes_fl_tab[2][byte(x, 2)] ^ \
> + aes_fl_tab[3][byte(x, 3)] )
>
> +#define star_x(x) (((x) & 0x7f7f7f7f) << 1) ^ x) & 0x80808080) >> 7) *
> 0x1b)
>
> You used inlines for complex function-like calls above, why not here?
As above.
>
> +#define imix_col(y,x) \
> +u = star_x(x);\
> +v = star_x(u);\
> +w = star_x(v);\
> +t = w ^ (x); \
> + (y) = u ^ v ^ w;\
> + (y) ^= ror32(u ^ t, 8) ^ \
> + ror32(v ^ t, 16) ^ \
> + ror32(t,24)
>
> this #define is bad, bad, BAD. Imagine: if(...) imix_col(a,b);
> Also I'm not sure that usage of "hidden" params (u,v,w,t) is ok.
As above.
> --
> vda
>
The thing is I didn't want to modify the existing source code of
crpto/aes.c except where necessary.
--
Andreas Steinmetz SPAMmers use [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][PATCH 4/4] AES assembler implementation for x86_64
Adrian Bunk wrote: > That is not specifically against this patch, but before we add another > AES implementation, I'd like to find a better solution for the general > AES selection. That would be nice as I didn't like having to duplicate a whole Kconfig entry which in fact means that it is triplicated now. I'm fine with any solution here but I do believe whatever solution is for the crypto maintainers to decide. [snip] >>+ depends on CRYPTO && (X86 && !X86_64) >>+ depends on CRYPTO && X86 && !X86_64 >>... > > > This doesn't make any difference. > > I think the former version was better readable, but that's no strong > opinion. This was only personal preference during development and actually you're right, the former version is better readable. -- Andreas Steinmetz SPAMmers use [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/
[RFC][PATCH 3/4] AES assembler implementation for x86_64
The attached patch contains the x86_64 arch specific Makefile stuff. -- Andreas Steinmetz SPAMmers use [EMAIL PROTECTED] diff -rNu linux-2.6.11.2.orig/arch/x86_64/Makefile linux-2.6.11.2/arch/x86_64/Makefile --- linux-2.6.11.2.orig/arch/x86_64/Makefile2005-03-09 09:12:47.0 +0100 +++ linux-2.6.11.2/arch/x86_64/Makefile 2005-04-17 13:05:04.0 +0200 @@ -65,7 +65,8 @@ head-y := arch/x86_64/kernel/head.o arch/x86_64/kernel/head64.o arch/x86_64/kernel/init_task.o libs-y += arch/x86_64/lib/ -core-y += arch/x86_64/kernel/ arch/x86_64/mm/ +core-y += arch/x86_64/kernel/ arch/x86_64/mm/ \ + arch/x86_64/crypto/ core-$(CONFIG_IA32_EMULATION) += arch/x86_64/ia32/ drivers-$(CONFIG_PCI) += arch/x86_64/pci/ drivers-$(CONFIG_OPROFILE) += arch/x86_64/oprofile/ diff -rNu linux-2.6.11.2.orig/arch/x86_64/crypto/Makefile linux-2.6.11.2/arch/x86_64/crypto/Makefile --- linux-2.6.11.2.orig/arch/x86_64/crypto/Makefile 1970-01-01 01:00:00.0 +0100 +++ linux-2.6.11.2/arch/x86_64/crypto/Makefile 2005-04-17 13:02:00.0 +0200 @@ -0,0 +1,9 @@ +# +# x86_64/crypto/Makefile +# +# Arch-specific CryptoAPI modules. +# + +obj-$(CONFIG_CRYPTO_AES_X86_64) += aes-x86_64.o + +aes-x86_64-y := aes-x86_64-asm.o aes.o
[RFC][PATCH 4/4] AES assembler implementation for x86_64
The attached patch contains the required changes for the crypto Kconfig to enable the usage of the x86_64 AES assembler implementation. -- Andreas Steinmetz SPAMmers use [EMAIL PROTECTED] diff -rNu linux-2.6.11.2.orig/crypto/Kconfig linux-2.6.11.2/crypto/Kconfig --- linux-2.6.11.2.orig/crypto/Kconfig 2005-03-09 09:12:53.0 +0100 +++ linux-2.6.11.2/crypto/Kconfig 2005-04-17 13:10:51.0 +0200 @@ -133,7 +133,7 @@ config CRYPTO_AES tristate "AES cipher algorithms" - depends on CRYPTO && !(X86 && !X86_64) + depends on CRYPTO && !X86 && !X86_64 help AES cipher algorithms (FIPS-197). AES uses the Rijndael algorithm. @@ -153,7 +153,27 @@ config CRYPTO_AES_586 tristate "AES cipher algorithms (i586)" - depends on CRYPTO && (X86 && !X86_64) + depends on CRYPTO && X86 && !X86_64 + help + AES cipher algorithms (FIPS-197). AES uses the Rijndael + algorithm. + + Rijndael appears to be consistently a very good performer in + both hardware and software across a wide range of computing + environments regardless of its use in feedback or non-feedback + modes. Its key setup time is excellent, and its key agility is + good. Rijndael's very low memory requirements make it very well + suited for restricted-space environments, in which it also + demonstrates excellent performance. Rijndael's operations are + among the easiest to defend against power and timing attacks. + + The AES specifies three key sizes: 128, 192 and 256 bits + + See <http://csrc.nist.gov/encryption/aes/> for more information. + +config CRYPTO_AES_X86_64 + tristate "AES cipher algorithms (x86_64)" + depends on CRYPTO && X86 && X86_64 help AES cipher algorithms (FIPS-197). AES uses the Rijndael algorithm.
[RFC][PATCH 2/4] AES assembler implementation for x86_64
The attached patch contains Gladman's in-kernel code for key schedule
and table generation modified to fit to my assembler implementation,
--
Andreas Steinmetz SPAMmers use [EMAIL PROTECTED]
diff -rNu linux-2.6.11.2.orig/arch/x86_64/crypto/aes.c
linux-2.6.11.2/arch/x86_64/crypto/aes.c
--- linux-2.6.11.2.orig/arch/x86_64/crypto/aes.c1970-01-01
01:00:00.0 +0100
+++ linux-2.6.11.2/arch/x86_64/crypto/aes.c 2005-04-17 13:34:17.0
+0200
@@ -0,0 +1,332 @@
+/*
+ * Cryptographic API.
+ *
+ * AES Cipher Algorithm.
+ *
+ * Based on Brian Gladman's code.
+ *
+ * Linux developers:
+ * Alexander Kjeldaas <[EMAIL PROTECTED]>
+ * Herbert Valerio Riedel <[EMAIL PROTECTED]>
+ * Kyle McMartin <[EMAIL PROTECTED]>
+ * Adam J. Richter <[EMAIL PROTECTED]> (conversion to 2.5 API).
+ * Andreas Steinmetz <[EMAIL PROTECTED]> (adapted to x86_64 assembler)
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * ---
+ * Copyright (c) 2002, Dr Brian Gladman <[EMAIL PROTECTED]>, Worcester, UK.
+ * All rights reserved.
+ *
+ * LICENSE TERMS
+ *
+ * The free distribution and use of this software in both source and binary
+ * form is allowed (with or without changes) provided that:
+ *
+ * 1. distributions of this source code include the above copyright
+ * notice, this list of conditions and the following disclaimer;
+ *
+ * 2. distributions in binary form include the above copyright
+ * notice, this list of conditions and the following disclaimer
+ * in the documentation and/or other associated materials;
+ *
+ * 3. the copyright holder's name is not used to endorse products
+ * built using this software without specific written permission.
+ *
+ * ALTERNATIVELY, provided that this notice is retained in full, this product
+ * may be distributed under the terms of the GNU General Public License (GPL),
+ * in which case the provisions of the GPL apply INSTEAD OF those given above.
+ *
+ * DISCLAIMER
+ *
+ * This software is provided 'as is' with no explicit or implied warranties
+ * in respect of its properties, including, but not limited to, correctness
+ * and/or fitness for purpose.
+ * ---
+ */
+
+/* Some changes from the Gladman version:
+s/RIJNDAEL(e_key)/E_KEY/g
+s/RIJNDAEL(d_key)/D_KEY/g
+*/
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define AES_MIN_KEY_SIZE 16
+#define AES_MAX_KEY_SIZE 32
+
+#define AES_BLOCK_SIZE 16
+
+/*
+ * #define byte(x, nr) ((unsigned char)((x) >> (nr*8)))
+ */
+inline static u8
+byte(const u32 x, const unsigned n)
+{
+ return x >> (n << 3);
+}
+
+#define u32_in(x) le32_to_cpu(*(const u32 *)(x))
+
+struct aes_ctx {
+ u32 key_length;
+ u32 E[60];
+ u32 D[60];
+};
+
+#define E_KEY ctx->E
+#define D_KEY ctx->D
+
+static u8 pow_tab[256] __initdata;
+static u8 log_tab[256] __initdata;
+static u8 sbx_tab[256] __initdata;
+static u8 isb_tab[256] __initdata;
+static u32 rco_tab[10];
+u32 aes_ft_tab[4][256];
+u32 aes_it_tab[4][256];
+
+u32 aes_fl_tab[4][256];
+u32 aes_il_tab[4][256];
+
+static inline u32 __init rol32(u32 word, unsigned int shift)
+{
+ return (word << shift) | (word >> (32 - shift));
+}
+
+static inline u32 ror32(u32 word, unsigned int shift)
+{
+ return (word >> shift) | (word << (32 - shift));
+}
+
+static inline u8 __init
+f_mult (u8 a, u8 b)
+{
+ u8 aa = log_tab[a], cc = aa + log_tab[b];
+
+ return pow_tab[cc + (cc < aa ? 1 : 0)];
+}
+
+#define ff_mult(a,b)(a && b ? f_mult(a, b) : 0)
+
+#define ls_box(x) \
+( aes_fl_tab[0][byte(x, 0)] ^ \
+ aes_fl_tab[1][byte(x, 1)] ^ \
+ aes_fl_tab[2][byte(x, 2)] ^ \
+ aes_fl_tab[3][byte(x, 3)] )
+
+void __init
+gen_tabs (void)
+{
+ u32 i, t;
+ u8 p, q;
+
+ /* log and power tables for GF(2**8) finite field with
+ 0x011b as modular polynomial - the simplest primitive
+ root is 0x03, used here to generate the tables */
+
+ for (i = 0, p = 1; i < 256; ++i) {
+ pow_tab[i] = (u8) p;
+ log_tab[p] = (u8) i;
+
+ p ^= (p << 1) ^ (p & 0x80 ? 0x01b : 0);
+ }
+
+ log_tab[1] = 0;
+
+ for (i = 0, p = 1; i < 10; ++i) {
+ rco_tab[i] = p;
+
+ p = (p << 1) ^ (p & 0x80 ? 0x01b : 0);
+ }
+
+ for (i = 0; i < 256; ++i) {
+ p = (i ? pow_tab[255 - log_tab[i]] :
[RFC][PATCH 1/4] AES assembler implementation for x86_64
The attached patch contains my AES assembler implementation for x86_64. This includes only encrypt/decrypt as Gladman's in-kernel code is used for key schedule and table generation. -- Andreas Steinmetz SPAMmers use [EMAIL PROTECTED] diff -rNu linux-2.6.11.2.orig/arch/x86_64/crypto/aes-x86_64-asm.S linux-2.6.11.2/arch/x86_64/crypto/aes-x86_64-asm.S --- linux-2.6.11.2.orig/arch/x86_64/crypto/aes-x86_64-asm.S 1970-01-01 01:00:00.0 +0100 +++ linux-2.6.11.2/arch/x86_64/crypto/aes-x86_64-asm.S 2005-04-17 12:56:05.0 +0200 @@ -0,0 +1,186 @@ +/* AES (Rijndael) implementation (FIPS PUB 197) for x86_64 + * + * Copyright (C) 2005 Andreas Steinmetz, <[EMAIL PROTECTED]> + * + * License: + * This code can be distributed under the terms of the GNU General Public + * License (GPL) Version 2 provided that the above header down to and + * including this sentence is retained in full. + */ + +.extern aes_ft_tab +.extern aes_it_tab +.extern aes_fl_tab +.extern aes_il_tab + +.text + +#define R1 %rax +#define R1E%eax +#define R1X%ax +#define R1H%ah +#define R1L%al +#define R2 %rbx +#define R2E%ebx +#define R2X%bx +#define R2H%bh +#define R2L%bl +#define R3 %rcx +#define R3E%ecx +#define R3X%cx +#define R3H%ch +#define R3L%cl +#define R4 %rdx +#define R4E%edx +#define R4X%dx +#define R4H%dh +#define R4L%dl +#define R5 %rsi +#define R5E%esi +#define R6 %rdi +#define R6E%edi +#define R7 %rbp +#define R7E%ebp +#define R8 %r8 +#define R9 %r9 +#define R10%r10 +#define R11%r11 + +#define prologue(FUNC,BASE,B128,B192,r1,r2,r3,r4,r5,r6,r7,r8,r9,r10,r11) \ + .global FUNC; \ + .type FUNC,@function; \ + .align 8; \ +FUNC: movqr1,r2; \ + movqr3,r4; \ + leaqBASE+52(r8),r9; \ + movqr10,r11;\ + movl(r7),r5 ## E; \ + movl4(r7),r1 ## E; \ + movl8(r7),r6 ## E; \ + movl12(r7),r7 ## E; \ + movl(r8),r10 ## E; \ + xorl-48(r9),r5 ## E;\ + xorl-44(r9),r1 ## E;\ + xorl-40(r9),r6 ## E;\ + xorl-36(r9),r7 ## E;\ + cmpl$24,r10 ## E; \ + jb B128; \ + leaq32(r9),r9; \ + je B192; \ + leaq32(r9),r9; + +#define epilogue(r1,r2,r3,r4,r5,r6,r7,r8,r9) \ + movqr1,r2; \ + movqr3,r4; \ + movlr5 ## E,(r9); \ + movlr6 ## E,4(r9); \ + movlr7 ## E,8(r9); \ + movlr8 ## E,12(r9); \ + ret; + +#define round(TAB,OFFSET,r1,r2,r3,r4,r5,r6,r7,r8,ra,rb,rc,rd) \ + movzbl r2 ## H,r5 ## E;\ + movzbl r2 ## L,r6 ## E;\ + movlTAB+1024(,r5,4),r5 ## E;\ + movwr4 ## X,r2 ## X;\ + movlTAB(,r6,4),r6 ## E; \ + roll$16,r2 ## E;\ + shrl$16,r4 ## E;\ + movzbl r4 ## H,r7 ## E;\ + movzbl r4 ## L,r4 ## E;\ + xorlOFFSET(r8),ra ## E; \ + xorlOFFSET+4(r8),rb ## E; \ + xorlTAB+3072(,r7,4),r5 ## E;\ + xorlTAB+2048(,r4,4),r6 ## E;\ + movzbl r1 ## L,r7 ## E;\ + movzbl r1 ## H,r4 ## E;\ + movlTAB+1024(,r4,4),r4 ## E;\ + movwr3 ## X,r1 ## X;\ + roll$16,r1 ## E;\ + shrl$16,r3 ## E;\ + xorlTAB(,r7,4),r5 ## E; \ + movzbl r3 ## H,r7 ## E;\ + movzbl r3 ## L,r3 ## E;\ + xorlTAB+3072(,r7,4),r4 ## E;\ + xorlTAB+2048(,r3,4),r5 ## E;\ + movzbl r1 ## H,r7 ## E;\ + movzbl r1 ## L,r3 ## E;\ + shrl$16,r1 ## E;\ + xorlTAB+3072(,r7,4),r6 ## E;\ + movlTAB+2048(,r3,4),r3 ## E;\ + movzbl r1 ## H,r7 ## E;\ + movzbl r1 ## L,r1 ## E;\ + xorlTAB+1024(,r7,4),r6 ## E;\ + xorlTAB(,r1,4),r3 ## E; \ + movzbl r2 ## H,r1 ## E;\ + movzbl r2 ## L,r7 ## E;\ + shrl$16,r2 ## E;\ + xorlTAB+3072(,r1,4),r3 ## E;\ + xorlTAB+2048(,r7,4),r4 ## E;\ + movzbl r2 ## H,r1 ## E;\ + movzbl r2 ## L,r2 ## E;\ + xorlOFFSET+8(r8),rc ## E; \ + xorlOFFSET+12(r8),rd ## E; \ + xorlTAB+1024(,r1,4),r3 ## E;\ + xorlTAB(,r2,4),r4 ## E; + +#define move_regs(r1,r2,r3,r4) \ + movlr3 ## E,r1 ## E;\ + movlr4 ## E,r2 ## E; + +#define entry(FUNC,BASE,B128,B192) \ + prologue(FUNC,BASE,B
[RFC][PATCH 0/4] AES assembler implementation for x86_64
Implementation: === The encrypt/decrypt code is based on an x86 implementation I did a while ago which I never published. This unpublished implementation does include an assembler based key schedule and precomputed tables. For simplicity and best acceptance, however, I took Gladman's in-kernel code for table generation and key schedule for the kernel port of my assembler code and modified this code to produce the key schedule as required by my assembler implementation. File locations and Kconfig are kept similar to the i586 AES assembler implementation. It may seem a little bit strange to use 32 bit I/O and registers in the assembler implementation but this gives the best code size. My implementation takes one instruction more per round compared to Gladman's x86 assembler but it doesn't require any stack for local variables or saved registers and it is less serialized than Gladman's x86 code. Note that all comparisons to Gladman's code were done after my code was implemented. I did only use FIPS PUB 197 for the implementation so my implementation is independent work. If anybody has a better assembler solution for x86_64 I'll be pleased to have my code replaced with the better solution. Testing: The implementation passes the in-kernel crypto testing module and I'm running it without any problems on my laptop where it is mainly used for dm-crypt. Microbenchmark: === The microbenchmark was done in userspace with similar compile flags as used during kernel compile. Encrypt/decrypt is about 35% faster than the generic C implementation. As the generic C as well as my assembler implementation are both table driven I don't really expect that there is much room for further improvements though I'll be glad to be corrected here. The key schedule is about 5% slower than the generic C implementation. This is due to the fact that some more work has to be done in the key schedule routine to fit the schedule to the assembler implementation. Code Size: == Encrypt and decrypt are together about 2.1 Kbytes smaller than the generic C implementation which is important with regard to L1 cache usage. The key schedule routine is about 100 bytes larger than the generic C implementation. Data Size: == There's no difference in data size requirements between the assembler implementation and the generic C implementation. License: Gladmans's code is dual BSD/GPL whereas my assembler code is GPLv2 only (I'm not going to change the license for my code). So I had to change the module license for the x86_64 aes module from 'Dual BSD/GPL' to 'GPL' to reflect the most restrictive license within the module. PS: It can happen that it may take a while until I can reply as I'm regularly offline due to my current daytime job requirements. -- Andreas Steinmetz SPAMmers use [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: [PATCH encrypted swsusp 1/3] core functionality
Pavel Machek wrote: > Andreas, do you think you could write nice, long, FAQ entries so that > we don't have to go through this discussion over and over? I can do so over the weekend. Am I right that you mean the FAQ section of Documentation/power/swsusp.txt? BTW: would it make sense to reset the suspend header via software_resume() if booted with noresume? Currently this code path does nothing. -- Andreas Steinmetz SPAMmers use [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: [PATCH encrypted swsusp 1/3] core functionality
Matt Mackall wrote: > A much more likely vector is stealing the laptop while it's suspended. > And the encrypted swsusp patch has -zero- security here: it writes the > key in the header in the clear. It's rather odd that everyone's hung > up on the "box rooted after resume" attack and completely ignoring the > much more common "stole my laptop" attack. > Thats because you have already have a solution for "stolen while suspended" with dm-crypt and initrd/initramfs but you don't have a solution for "rooted after resume". -- Andreas Steinmetz SPAMmers use [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: [PATCH encrypted swsusp 1/3] core functionality
Matt Mackall wrote: > Zero only the mlocked regions. This should take essentially no time at > all. Swsusp knows which these are because they have to be mlocked > after resume as well. If it's not mlocked, it's liable to be swapped > out anyway. Nitpicking: What happens if the disk decides to relocate a close to failing sector containing mlocked data during resume zeroing? This just means that there will be sensitive data around on the disk that can't be zeroed out anymore but which might be recovered by specialized companies/institutions. Encrypting these data in the first place reduces this problem to a single potentially problematic sector. If this risk is then still too high for you then there's always the possiblity to use a sledgehammer :-) -- Andreas Steinmetz SPAMmers use [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: [PATCH encrypted swsusp 1/3] core functionality
Herbert Xu wrote: > On Wed, Apr 13, 2005 at 02:59:28PM +0200, Andreas Steinmetz wrote: > >>Herbert Xu wrote: >> >>>What's wrong with using swap over dmcrypt + initramfs? People have >>>already used that to do encrypted swsusp. >> >>Nothing. The problem is the fact that after resume there is then >>unencrypted(*) data on disk that should never have been there, e.g. >>dm-crypt keys, ssh keys, ... > > > Why is that? In the case of swap over dmcrypt, swsusp never reads/writes > the disk directly. All operations are done through dmcrypt. > > The user has to enter a password before the system can be resumed. Think of it the following way: user suspend and later resumes. During suspend some mlocked memory e.g. from ssh-agent gets dumped to swap. Some days later the system gets broken in from a remote place. Unfortunately the ssh keys are still on swap (assuming that ssh-agent is not running then) and can be recovered by the intruder. The intruder can then gain access to other sites with the data recovered from the earlier suspend. You see, it is not a matter of having encrypted swap, what matters here is what suspend needs to write to swap and this can be stuff that does not belong there so it needs to be erased after resume. And the easiest way to do this is to encrypt the suspend image with a temporary key that gets cleared on resume. If you don't resume mkswap will also clear the key though i have to admit that there's a small window then in which the key and data are still accessible. -- Andreas Steinmetz SPAMmers use [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: [PATCH encrypted swsusp 1/3] core functionality
Pavel Machek wrote: > Applied (it is *not* going to make it into 2.6.12, and not sure about > 2.6.13, but it is in my local tree now. You had Kconfig and docs > changes, too, can you retransmit them? > Pavel No changes to config and docs, but I'll attach them again nevertheless. BTW: it was quite clear to me that this can't make 2.6.12 and that 2.6.13 might be a bit early. -- Andreas Steinmetz SPAMmers use [EMAIL PROTECTED] --- linux-2.6.11.2/kernel/power/Kconfig.ast 2005-04-10 20:44:48.0 +0200 +++ linux-2.6.11.2/kernel/power/Kconfig 2005-04-10 21:01:36.0 +0200 @@ -72,3 +72,14 @@ suspended image to. It will simply pick the first available swap device. +config SWSUSP_ENCRYPT + bool "Encrypt suspend image" + depends on SOFTWARE_SUSPEND && CRYPTO=y && (CRYPTO_AES=y || CRYPTO_AES_586=y) + default "" + ---help--- + To prevent data gathering from swap after resume you can encrypt + the suspend image with a temporary key that is deleted on + resume. + + Note that the temporary key is stored unencrypted on disk while the + system is suspended. --- linux-2.6.11.2/Documentation/power/swsusp.txt.ast 2005-04-10 21:07:01.0 +0200 +++ linux-2.6.11.2/Documentation/power/swsusp.txt 2005-04-10 21:10:56.0 +0200 @@ -30,6 +30,13 @@ echo platform > /sys/power/disk; echo disk > /sys/power/state +Encrypted suspend image: + +If you want to store your suspend image encrypted with a temporary +key to prevent data gathering after resume you must compile +crypto and the aes algorithm into the kernel - modules won't work +as they cannot be loaded at resume time. + Article about goals and implementation of Software Suspend for Linux
Re: [PATCH encrypted swsusp 1/3] core functionality
Herbert Xu wrote: > What's wrong with using swap over dmcrypt + initramfs? People have > already used that to do encrypted swsusp. Nothing. The problem is the fact that after resume there is then unencrypted(*) data on disk that should never have been there, e.g. dm-crypt keys, ssh keys, ... This may lead to nasty surprises that can occur after weeks or months. (*) unencrypted from the point of view of the running system. -- Andreas Steinmetz SPAMmers use [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.11 acpi battery state readout as source of keyboard/touchpad troubles
Pavel Machek wrote: > CONFIG_ACPI_DEBUG enabled by chance? > Pavel # CONFIG_ACPI_DEBUG is not set -- Andreas Steinmetz SPAMmers use [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/
2.6.12rc2: Oops with pcmcia ide flash disk
2.6.12rc2 oopses during eject of a pcmcia ide flash disk on x86_64.
2.6.11.2 works fine.
Attached is the kernel config and the oops itself.
--
Andreas Steinmetz SPAMmers use [EMAIL PROTECTED]
Apr 12 14:22:45 gringo kernel: cs: memory probe 0x0c-0x0f: excluding
0xc-0xd3fff 0xd8000-0xd 0xe4000-0xf
Apr 12 14:22:45 gringo kernel: ttyS16: detected caps 0700 should be 0100
Apr 12 14:22:45 gringo kernel: ttyS16 at I/O 0x100 (irq = 17) is a 16C950/954
Apr 12 14:22:45 gringo kernel: ttyS17 at I/O 0x108 (irq = 17) is a 8250
Apr 12 14:22:45 gringo kernel: cs: memory probe 0x0c-0x0f: excluding
0xc-0xd3fff 0xd8000-0xd 0xe4000-0xf
Apr 12 14:22:45 gringo kernel: hde: 16MB CTS, CFA DISK drive
Apr 12 14:22:45 gringo kernel: ide2 at 0x110-0x117,0x11e on irq 18
Apr 12 14:22:45 gringo kernel: hde: max request size: 128KiB
Apr 12 14:22:45 gringo kernel: hde: 32000 sectors (16 MB) w/4KiB Cache,
CHS=500/2/32
Apr 12 14:22:45 gringo kernel: hde: cache flushes not supported
Apr 12 14:22:45 gringo kernel: hde: hde1
Apr 12 14:22:45 gringo kernel: ide-cs: hde: Vcc = 3.3, Vpp = 0.0
Apr 12 14:22:45 gringo kernel: hde: hde1
Apr 12 14:22:45 gringo kernel: Unable to handle kernel NULL pointer dereference
at 0020 RIP:
Apr 12 14:22:45 gringo kernel: {ide_drive_remove+21}
Apr 12 14:22:45 gringo kernel: PGD 3f76a067 PUD 3f708067 PMD 0
Apr 12 14:22:45 gringo kernel: Oops: [1]
Apr 12 14:22:45 gringo kernel: CPU 0
Apr 12 14:22:45 gringo kernel: Modules linked in:
Apr 12 14:22:45 gringo kernel: Pid: 1066, comm: cardctl Not tainted
2.6.12-rc2-gringo
Apr 12 14:22:45 gringo kernel: RIP: 0010:[]
{ide_drive_remove+21}
Apr 12 14:22:45 gringo kernel: RSP: :81003f6afa28 EFLAGS: 00010296
Apr 12 14:22:45 gringo kernel: RAX: 805d5050 RBX: 805d51c0 RCX:
805d5198
Apr 12 14:22:45 gringo kernel: RDX: RSI: RDI:
805d5050
Apr 12 14:22:45 gringo kernel: RBP: 805d5178 R08: 0117 R09:
0001
Apr 12 14:22:45 gringo kernel: R10: R11: 80182c10 R12:
80511cf0
Apr 12 14:22:45 gringo kernel: R13: 0001 R14: 0002 R15:
805115a0
Apr 12 14:22:45 gringo kernel: FS: 2ae0aae0()
GS:805ee340() knlGS:
Apr 12 14:22:45 gringo kernel: CS: 0010 DS: ES: CR0: 8005003b
Apr 12 14:22:45 gringo kernel: CR2: 0020 CR3: 3f072000 CR4:
06e0
Apr 12 14:22:45 gringo kernel: Process cardctl (pid: 1066, threadinfo
81003f6ae000, task 81000237c820)
Apr 12 14:22:45 gringo kernel: Stack: 0001 802b5f67
805d5178 805113a0
Apr 12 14:22:45 gringo kernel:81003fa17000 802b6194
805d5178 805d5738
Apr 12 14:22:45 gringo kernel:81003fa17000 802b4fc8
Apr 12 14:22:45 gringo kernel: Call
Trace:{device_release_driver+119}
{bus_remove_device+180}
Apr 12 14:22:45 gringo kernel:{device_del+88}
{device_unregister+9}
Apr 12 14:22:45 gringo kernel:{ide_unregister+546}
{send_event_callback+0}
Apr 12 14:22:45 gringo kernel:{ide_release+37}
{ide_event+174}
Apr 12 14:22:45 gringo kernel:
{avc_has_perm_noaudit+574}
{send_event_callback+0}
Apr 12 14:22:45 gringo kernel:
{__bus_for_each_dev+109}
{send_event_callback+0}
Apr 12 14:22:45 gringo kernel:{bus_for_each_dev+72}
{send_event+93}
Apr 12 14:22:45 gringo kernel:{ds_event+103}
{send_event+69}
Apr 12 14:22:45 gringo kernel:{socket_shutdown+13}
{send_event+69}
Apr 12 14:22:45 gringo kernel:{socket_remove+9}
{pcmcia_eject_card+93}
Apr 12 14:22:45 gringo kernel:{ds_ioctl+1278}
{inode_has_perm+106}
Apr 12 14:22:45 gringo kernel:
{do_get_write_access+1203}
{avc_alloc_node+56}
Apr 12 14:22:45 gringo kernel:
{selinux_file_ioctl+762} {avc_has_perm+90}
Apr 12 14:22:45 gringo kernel:{journal_stop+480}
{task_has_capability+97}
Apr 12 14:22:45 gringo kernel:{do_ioctl+78}
{vfs_ioctl+637}
Apr 12 14:22:45 gringo kernel:{sys_ioctl+106}
{system_call+126}
Apr 12 14:22:45 gringo kernel:
Apr 12 14:22:45 gringo kernel:
Apr 12 14:22:45 gringo kernel: Code: ff 52 20 31 c0 48 83 c4 08 c3 90 41 54 48
8d 87 38 01 00 00
Apr 12 14:22:45 gringo kernel: RIP {ide_drive_remove+21} RSP
Apr 12 14:22:45 gringo kernel: CR2: 0020
config.gz
Description: application/gunzip
Re: [PATCH encrypted swsusp 1/3] core functionality
Here comes the next incarnation, this time against 2.6.12rc2.
Unfortunately only compile tested as 2.6.12rc2 happily oopses away
(vanilla from kernel.org, oops already sent to lkml).
Please let me know if you want any further changes.
--
Andreas Steinmetz SPAMmers use [EMAIL PROTECTED]
--- linux-2.6.12-rc2/kernel/power/swsusp.c.ast 2005-04-12 13:20:41.0
+0200
+++ linux-2.6.12-rc2/kernel/power/swsusp.c 2005-04-12 14:20:41.0
+0200
@@ -31,6 +31,9 @@
* Alex Badea <[EMAIL PROTECTED]>:
* Fixed runaway init
*
+ * Andreas Steinmetz <[EMAIL PROTECTED]>:
+ * Added encrypted suspend option
+ *
* More state savers are welcome. Especially for the scsi layer...
*
* For TODOs,FIXMEs also look in Documentation/power/swsusp.txt
@@ -72,6 +75,16 @@
#include "power.h"
+#ifdef CONFIG_SWSUSP_ENCRYPT
+#include
+#include
+#include
+#endif
+
+#define CIPHER "aes"
+#define MAXKEY 32
+#define MAXIV 32
+
/* References to section boundaries */
extern const void __nosave_begin, __nosave_end;
@@ -102,7 +115,9 @@ static suspend_pagedir_t *pagedir_save;
#define SWSUSP_SIG "S1SUSPEND"
static struct swsusp_header {
- char reserved[PAGE_SIZE - 20 - sizeof(swp_entry_t)];
+ char reserved[PAGE_SIZE - 20 - MAXKEY - MAXIV - sizeof(swp_entry_t)];
+ u8 key[MAXKEY];
+ u8 iv[MAXIV];
swp_entry_t swsusp_info;
charorig_sig[10];
charsig[10];
@@ -110,6 +125,11 @@ static struct swsusp_header {
static struct swsusp_info swsusp_info;
+#ifdef CONFIG_SWSUSP_ENCRYPT
+static u8 key[MAXKEY];
+static u8 iv[MAXIV];
+#endif
+
/*
* XXX: We try to keep some more pages free so that I/O operations succeed
* without paging. Might this be more?
@@ -128,6 +148,60 @@ static struct swsusp_info swsusp_info;
static unsigned short swapfile_used[MAX_SWAPFILES];
static unsigned short root_swap;
+#ifdef CONFIG_SWSUSP_ENCRYPT
+static int crypto_init(int mode, struct crypto_tfm **tfm)
+{
+ char *modemsg;
+ int len;
+ int error = 0;
+
+ modemsg = mode ? "suspend not possible" : "resume not possible";
+
+ *tfm = crypto_alloc_tfm(CIPHER, CRYPTO_TFM_MODE_CBC);
+ if(!*tfm) {
+ printk(KERN_ERR "swsusp: no tfm, %s\n", modemsg);
+ error = -EINVAL;
+ goto out;
+ }
+
+ if(sizeof(key) < crypto_tfm_alg_min_keysize(*tfm)) {
+ printk(KERN_ERR "swsusp: key buffer too small, %s\n", modemsg);
+ error = -ENOKEY;
+ goto fail;
+ }
+
+ if (mode) {
+ get_random_bytes(key, MAXKEY);
+ get_random_bytes(iv, MAXIV);
+ }
+
+ len = crypto_tfm_alg_max_keysize(*tfm);
+ if (len > sizeof(key))
+ len = sizeof(key);
+
+ if (crypto_cipher_setkey(*tfm, key, len)) {
+ printk(KERN_ERR "swsusp: key setup failure, %s\n", modemsg);
+ error = -EKEYREJECTED;
+ goto fail;
+ }
+
+ len = crypto_tfm_alg_ivsize(*tfm);
+
+ if (sizeof(iv) < len) {
+ printk(KERN_ERR "swsusp: iv buffer too small, %s\n", modemsg);
+ error = -EOVERFLOW;
+ goto fail;
+ }
+
+ crypto_cipher_set_iv(*tfm, iv, len);
+
+ goto out;
+
+fail: crypto_free_tfm(*tfm);
+out: return error;
+}
+#endif
+
static int mark_swapfiles(swp_entry_t prev)
{
int error;
@@ -139,6 +213,10 @@ static int mark_swapfiles(swp_entry_t pr
!memcmp("SWAPSPACE2",swsusp_header.sig, 10)) {
memcpy(swsusp_header.orig_sig,swsusp_header.sig, 10);
memcpy(swsusp_header.sig,SWSUSP_SIG, 10);
+#ifdef CONFIG_SWSUSP_ENCRYPT
+ memcpy(swsusp_header.key, key, MAXKEY);
+ memcpy(swsusp_header.iv, iv, MAXIV);
+#endif
swsusp_header.swsusp_info = prev;
error = rw_swap_page_sync(WRITE,
swp_entry(root_swap, 0),
@@ -285,6 +363,19 @@ static int data_write(void)
int error = 0, i = 0;
unsigned int mod = nr_copy_pages / 100;
struct pbe *p;
+#ifdef CONFIG_SWSUSP_ENCRYPT
+ struct crypto_tfm *tfm;
+ struct scatterlist src, dst;
+
+ if ((error = crypto_init(1, &tfm)))
+ return error;
+
+ src.offset = 0;
+ src.length = PAGE_SIZE;
+ dst.page = virt_to_page((void *)&swsusp_header);
+ dst.offset = 0;
+ dst.length = PAGE_SIZE;
+#endif
if (!mod)
mod = 1;
@@ -293,11 +384,22 @@ static int data_write(void)
for_each_pbe(p, pagedir_nosave) {
if (!(i%mod))
printk( "\b\b\b\b%3d%%", i / mod );
+#ifdef CONFIG_SWSUSP_ENCRYPT
+ src.page = virt_to_page(p->address);
+ error = crypto_ci
Re: [PATCH encrypted swsusp 1/3] core functionality
Rafael J. Wysocki wrote:
> Hi,
>
> On Monday, 11 of April 2005 18:11, Andreas Steinmetz wrote:
>
>>Pavel Machek wrote:
>>
>>>Was it really neccessary to include "union u"? I don't like its name,
>>
>>Here comes the patch with this reverted. I'm now using casts when
>>'abusing' the space for encryption. Furthermore the iv set up in the tfm
>>is used instead of the local copy.
>
>
> I had no time to review your patch earlier, sorry. I'm inlining it so that I
> can
> comment it:
>
>
>>--- linux-2.6.11.2/kernel/power/swsusp.c.ast 2005-04-10 14:08:55.0
>>+0200
>>+++ linux-2.6.11.2/kernel/power/swsusp.c 2005-04-11 18:05:58.0
>>+0200
>>@@ -31,6 +31,9 @@
>> * Alex Badea <[EMAIL PROTECTED]>:
>> * Fixed runaway init
>> *
>>+ * Andreas Steinmetz <[EMAIL PROTECTED]>:
>>+ * Added encrypted suspend option
>>+ *
>> * More state savers are welcome. Especially for the scsi layer...
>> *
>> * For TODOs,FIXMEs also look in Documentation/power/swsusp.txt
>>@@ -72,6 +75,16 @@
>>
>> #include "power.h"
>>
>>+#ifdef CONFIG_SWSUSP_ENCRYPT
>>+#include
>>+#include
>>+#include
>>+#endif
>>+
>>+#define CIPHER "aes"
>>+#define MAXKEY 32
>>+#define MAXIV 32
>
>
> Why not to put these definitions under #ifdef?
>
I keep it the way Pavel likes it here if you don't mind.
>
>>+
>> /* References to section boundaries */
>> extern const void __nosave_begin, __nosave_end;
>>
>>@@ -104,7 +117,9 @@
>> #define SWSUSP_SIG "S1SUSPEND"
>>
>> static struct swsusp_header {
>>- char reserved[PAGE_SIZE - 20 - sizeof(swp_entry_t)];
>
>
> I would add #ifdef here as well.
Same as above.
>
>
>>+ char reserved[PAGE_SIZE - 20 - MAXKEY - MAXIV - sizeof(swp_entry_t)];
>>+ u8 key[MAXKEY];
>>+ u8 iv[MAXIV];
>> swp_entry_t swsusp_info;
>> charorig_sig[10];
>> charsig[10];
>>@@ -112,6 +127,11 @@
>>
>> static struct swsusp_info swsusp_info;
>>
>>+#ifdef CONFIG_SWSUSP_ENCRYPT
>>+static u8 key[MAXKEY];
>>+static u8 iv[MAXIV];
>>+#endif
>>+
>> /*
>> * XXX: We try to keep some more pages free so that I/O operations succeed
>> * without paging. Might this be more?
>>@@ -130,6 +150,52 @@
>> static unsigned short swapfile_used[MAX_SWAPFILES];
>> static unsigned short root_swap;
>>
>>+#ifdef CONFIG_SWSUSP_ENCRYPT
>>+static struct crypto_tfm *crypto_init(int mode)
>
>
> I think it's better if this function returns an int error code and the
> messages are printed where it's called from. This way, the essential
> part of the code would be easier to grasp (Pavel?).
>
Pavel doesn't mind printing the errors here as far as I can see. The
messages will be adapted to suspend/resume stae.
>
>>+{
>>+ struct crypto_tfm *tfm;
>>+ int len;
>>+
>>+ tfm = crypto_alloc_tfm(CIPHER, CRYPTO_TFM_MODE_CBC);
>>+ if(!tfm) {
>>+ printk(KERN_ERR "swsusp: no tfm, suspend not possible\n");
>>+ return NULL;
>>+ }
>>+
>>+ if(sizeof(key) < crypto_tfm_alg_min_keysize(tfm)) {
>>+ printk("swsusp: key buffer too small, suspend not possible\n");
>>+ crypto_free_tfm(tfm);
>>+ return NULL;
>>+ }
>>+
>>+ if (sizeof(iv) < crypto_tfm_alg_ivsize(tfm)) {
>>+ printk("swsusp: iv buffer too small, suspend not possible\n");
>>+ crypto_free_tfm(tfm);
>>+ return NULL;
>>+ }
>>+
>>+ if (mode) {
>>+ get_random_bytes(key, MAXKEY);
>
>
> I hope you realize that this may give you a sequence of bits that you should
> not use as a key ...
I don't get what you mean here. As far as I know aes has no weak keys.
The only danger I can see here is that get_get_random_bytes returns a
consecutive sequence of zeroes (or some other constant value) on every
invocation. Otherwise a sequence of zeroes is just one of 2^256 possible
keys. I prefer to keep the key space as wide open as possible.
Please let me know if you did mean something different.
>
>
>>+ get_random_bytes(iv, MAXIV);
>>+ }
>>+
>>+ len = crypto_tfm_alg_max_keysize(tfm);
>
>
> You have used this value earlier. Why don't you initialize len at that time?
>
Not correct. Earl
Re: [PATCH] zero disk pages used by swsusp on resume
Rafael J. Wysocki wrote: > Hi, > > On Monday, 11 of April 2005 19:02, Andreas Steinmetz wrote: > >>Rafael J. Wysocki wrote: >> >>>Hi, >>> >>>On Monday, 11 of April 2005 12:37, Oliver Neukum wrote: >>> >>> >>>>Am Sonntag, 10. April 2005 22:14 schrieb Pavel Machek: >>>> >>>> >>>>>Hi! >>>>> >>>>> >>>>> >>>>>>>Oliver Neukum wrote: >>>>>>> >>>>>>> >>>>>>>>What is the point in doing so after they've rested on the disk for ages? >>>>>>> >>>>>>>The point is not physical access to the disk but data gathering after >>>>>>>resume or reboot. >>>>>> >>>>>>After resume or reboot normal access control mechanisms will work >>>>>>again. Those who can read a swap partition under normal circumstances >>>>>>can also read /dev/kmem. It seems to me like you are putting an extra >>>>>>lock on a window on the third floor while leaving the front door open. >>>>> >>>>>Andreas is right, his patches are needed. >>>>> >>>>>Currently, if your laptop is stolen after resume, they can still data >>>>>in swsusp image. >>>>> >>>>>Zeroing the swsusp pages helps a lot here, because at least they are >>>>>not getting swsusp image data without heavy tools. [Or think root >>>>>compromise month after you used swsusp.] >>>>> >>>>>Encrypting swsusp image is of course even better, because you don't >>>>>have to write large ammounts of zeros to your disks during resume ;-). >>>> >>>>Not only is it better, it completely supercedes wiping the image. >>>>Your laptop being stolen after resume is very much a corner case. >>>>You suspend your laptop while you are not around, don't you? >>> >>> >>>Not necessarily. Some people use suspend instead of shutdown. :-) >> >>Now here's what I'm currently doing: >> >>I do usually suspend instead of shutdown. The suspend partition is the >>only unencrypted swap partition and it is disabled during regular >>operation so it is not used for regular swapping. Except for a small >>boot partition without any valuable data all other partitions are encrypted. >> >>The key for dm-crypt setup is stored on an ide flash disk which isn't >>inserted during travelling and which is transported separately. >> >>Now let's imagine the laptop gets stolen by an average thief which is >>the most common case.Thief needs to know if the laptop is working >>because thief wants to sell it so thief powers on the laptop. >> >>swsusp resumes and with the encryption patch renders the suspend image >>worthless. The suspend/resume script immediately checks for the presence >>of the ide flash disk with the correct key (match is done against the >>in-kernel dm-crypt key). If the ide flash disk is not present or if >>there is a key mismatch the script shuts the system immediately down, so >>the in-kernel key is lost. >> >>The only way for the thief now to access any data on the disk is to come >>back and steal the flash disk, too. > > > Yes. And if you accidentally lose the flash disk, you are locked out of your > own data. ;-) The same happens if the data on the flash disk is lost (which > occurs, from time to time). You should be _really_ careful doing such things > and IMO it's not to be tried by Joe User. Right. But thats what this backup flash disk in some safe place is for. No risk, no fun :-) -- Andreas Steinmetz SPAMmers use [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: [PATCH encrypted swsusp 1/3] core functionality
Rafael J. Wysocki wrote: > Hi, > > On Monday, 11 of April 2005 23:08, Pavel Machek wrote: > >>Hi! >> > > ]--snip--[ > >>>>@@ -130,6 +150,52 @@ >>>> static unsigned short swapfile_used[MAX_SWAPFILES]; >>>> static unsigned short root_swap; >>>> >>>>+#ifdef CONFIG_SWSUSP_ENCRYPT >>>>+static struct crypto_tfm *crypto_init(int mode) >>> >>>I think it's better if this function returns an int error code and the >>>messages are printed where it's called from. This way, the essential >>>part of the code would be easier to grasp (Pavel?). >> >>Agreed. Actually I do not care where messages are printed, but >>returning different code for different errors seems right. > > > Hm. You probably don't want suspend-related messages to be printed during > resume (this function is called in two different places)? :-) > > Rafael > > Will be changed. -- Andreas Steinmetz SPAMmers use [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: [PATCH] zero disk pages used by swsusp on resume
Rafael J. Wysocki wrote: > Hi, > > On Monday, 11 of April 2005 12:37, Oliver Neukum wrote: > >>Am Sonntag, 10. April 2005 22:14 schrieb Pavel Machek: >> >>>Hi! >>> >>> >>>>>Oliver Neukum wrote: >>>>> >>>>>>What is the point in doing so after they've rested on the disk for ages? >>>>> >>>>>The point is not physical access to the disk but data gathering after >>>>>resume or reboot. >>>> >>>>After resume or reboot normal access control mechanisms will work >>>>again. Those who can read a swap partition under normal circumstances >>>>can also read /dev/kmem. It seems to me like you are putting an extra >>>>lock on a window on the third floor while leaving the front door open. >>> >>>Andreas is right, his patches are needed. >>> >>>Currently, if your laptop is stolen after resume, they can still data >>>in swsusp image. >>> >>>Zeroing the swsusp pages helps a lot here, because at least they are >>>not getting swsusp image data without heavy tools. [Or think root >>>compromise month after you used swsusp.] >>> >>>Encrypting swsusp image is of course even better, because you don't >>>have to write large ammounts of zeros to your disks during resume ;-). >> >>Not only is it better, it completely supercedes wiping the image. >>Your laptop being stolen after resume is very much a corner case. >>You suspend your laptop while you are not around, don't you? > > > Not necessarily. Some people use suspend instead of shutdown. :-) Now here's what I'm currently doing: I do usually suspend instead of shutdown. The suspend partition is the only unencrypted swap partition and it is disabled during regular operation so it is not used for regular swapping. Except for a small boot partition without any valuable data all other partitions are encrypted. The key for dm-crypt setup is stored on an ide flash disk which isn't inserted during travelling and which is transported separately. Now let's imagine the laptop gets stolen by an average thief which is the most common case.Thief needs to know if the laptop is working because thief wants to sell it so thief powers on the laptop. swsusp resumes and with the encryption patch renders the suspend image worthless. The suspend/resume script immediately checks for the presence of the ide flash disk with the correct key (match is done against the in-kernel dm-crypt key). If the ide flash disk is not present or if there is a key mismatch the script shuts the system immediately down, so the in-kernel key is lost. The only way for the thief now to access any data on the disk is to come back and steal the flash disk, too. When the initrd feature pavel just notified me about comes from mm to mainline one can additionally protect the swap partition used for suspend with dm-crypt and collect the key at resume time via initrd. In this case the disk is then not only protected against the average thief but also against the professinal one as long as the flash disk is secure. And if the laptop is not stolen the encrypted suspend image prevents against nasty surprises of sensitive data turning up on disk that should never have been put there in the first place (oh well, but one needs to suspend from time to time). -- Andreas Steinmetz SPAMmers use [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: [PATCH encrypted swsusp 1/3] core functionality
Pavel Machek wrote: > I'd like to retain ability to read suspend image in any order (so that > code can be reused for swap encryption, etc). > Pavel This is not possible with cipher block chaining as used right now. One would have to use a non-random iv set needs to set for every page. And this leads to exactly the same problem why dm-crypt now offers the 'essiv' mode. I don't know if a random access feature is worth this effort as sequential disk access (sequential write, sequential read) is usally the fastest method anyway. For regular swap encryption I do hope that the initrd feature of swsup2 will eventually find its way into the mainline kernel. This way you can have an external key for dm-crypt to access the encrypted swap partition. dm-crypt thus would guard the system during suspend/poweroff while the encrypted suspend image guards against data gathering after resume/reboot (the latter when mkswap is used). -- Andreas Steinmetz SPAMmers use [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: [PATCH encrypted swsusp 1/3] core functionality
Pavel Machek wrote:
> Was it really neccessary to include "union u"? I don't like its name,
Here comes the patch with this reverted. I'm now using casts when
'abusing' the space for encryption. Furthermore the iv set up in the tfm
is used instead of the local copy.
--
Andreas Steinmetz SPAMmers use [EMAIL PROTECTED]
--- linux-2.6.11.2/kernel/power/swsusp.c.ast2005-04-10 14:08:55.0
+0200
+++ linux-2.6.11.2/kernel/power/swsusp.c2005-04-11 18:05:58.0
+0200
@@ -31,6 +31,9 @@
* Alex Badea <[EMAIL PROTECTED]>:
* Fixed runaway init
*
+ * Andreas Steinmetz <[EMAIL PROTECTED]>:
+ * Added encrypted suspend option
+ *
* More state savers are welcome. Especially for the scsi layer...
*
* For TODOs,FIXMEs also look in Documentation/power/swsusp.txt
@@ -72,6 +75,16 @@
#include "power.h"
+#ifdef CONFIG_SWSUSP_ENCRYPT
+#include
+#include
+#include
+#endif
+
+#define CIPHER "aes"
+#define MAXKEY 32
+#define MAXIV 32
+
/* References to section boundaries */
extern const void __nosave_begin, __nosave_end;
@@ -104,7 +117,9 @@
#define SWSUSP_SIG "S1SUSPEND"
static struct swsusp_header {
- char reserved[PAGE_SIZE - 20 - sizeof(swp_entry_t)];
+ char reserved[PAGE_SIZE - 20 - MAXKEY - MAXIV - sizeof(swp_entry_t)];
+ u8 key[MAXKEY];
+ u8 iv[MAXIV];
swp_entry_t swsusp_info;
charorig_sig[10];
charsig[10];
@@ -112,6 +127,11 @@
static struct swsusp_info swsusp_info;
+#ifdef CONFIG_SWSUSP_ENCRYPT
+static u8 key[MAXKEY];
+static u8 iv[MAXIV];
+#endif
+
/*
* XXX: We try to keep some more pages free so that I/O operations succeed
* without paging. Might this be more?
@@ -130,6 +150,52 @@
static unsigned short swapfile_used[MAX_SWAPFILES];
static unsigned short root_swap;
+#ifdef CONFIG_SWSUSP_ENCRYPT
+static struct crypto_tfm *crypto_init(int mode)
+{
+ struct crypto_tfm *tfm;
+ int len;
+
+ tfm = crypto_alloc_tfm(CIPHER, CRYPTO_TFM_MODE_CBC);
+ if(!tfm) {
+ printk(KERN_ERR "swsusp: no tfm, suspend not possible\n");
+ return NULL;
+ }
+
+ if(sizeof(key) < crypto_tfm_alg_min_keysize(tfm)) {
+ printk("swsusp: key buffer too small, suspend not possible\n");
+ crypto_free_tfm(tfm);
+ return NULL;
+ }
+
+ if (sizeof(iv) < crypto_tfm_alg_ivsize(tfm)) {
+ printk("swsusp: iv buffer too small, suspend not possible\n");
+ crypto_free_tfm(tfm);
+ return NULL;
+ }
+
+ if (mode) {
+ get_random_bytes(key, MAXKEY);
+ get_random_bytes(iv, MAXIV);
+ }
+
+ len = crypto_tfm_alg_max_keysize(tfm);
+ if (len > sizeof(key))
+ len = sizeof(key);
+
+ if (crypto_cipher_setkey(tfm, key, len)) {
+ printk(KERN_ERR "swsusp: key setup failure, suspend not
possible\n");
+ crypto_free_tfm(tfm);
+ return NULL;
+ }
+
+ len = crypto_tfm_alg_blocksize(tfm);
+ crypto_cipher_set_iv(tfm, iv, len);
+
+ return tfm;
+}
+#endif
+
static int mark_swapfiles(swp_entry_t prev)
{
int error;
@@ -141,6 +207,10 @@
!memcmp("SWAPSPACE2",swsusp_header.sig, 10)) {
memcpy(swsusp_header.orig_sig,swsusp_header.sig, 10);
memcpy(swsusp_header.sig,SWSUSP_SIG, 10);
+#ifdef CONFIG_SWSUSP_ENCRYPT
+ memcpy(swsusp_header.key, key, MAXKEY);
+ memcpy(swsusp_header.iv, iv, MAXIV);
+#endif
swsusp_header.swsusp_info = prev;
error = rw_swap_page_sync(WRITE,
swp_entry(root_swap, 0),
@@ -294,6 +364,19 @@
int error = 0;
int i;
unsigned int mod = nr_copy_pages / 100;
+#ifdef CONFIG_SWSUSP_ENCRYPT
+ struct crypto_tfm *tfm;
+ struct scatterlist src, dst;
+
+ if (!(tfm = crypto_init(1)))
+ return -EINVAL;
+
+ src.offset = 0;
+ src.length = PAGE_SIZE;
+ dst.page = virt_to_page((void *)&swsusp_header);
+ dst.offset = 0;
+ dst.length = PAGE_SIZE;
+#endif
if (!mod)
mod = 1;
@@ -302,10 +385,21 @@
for (i = 0; i < nr_copy_pages && !error; i++) {
if (!(i%mod))
printk( "\b\b\b\b%3d%%", i / mod );
+#ifdef CONFIG_SWSUSP_ENCRYPT
+ src.page = virt_to_page((pagedir_nosave+i)->address);
+ error = crypto_cipher_encrypt(tfm, &dst, &src, PAGE_SIZE);
+ if (!error)
+ error = write_page((unsigned long)&swsusp_header,
+ &((pagedir_nosave+i)->swap_address));
+#else
error
Re: Oops in swsusp
Rafael J. Wysocki wrote:
> Hi,
>
> On Monday, 11 of April 2005 01:17, Andreas Steinmetz wrote:
>
>>Pavel,
>>during testing of the encrypted swsusp_image on x86_64 I did get an Oops
>>from time to time at memcpy+11 called from swsusp_save+1090 which turns
>>out to be the memcpy in copy_data_pages() of swsusp.c.
>>The Oops is caused by a NULL pointer (I don't remember if it was source
>>or destination).
>
>
> It's quite important, however. If it's the destination, it's probably a bug
> in
> swsusp. Otherwise, the problem is more serious. Could you, please,
> add BUG_ON(!pbe->address) right before the memcpy() and retest?
Here's the result:
BUG_ON(!pbe->address) hits, so is seems to be a swsusp problem.
So I added a BUG_ON(!to_copy) as shown below (mangled for mailing):
if (saveable(zone, &zone_pfn)) {
struct page * page;
BUG_ON(!to_copy);
page = pfn_to_page(zone_pfn + zone->zone_start_pfn);
pbe->orig_address = (long) page_address(page);
/* copy_page is not usable for copying task structs. */
BUG_ON(!pbe->address);
memcpy((void *)pbe->address, (void *)pbe->orig_address,
PAGE_SIZE);
pbe++;
to_copy--;
}
The BUG_ON(!to_copy) hits, too.
So it seems that the result sum of saveable() increases between
count_data_pages() and copy_data_pages(). The problem seems to be
easiest hit when starting a larger GUI application and suspending during
application startup. It does ususally take a few suspend/resume
iterations to hit the bug.
Pavel,
the crypto stuff in swsusp.c starts in data_write() which is called
after copy_data_pages() if I'm right. In this case the crypto stuff
can't be the culprit.
--
Andreas Steinmetz SPAMmers use [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: [PATCH encrypted swsusp 3/3] documentation
Bodo Eggert wrote: > Andreas Steinmetz <[EMAIL PROTECTED]> wrote: > > >>+If you want to store your suspend image encrypted with a temporary >>+key to prevent data gathering after resume you must compile >>+crypto and the aes algorithm into the kernel - modules won't work >>+as they cannot be loaded at resume time. > > > Can't that be ensured by selecting these options? Yes, it is ensured. The text is there to give some hint how to to make this option selectable. -- Andreas Steinmetz SPAMmers use [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: [PATCH encrypted swsusp 1/3] core functionality
Pavel Machek wrote:
> Hi!
>
>
>>The following patch adds the core functionality for the encrypted
>>suspend image.
>
>
> +#ifdef CONFIG_SWSUSP_ENCRYPT
> +static struct crypto_tfm *crypto_init(int mode)
> +{
> + struct crypto_tfm *tfm;
> + int len;
> +
> + tfm = crypto_alloc_tfm(CIPHER, CRYPTO_TFM_MODE_CBC);
> + if(!tfm) {
> ~ please put space between if and (
>
> + printk(KERN_ERR "swsusp: no tfm, suspend not
> possible\n");
> + return NULL;
> + }
> +
> + if(sizeof(key) < crypto_tfm_alg_min_keysize(tfm)) {
>
> same here.
>
> Was it really neccessary to include "union u"? I don't like its name,
> and perhaps few casts are better than this. If not, it probably should
> go in separate patch, and ASAP.
I'll revert this and use few casts.
--
Andreas Steinmetz SPAMmers use [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: Oops in swsusp
Rafael J. Wysocki wrote: > Hi, > > On Monday, 11 of April 2005 01:17, Andreas Steinmetz wrote: > >>Pavel, >>during testing of the encrypted swsusp_image on x86_64 I did get an Oops >>from time to time at memcpy+11 called from swsusp_save+1090 which turns >>out to be the memcpy in copy_data_pages() of swsusp.c. >>The Oops is caused by a NULL pointer (I don't remember if it was source >>or destination). > > > It's quite important, however. If it's the destination, it's probably a bug > in > swsusp. Otherwise, the problem is more serious. Could you, please, > add BUG_ON(!pbe->address) right before the memcpy() and retest? I'll try. -- Andreas Steinmetz SPAMmers use [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: [PATCH encrypted swsusp 1/3] core functionality
[EMAIL PROTECTED] wrote: >>>The following patch adds the core functionality for the encrypted >>>suspend image. >> >>[Please inline patches, it makes it easier to comment on them.] Aiyeeh - good ole Mozilla tends to reformat things when inlining... >>You seem to reuse same key/iv for all the blocks. I'm no crypto >>expert, but I think that is seriously wrong... You probably should use >>block number as a IV or something like that. > > > Or use a feedback loop: xor your data with the outcome of the previous > round. And for the initial block use 0x00...00 for 'previous block'- > value. I'm already using cipher block chaining, look for CRYPTO_TFM_MODE_CBC in swsusp.c. You may want to have a look at cbc_process in crypto/cipher.c. Thus using the same key is ok. The only known drawback is a watermarking "attack" but this can only used to look for the existence of specially crafted files which are not stored on disk during software suspend. I should, however, use crypto_cipher_en/decrypt instead of crypto_cipher_en/decrypt_iv as I actually wanted to use the iv in the tfm I did set up with crypto_cipher_set_iv instead of the local copy. Going to fix that. -- Andreas Steinmetz SPAMmers use [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/
[PATCH encrypted swsusp 1/3] core functionality
The following patch adds the core functionality for the encrypted
suspend image.
--
Andreas Steinmetz SPAMmers use [EMAIL PROTECTED]
--- linux-2.6.11.2/kernel/power/swsusp.c.ast2005-04-10 14:08:55.0
+0200
+++ linux-2.6.11.2/kernel/power/swsusp.c2005-04-11 00:50:45.0
+0200
@@ -31,6 +31,9 @@
* Alex Badea <[EMAIL PROTECTED]>:
* Fixed runaway init
*
+ * Andreas Steinmetz <[EMAIL PROTECTED]>:
+ * Added encrypted suspend option
+ *
* More state savers are welcome. Especially for the scsi layer...
*
* For TODOs,FIXMEs also look in Documentation/power/swsusp.txt
@@ -72,6 +75,16 @@
#include "power.h"
+#ifdef CONFIG_SWSUSP_ENCRYPT
+#include
+#include
+#include
+#endif
+
+#define CIPHER "aes"
+#define MAXKEY 32
+#define MAXIV 32
+
/* References to section boundaries */
extern const void __nosave_begin, __nosave_end;
@@ -103,15 +116,27 @@
#define SWSUSP_SIG "S1SUSPEND"
-static struct swsusp_header {
- char reserved[PAGE_SIZE - 20 - sizeof(swp_entry_t)];
+struct swsusp_header {
+ char reserved[PAGE_SIZE - 20 - MAXKEY - MAXIV - sizeof(swp_entry_t)];
+ u8 key[MAXKEY];
+ u8 iv[MAXIV];
swp_entry_t swsusp_info;
charorig_sig[10];
charsig[10];
-} __attribute__((packed, aligned(PAGE_SIZE))) swsusp_header;
+} __attribute__((packed, aligned(PAGE_SIZE)));
+
+static union {
+ struct swsusp_header __attribute__((packed, aligned(PAGE_SIZE)))
swsusp_header;
+ u8 buffer[PAGE_SIZE] __attribute__((aligned(PAGE_SIZE)));
+} __attribute__((packed, aligned(PAGE_SIZE))) u;
static struct swsusp_info swsusp_info;
+#ifdef CONFIG_SWSUSP_ENCRYPT
+static u8 key[MAXKEY];
+static u8 iv[MAXIV];
+#endif
+
/*
* XXX: We try to keep some more pages free so that I/O operations succeed
* without paging. Might this be more?
@@ -130,22 +155,72 @@
static unsigned short swapfile_used[MAX_SWAPFILES];
static unsigned short root_swap;
+#ifdef CONFIG_SWSUSP_ENCRYPT
+static struct crypto_tfm *crypto_init(int mode)
+{
+ struct crypto_tfm *tfm;
+ int len;
+
+ tfm = crypto_alloc_tfm(CIPHER, CRYPTO_TFM_MODE_CBC);
+ if(!tfm) {
+ printk(KERN_ERR "swsusp: no tfm, suspend not possible\n");
+ return NULL;
+ }
+
+ if(sizeof(key) < crypto_tfm_alg_min_keysize(tfm)) {
+ printk("swsusp: key buffer too small, suspend not possible\n");
+ crypto_free_tfm(tfm);
+ return NULL;
+ }
+
+ if (sizeof(iv) < crypto_tfm_alg_ivsize(tfm)) {
+ printk("swsusp: iv buffer too small, suspend not possible\n");
+ crypto_free_tfm(tfm);
+ return NULL;
+ }
+
+ if (mode) {
+ get_random_bytes(key, MAXKEY);
+ get_random_bytes(iv, MAXIV);
+ }
+
+ len = crypto_tfm_alg_max_keysize(tfm);
+ if (len > sizeof(key))
+ len = sizeof(key);
+
+ if (crypto_cipher_setkey(tfm, key, len)) {
+ printk(KERN_ERR "swsusp: key setup failure, suspend not
possible\n");
+ crypto_free_tfm(tfm);
+ return NULL;
+ }
+
+ len = crypto_tfm_alg_blocksize(tfm);
+ crypto_cipher_set_iv(tfm, iv, len);
+
+ return tfm;
+}
+#endif
+
static int mark_swapfiles(swp_entry_t prev)
{
int error;
rw_swap_page_sync(READ,
swp_entry(root_swap, 0),
- virt_to_page((unsigned long)&swsusp_header));
- if (!memcmp("SWAP-SPACE",swsusp_header.sig, 10) ||
- !memcmp("SWAPSPACE2",swsusp_header.sig, 10)) {
- memcpy(swsusp_header.orig_sig,swsusp_header.sig, 10);
- memcpy(swsusp_header.sig,SWSUSP_SIG, 10);
- swsusp_header.swsusp_info = prev;
+ virt_to_page((unsigned long)&u.swsusp_header));
+ if (!memcmp("SWAP-SPACE",u.swsusp_header.sig, 10) ||
+ !memcmp("SWAPSPACE2",u.swsusp_header.sig, 10)) {
+ memcpy(u.swsusp_header.orig_sig,u.swsusp_header.sig, 10);
+ memcpy(u.swsusp_header.sig,SWSUSP_SIG, 10);
+#ifdef CONFIG_SWSUSP_ENCRYPT
+ memcpy(u.swsusp_header.key, key, MAXKEY);
+ memcpy(u.swsusp_header.iv, iv, MAXIV);
+#endif
+ u.swsusp_header.swsusp_info = prev;
error = rw_swap_page_sync(WRITE,
swp_entry(root_swap, 0),
virt_to_page((unsigned long)
- &swsusp_header));
+ &u.swsusp_header));
} else {
pr_debug("swsusp: Partition is not swap space.\n");
error = -ENODEV;
@@ -294,6
[PATCH encrypted swsusp 3/3] documentation
The following patch adds some information for encrypted suspend to the swsusp documentation. -- Andreas Steinmetz SPAMmers use [EMAIL PROTECTED] --- linux-2.6.11.2/Documentation/power/swsusp.txt.ast 2005-04-10 21:07:01.0 +0200 +++ linux-2.6.11.2/Documentation/power/swsusp.txt 2005-04-10 21:10:56.0 +0200 @@ -30,6 +30,13 @@ echo platform > /sys/power/disk; echo disk > /sys/power/state +Encrypted suspend image: + +If you want to store your suspend image encrypted with a temporary +key to prevent data gathering after resume you must compile +crypto and the aes algorithm into the kernel - modules won't work +as they cannot be loaded at resume time. + Article about goals and implementation of Software Suspend for Linux
[PATCH encrypted swsusp 2/3] configuration
The following patch includes the necessary kernel configuration option. -- Andreas Steinmetz SPAMmers use [EMAIL PROTECTED] --- linux-2.6.11.2/kernel/power/Kconfig.ast 2005-04-10 20:44:48.0 +0200 +++ linux-2.6.11.2/kernel/power/Kconfig 2005-04-10 21:01:36.0 +0200 @@ -72,3 +72,14 @@ suspended image to. It will simply pick the first available swap device. +config SWSUSP_ENCRYPT + bool "Encrypt suspend image" + depends on SOFTWARE_SUSPEND && CRYPTO=y && (CRYPTO_AES=y || CRYPTO_AES_586=y) + default "" + ---help--- + To prevent data gathering from swap after resume you can encrypt + the suspend image with a temporary key that is deleted on + resume. + + Note that the temporary key is stored unencrypted on disk while the + system is suspended.
Oops in swsusp
Pavel, during testing of the encrypted swsusp_image on x86_64 I did get an Oops from time to time at memcpy+11 called from swsusp_save+1090 which turns out to be the memcpy in copy_data_pages() of swsusp.c. The Oops is caused by a NULL pointer (I don't remember if it was source or destination). This Oops seems to be unrelated to the encrypted image addition as I didn't touch any code in that area. -- Andreas Steinmetz SPAMmers use [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/
[PATCH encrypted swsusp 0/3] encrypted swsusp image
The following patches allow for encryption of the on-disk swsusp image to prevent data gathering of e.g. in-kernel keys or mlocked data after resume. For this purpose the aes cipher must be compiled into the kernel as module load is not possible at resume time. A random key is generated at suspend time, stored in the suspend header on disk and deleted from the header at resume time. If you don't resume a mkswap on the suspend partition will also delete the temporary key. Only the data pages are encrypted as only these may contain sensitive data. This works on my x86_64 laptop (64bit mode) and probably needs testing on other platforms. -- Andreas Steinmetz SPAMmers use [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: [PATCH] zero disk pages used by swsusp on resume
Pavel Machek wrote: > Hi! > > >>>Hi! What about doing it right? Encrypt it with symmetric cypher >>>and store key in suspend header. That way key is removed automagically >>>while fixing signatures. No need to clear anythink. >> >>Good idea. I'll have a look though it will take a while (busy with my job). >> >> >>>OTOH we may want to dm-crypt whole swap partition. >> >>This would leave the problem that the in-kernel data would be accessible >>on the swap device after resume. > > > I meant "when dm-crypt is used, encrypting swsusp data with second key > is no longer _that_ nice"... Hmm, thinking of a future swsusp2 with initrd capabilites encrption of the suspend image itself is still useful to prevent data gathering after resume. Using dm-crypt for encryption of the swap partition in this case is useful during resume so this fits nicely together. BTW: I spent my day on implementing the encryption of the suspend image and will send patches after a few more tests. -- Andreas Steinmetz SPAMmers use [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: [PATCH] zero disk pages used by swsusp on resume
Oliver Neukum wrote: > What is the point in doing so after they've rested on the disk for ages? The point is not physical access to the disk but data gathering after resume or reboot. -- Andreas Steinmetz SPAMmers use [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: [PATCH] zero disk pages used by swsusp on resume
[reformatted] Pavel Machek wrote: > Hi! What about doing it right? Encrypt it with symmetric cypher > and store key in suspend header. That way key is removed automagically > while fixing signatures. No need to clear anythink. Good idea. I'll have a look though it will take a while (busy with my job). > OTOH we may want to dm-crypt whole swap partition. This would leave the problem that the in-kernel data would be accessible on the swap device after resume. > You could still store key in header... --p Which is the good idea from step one above. > > -- pavel. Sent from mobile phone. Sorry for poor formatting. The only remark I do have here is that swsusp would then depend on crypto so the swsusp encryption should be a config option. -- Andreas Steinmetz SPAMmers use [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/
[PATCH] zero disk pages used by swsusp on resume
It may not be desireable to leave swsusp saved pages on disk after
resume as they may contain sensitive data that was never intended to be
stored on disk in an way (e.g. in-kernel dm-crypt keys, mlocked pages).
The attached simple patch against 2.6.11.2 should fix this by zeroing
the swap pages after reading them.
The patch is by no means perfect. Especially it isn't invoked on error
conditions. However it seems to work during regular operation.
Note that it is not possible to do this from userspace in a performant
way, one has to zero the whole swap partition used for swsusp to achive
a similar effect which quite often means clearing 2GB instead of about a
few 100MB. The difference in speed and power consumption is important
especially for laptops when resuming on battery. The userspace method
also allows for a window in which at least some of the data may still be
read.
--
Andreas Steinmetz SPAMmers use [EMAIL PROTECTED]
--- linux-2.6.11.2/kernel/power/swsusp.c.ast2005-04-10 14:08:55.0
+0200
+++ linux-2.6.11.2/kernel/power/swsusp.c2005-04-10 14:24:10.0
+0200
@@ -112,6 +112,10 @@
static struct swsusp_info swsusp_info;
+static struct swsusp_clear {
+ char zero[PAGE_SIZE];
+} __attribute__((packed, aligned(PAGE_SIZE))) swsusp_clear __initdata;
+
/*
* XXX: We try to keep some more pages free so that I/O operations succeed
* without paging. Might this be more?
@@ -1169,6 +1173,29 @@
}
+static int __init data_clear(void)
+{
+ struct pbe * p;
+ int error = 0;
+ int i;
+ int mod = nr_copy_pages / 100;
+
+ if (!mod)
+ mod = 1;
+
+ memset(&swsusp_clear, 0, sizeof(swsusp_clear));
+
+ printk( "Clearing disk data (%d pages): ", nr_copy_pages );
+ for(i = 0, p = pagedir_nosave; i < nr_copy_pages && !error; i++, p++) {
+ if (!(i%mod))
+ printk( "\b\b\b\b%3d%%", i / mod );
+ error = bio_write_page(swp_offset(p->swap_address),
+ (void *)&swsusp_clear);
+ }
+ printk(" %d done.\n",i);
+ return error;
+}
+
extern dev_t __init name_to_dev_t(const char *line);
static int __init read_pagedir(void)
@@ -1208,6 +1235,8 @@
return error;
if ((error = data_read()))
free_pages((unsigned long)pagedir_nosave, pagedir_order);
+ else
+ data_clear();
return error;
}
2.6.11 acpi battery state readout as source of keyboard/touchpad troubles
In traceing the source of my sporadic synaptics touchpad troubles psmouse.c: TouchPad at isa0060/serio4/input0 lost sync at byte 1 psmouse.c: TouchPad at isa0060/serio4/input0 lost sync at byte 1 psmouse.c: TouchPad at isa0060/serio4/input0 lost sync at byte 1 psmouse.c: TouchPad at isa0060/serio4/input0 lost sync at byte 1 psmouse.c: TouchPad at isa0060/serio4/input0 lost sync at byte 1 psmouse.c: TouchPad at isa0060/serio4/input0 - driver resynched. and keyboard troubles (sporadically lost key up/down events) on an Acer Aspire 1520 (x86_64, latest bios v1.09) I did enable the report_lost_ticks option which did spit out stuff like the following at regular intervals: time.c: Lost 17 timer tick(s)! rip handle_IRQ_event+0x20/0x60) time.c: Lost 8 timer tick(s)! rip handle_IRQ_event+0x20/0x60) time.c: Lost 19 timer tick(s)! rip handle_IRQ_event+0x20/0x60) time.c: Lost 8 timer tick(s)! rip handle_IRQ_event+0x20/0x60) time.c: Lost 18 timer tick(s)! rip handle_IRQ_event+0x20/0x60) time.c: Lost 8 timer tick(s)! rip handle_IRQ_event+0x20/0x60) This looked suspiciously like it happended when the the kde laptop applet polled the battery status. So I did terminate the applet. The result was no more lost ticks, no lost keyboard events and no more lost touchpad sync. To verify ACPI battery data as the source of trouble i did a simple cat /proc/acpi/battery/BAT0/state which instantly resulted in: time.c: Lost 19 timer tick(s)! rip handle_IRQ_event+0x20/0x60) So it seems ACPI battery readout does cause some long running interrupt disable and that it causes nasty side effects for the 8042 input. Note that doing cat /proc/acpi/battery/BAT0/info doesn't cause any trouble (battery alarm is unsupported). I can ignore the lost ticks but the keyboard/touchpad problems caused by the state readout are definitely nasty. Any ideas? -- Andreas Steinmetz SPAMmers use [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: Problems with SCSI tape rewind / verify on 2.4.29
Andrew Morton wrote: (what's a BSF?) Backward space count files (man mt). -- Andreas Steinmetz SPAMmers use [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: Odd data corruption problem with LVM/ReiserFS
pcg( Marc)@goof(A.).(Lehmann )com wrote: I use both reiserfs and ext3 on lvm/dm on raid. Both filesystems have issues when restoring from backup (i.e. very heavy write activity). I did report this to the linux kernel, and got as reply that there are indeed races *somewhere*, but as of yet there is no fix. The symptoms are _not_ I/O errors (but until I see logs I wouldn't believe you that there are real I/O errors), but usually too-high block numbers. To clarify: there were no disk I/O errors, only I/O errors were reported by find during operation so it is definitely filesystem corruption that is going on here. Though find performs heavy read activity there could well be heavy write activity be involved due to atime updates so this fits your description. A reboot fixes this for both ext3 and reiserfs (i.e. the error is gone). Well, it didn't fix it for me. The fs was trashed for good. The major question for me is now usability of md/dm for any purpose with 2.6.x. For me this is a showstopper for any kind of 2.6 production use. -- Andreas Steinmetz SPAMmers use [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: Odd data corruption problem with LVM/ReiserFS
Alex Adriaanse wrote: The weird thing is I did not see any I/O errors in my logs, and running find on /var worked without a problem. By the way, did you take any DM snapshots when you experienced that corruption? No, no snapshots. Just working find on a large dataset (source tree, about 16GB). The fun part is that I got the I/O errors for varying diretories and 'ls'-sing thes directories after find failed, too. However a follow-up tar to the ieee1394 disk to salvage the data actually could access all data correctly. One day before I did experience the same symptom but did reboot. This caused actual damage all over the place and I had to restore from the last checkpoint I made. -- Andreas Steinmetz SPAMmers use [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: Odd data corruption problem with LVM/ReiserFS
Alex Adriaanse wrote: As far as I can tell all the directories are still intact, but there was a good number of files that had been corrupted. Those files looked like they had some chunks removed, and some had a bunch of NUL characters (in blocks of 4096 characters). Some files even had chunks of other files inside of them! I can second that. I had the same experience this weekend on a md/dm/reiserfs setup. The funny thing is that e.g. find reports I/O errors but if you then run tar on the tree you eventually get the correct data from tar. Then run find again and you'll again get I/O errors. I did a reiserfsck (3.6.19) on /var, which did not report any problems. You need to run 'reiserfsck --rebuild-tree' and see what happens :-( Anyway, what do you guys think could be the problem? Could it be that the LVM / Device Mapper snapshot feature is solely responsible for this corruption? (I'm sure there's a reason it's marked Experimental). I don't think so - I changed from reiserfs to ext3 without changing the underlying dm/raid5 and this seems to work properly. I can furthermore state that reiserfs without dm/md does work correctly as I use reiserfs on a ieee1394 backup disk (that saved me from terrible trouble). Currently I can only warn to not use reiserfs with dm/md on 2.6. -- Andreas Steinmetz SPAMmers use [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/
