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
| ||
|
Date: Tue, 19 Jan 2016 15:51:49 -0800 From: Andy Lutomirski <luto@...capital.net> To: Jean Delvare <jdelvare@...e.de> Cc: Pali Rohár <pali.rohar@...il.com>, Andy Lutomirski <luto@...nel.org>, platform-driver-x86@...r.kernel.org, "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org> Subject: Re: [PATCH v2 3/3] dmi: Make dmi_walk and dmi_walk_early return real error codes On Tue, Jan 19, 2016 at 1:40 AM, Jean Delvare <jdelvare@...e.de> wrote: > On Tue, 19 Jan 2016 10:07:36 +0100, Pali Rohár wrote: >> On Tuesday 19 January 2016 10:03:03 Jean Delvare wrote: >> > Hi Pali, >> > >> > On Tue, 19 Jan 2016 09:36:33 +0100, Pali Rohár wrote: >> > > On Tuesday 19 January 2016 08:54:26 Jean Delvare wrote: >> > > > > @@ -978,11 +978,11 @@ int dmi_walk(void (*decode)(const struct dmi_header *, void *), >> > > > > u8 *buf; >> > > > > >> > > > > if (!dmi_available) >> > > > > - return -1; >> > > > > + return -ENOENT; >> > > > >> > > > -ENOSYS would seem more appropriate? >> > > >> > > IIRC -ENOSYS is for non implemented syscalls. >> > >> > I can see a lot of -ENOSYS in include/linux/*.h returned by stubs when >> > a specific subsystem is not included. Not related to syscalls at all. >> > This is what lead to my suggestion. >> >> https://lkml.org/lkml/2014/8/22/492 > > Thanks for the pointer, I wasn't aware of that. > > It really should be documented. No, checkpatch.pl isn't documentation. > > Also the commit sadly doesn't say why using ENOSYS in other contexts is > considered a bad thing. What actual trouble did it cause? The trouble is that user code likes to assume that, when a syscall returns -ENOSYS, that syscall isn't implemented. Letting ENOSYS leak out to userspace via a syscall that *is* implemented can confused things. > > Are the current presumably incorrect uses of ENOSYS ultimately going to > be fixed? If not, I see no point in preventing other use cases. We at least want to prevent it from newly introduced syscalls. I'll try to clean up the docs. --Andy
Powered by blists - more mailing lists