Message-ID: <5312f022-96ea-5555-8d17-4e60a33cf8f8@digikod.net>
Date:   Sat, 13 Nov 2021 14:02:02 +0100
From:   Mickaël Salaün <mic@...ikod.net>
To:     "Alejandro Colomar (man-pages)" <alx.manpages@...il.com>,
        Al Viro <viro@...iv.linux.org.uk>,
        Andrew Morton <akpm@...ux-foundation.org>
Cc:     Aleksa Sarai <cyphar@...har.com>,
        Andy Lutomirski <luto@...nel.org>,
        Arnd Bergmann <arnd@...db.de>,
        Casey Schaufler <casey@...aufler-ca.com>,
        Christian Brauner <christian.brauner@...ntu.com>,
        Christian Heimes <christian@...hon.org>,
        Deven Bowers <deven.desai@...ux.microsoft.com>,
        Dmitry Vyukov <dvyukov@...gle.com>,
        Eric Biggers <ebiggers@...nel.org>,
        Eric Chiang <ericchiang@...gle.com>,
        Florian Weimer <fweimer@...hat.com>,
        Geert Uytterhoeven <geert@...ux-m68k.org>,
        James Morris <jmorris@...ei.org>, Jan Kara <jack@...e.cz>,
        Jann Horn <jannh@...gle.com>, Jonathan Corbet <corbet@....net>,
        Kees Cook <keescook@...omium.org>,
        Lakshmi Ramasubramanian <nramas@...ux.microsoft.com>,
        "Madhavan T . Venkataraman" <madvenka@...ux.microsoft.com>,
        Matthew Garrett <mjg59@...gle.com>,
        Matthew Wilcox <willy@...radead.org>,
        Miklos Szeredi <mszeredi@...hat.com>,
        Mimi Zohar <zohar@...ux.ibm.com>,
        Paul Moore <paul@...l-moore.com>,
        Philippe Trébuchet 
        <philippe.trebuchet@....gouv.fr>,
        Scott Shell <scottsh@...rosoft.com>,
        Shuah Khan <shuah@...nel.org>,
        Steve Dower <steve.dower@...hon.org>,
        Steve Grubb <sgrubb@...hat.com>,
        Thibaut Sautereau <thibaut.sautereau@....gouv.fr>,
        Vincent Strubel <vincent.strubel@....gouv.fr>,
        Yin Fengwei <fengwei.yin@...el.com>,
        kernel-hardening@...ts.openwall.com, linux-api@...r.kernel.org,
        linux-fsdevel@...r.kernel.org, linux-integrity@...r.kernel.org,
        linux-kernel@...r.kernel.org,
        linux-security-module@...r.kernel.org,
        Mickaël Salaün <mic@...ux.microsoft.com>
Subject: Re: [PATCH v16 1/3] fs: Add trusted_for(2) syscall implementation and
 related sysctl


On 12/11/2021 20:16, Alejandro Colomar (man-pages) wrote:
> Hi Mickaël,

Hi Alejandro,

> 
> On 11/10/21 20:06, Mickaël Salaün wrote:
>> diff --git a/fs/open.c b/fs/open.c
>> index f732fb94600c..96a80abec41b 100644
>> --- a/fs/open.c
>> +++ b/fs/open.c
>> @@ -480,6 +482,114 @@ SYSCALL_DEFINE2(access, const char __user *,
>> filename, int, mode)
>>       return do_faccessat(AT_FDCWD, filename, mode, 0);
>>   }
>>   +#define TRUST_POLICY_EXEC_MOUNT            BIT(0)
>> +#define TRUST_POLICY_EXEC_FILE            BIT(1)
>> +
>> +int sysctl_trusted_for_policy __read_mostly;
>> +
>> +/**
> ...
>> + */
>> +SYSCALL_DEFINE3(trusted_for, const int, fd, const enum
>> trusted_for_usage, usage,
> 
> Please, don't use enums for interfaces.  They are implementation defined
> types, and vary between compilers and within the same compiler also
> depending on optimization flags.
> 
> C17::6.7.2.2.4:
> [
> Each enumerated type shall be compatible with char,
> a signed integer type, or an unsigned integer type.
> The choice of type is implementation-defined,130)
> but shall be capable of representing the values of
> all the members of the enumeration.
> ]
> 
> See also:
> <https://stackoverflow.com/questions/366017/what-is-the-size-of-an-enum-in-c>
> 
> 
> So, please use only standard integer types for interfaces.
> 
> And in the case of enums, since the language specifies that enumeration
> constants (the macro-like identifiers) are of type int, it makes sense
> for functions to use int.
> 
> C17::6.7.2.2.3:
> [
> The identifiers in an enumerator list are declared as constants
> that have type int and may appear wherever such are permitted.
> ]
> 
> I'd use an int for the API/ABI, even if it's expected to be assigned
> values of 'enum trusted_for_usage' (that should be specified in the
> manual page in DESCRIPTION, but not in SYNOPSIS, which should specify int).
> 
> 
> 
> TL;DR:
> 
> ISO C specifies that for the following code:
> 
>     enum foo {BAR};
> 
>     enum foo foobar;
> 
> typeof(foo)    shall be int
> typeof(foobar) is implementation-defined

I tested with some version of GCC (from 4.9 to 11) and clang (10 and 11)
with different optimizations and the related sizes are at least the same
as for the int type.

> 
> Since foobar = BAR; assigns an int, the best thing to do to avoid
> implementation-defined behavior, is to declare foobar as int too.

OK, so it should be enough to change the syscall argument type from enum
trusted_for_usage to int, but we can keep the UAPI with the enum (i.e.
we don't need to change the value to #define TRUSTED_FOR_EXECUTION 1) right?

> 
> 
>> diff --git a/include/linux/syscalls.h b/include/linux/syscalls.h
>> index 528a478dbda8..c535e0e43cc8 100644
>> --- a/include/linux/syscalls.h
>> +++ b/include/linux/syscalls.h
>> @@ -462,6 +463,7 @@ asmlinkage long sys_fallocate(int fd, int mode,
>> loff_t offset, loff_t len);
>>   asmlinkage long sys_faccessat(int dfd, const char __user *filename,
>> int mode);
>>   asmlinkage long sys_faccessat2(int dfd, const char __user *filename,
>> int mode,
>>                      int flags);
>> +asmlinkage long sys_trusted_for(int fd, enum trusted_for_usage usage,
>> u32 flags);
> 
> Same here.
> 
>>   asmlinkage long sys_chdir(const char __user *filename);
>>   asmlinkage long sys_fchdir(unsigned int fd);
>>   asmlinkage long sys_chroot(const char __user *filename);
> 
> Thanks,
> Alex
> 
> 

Powered by blists - more mailing lists