linux-kernel - Re: [RFC, PATCH] Extensible AIO interface

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: <20121001234439.GC14533@lenny.home.zabbo.net>
Date:	Mon, 1 Oct 2012 16:44:39 -0700
From:	Zach Brown <zab@...bo.net>
To:	Kent Overstreet <koverstreet@...gle.com>
Cc:	linux-kernel@...r.kernel.org, linux-fsdevel@...r.kernel.org,
	tytso@...gle.com, tj@...nel.org,
	Dave Kleikamp <dave.kleikamp@...cle.com>,
	Dmitry Monakhov <dmonakhov@...nvz.org>,
	"Maxim V. Patlasov" <mpatlasov@...allels.com>,
	michael.mesnier@...el.com, jeffrey.d.skirvin@...el.com,
	Martin Petersen <martin.petersen@...cle.com>
Subject: Re: [RFC, PATCH] Extensible AIO interface

> Not just per sector, Per hardware sector. For passing around checksums
> userspace would have to find out the hardware sector size and checksum
> type/size via a different interface, and then the attribute would
> contain a pointer to a buffer that can hold the appropriate number of
> checksums.

All problems fall to another layer of indirection? :)  But yes, that's
fair.  I was obviously just assuming that the checksums would be in the
attribute.

But now we're talking about layers of user pointers.  Would the
attribute parser need to verify/copy pointers before downstream kernel
code tries to work with it?  Would it be up to the attribute consumers
to verify the pointers that the core doesn't really touch?  Are these
second pointers native (enter compat goo) or u64s?

> I don't think there's anything fragile about the basic idea though. Or
> do you have some way of improving upon it in mind?

Nothing super great is springing to mind, no.

> The idea with the size field is that it's just sizeof(the particular
> attribute struct), so when userspace is appending attributes it just
> sets size = sizeof() and attr_list->size += attr->size.

I suppose.  But this also raises the spectre of aligning the packed
attributes to match their struct definitions.  It's the netlink(3)
macros all over again, right?  I guess unaligned accesses aren't *that*
big a deal.  But still.

And what about duplicate instances of a given attribute id?  Use the
first?  The last?  Error?  Depends on the id?

It just seems like there are a lot of corner cases that can go wrong
with an API that is so free form.  I'd like something a lot harder to
make mistakes with.

- z
(being That Guy today, apparently :/)
--
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/