linux-kernel - Re: efivarfs and writev() support

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]

Date:	Thu, 12 Mar 2015 06:34:37 +0000
From:	Al Viro <viro@...IV.linux.org.uk>
To:	Marcel Holtmann <marcel@...tmann.org>
Cc:	Matt Fleming <matt@...eblueprint.co.uk>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	linux-efi@...r.kernel.org,
	Matthew Garrett <matthew.garrett@...ula.com>,
	Jeremy Kerr <jk@...abs.org>,
	Matt Fleming <matt.fleming@...el.com>
Subject: Re: efivarfs and writev() support

On Wed, Mar 11, 2015 at 08:12:52AM -0700, Marcel Holtmann wrote:
> Hi Matt,
> 
> >> it seems that efivarfs only supports readv(), but when it comes to
> >> writev(), I am getting an error. Is there any reason to not support
> >> vectored write on this filesystem? Especially with the uint32 header
> >> for each file, I think it would make perfect sense to support it.
> > 
> > What error are you seeing? I thought that the vfs fell back to a looped
> > write if the file system doesn't support .write_iter()?
> 
> that seems to work for readv(), but not for writev().
> 
> > But yes, we definitely should support writev().
> 
> I just get an EIO error and have not traced this down any further.

What arguments are you feeding to it?  Note that the thing is sensitive to
range boundaries; it's not as if series of write() to it would be equivalent
to single write() from concatenation.  And writev() is equivalent to
series of write().

If you want behaviour a-la UDP sockets (syscall boundaries matter,
boundaries between vector elements do not), we can certainly do that,
but this is different from the current semantics.  AFAICS, said
semantics makes little sense, but it's a user-visible change...
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/