From: hpa@zytor.com
To: Andy Lutomirski <luto@kernel.org>,
"Bae, Chang Seok" <chang.seok.bae@intel.com>
Cc: Andrew Lutomirski <luto@kernel.org>,
Thomas Gleixner <tglx@linutronix.de>,
Ingo Molnar <mingo@kernel.org>, Andi Kleen <ak@linux.intel.com>,
Dave Hansen <dave.hansen@linux.intel.com>,
"Metzger, Markus T" <markus.t.metzger@intel.com>,
"Ravi V. Shankar" <ravi.v.shankar@intel.com>,
LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH V2 06/15] taint: Add taint for insecure
Date: Thu, 31 May 2018 13:50:23 -0700 [thread overview]
Message-ID: <60869EFF-9C2E-4415-B538-0826FA26B698@zytor.com> (raw)
In-Reply-To: <CALCETrUL0sV3f4z=S0y-fwPE82pp8BTGDGkvi=MPHak8-zwBnQ@mail.gmail.com>
On May 31, 2018 1:25:39 PM PDT, Andy Lutomirski <luto@kernel.org> wrote:
>On Thu, May 31, 2018 at 10:58 AM Chang S. Bae
><chang.seok.bae@intel.com> wrote:
>>
>> When adding new feature support, patches need to be
>> incrementally applied and tested with temporal parameters.
>> For such testing (or root-only) purposes, the new flag
>> will serve to tag the kernel taint state properly.
>
>I'm okay with this, I guess, but I'm not at all convinced we need it.
This was my idea. It isn't the only thing that may want it, and I think it is critical that we give the system a way to flag that the system contains experimental code that is known to break security. Sometimes that kind of experimental code is useful (I have written some myself, e.g. to treat SMAP), but it is a good idea to be able to flag such a kernel permanently, even if it's a module that can be removed.
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
next prev parent reply other threads:[~2018-05-31 20:50 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-05-31 17:58 [PATCH V2 00/15] x86: Enable FSGSBASE instructions Chang S. Bae
2018-05-31 17:58 ` [PATCH V2 01/15] x86/fsgsbase/64: Introduce FS/GS base helper functions Chang S. Bae
2018-05-31 20:14 ` Andy Lutomirski
2018-05-31 21:03 ` Bae, Chang Seok
2018-05-31 17:58 ` [PATCH V2 02/15] x86/fsgsbase/64: Make ptrace read FS/GS base accurately Chang S. Bae
2018-05-31 20:14 ` Andy Lutomirski
2018-05-31 20:31 ` hpa
2018-05-31 20:38 ` Andy Lutomirski
2018-05-31 17:58 ` [PATCH V2 03/15] x86/fsgsbase/64: Use FS/GS base helpers in core dump Chang S. Bae
2018-05-31 20:15 ` Andy Lutomirski
2018-05-31 21:03 ` Bae, Chang Seok
2018-05-31 17:58 ` [PATCH V2 04/15] x86/fsgsbase/64: Factor out load FS/GS segments from __switch_to Chang S. Bae
2018-05-31 20:16 ` Andy Lutomirski
2018-05-31 17:58 ` [PATCH V2 05/15] x86/vdso: Move out the CPU number store Chang S. Bae
2018-05-31 20:25 ` Andy Lutomirski
2018-05-31 21:06 ` Bae, Chang Seok
2018-06-05 7:02 ` [lkp-robot] [x86/vdso] f52001961d: BUG:kernel_hang_in_early-boot_stage,last_printk:Probing_EDD(edd=off_to_disable)...ok kernel test robot
2018-05-31 17:58 ` [PATCH V2 06/15] taint: Add taint for insecure Chang S. Bae
2018-05-31 20:25 ` Andy Lutomirski
2018-05-31 20:50 ` hpa [this message]
2018-05-31 17:58 ` [PATCH V2 07/15] x86/fsgsbase/64: Add 'unsafe_fsgsbase' to enable CR4.FSGSBASE Chang S. Bae
2018-05-31 17:58 ` [PATCH V2 08/15] x86/fsgsbase/64: Add intrinsics/macros for FSGSBASE instructions Chang S. Bae
2018-05-31 17:58 ` [PATCH V2 09/15] x86/fsgsbase/64: Enable FSGSBASE instructions in helper functions Chang S. Bae
2018-05-31 17:58 ` [PATCH V2 10/15] x86/fsgsbase/64: Preserve FS/GS state in __switch_to if FSGSBASE is on Chang S. Bae
2018-05-31 17:58 ` [PATCH V2 11/15] x86/fsgsbase/64: When copying a thread, use FSGSBASE if enabled Chang S. Bae
2018-05-31 17:58 ` [PATCH V2 12/15] x86/fsgsbase/64: Use per-CPU base as GS base on paranoid_entry Chang S. Bae
2018-05-31 17:58 ` [PATCH V2 13/15] x86/fsgsbase/64: Enable FSGSBASE by default and add a chicken bit Chang S. Bae
2018-05-31 17:58 ` [PATCH V2 14/15] x86/elf: Enumerate kernel FSGSBASE capability in AT_HWCAP2 Chang S. Bae
2018-05-31 17:58 ` [PATCH V2 15/15] x86/fsgsbase/64: Add documentation for FSGSBASE Chang S. Bae
2018-05-31 20:37 ` [PATCH V2 00/15] x86: Enable FSGSBASE instructions Andy Lutomirski
2018-05-31 21:11 ` Bae, Chang Seok
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=60869EFF-9C2E-4415-B538-0826FA26B698@zytor.com \
--to=hpa@zytor.com \
--cc=ak@linux.intel.com \
--cc=chang.seok.bae@intel.com \
--cc=dave.hansen@linux.intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=luto@kernel.org \
--cc=markus.t.metzger@intel.com \
--cc=mingo@kernel.org \
--cc=ravi.v.shankar@intel.com \
--cc=tglx@linutronix.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).