Skip to contentSkip to conversation

block: Restore tape support

PATCH In review Bart Van Assche 6 participants 9 messages Dec 10, 2018

Subsystems (2)
Stable branch Block layer
lore
Share & tools
lore

Bart Van Assche

author
#0 lore raw

PATCH 1/1 block: Restore tape support

According to what I found in
https://bugzilla.kernel.org/show_bug.cgi?id=201935 patch "block: Clear kernel memory before copying to user" broke tape access. Hence revert that patch.

Reported-by Todd Aiken <[email protected]>
Fixes f3587d76da05 ("block: Clear kernel memory before copying to user") # v4.20-rc2
Cc Todd Aiken <[email protected]>
Cc Keith Busch <[email protected]>
Cc Laurence Oberman <[email protected]>
Cc [email protected]
Signed-off-by Bart Van Assche <[email protected]>
---
 block/bio.c | 1 -
 1 file changed, 1 deletion(-)
block/bio.c +0 -1
index 06760543ec81..90c32cd3e0c7 100644
@@ -1262,7 +1262,6 @@ struct bio *bio_copy_user_iov(struct request_queue *q,
 		if (ret)
 			goto cleanup;
 	} else {
-		zero_fill_bio(bio);
 		iov_iter_advance(iter, bio->bi_iter.bi_size);
 	}
Signature · 1 line
2.19.2
#1 lore raw
Quoted 4 lines · Bart Van Assche

According to what I found in
https://bugzilla.kernel.org/show_bug.cgi?id=201935 patch "block: Clear kernel memory before copying to user" broke tape access. Hence revert that patch.

This looks wrong. The patch from Keith is obviously correct for normal usage of bio_copy_user_iov. The SCSI tape drivers use the somewhat odd null_mapped case, so we probably need to refine the checks for that a bit.

#2 lore raw
Quoted 8 lines · Christoph Hellwig
Quoted 6 lines · Bart Van Assche

According to what I found in
https://bugzilla.kernel.org/show_bug.cgi?id=201935 patch "block:
Clear
kernel memory before copying to user" broke tape access. Hence revert
that patch.

Quoted 5 lines

This looks wrong.  The patch from Keith is obviously correct for normal usage of bio_copy_user_iov.  The SCSI tape drivers use the somewhat odd null_mapped case, so we probably need to refine the checks
for that a bit.

I am going to look into that, just connected a tape device so I can reproduce and then see what we need to make it more specific in the st driver.
I may need help from folks who understand the bio stuff better than I do.

Back when I have more.

Regards
Laurence

#3 lore raw
In reply to Bart Van Assche
Quoted 4 lines · Bart Van Assche

According to what I found in
https://bugzilla.kernel.org/show_bug.cgi?id=201935 patch "block: Clear kernel memory before copying to user" broke tape access. Hence revert that patch.

Instead of reverting back to the leaking arbitrary kernel memory, why not just make a fix on top of it? This should do it:

---

block/bio.c +2 -1
index c4ef8aa46452..55a5386fd431 100644
@@ -1262,7 +1262,8 @@ struct bio *bio_copy_user_iov(struct request_queue *q,
 		if (ret)
 			goto cleanup;
 	} else {
-		zero_fill_bio(bio);
+		if (bmd->is_our_pages)
+			zero_fill_bio(bio);
 		iov_iter_advance(iter, bio->bi_iter.bi_size);
 	}

--

maintainer
#4 lore raw
Quoted 15 lines · Keith Busch
Quoted 4 lines · Bart Van Assche

According to what I found in
https://bugzilla.kernel.org/show_bug.cgi?id=201935 patch "block: Clear kernel memory before copying to user" broke tape access. Hence revert that patch.

Instead of reverting back to the leaking arbitrary kernel memory, why not just make a fix on top of it? This should do it:

---

block/bio.c +0 -0
index c4ef8aa46452..55a5386fd431 100644

block/bio.c struct bio *bio_copy_user_iov(struct request_queue *q, · line 1269

Quoted 9 lines
block/bio.c +2 -1
@@ -1262,7 +1262,8 @@ struct bio *bio_copy_user_iov(struct request_queue *q,
 		if (ret)
 			goto cleanup;
 	} else {
-		zero_fill_bio(bio);
+		if (bmd->is_our_pages)
+			zero_fill_bio(bio);
 		iov_iter_advance(iter, bio->bi_iter.bi_size);
 	}

That should be fine, the other case is user mapped memory anyway.

Signature · 1 line
Jens Axboe
#5 lore raw
Quoted 23 lines · Jens Axboe
Quoted 22 lines · Keith Busch
Quoted 6 lines · Bart Van Assche

According to what I found in
https://bugzilla.kernel.org/show_bug.cgi?id=201935 patch "block:
Clear
kernel memory before copying to user" broke tape access. Hence revert
that patch.

Instead of reverting back to the leaking arbitrary kernel memory, why
not just make a fix on top of it? This should do it:

---

block/bio.c +0 -0
index c4ef8aa46452..55a5386fd431 100644
@@ -1262,7 +1262,8 @@ struct bio *bio_copy_user_iov(struct
 request_queue *q,
  		if (ret)
  			goto cleanup;
  	} else {
Quoted 9 lines
Quoted 6 lines
block/bio.c +2 -1
-		zero_fill_bio(bio);
+		if (bmd->is_our_pages)
+			zero_fill_bio(bio);
  		iov_iter_advance(iter, bio->bi_iter.bi_size);
  	}

That should be fine, the other case is user mapped memory anyway.

OK, I will test this today
Thanks folks!!
Laurence

Tested-by
#6 lore raw
In reply to Keith Busch
Quoted 26 lines · Keith Busch
Quoted 6 lines · Bart Van Assche

According to what I found in
https://bugzilla.kernel.org/show_bug.cgi?id=201935 patch "block:
Clear
kernel memory before copying to user" broke tape access. Hence revert
that patch.

Instead of reverting back to the leaking arbitrary kernel memory, why not just make a fix on top of it? This should do it:

---

block/bio.c +2 -1
index c4ef8aa46452..55a5386fd431 100644
@@ -1262,7 +1262,8 @@ struct bio *bio_copy_user_iov(struct
 request_queue *q,
  		if (ret)
  			goto cleanup;
  	} else {
-		zero_fill_bio(bio);
+		if (bmd->is_our_pages)
+			zero_fill_bio(bio);
  		iov_iter_advance(iter, bio->bi_iter.bi_size);
  	}
Quoted 2 lines


--

Reproduced on 4.20-rc6

# tar cvf /dev/st0 /etc
...
Showed data was written in tar
However listing is empty, data not actually written
# tar tvf /dev/st0 
#

Then:

Applied Keith Patch

# tar cvf /dev/st0 /etc
...
# tar tvf /dev/st0

Data was written and can be read

..drwxr-xr-x root/root         0 2018-10-31 08:41 etc/fwupd/ -rw-r--r-- root/root       292 2018-06-07 08:27 etc/fwupd/daemon.conf drwxr-xr-x root/root         0 2018-10-31 08:41 etc/fwupd/remotes.d/ -rw-r--r-- root/root       181 2018-09-05 06:00 etc/fwupd/remotes.d/fwupd.conf
-rw-r--r-- root/root       327 2018-06-07 08:27 etc/fwupd/remotes.d/lvfs-testing.conf
-rw-r--r-- root/root       283 2018-09-05 06:00 etc/fwupd/remotes.d/lvfs.conf
-rw-r--r-- root/root       283 2018-09-05 06:00 etc/fwupd/remotes.d/vendor.conf
-rw-r--r-- root/root       118 2018-09-05 06:00 etc/fwupd/uefi.conf -r--r----- root/root      4328 2018-09-25 01:57 etc/sudoers.rpmnew -rw-r--r-- root/root      2331 2018-11-02 14:50 etc/hercules.cnf -rw-r--r-- root/root       147 2018-11-06 17:08 etc/minirc.p2000

[   96.272548] st 2:0:0:0: [st0] Block limits 1 - 16777215 bytes. [   96.300782] st 2:0:0:0: [st0] Mode sense. Length 11, medium 0, WBS 10, BLL 8
[   96.334985] st 2:0:0:0: [st0] Density 58, tape length: 0, drv
buffer: 1
[   96.367366] st 2:0:0:0: [st0] Block size: 0, buffer size: 4096 (1 blocks).
[   97.197209] st 2:0:0:0: [st0] Rewinding tape.
[  103.104429] st 2:0:0:0: [st0] Block limits 1 - 16777215 bytes. [  103.133142] st 2:0:0:0: [st0] Mode sense. Length 11, medium 0, WBS 10, BLL 8
[  103.167421] st 2:0:0:0: [st0] Density 58, tape length: 0, drv
buffer: 1
[  103.199711] st 2:0:0:0: [st0] Block size: 0, buffer size: 4096 (1 blocks).
[  104.109081] st 2:0:0:0: [st0] Rewinding tape.

Tested and works fine.
Thanks All

Tested-by Laurence Oberman <[email protected]>
#8 lore raw

----- Message from Keith Busch <[email protected]> ---------
Date: Mon, 10 Dec 2018 13:26:47 -0700
From: Keith Busch <[email protected]>
Subject: Re: [PATCH] block: Restore tape support
To: Laurence Oberman <[email protected]>
Cc: Bart Van Assche <[email protected]>, Jens Axboe
<[email protected]>, [email protected], Christoph Hellwig <[email protected]>, Todd Aiken <[email protected]>, [email protected]

Quoted 7 lines · Laurence Oberman
Quoted 4 lines

Tested and works fine.
Thanks All

Tested-by Laurence Oberman <[email protected]>

Cool, thank you for confirming.

I can also confirm that this fix works fine on my system.

----- End message from Keith Busch <[email protected]> -----