linux-kernel - Re: [PATCH v1 3/6] driver: Google EFI SMI

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, 27 Jan 2011 10:43:43 +0000
From:	Alan Cox <alan@...rguk.ukuu.org.uk>
To:	Mike Waychison <mikew@...gle.com>
Cc:	Greg KH <greg@...ah.com>, torvalds@...ux-foundation.org,
	San Mehat <san@...gle.com>, Aaron Durbin <adurbin@...gle.com>,
	Duncan Laurie <dlaurie@...gle.com>,
	linux-kernel@...r.kernel.org, Tim Hockin <thockin@...gle.com>
Subject: Re: [PATCH v1 3/6] driver: Google EFI SMI

> I understand that type widths change in a compat setting.  So what?
> Code in each environment is written to it's own namespace anyhow.

So you ned up with a pile of extra crap in the kernel to handle 32bit
userspace on 64bit and the like. If instead the structs are carefully
laid out this doesn't occur.

> Here's what *I* think *you* think about __u32 vs u32 vs uint32_t.
> Correct me if I'm totally off-base here:

And the __aligned_ ones for things like u64 in ioctls and structs...

It's also a style and consistency thing, its trivialto use the same style
as the rest of the kernel, it's trivial to tweak and it helps keep
coherency of style, even if you are sitting at the keyboard mumbling
"bunch of morons if you ask me" while doing it ;)

> I believe the above is non-sense because there is no concerted effort
> to ever let userland include kernel headers in any meaningful way.

Where do you think the library headers are distilled from ?

> Well, personally I like ioctls and system calls.  They don't bloat the
> system with unneeded crud and abstractions that aren't very useful.
> So what if you can't easily interface with them from a bare shell.
> That's what userland utilities are for anyhow.

ioctl has its place and I would agree with you on this one the interface
is essentially structure based so there isn't really that much you can do
about it anyway beyond getting the structures right.

(and the less the rest of the world has to know about EFI SMI internals
the better)

> I'm not sure if you are trying to suggest that there is a better way
> to solve these problems without actually saying so.  We could probably
> use a different interface, sure.

sysfs stuff only really helps for unsynchronized queries, ioctl is
read-modify-write which is a property sysfs lacks.

Alan
--
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/