Re: [PATCH v6 00/11] Intel SGX Driver
On Jan 3, 10:48am, Pavel Machek wrote:
} Subject: Re: [PATCH v6 00/11] Intel SGX Driver
> Hi!
Good morning.
> :-). Stuff proceeds as usual. Too bad it is raining outside, instead
> of snowing.
-19C here, so we have snow... :-)
> > > So ... even with SGX, host can generate bitflips in the enclave,
> > > right?
> > Correct.
> I'd say that you can't generate bitflips because if you do hardware
> will kill the enclave. This seems to be significant difference from
> AMD "secure" memory encryption.
SGX is an entirely different class of technology compared to AME SME
or the Intel equivalent TME (Total Memory Encryption). Both of these
are best described as the notion of applying the concept of whole disk
encryption to memory.
There are lots of well understood issues surrounding this approach,
whether the target is memory pages or disk sectors. I think the issue
comes down to the fact that there is a desire to enable a BIOS option
and become 'secure', unfortunately the world is not that simple.
> > Forcing a bitflip in enclave memory causes the next page fetch
> > containing the bitflipped location to fail its integrity check.
> > Since this technically shouldn't be possible, this situation was
> > classified as a hardware failure which is handled by the processor
> > locking its execution state, thus taking the machine down.
> So you can't really do bitflips on the SGX protected memory, because
> MM{E,U} hardware will catch that and kill machine if you try?
Correct.
Which obviously has issues in a multi-tenant cloud environment, but
again, it comes down to risk management. Killing a machine is
problematic, a massive data compromise isn't much fun either.
> So SGX protected memory is not swappable?
The architecture provides support for swapping enclave pages and the
Linux driver supports it.
The swapped pages retain their confidentiality and integrity
protections.
> > It would seem to be a misfeature for the self-protection mechanism to
> > not generate some type of trappable fault rather then generating a
> > processor lockup but hindsight is always 20/20. Philosophically this
> > is a good example of security risk managment. Locking a machine is
> > obviously problematic in a cloud service environment, but it has to be
> > taken in the perspective of whether or not it would be preferable to
> > have a successful privilege escalation attack which could result in
> > exfiltration of sensitive data.
> Ok, right, it should fault. They can fix it in new version?
Good question and something only Intel can answer.
A large part of SGX is implemented in microcode, in part due to the
complexity of the technologies involved, notably the group signing
(EPID) implementation.
Beyond that, there was a specific acknowledgement that this was
security sensitive code and may need an upgrade, hence the microcode
implementation.
Since the drop and lock 'feature' is closely tied to the MM{E,U}
implementation, the question would be whether or not this behavior
could be changed with updated firmware. If it was easy to change the
behavior of the MMU with microcode the industry would be less frantic
right now... :-)
If it would be possible to change the drop and lock response it would
arguably improve the utility of the technology in certain
environments. SGX2 would have been a great time for that.
> > Arguably not as much fun as what appears to be pending, given what
> > appears to be the difficulty of some Intel processors to deal with
> > page faults induced by speculative memory references... :-)
> Do you have more info on that? Will they actually leak information,
> or is it just good for rowhammering the kernel memory?
If we are talking about the issues motivating the KPTI work I don't
have any useful information beyond what is raging through the industry
right now.
With respect to SGX, the issues giving rise to KPTI are characteristic
of what this technology is designed to address. The technical 'news'
sites, which are even more of an abomination then usual with this
issue, are talking about privileged information such as credentials,
passwords et.al being leaked by this vulnerability.
Data committed to enclaves are only accessible by the enclave, even
the kernel, by definition, can't access the memory. Given current
events that is an arguably useful behavior.
> Best regards,
> Pavel
Stay dry.
Have a good day.
Greg
}-- End of excerpt from Pavel Machek
As always,
Dr. G.W. Wettstein, Ph.D. Enjellic Systems Development, LLC.
4206 N. 19th Ave. Specializing in information infra-structure
Fargo, ND 58102development.
PH: 701-281-1686
FAX: 701-281-3949 EMAIL: g...@enjellic.com
--
"Lots of folks confuse bad management with destiny."
-- Kin Hubbard
--
--
To unsubscribe from this list: se
Re: [PATCH] doc: memory-barriers: reStructure Text
> Am 04.01.2018 um 04:59 schrieb afzal mohammed : > > Hi, > > On Thu, Jan 04, 2018 at 09:48:50AM +0800, Boqun Feng wrote: > >>> The location chosen is "Documentation/kernel-hacking", i was unsure >>> where this should reside & there was no .rst file in top-level directory >>> "Documentation", so put it into one of the existing folder that seemed >>> to me as not that unsuitable. >>> >>> Other files refer to memory-barrier.txt, those also needs to be >>> adjusted based on where .rst can reside. > >> How do you plan to handle the external references? For example, the >> following LWN articles has a link this file: >> >> https://lwn.net/Articles/718628/ >> >> And changing the name and/or location will break that link, AFAIK. > > If necessary to handle these, symlink might help here i believe. IMO symlinks are mostly ending in a mess, URLs are never stable. There is a https://www.kernel.org/doc/html/latest/objects.inv to handle such requirements. Take a look at *intersphinx* : http://www.sphinx-doc.org/en/stable/ext/intersphinx.html to see how it works: Each Sphinx HTML build creates a file named objects.inv that contains a mapping from object names to URIs relative to the HTML set’s root. This means articles from external (like lwn articles) has to be recompiled. Not perfect, but a first solution. > Am 04.01.2018 um 00:48 schrieb Peter Zijlstra : > > So I hate this rst crap with a passion, so NAK from me. I really like them, factually valuable comments .. please express your concern so that we have a chance to move on. > Upon trying to understand memory-barriers.txt, i felt that it might be > better to have it in PDF/HTML format, thus attempted to convert it to > rst. And i see it not being welcomed, hence shelving the conversion. I think that's a pity. -- Markus -- -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] x86: Add topology_hw_smt_threads() and remove smp_num_siblings
Commit bbb65d2d365e ("x86: use cpuid vector 0xb when available for
detecting cpu topology") changed the value of smp_num_siblings from the
active number of threads in a core to the maximum number threads in a
core. e.g.) On Intel Haswell and newer systems smp_num_siblings is
two even if SMT is disabled.
topology_max_smt_threads() already returns the active number of threads.
Introduce topology_hw_smt_threads() which returns the maximum number of
threads. These are used to fix and replace references to smp_num_siblings.
Signed-off-by: Prarit Bhargava
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: "H. Peter Anvin"
Cc: x...@kernel.org
Cc: Jonathan Corbet
Cc: Andi Kleen
Cc: Vitaly Kuznetsov
Cc: linux-doc@vger.kernel.org
Cc: linux-e...@vger.kernel.org
Cc: oprofile-l...@lists.sf.net
---
Documentation/x86/topology.txt | 13 +
arch/x86/include/asm/perf_event_p4.h| 4 ++--
arch/x86/include/asm/smp.h | 2 --
arch/x86/include/asm/topology.h | 10 +-
arch/x86/kernel/cpu/amd.c | 6 ++
arch/x86/kernel/cpu/common.c| 18 +++---
arch/x86/kernel/cpu/mcheck/mce-inject.c | 3 ++-
arch/x86/kernel/cpu/topology.c | 4 ++--
arch/x86/kernel/itmt.c | 2 +-
arch/x86/kernel/process.c | 3 ++-
arch/x86/kernel/smpboot.c | 22 --
arch/x86/oprofile/nmi_int.c | 2 +-
arch/x86/oprofile/op_model_p4.c | 4 ++--
13 files changed, 47 insertions(+), 46 deletions(-)
diff --git a/Documentation/x86/topology.txt b/Documentation/x86/topology.txt
index f3e9d7e9ed6c..9fa07a4460df 100644
--- a/Documentation/x86/topology.txt
+++ b/Documentation/x86/topology.txt
@@ -83,13 +83,18 @@ The topology of a system is described in the units of:
Core-related topology information in the kernel:
- - smp_num_siblings:
+ - topology_hw_smt_threads:
-The number of threads in a core. The number of threads in a package can be
-calculated by:
+The maximum number of threads that a core's hardware supports. For
+example, on Intel Haswell and newer systems this is 2 even if SMT is
+disabled.
- threads_per_package = cpuinfo_x86.x86_max_cores * smp_num_siblings
+ - topology_max_smt_threads:
+The number of threads/core available at runtime. The number of threads in
+a package can be calculated by:
+
+threads_per_package = cpuinfo_x86.x86_max_cores * topology_max_smt_threads
* Threads:
diff --git a/arch/x86/include/asm/perf_event_p4.h
b/arch/x86/include/asm/perf_event_p4.h
index 94de1a05aeba..11afdadce9c2 100644
--- a/arch/x86/include/asm/perf_event_p4.h
+++ b/arch/x86/include/asm/perf_event_p4.h
@@ -181,7 +181,7 @@ static inline u64 p4_clear_ht_bit(u64 config)
static inline int p4_ht_active(void)
{
#ifdef CONFIG_SMP
- return smp_num_siblings > 1;
+ return topology_max_smt_threads() > 1;
#endif
return 0;
}
@@ -189,7 +189,7 @@ static inline int p4_ht_active(void)
static inline int p4_ht_thread(int cpu)
{
#ifdef CONFIG_SMP
- if (smp_num_siblings == 2)
+ if (topology_max_smt_threads() == 2)
return cpu !=
cpumask_first(this_cpu_cpumask_var_ptr(cpu_sibling_map));
#endif
return 0;
diff --git a/arch/x86/include/asm/smp.h b/arch/x86/include/asm/smp.h
index 461f53d27708..cf28a3932917 100644
--- a/arch/x86/include/asm/smp.h
+++ b/arch/x86/include/asm/smp.h
@@ -18,7 +18,6 @@
#include
#include
-extern int smp_num_siblings;
extern unsigned int num_processors;
DECLARE_PER_CPU_READ_MOSTLY(cpumask_var_t, cpu_sibling_map);
@@ -170,7 +169,6 @@ static inline int wbinvd_on_all_cpus(void)
wbinvd();
return 0;
}
-#define smp_num_siblings 1
#endif /* CONFIG_SMP */
extern unsigned disabled_cpus;
diff --git a/arch/x86/include/asm/topology.h b/arch/x86/include/asm/topology.h
index c1d2a9892352..b5ff1c784eef 100644
--- a/arch/x86/include/asm/topology.h
+++ b/arch/x86/include/asm/topology.h
@@ -116,16 +116,16 @@ extern unsigned int __max_logical_packages;
#define topology_max_packages()(__max_logical_packages)
extern int __max_smt_threads;
-
-static inline int topology_max_smt_threads(void)
-{
- return __max_smt_threads;
-}
+#define topology_max_smt_threads() (__max_smt_threads)
+extern int __hw_smt_threads;
+#define topology_hw_smt_threads() (__hw_smt_threads)
int topology_update_package_map(unsigned int apicid, unsigned int cpu);
extern int topology_phys_to_logical_pkg(unsigned int pkg);
#else
#define topology_max_packages()(1)
+#define topology_max_smt_threads() (1)
+#define topology_hw_smt_threads() (1)
static inline int
topology_update_package_map(unsigned int apicid, unsigned int cpu) { return 0;
}
static inline int topology_phys_to_logical_pkg(unsigned int pkg) { return 0; }
diff --git a/arch/x86/kernel/cpu/amd.c b/arch/x8
Hallo mein lieber Freund,
Hallo mein lieber Freund, Ich schreibe dir diese Post mit schweren Tränen In meinen Augen und großem Kummer in meinem Herzen, Mein Name ist Vera Hollin Kvan, und ich kontaktiere dich aus meinem Land Indien Ich möchte dir das sagen, weil ich keine habe Eine andere Möglichkeit, als Ihnen zu sagen, wie ich berührt war, um Sie zu öffnen, heiratete ich mit Herrn Hollin Kvan, der für neun Jahre mit der tunesischen Botschaft in Madrid Spanien arbeitete, bevor er im Jahr 2005 starb. Wir waren elf Jahre ohne verheiratet Kind. Er starb nach einer kurzen Krankheit, die nur fünf Tage dauerte. Seit seinem Tod entschied ich mich, nicht wieder zu heiraten. Als mein verstorbener Mann noch am Leben war, hinterlegte er die Summe von $ 4.850.000,00USD (Vier Millionen achthundertundfünfzigtausend Dollar) in einer Bank hier in Indien Neu-Delhi, der Hauptstadt Indiens, gegenwärtig dieses Geld ist immer noch in der Bank. Er stellte dieses Geld für den Export von Gold aus dem Minenfactory in Madrid Spanien zur Verfügung. In letzter Zeit sagte mir mein Doktor, dass ich wegen der Krebserkrankung für die Dauer von sieben Monaten nicht überleben würde. Derjenige, der mich am meisten stört, ist meine Schlaganfall-Krankheit. Nachdem ich meinen Zustand gekannt habe, habe ich beschlossen, dir dieses Geld auszuhändigen, um auf die weniger privilegierten Menschen aufzupassen, du wirst dieses Geld auf die Art und Weise benutzen, wie ich es hier unterrichten werde. Ich möchte, dass Sie 30 Prozent des gesamten Geldes für Ihren persönlichen Gebrauch aufwenden, während 70% des Geldes an wohltätige Zwecke gehen, Menschen auf der Straße und dem Waisenhaus helfen. Ich bin als Waise aufgewachsen und habe keinen Körper als mein Familienmitglied, nur um zu beenden, dass das Haus Gottes auch erhalten wird. Mache dies, damit Gott meine Sünden vergibt und meine Seele akzeptiert, weil diese Krankheiten mich so sehr leiden. Sobald ich Ihre Antwort erhalten habe, werde ich Ihnen den Kontakt der Bank hier in Delhi Indien geben und ich werde auch den Bankmanager beauftragen, Ihnen einen Vollmachtenbrief auszustellen, der Ihnen den gegenwärtigen Begünstigten des Geldes in der Bank beweisen wird, wenn Sie versichern mir, dass Sie entsprechend handeln werden, wie ich hier angegeben habe. Ich hoffe auf Ihre Antwort. Von Vera Hollin kVan -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 0/1] Support for generalized use of make C={1,2} via a wrapper program
This patch implements features to make it easier to run checkers on the
entire kernel as part of automatic and developer testing.
This is done by replacing the sparse specific setup for the C={1,2} variable
in the makefiles with setup for running scripts/runchecks, a new program that
can run any number of different "checkers". The behaviour of runchecks is
defined by simple "global" configuration in scripts/runchecks.cfg which can be
extended by local configuration applying to individual files, directories or
subtrees in the source.
The runchecks.cfg files are parsed according to this minimal language:
# comments
# "Global configuration in scripts/runchecks.cfg:
checker
typedef NAME regex
run
except checkpatch_type [files ...]
pervasive checkpatch_type1 [checkpatch_type2 ...]
With "make C=2" runchecks first parse the file scripts/runchecks.cfg, then
look for a file named 'runchecks.cfg' in the same directory as the source file.
If that file exists, it will be parsed and it's local configuration applied to
allow suppression on a per checker, per check and per file basis.
If a "local" configuration does not exist, either in the source directory or
above, make will simply silently ignore the file. This way the semantics
of "no in-tree runchecks.cfg file" is equivalent to a configuration where
all checks have been suppressed.
The idea is that the community can work to add runchecks.cfg files to
directories, serving both as documentation and as a way for subsystem
maintainers to enforce policies and individual tastes as well as TODOs and/or
priorities, to make it easier for newcomers to contribute in this area. By
ignoring directories/subtrees without such files, automation can start right
away as it is trivially possible to run errorless with C=2 for the entire
kernel.
For the checker maintainers this should be a benefit as well: new
or improved checks would generate new errors/warnings. With automatic testing
for the checkers, these new checks would generate error reports and cause
builds to fail. Adding the new check a 'pervasive' option at the top level or
even for specific files, marked with a "new check - please consider fixing"
comment
or similar would make those builds pass while documenting and making the new
check
more visible.
The patch includes documentation with some more details.
This patch has evolved from an earlier shell script implementation I made
as only a wrapper script around checkpatch. That version have been used for a
number of years on a driver project I worked on where we had automatic checkin
regression testing. I extended that to also run checkpatch to avoid having to
clean up frequent unintended whitespace changes and style violations from
others...
I have also tested this on some directories I am familiar with. The
result of that work is available in two patch sets of 10 and 11 patches.
I will post these fixes as separate patch sets later.
Version 2 and 1 of this set and related discussion can be found here:
v2: https://lkml.org/lkml/2017/12/16/343
v1: https://lkml.org/lkml/2017/11/16/458
Changes from v2:
-
* Squashed patches #1 and #2 from v2.
Fixed a few spelling errors + some suggested text improvements
in the docs.
* Shelved patch #3 as it's usefulness is not clear
* Removed patch #4-#5 as they were included here
as examples for discussion
* rebased to v4.15-rc6
Changes from v1:
-
Based on feedback, the implementation is completely rewritten and extended.
Instead of patches to checkpatch, and a sole checkpatch focus, it is now a
generic solution implemented in python, for any type of checkers, extendable
through some basic generic functionality, and for special needs by subclassing
the Checker class in the implementation.
This implementation fully supports checkpatch, sparse and
checkdoc == kernel-doc -none, and also has been tested with coccicheck.
To facilitate the same mechanism of using check types to filter what
checks to be suppressed, I introduced the concept of "typedefs" which allows
runchecks to effectively augment the check type space of the checker in cases
where types either are not available at all (checkdoc) or where only a few
can be filtered out (sparse)
With this in place it also became trivial to make the look and feel similar
for sparse and checkdoc as for checkpatch, with some optional color support
too, to make fixing issues in the code, the goal of this whole exercise,
much more pleasant IMHO :-)
Thanks,
Knut
Knut Omang (1):
runchecks: Generalize make C={1,2} to support multiple checkers
Documentation/dev-tools/coccinelle.rst | 12 +-
Documentation/dev-tools/index.rst | 1 +-
Documentation/dev-tools/runchecks.rst | 215 -
Documentation/dev-tools/sparse.rst | 30 +-
Documentation/kbuild/kbuild.txt| 9 +-
Makefile | 23 +-
scripts/Makefile.build | 4 +-
scrip
[PATCH v3 1/1] runchecks: Generalize make C={1,2} to support multiple checkers
Add scripts/runchecks which has generic support for running checker tools in a convenient and user friendly way that the author hopes can contribute to rein in issues detected by these tools in a manageable and convenient way. scripts/runchecks provides the following basic functionality: * Makes it possible to selectively suppress output from individual checks on a per file or per subsystem basis. * Unifies output and suppression input from different tools by providing a single unified syntax and presentation for the underlying tools in the style of "scripts/checkpatch.pl --show-types". * Allows selective run of one, or more (or all) configured tools for each file. In the Makefile system, the sparse specific setup has been replaced by setup for runchecks. This version of runchecks together with a "global" configuration file in "scripts/runchecks.cfg" supports sparse, checkpatch, and checkdoc, a trivial abstraction above a call to 'kernel-doc -none'. It also supports forwarding calls to coccicheck for coccinelle support but this is not quite as worked through as the three other checkers, mainly because of lack of error data as all checks pass by default right now. The code is designed to be easily extensible to support more checkers as they emerge, and some generic checker support is even available just via simple additions to "scripts/runchecks.cfg". The runchecks program unifies configuration, processing and output for multiple checker tools to make them all run as part of the C=1 or C=2 option to make. Currently with full support and unified behaviour for sparse: sparse checkpatch: scripts/checkpatch.pl checkdoc: kernel-doc -none In principle supported but not unified in output(yet): coccinelle: scripts/coccicheck Introduces a new documentation section titled "Makefile support for running checkers" Also updates documentation for the make C= option in some other doc files, as the behaviour has been changed to be less sparse specific and more generic. The coccinelle documentation also had the behaviour of C=1 and C=2 swapped. Signed-off-by: Knut Omang Reviewed-by: Håkon Bugge Reviewed-by: Åsmund Østvold Reviewed-by: John Haxby --- Documentation/dev-tools/coccinelle.rst | 12 +- Documentation/dev-tools/index.rst | 1 +- Documentation/dev-tools/runchecks.rst | 215 - Documentation/dev-tools/sparse.rst | 30 +- Documentation/kbuild/kbuild.txt| 9 +- Makefile | 23 +- scripts/Makefile.build | 4 +- scripts/runchecks | 734 ++- scripts/runchecks.cfg | 63 ++- scripts/runchecks_help.txt | 43 ++- 10 files changed, 1114 insertions(+), 20 deletions(-) create mode 100644 Documentation/dev-tools/runchecks.rst create mode 100755 scripts/runchecks create mode 100644 scripts/runchecks.cfg create mode 100644 scripts/runchecks_help.txt diff --git a/Documentation/dev-tools/coccinelle.rst b/Documentation/dev-tools/coccinelle.rst index 94f41c2..c98cc44 100644 --- a/Documentation/dev-tools/coccinelle.rst +++ b/Documentation/dev-tools/coccinelle.rst @@ -157,17 +157,19 @@ For example, to check drivers/net/wireless/ one may write:: make coccicheck M=drivers/net/wireless/ -To apply Coccinelle on a file basis, instead of a directory basis, the -following command may be used:: +To apply Coccinelle as the only checker on a file basis, +instead of a directory basis, the following command may be used:: -make C=1 CHECK="scripts/coccicheck" +make C=2 CF="--run:coccicheck" -To check only newly edited code, use the value 2 for the C flag, i.e.:: +To check only newly edited code, use the value 1 for the C flag, i.e.:: -make C=2 CHECK="scripts/coccicheck" +make C=1 CF="--run:coccicheck" In these modes, which works on a file basis, there is no information about semantic patches displayed, and no commit message proposed. +For more information about options in this calling mode, see +Documentation/dev-tools/runchecks.rst . This runs every semantic patch in scripts/coccinelle by default. The COCCI variable may additionally be used to only apply a single diff --git a/Documentation/dev-tools/index.rst b/Documentation/dev-tools/index.rst index e313925..cb4506d 100644 --- a/Documentation/dev-tools/index.rst +++ b/Documentation/dev-tools/index.rst @@ -16,6 +16,7 @@ whole; patches welcome! coccinelle sparse + runchecks kcov gcov kasan diff --git a/Documentation/dev-tools/runchecks.rst b/Documentation/dev-tools/runchecks.rst new file mode 100644 index 000..1a43c05 --- /dev/null +++ b/Documentation/dev-tools/runchecks.rst @@ -0,0 +1,215 @@ +.. Copyright 2017 Knut Omang + +Makefile support for running checkers += + +Tools like sparse, coccinelle, and scripts/checkpatch.pl are able to detect a +lot of syntactic and semantic issues with the code, and are also
Re: [PATCH v6 00/11] Intel SGX Driver
So how does this protect against the MELTDOWN attack (CVE-2017-5754) and the MELTATOMBOMBA4 worm which uses this exploit? Ced On 25 November 2017 at 20:29, Jarkko Sakkinen wrote: > Intel(R) SGX is a set of CPU instructions that can be used by applications to > set aside private regions of code and data. The code outside the enclave is > disallowed to access the memory inside the enclave by the CPU access control. > In a way you can think that SGX provides inverted sandbox. It protects the > application from a malicious host. > > There is a new hardware unit in the processor called Memory Encryption Engine > (MEE) starting from the Skylake microacrhitecture. BIOS can define one or many > MEE regions that can hold enclave data by configuring them with PRMRR > registers. > > The MEE automatically encrypts the data leaving the processor package to the > MEE regions. The data is encrypted using a random key whose life-time is > exactly one power cycle. > > You can tell if your CPU supports SGX by looking into /proc/cpuinfo: > > cat /proc/cpuinfo | grep sgx > > The GIT repositoy for SGX driver resides in > > https://github.com/jsakkine-intel/linux-sgx.git > > 'le' branch contains the upstream candidate patches. > > 'master' branch contains the same patches with the following differences: > > * top-level patch modifies the ioctl API to be SDK compatible > * does not use flexible launch control but instead relies on SDK provided > Intel launch enclave. > > Backlog: > * AES: how to use arch/x86/crypto/aesni-intel_asm.S from the enclave. I > guess these routines should be fairly easy to call directly (haven't > investigated deeply). Any advice is appreciated. > * Layout: what and where to place in arch/x86. > * MAINTAINERS: who to add as reviewer. > > v6 > * Fixed semaphore underrun when accessing /dev/sgx from the launch enclave. > * In sgx_encl_create() s/IS_ERR(secs)/IS_ERR(encl)/. > * Removed virtualization chapter from the documentation. > * Changed the default filename for the signing key as signing_key.pem. > * Reworked EPC management in a way that instead of a linked list of > struct sgx_epc_page instances there is an array of integers that > encodes address and bank of an EPC page (the same data as 'pa' field > earlier). The locking has been moved to the EPC bank level instead > of a global lock. > * Relaxed locking requirements for EPC management. EPC pages can be > released back to the EPC bank concurrently. > * Cleaned up ptrace() code. > * Refined commit messages for new architectural constants. > * Sorted includes in every source file. > * Sorted local variable declarations according to the line length in > every function. > * Style fixes based on Darren's comments to sgx_le.c. > > v5: > * Described IPC between the Launch Enclave and kernel in the commit messages. > * Fixed all relevant checkpatch.pl issues that I have forgot fix in earlier > versions except those that exist in the imported TinyCrypt code. > * Fixed spelling mistakes in the documentation. > * Forgot to check the return value of sgx_drv_subsys_init(). > * Encapsulated properly page cache init and teardown. > * Collect epc pages to a temp list in sgx_add_epc_bank > * Removed SGX_ENCLAVE_INIT_ARCH constant. > > v4: > * Tied life-cycle of the sgx_le_proxy process to /dev/sgx. > * Removed __exit annotation from sgx_drv_subsys_exit(). > * Fixed a leak of a backing page in sgx_process_add_page_req() in the > case when vm_insert_pfn() fails. > * Removed unused symbol exports for sgx_page_cache.c. > * Updated sgx_alloc_page() to require encl parameter and documented the > behavior (Sean Christopherson). > * Refactored a more lean API for sgx_encl_find() and documented the behavior. > * Moved #PF handler to sgx_fault.c. > * Replaced subsys_system_register() with plain bus_register(). > * Retry EINIT 2nd time only if MSRs are not locked. > > v3: > * Check that FEATURE_CONTROL_LOCKED and FEATURE_CONTROL_SGX_ENABLE are set. > * Return -ERESTARTSYS in __sgx_encl_add_page() when sgx_alloc_page() fails. > * Use unused bits in epc_page->pa to store the bank number. > * Removed #ifdef for WQ_NONREENTRANT. > * If mmu_notifier_register() fails with -EINTR, return -ERESTARTSYS. > * Added --remove-section=.got.plt to objcopy flags in order to prevent a > dummy .got.plt, which will cause an inconsistent size for the LE. > * Documented sgx_encl_* functions. > * Added remark about AES implementation used inside the LE. > * Removed redundant sgx_sys_exit() from le/main.c. > * Fixed struct sgx_secinfo alignment from 128 to 64 bytes. > * Validate miscselect in sgx_encl_create(). > * Fixed SSA frame size calculation to take the misc region into account. > * Implemented consistent exception handling to __encls() and __encls_ret(). > * Implemented a proper device model in order to allow sysfs attributes > and in-kernel API. > * Cleaned up various "find enclave" implementations to the unified > sgx_encl_find(). > * Va
Re: [PATCH v6 00/11] Intel SGX Driver
On Thu, Jan 04, 2018 at 03:17:24PM +0100, Cedric Blancher wrote: > So how does this protect against the MELTDOWN attack (CVE-2017-5754) > and the MELTATOMBOMBA4 worm which uses this exploit? It has nothing to do with it at all, sorry. greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v6 00/11] Intel SGX Driver
On Thu, 2018-01-04 at 15:17 +0100, Cedric Blancher wrote: > So how does this protect against the MELTDOWN attack (CVE-2017-5754) > and the MELTATOMBOMBA4 worm which uses this exploit? Actually, a data exfiltration attack against SGX, using page tables has already been documented: https://www.usenix.org/conference/usenixsecurity17/technical-sessions/presentation/van-bulck It doesn't exploit speculation as the mechanism for gathering data (it exploits page faults), but the structure of the side channel attack used to exfiltrate data from the supposedly secure enclave is very similar to Spectre. The targetting mechanism is very different, though: the page table exploit assumes you can control the page tables, so you must be highly privileged on the platform but with Spectre you merely have to be an ordinary user. James -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 1/1] runchecks: Generalize make C={1,2} to support multiple checkers
On Thu, 04 Jan 2018, Knut Omang wrote: > Add scripts/runchecks which has generic support for running > checker tools in a convenient and user friendly way that > the author hopes can contribute to rein in issues detected > by these tools in a manageable and convenient way. > > scripts/runchecks provides the following basic functionality: > > * Makes it possible to selectively suppress output from individual > checks on a per file or per subsystem basis. > * Unifies output and suppression input from different tools > by providing a single unified syntax and presentation for the > underlying tools in the style of "scripts/checkpatch.pl --show-types". > * Allows selective run of one, or more (or all) configured tools > for each file. > > In the Makefile system, the sparse specific setup has been replaced > by setup for runchecks. > > This version of runchecks together with a "global" configuration > file in "scripts/runchecks.cfg" supports sparse, checkpatch, and checkdoc, > a trivial abstraction above a call to 'kernel-doc -none'. > It also supports forwarding calls to coccicheck for coccinelle support > but this is not quite as worked through as the three other checkers, > mainly because of lack of error data as all checks pass by default > right now. > > The code is designed to be easily extensible to support more checkers > as they emerge, and some generic checker support is even available > just via simple additions to "scripts/runchecks.cfg". > > The runchecks program unifies configuration, processing > and output for multiple checker tools to make them > all run as part of the C=1 or C=2 option to make. > > Currently with full support and unified behaviour for > sparse: sparse > checkpatch: scripts/checkpatch.pl > checkdoc: kernel-doc -none > > In principle supported but not unified in output(yet): > coccinelle: scripts/coccicheck > > Introduces a new documentation section titled > "Makefile support for running checkers" > > Also updates documentation for the make C= option > in some other doc files, as the behaviour has > been changed to be less sparse specific and more > generic. The coccinelle documentation also had the > behaviour of C=1 and C=2 swapped. I'm surprised the commit message and the provided documentation say nothing about using CHECK=foo on the command line. That already supports arbitrary checkers. How does this relate to that? Is this supposed to be a complete replacement? Or what? 'make help' also references $CHECK, and this patch doesn't update the help text. > Signed-off-by: Knut Omang > Reviewed-by: Håkon Bugge > Reviewed-by: Åsmund Østvold > Reviewed-by: John Haxby > --- > Documentation/dev-tools/coccinelle.rst | 12 +- > Documentation/dev-tools/index.rst | 1 +- > Documentation/dev-tools/runchecks.rst | 215 - > Documentation/dev-tools/sparse.rst | 30 +- > Documentation/kbuild/kbuild.txt| 9 +- > Makefile | 23 +- > scripts/Makefile.build | 4 +- > scripts/runchecks | 734 ++- > scripts/runchecks.cfg | 63 ++- > scripts/runchecks_help.txt | 43 ++- Please get rid of runchecks_help.txt and use the usual python mechanisms to specify and parse command line options, with their help texts, including automated --help output. This keeps the implementation and the help together, with hopes they'll actually stay in sync. Please don't hand roll argument parsers in python. BR, Jani. > 10 files changed, 1114 insertions(+), 20 deletions(-) > create mode 100644 Documentation/dev-tools/runchecks.rst > create mode 100755 scripts/runchecks > create mode 100644 scripts/runchecks.cfg > create mode 100644 scripts/runchecks_help.txt > > diff --git a/Documentation/dev-tools/coccinelle.rst > b/Documentation/dev-tools/coccinelle.rst > index 94f41c2..c98cc44 100644 > --- a/Documentation/dev-tools/coccinelle.rst > +++ b/Documentation/dev-tools/coccinelle.rst > @@ -157,17 +157,19 @@ For example, to check drivers/net/wireless/ one may > write:: > > make coccicheck M=drivers/net/wireless/ > > -To apply Coccinelle on a file basis, instead of a directory basis, the > -following command may be used:: > +To apply Coccinelle as the only checker on a file basis, > +instead of a directory basis, the following command may be used:: > > -make C=1 CHECK="scripts/coccicheck" > +make C=2 CF="--run:coccicheck" > > -To check only newly edited code, use the value 2 for the C flag, i.e.:: > +To check only newly edited code, use the value 1 for the C flag, i.e.:: > > -make C=2 CHECK="scripts/coccicheck" > +make C=1 CF="--run:coccicheck" > > In these modes, which works on a file basis, there is no information > about semantic patches displayed, and no commit message proposed. > +For more information about options in this calling mode, see > +Documentation/dev-tools/runchecks.rst . > > This runs every
Re: [PATCH v3 1/1] runchecks: Generalize make C={1,2} to support multiple checkers
On Thu, 2018-01-04 at 17:50 +0200, Jani Nikula wrote:
> On Thu, 04 Jan 2018, Knut Omang wrote:
> > Add scripts/runchecks which has generic support for running
> > checker tools in a convenient and user friendly way that
> > the author hopes can contribute to rein in issues detected
> > by these tools in a manageable and convenient way.
> >
> > scripts/runchecks provides the following basic functionality:
> >
> > * Makes it possible to selectively suppress output from individual
> > checks on a per file or per subsystem basis.
> > * Unifies output and suppression input from different tools
> > by providing a single unified syntax and presentation for the
> > underlying tools in the style of "scripts/checkpatch.pl --show-types".
> > * Allows selective run of one, or more (or all) configured tools
> > for each file.
> >
> > In the Makefile system, the sparse specific setup has been replaced
> > by setup for runchecks.
> >
> > This version of runchecks together with a "global" configuration
> > file in "scripts/runchecks.cfg" supports sparse, checkpatch, and checkdoc,
> > a trivial abstraction above a call to 'kernel-doc -none'.
> > It also supports forwarding calls to coccicheck for coccinelle support
> > but this is not quite as worked through as the three other checkers,
> > mainly because of lack of error data as all checks pass by default
> > right now.
> >
> > The code is designed to be easily extensible to support more checkers
> > as they emerge, and some generic checker support is even available
> > just via simple additions to "scripts/runchecks.cfg".
> >
> > The runchecks program unifies configuration, processing
> > and output for multiple checker tools to make them
> > all run as part of the C=1 or C=2 option to make.
> >
> > Currently with full support and unified behaviour for
> > sparse: sparse
> > checkpatch: scripts/checkpatch.pl
> > checkdoc: kernel-doc -none
> >
> > In principle supported but not unified in output(yet):
> > coccinelle: scripts/coccicheck
> >
> > Introduces a new documentation section titled
> > "Makefile support for running checkers"
> >
> > Also updates documentation for the make C= option
> > in some other doc files, as the behaviour has
> > been changed to be less sparse specific and more
> > generic. The coccinelle documentation also had the
> > behaviour of C=1 and C=2 swapped.
>
> I'm surprised the commit message and the provided documentation say
> nothing about using CHECK=foo on the command line. That already supports
> arbitrary checkers.
The problem, highlighted by Jim Davis in
https://lkml.org/lkml/2017/11/20/638
is that the current solution isn't flexible enough - that discussion
is what lead me to this reimplementation of what I originally intended
to be a checkpatch only solution.
> How does this relate to that? Is this supposed to be
> a complete replacement? Or what?
It has evolved into a complete replacement of the intention of CHECK.
> 'make help' also references $CHECK, and this patch doesn't update the
> help text.
I realize now that this needs to be handled in some way due to the way I split
the
arguments with '--' - the intention was to keep it for bw compatibility.
It would be good to know if people rely on using CHECK with C={1,2} for
anything beside the checkers supported by runchecks today, if not,
it could either be removed or simply replace by an expansion into a
'--run:$CHECK'
argument to runchecks
Then runchecks' implicit method of declaring
checker
in scripts/runchecks.cfg could be used for people with checkers that
need no further input/output adaptation.
Further suggestions appreciated on this matter.
> > Signed-off-by: Knut Omang
> > Reviewed-by: Håkon Bugge
> > Reviewed-by: Åsmund Østvold
> > Reviewed-by: John Haxby
> > ---
> > Documentation/dev-tools/coccinelle.rst | 12 +-
> > Documentation/dev-tools/index.rst | 1 +-
> > Documentation/dev-tools/runchecks.rst | 215 -
> > Documentation/dev-tools/sparse.rst | 30 +-
> > Documentation/kbuild/kbuild.txt| 9 +-
> > Makefile | 23 +-
> > scripts/Makefile.build | 4 +-
> > scripts/runchecks | 734 ++-
> > scripts/runchecks.cfg | 63 ++-
> > scripts/runchecks_help.txt | 43 ++-
>
> Please get rid of runchecks_help.txt and use the usual python mechanisms
> to specify and parse command line options, with their help texts,
> including automated --help output. This keeps the implementation and the
> help together, with hopes they'll actually stay in sync. Please don't
> hand roll argument parsers in python.
Hmm - I have been burnt by the use of unstable interfaces in Python before,
when I needed it to work on a (Linux) system with Python v.2.6.x only
- argparse was introduced in v.2.7. and alternative choices are not
at all clear to me, see for instance:
https://dmerej.info/blog/post/doco
Re: [PATCH v6 00/11] Intel SGX Driver
On Jan 4, 3:27pm, Greg Kroah-Hartman wrote: } Subject: Re: [PATCH v6 00/11] Intel SGX Driver Wild day, enjoyed by all I'm sure. > On Thu, Jan 04, 2018 at 03:17:24PM +0100, Cedric Blancher wrote: > > So how does this protect against the MELTDOWN attack (CVE-2017-5754) > > and the MELTATOMBOMBA4 worm which uses this exploit? > It has nothing to do with it at all, sorry. Precision seems to be everything in these discussions. Since SGX obviously does not mitigate micro-architectural state probing it is not an effective general remediation against MELTDOWN. Does your statement indicate there is solid documentation that MELTDOWN can be used by a process of any privilege level to dump out the unencrypted contents of an initialized enclave? That would obviously be a big story as well. > greg k-h Have a good evening. Greg }-- End of excerpt from Greg Kroah-Hartman As always, Dr. G.W. Wettstein, Ph.D. Enjellic Systems Development, LLC. 4206 N. 19th Ave. Specializing in information infra-structure Fargo, ND 58102development. PH: 701-281-1686 FAX: 701-281-3949 EMAIL: g...@enjellic.com -- "If you get to thinkin' you're a person of some influence, try orderin' somebody else's dog around." -- Cowboy Wisdom -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH][RESEND] cgroup, docs: document the root cgroup behavior of cpu and io controllers
Currently, cgroups v2 documentation contains only a generic remark that "How resource consumption in the root cgroup is governed is up to each controller", which isn't really telling users much, who need to dig in the code and / or commit messages to learn the exact behavior. In cgroups v1 at least the blkio controller had its operation with respect to competition between child threads and child cgroups documented in blkio-controller.txt, with references to cfq-iosched.txt. Also, cgroups v2 documentation describes v1 behavior of both cpu and blkio controllers in an "Issues with v1" section. Let's document this behavior also for cgroups v2 to make life easier for users. Signed-off-by: Maciej S. Szmigiero --- This is a resend without any changes. Documentation/cgroup-v2.txt | 11 +++ 1 file changed, 11 insertions(+) diff --git a/Documentation/cgroup-v2.txt b/Documentation/cgroup-v2.txt index c783bbb9d0fb..f8824c288dbb 100644 --- a/Documentation/cgroup-v2.txt +++ b/Documentation/cgroup-v2.txt @@ -906,6 +906,13 @@ have placed RT processes into nonroot cgroups during the system boot process, and these processes may need to be moved to the root cgroup before the cpu controller can be enabled. +When distributing CPU cycles in the root cgroup each thread in this +cgroup is treated as if it was hosted in a separate child cgroup of the +root cgroup. This child cgroup weight is dependent on its thread nice +level. +For details of this mapping see sched_prio_to_weight array in +kernel/sched/core.c file (values from this array should be scaled +appropriately so the neutral - nice 0 - value is 100 instead of 1024). CPU Interface Files ~~~ @@ -1247,6 +1254,10 @@ limit distribution; however, weight based distribution is available only if cfq-iosched is in use and neither scheme is available for blk-mq devices. +Root cgroup processes are hosted in an implicit leaf child node. +When distributing IO resources this implicit child node is taken into +account as if it was a normal child cgroup of the root cgroup with a +weight value of 200. IO Interface Files ~~ -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3] arm64: v8.4: Support for new floating point multiplication instructions
Hi will/catalin On 2017/12/13 18:09, Suzuki K Poulose wrote: > On 13/12/17 10:13, Dongjiu Geng wrote: >> ARM v8.4 extensions add new neon instructions for performing a >> multiplication of each FP16 element of one vector with the corresponding >> FP16 element of a second vector, and to add or subtract this without an >> intermediate rounding to the corresponding FP32 element in a third vector. >> >> This patch detects this feature and let the userspace know about it via a >> HWCAP bit and MRS emulation. >> >> Cc: Dave Martin >> Cc: Suzuki K Poulose >> Signed-off-by: Dongjiu Geng >> Reviewed-by: Dave Martin > > Looks good to me. > > Reviewed-by: Suzuki K Poulose sorry to disturb you. Reminder, hope this patch can be applied to Linux 4.15-rc7. Thanks a lot in advance. > > > . > -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] doc: memory-barriers: reStructure Text
Hi, On Thu, Jan 04, 2018 at 11:27:55AM +0100, Markus Heiser wrote: > IMO symlinks are mostly ending in a mess, URLs are never stable. > There is a > > https://www.kernel.org/doc/html/latest/objects.inv > > to handle such requirements. Take a look at *intersphinx* : > > http://www.sphinx-doc.org/en/stable/ext/intersphinx.html > > to see how it works: Each Sphinx HTML build creates a file named objects.inv > that > contains a mapping from object names to URIs relative to the HTML set’s root. > > This means articles from external (like lwn articles) has to be recompiled. > Not perfect, but a first solution. Thanks for the details. > I really like them Initially i was sceptical of rst & once instead of hitting the fly, hit "make htmldocs" on the keyboard :), and the opinion about it was changed. It was easy to navigate through various docs & the realized that various topics (& many) were present (yes, it was there earlier also, but had to dive inside Documentation & search, while viewing the toplevel index.html made them standout). It was like earlier you had to go after docs, but now it was docs coming after you, that is my opinion. Later while fighting with memory-barriers.txt, felt that it might be good for it as well as to be in that company. And the readability as a text is not hurt as well. It was thought that rst conversion could be done quickly, but since this was my first attempt with rst, had to put some effort to get a not so bad output, even if this patch dies, i am happy to have learnt rst conversion to some extent. > > Upon trying to understand memory-barriers.txt, i felt that it might be > > better to have it in PDF/HTML format, thus attempted to convert it to > > rst. And i see it not being welcomed, hence shelving the conversion. > > I think that's a pity. When one of the author of the original document objected, i felt it is better to backoff. But if there is a consensus, i will proceed. afzal -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3] arm64: v8.4: Support for new floating point multiplication instructions
On Fri, Jan 05, 2018 at 09:22:54AM +0800, gengdongjiu wrote: > Hi will/catalin > > On 2017/12/13 18:09, Suzuki K Poulose wrote: > > On 13/12/17 10:13, Dongjiu Geng wrote: > >> ARM v8.4 extensions add new neon instructions for performing a > >> multiplication of each FP16 element of one vector with the corresponding > >> FP16 element of a second vector, and to add or subtract this without an > >> intermediate rounding to the corresponding FP32 element in a third vector. > >> > >> This patch detects this feature and let the userspace know about it via a > >> HWCAP bit and MRS emulation. > >> > >> Cc: Dave Martin > >> Cc: Suzuki K Poulose > >> Signed-off-by: Dongjiu Geng > >> Reviewed-by: Dave Martin > > > > Looks good to me. > > > > Reviewed-by: Suzuki K Poulose > > sorry to disturb you. Reminder, hope this patch can be applied to Linux > 4.15-rc7. New features should not be going into 4.15-rc, that should be a 4.16-rc1 thing, right? thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
