linux-kernel - Re: Linux 6.2-rc1

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <58d3649f-3c8c-8b12-1930-f06f59837ad5@kernel.dk>
Date:   Thu, 5 Jan 2023 10:45:47 -0700
From:   Jens Axboe <axboe@...nel.dk>
To:     Pali Rohár <pali@...nel.org>
Cc:     Linus Torvalds <torvalds@...ux-foundation.org>,
        Christoph Hellwig <hch@...radead.org>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: Linux 6.2-rc1

On 1/5/23 10:42?AM, Pali Roh?r wrote:
> On Wednesday 04 January 2023 14:43:16 Jens Axboe wrote:
>> On 1/4/23 2:32?PM, Linus Torvalds wrote:
>>>> But here it is CD-RW media in read-write mode with kernel udf
>>>> filesystem driver without any userspace involved (after proper
>>>> formatting).
>>>
>>> ... but I'm not sure about direct writeable mount support.
>>>
>>> That may indeed be an area that only pktcdvd ended up doing. I've
>>> never used it myself, even historically.
>>>
>>> Let's bring in more people. Because they may not have thought about
>>> some RW UDF case.
>>
>> We did think about it, since that's the only reason for pktcdvd to
>> exist. Basically what the driver does is ensure that any write is 32K in
>> size, which is the size which can be written to media. It'll gather data
>> as needed to make that happen. Thats it. Outside of that, it's just some
>> setup and closing code.
>>
>> This obviously would be better to handle in userspace, all of it. Back
>> when I wrote this driver, we didn't have a lot of the fancier stuff we
>> have today. It could be done via ublk, for example, or something like
>> that.
>>
>> The surprising bit here is:
>>
>> 1) Someone is still using this driver, and
>> 2) It actually works!
> 
> Yes, there are still users and userspace tools (cdrwtool / pktsetup) are
> still receiving either small patches or issue reports. I think that it
> was two years ago when cdrwtool received big fixups to support
> formatting CD-RW discs on new CD/DVD drives.
> 
>> While I'd love to nudge folks in other directions for this use case, and
>> I strongly think that we should, it also doesn't seem fair to just yank
>> it while folks are using it... But I'd like to VERY strongly encourage
>> folks to come up with a new solution for this use case. It really isn't
>> a solution that belongs in the kernel today.
> 
> Linus in previous email wrote that he did "make SCSI commands generic"
> work in past so direct usage of /dev/cdrom device works for CD-R burning
> and read-only mounting.

Not quite sure what that refers to, as I'm pretty sure I did all of that
work. But maybe Linus can refresh my memory here :-)

> So could not be (for example sr.c) driver extended to directly do
> pktcdvd's work? So when somebody opens /dev/cdrom device in O_RDWR mode
> and CD-RW medium is present then it would behave like pktcdvd device...
> To have /dev/cdrom generic also for CD-RW write access.

As mentioned, I don't think this kind of code belongs in the kernel. sr
or cdrom could easily be modified to support the necessary bits to
handle a writeable open, but the grunt of the pktcdvd code deals with
retrieving and writing out bigger chunks of data. And that part really
does belong in userspace imho.

-- 
Jens Axboe