From: Greg Kroah-Hartman Date: Thu, 11 Jul 2019 11:45:58 +0000 (+0200) Subject: 5.2-stable patches X-Git-Tag: v5.2.1~38 X-Git-Url: http://git.ipfire.org/?a=commitdiff_plain;h=81a245bd0b5775308c8bd3f5236513ef28fb9abe;p=thirdparty%2Fkernel%2Fstable-queue.git 5.2-stable patches added patches: alsa-hda-realtek-headphone-mic-can-t-record-after-s3.patch alsa-usb-audio-fix-parse-of-uac2-extension-units.patch block-bfq-null-out-the-bic-when-it-s-no-longer-valid.patch block-fix-.bi_size-overflow.patch documentation-add-section-about-cpu-vulnerabilities-for-spectre.patch documentation-admin-remove-the-vsyscall-native-documentation.patch fscrypt-don-t-set-policy-for-a-dead-directory.patch media-stv0297-fix-frequency-range-limit.patch perf-auxtrace-fix-itrace-defaults-for-perf-script.patch perf-header-assign-proper-ff-ph-in-perf_event__synthesize_features.patch perf-intel-pt-fix-itrace-defaults-for-perf-script-intel-pt-documentation.patch perf-intel-pt-fix-itrace-defaults-for-perf-script.patch perf-pmu-fix-uncore-pmu-alias-list-for-arm64.patch perf-thread-stack-fix-thread-stack-return-from-kernel-for-kernel-only-case.patch tpm-actually-fail-on-tpm-errors-during-get-random.patch tpm-fix-tpm-1.2-shutdown-sequence-to-prevent-future-tpm-operations.patch udf-fix-incorrect-final-not_allocated-hole-extent-length.patch x86-ptrace-fix-possible-spectre-v1-in-ptrace_get_debugreg.patch x86-tls-fix-possible-spectre-v1-in-do_get_thread_area.patch --- diff --git a/queue-5.2/alsa-hda-realtek-headphone-mic-can-t-record-after-s3.patch b/queue-5.2/alsa-hda-realtek-headphone-mic-can-t-record-after-s3.patch new file mode 100644 index 00000000000..1295bdef2a4 --- /dev/null +++ b/queue-5.2/alsa-hda-realtek-headphone-mic-can-t-record-after-s3.patch @@ -0,0 +1,43 @@ +From d07a9a4f66e944fcc900812cbc2f6817bde6a43d Mon Sep 17 00:00:00 2001 +From: Kailang Yang +Date: Thu, 4 Jul 2019 16:02:10 +0800 +Subject: ALSA: hda/realtek - Headphone Mic can't record after S3 + +From: Kailang Yang + +commit d07a9a4f66e944fcc900812cbc2f6817bde6a43d upstream. + +Dell headset mode platform with ALC236. +It doesn't recording after system resume from S3. +S3 mode was deep. s2idle was not has this issue. +S3 deep will cut of codec power. So, the register will back to default +after resume back. +This patch will solve this issue. + +Signed-off-by: Kailang Yang +Cc: +Signed-off-by: Takashi Iwai +Signed-off-by: Greg Kroah-Hartman + +--- + sound/pci/hda/patch_realtek.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/sound/pci/hda/patch_realtek.c ++++ b/sound/pci/hda/patch_realtek.c +@@ -3255,6 +3255,7 @@ static void alc256_init(struct hda_codec + alc_update_coefex_idx(codec, 0x57, 0x04, 0x0007, 0x4); /* Hight power */ + alc_update_coefex_idx(codec, 0x53, 0x02, 0x8000, 1 << 15); /* Clear bit */ + alc_update_coefex_idx(codec, 0x53, 0x02, 0x8000, 0 << 15); ++ alc_update_coef_idx(codec, 0x36, 1 << 13, 1 << 5); /* Switch pcbeep path to Line in path*/ + } + + static void alc256_shutup(struct hda_codec *codec) +@@ -7825,7 +7826,6 @@ static int patch_alc269(struct hda_codec + spec->shutup = alc256_shutup; + spec->init_hook = alc256_init; + spec->gen.mixer_nid = 0; /* ALC256 does not have any loopback mixer path */ +- alc_update_coef_idx(codec, 0x36, 1 << 13, 1 << 5); /* Switch pcbeep path to Line in path*/ + break; + case 0x10ec0257: + spec->codec_variant = ALC269_TYPE_ALC257; diff --git a/queue-5.2/alsa-usb-audio-fix-parse-of-uac2-extension-units.patch b/queue-5.2/alsa-usb-audio-fix-parse-of-uac2-extension-units.patch new file mode 100644 index 00000000000..bed299d6ef1 --- /dev/null +++ b/queue-5.2/alsa-usb-audio-fix-parse-of-uac2-extension-units.patch @@ -0,0 +1,133 @@ +From ca95c7bf3d29716916baccdc77c3c2284b703069 Mon Sep 17 00:00:00 2001 +From: Takashi Iwai +Date: Thu, 4 Jul 2019 16:31:12 +0200 +Subject: ALSA: usb-audio: Fix parse of UAC2 Extension Units + +From: Takashi Iwai + +commit ca95c7bf3d29716916baccdc77c3c2284b703069 upstream. + +Extension Unit (XU) is used to have a compatible layout with +Processing Unit (PU) on UAC1, and the usb-audio driver code assumed it +for parsing the descriptors. Meanwhile, on UAC2, XU became slightly +incompatible with PU; namely, XU has a one-byte bmControls bitmap +while PU has two bytes bmControls bitmap. This incompatibility +results in the read of a wrong address for the last iExtension field, +which ended up with an incorrect string for the mixer element name, as +recently reported for Focusrite Scarlett 18i20 device. + +This patch corrects this misalignment by introducing a couple of new +macros and calling them depending on the descriptor type. + +Fixes: 23caaf19b11e ("ALSA: usb-mixer: Add support for Audio Class v2.0") +Reported-by: Stefan Sauer +Cc: +Signed-off-by: Takashi Iwai +Signed-off-by: Greg Kroah-Hartman + +--- + include/uapi/linux/usb/audio.h | 37 +++++++++++++++++++++++++++++++++++++ + sound/usb/mixer.c | 16 ++++++++++------ + 2 files changed, 47 insertions(+), 6 deletions(-) + +--- a/include/uapi/linux/usb/audio.h ++++ b/include/uapi/linux/usb/audio.h +@@ -450,6 +450,43 @@ static inline __u8 *uac_processing_unit_ + } + } + ++/* ++ * Extension Unit (XU) has almost compatible layout with Processing Unit, but ++ * on UAC2, it has a different bmControls size (bControlSize); it's 1 byte for ++ * XU while 2 bytes for PU. The last iExtension field is a one-byte index as ++ * well as iProcessing field of PU. ++ */ ++static inline __u8 uac_extension_unit_bControlSize(struct uac_processing_unit_descriptor *desc, ++ int protocol) ++{ ++ switch (protocol) { ++ case UAC_VERSION_1: ++ return desc->baSourceID[desc->bNrInPins + 4]; ++ case UAC_VERSION_2: ++ return 1; /* in UAC2, this value is constant */ ++ case UAC_VERSION_3: ++ return 4; /* in UAC3, this value is constant */ ++ default: ++ return 1; ++ } ++} ++ ++static inline __u8 uac_extension_unit_iExtension(struct uac_processing_unit_descriptor *desc, ++ int protocol) ++{ ++ __u8 control_size = uac_extension_unit_bControlSize(desc, protocol); ++ ++ switch (protocol) { ++ case UAC_VERSION_1: ++ case UAC_VERSION_2: ++ default: ++ return *(uac_processing_unit_bmControls(desc, protocol) ++ + control_size); ++ case UAC_VERSION_3: ++ return 0; /* UAC3 does not have this field */ ++ } ++} ++ + /* 4.5.2 Class-Specific AS Interface Descriptor */ + struct uac1_as_header_descriptor { + __u8 bLength; /* in bytes: 7 */ +--- a/sound/usb/mixer.c ++++ b/sound/usb/mixer.c +@@ -2303,7 +2303,7 @@ static struct procunit_info extunits[] = + */ + static int build_audio_procunit(struct mixer_build *state, int unitid, + void *raw_desc, struct procunit_info *list, +- char *name) ++ bool extension_unit) + { + struct uac_processing_unit_descriptor *desc = raw_desc; + int num_ins; +@@ -2320,6 +2320,8 @@ static int build_audio_procunit(struct m + static struct procunit_info default_info = { + 0, NULL, default_value_info + }; ++ const char *name = extension_unit ? ++ "Extension Unit" : "Processing Unit"; + + if (desc->bLength < 13) { + usb_audio_err(state->chip, "invalid %s descriptor (id %d)\n", name, unitid); +@@ -2433,7 +2435,10 @@ static int build_audio_procunit(struct m + } else if (info->name) { + strlcpy(kctl->id.name, info->name, sizeof(kctl->id.name)); + } else { +- nameid = uac_processing_unit_iProcessing(desc, state->mixer->protocol); ++ if (extension_unit) ++ nameid = uac_extension_unit_iExtension(desc, state->mixer->protocol); ++ else ++ nameid = uac_processing_unit_iProcessing(desc, state->mixer->protocol); + len = 0; + if (nameid) + len = snd_usb_copy_string_desc(state->chip, +@@ -2466,10 +2471,10 @@ static int parse_audio_processing_unit(s + case UAC_VERSION_2: + default: + return build_audio_procunit(state, unitid, raw_desc, +- procunits, "Processing Unit"); ++ procunits, false); + case UAC_VERSION_3: + return build_audio_procunit(state, unitid, raw_desc, +- uac3_procunits, "Processing Unit"); ++ uac3_procunits, false); + } + } + +@@ -2480,8 +2485,7 @@ static int parse_audio_extension_unit(st + * Note that we parse extension units with processing unit descriptors. + * That's ok as the layout is the same. + */ +- return build_audio_procunit(state, unitid, raw_desc, +- extunits, "Extension Unit"); ++ return build_audio_procunit(state, unitid, raw_desc, extunits, true); + } + + /* diff --git a/queue-5.2/block-bfq-null-out-the-bic-when-it-s-no-longer-valid.patch b/queue-5.2/block-bfq-null-out-the-bic-when-it-s-no-longer-valid.patch new file mode 100644 index 00000000000..81768c56407 --- /dev/null +++ b/queue-5.2/block-bfq-null-out-the-bic-when-it-s-no-longer-valid.patch @@ -0,0 +1,78 @@ +From dbc3117d4ca9e17819ac73501e914b8422686750 Mon Sep 17 00:00:00 2001 +From: Douglas Anderson +Date: Thu, 27 Jun 2019 21:44:09 -0700 +Subject: block, bfq: NULL out the bic when it's no longer valid + +From: Douglas Anderson + +commit dbc3117d4ca9e17819ac73501e914b8422686750 upstream. + +In reboot tests on several devices we were seeing a "use after free" +when slub_debug or KASAN was enabled. The kernel complained about: + + Unable to handle kernel paging request at virtual address 6b6b6c2b + +...which is a classic sign of use after free under slub_debug. The +stack crawl in kgdb looked like: + + 0 test_bit (addr=, nr=) + 1 bfq_bfqq_busy (bfqq=) + 2 bfq_select_queue (bfqd=) + 3 __bfq_dispatch_request (hctx=) + 4 bfq_dispatch_request (hctx=) + 5 0xc056ef00 in blk_mq_do_dispatch_sched (hctx=0xed249440) + 6 0xc056f728 in blk_mq_sched_dispatch_requests (hctx=0xed249440) + 7 0xc0568d24 in __blk_mq_run_hw_queue (hctx=0xed249440) + 8 0xc0568d94 in blk_mq_run_work_fn (work=) + 9 0xc024c5c4 in process_one_work (worker=0xec6d4640, work=0xed249480) + 10 0xc024cff4 in worker_thread (__worker=0xec6d4640) + +Digging in kgdb, it could be found that, though bfqq looked fine, +bfqq->bic had been freed. + +Through further digging, I postulated that perhaps it is illegal to +access a "bic" (AKA an "icq") after bfq_exit_icq() had been called +because the "bic" can be freed at some point in time after this call +is made. I confirmed that there certainly were cases where the exact +crashing code path would access the "bic" after bfq_exit_icq() had +been called. Sspecifically I set the "bfqq->bic" to (void *)0x7 and +saw that the bic was 0x7 at the time of the crash. + +To understand a bit more about why this crash was fairly uncommon (I +saw it only once in a few hundred reboots), you can see that much of +the time bfq_exit_icq_fbqq() fully frees the bfqq and thus it can't +access the ->bic anymore. The only case it doesn't is if +bfq_put_queue() sees a reference still held. + +However, even in the case when bfqq isn't freed, the crash is still +rare. Why? I tracked what happened to the "bic" after the exit +routine. It doesn't get freed right away. Rather, +put_io_context_active() eventually called put_io_context() which +queued up freeing on a workqueue. The freeing then actually happened +later than that through call_rcu(). Despite all these delays, some +extra debugging showed that all the hoops could be jumped through in +time and the memory could be freed causing the original crash. Phew! + +To make a long story short, assuming it truly is illegal to access an +icq after the "exit_icq" callback is finished, this patch is needed. + +Cc: stable@vger.kernel.org +Reviewed-by: Paolo Valente +Signed-off-by: Douglas Anderson +Signed-off-by: Jens Axboe +Signed-off-by: Greg Kroah-Hartman + +--- + block/bfq-iosched.c | 1 + + 1 file changed, 1 insertion(+) + +--- a/block/bfq-iosched.c ++++ b/block/bfq-iosched.c +@@ -4584,6 +4584,7 @@ static void bfq_exit_icq_bfqq(struct bfq + unsigned long flags; + + spin_lock_irqsave(&bfqd->lock, flags); ++ bfqq->bic = NULL; + bfq_exit_bfqq(bfqd, bfqq); + bic_set_bfqq(bic, NULL, is_sync); + spin_unlock_irqrestore(&bfqd->lock, flags); diff --git a/queue-5.2/block-fix-.bi_size-overflow.patch b/queue-5.2/block-fix-.bi_size-overflow.patch new file mode 100644 index 00000000000..1768c05f005 --- /dev/null +++ b/queue-5.2/block-fix-.bi_size-overflow.patch @@ -0,0 +1,140 @@ +From 79d08f89bb1b5c2c1ff90d9bb95497ab9e8aa7e0 Mon Sep 17 00:00:00 2001 +From: Ming Lei +Date: Mon, 1 Jul 2019 15:14:46 +0800 +Subject: block: fix .bi_size overflow + +From: Ming Lei + +commit 79d08f89bb1b5c2c1ff90d9bb95497ab9e8aa7e0 upstream. + +'bio->bi_iter.bi_size' is 'unsigned int', which at most hold 4G - 1 +bytes. + +Before 07173c3ec276 ("block: enable multipage bvecs"), one bio can +include very limited pages, and usually at most 256, so the fs bio +size won't be bigger than 1M bytes most of times. + +Since we support multi-page bvec, in theory one fs bio really can +be added > 1M pages, especially in case of hugepage, or big writeback +with too many dirty pages. Then there is chance in which .bi_size +is overflowed. + +Fixes this issue by using bio_full() to check if the added segment may +overflow .bi_size. + +Cc: Liu Yiding +Cc: kernel test robot +Cc: "Darrick J. Wong" +Cc: linux-xfs@vger.kernel.org +Cc: linux-fsdevel@vger.kernel.org +Cc: stable@vger.kernel.org +Fixes: 07173c3ec276 ("block: enable multipage bvecs") +Reviewed-by: Christoph Hellwig +Signed-off-by: Ming Lei +Signed-off-by: Jens Axboe +Signed-off-by: Greg Kroah-Hartman + +--- + block/bio.c | 10 +++++----- + fs/iomap.c | 2 +- + fs/xfs/xfs_aops.c | 2 +- + include/linux/bio.h | 18 ++++++++++++++++-- + 4 files changed, 23 insertions(+), 9 deletions(-) + +--- a/block/bio.c ++++ b/block/bio.c +@@ -731,7 +731,7 @@ static int __bio_add_pc_page(struct requ + } + } + +- if (bio_full(bio)) ++ if (bio_full(bio, len)) + return 0; + + if (bio->bi_phys_segments >= queue_max_segments(q)) +@@ -807,7 +807,7 @@ void __bio_add_page(struct bio *bio, str + struct bio_vec *bv = &bio->bi_io_vec[bio->bi_vcnt]; + + WARN_ON_ONCE(bio_flagged(bio, BIO_CLONED)); +- WARN_ON_ONCE(bio_full(bio)); ++ WARN_ON_ONCE(bio_full(bio, len)); + + bv->bv_page = page; + bv->bv_offset = off; +@@ -834,7 +834,7 @@ int bio_add_page(struct bio *bio, struct + bool same_page = false; + + if (!__bio_try_merge_page(bio, page, len, offset, &same_page)) { +- if (bio_full(bio)) ++ if (bio_full(bio, len)) + return 0; + __bio_add_page(bio, page, len, offset); + } +@@ -922,7 +922,7 @@ static int __bio_iov_iter_get_pages(stru + if (same_page) + put_page(page); + } else { +- if (WARN_ON_ONCE(bio_full(bio))) ++ if (WARN_ON_ONCE(bio_full(bio, len))) + return -EINVAL; + __bio_add_page(bio, page, len, offset); + } +@@ -966,7 +966,7 @@ int bio_iov_iter_get_pages(struct bio *b + ret = __bio_iov_bvec_add_pages(bio, iter); + else + ret = __bio_iov_iter_get_pages(bio, iter); +- } while (!ret && iov_iter_count(iter) && !bio_full(bio)); ++ } while (!ret && iov_iter_count(iter) && !bio_full(bio, 0)); + + if (iov_iter_bvec_no_ref(iter)) + bio_set_flag(bio, BIO_NO_PAGE_REF); +--- a/fs/iomap.c ++++ b/fs/iomap.c +@@ -333,7 +333,7 @@ iomap_readpage_actor(struct inode *inode + if (iop) + atomic_inc(&iop->read_count); + +- if (!ctx->bio || !is_contig || bio_full(ctx->bio)) { ++ if (!ctx->bio || !is_contig || bio_full(ctx->bio, plen)) { + gfp_t gfp = mapping_gfp_constraint(page->mapping, GFP_KERNEL); + int nr_vecs = (length + PAGE_SIZE - 1) >> PAGE_SHIFT; + +--- a/fs/xfs/xfs_aops.c ++++ b/fs/xfs/xfs_aops.c +@@ -782,7 +782,7 @@ xfs_add_to_ioend( + atomic_inc(&iop->write_count); + + if (!merged) { +- if (bio_full(wpc->ioend->io_bio)) ++ if (bio_full(wpc->ioend->io_bio, len)) + xfs_chain_bio(wpc->ioend, wbc, bdev, sector); + bio_add_page(wpc->ioend->io_bio, page, len, poff); + } +--- a/include/linux/bio.h ++++ b/include/linux/bio.h +@@ -102,9 +102,23 @@ static inline void *bio_data(struct bio + return NULL; + } + +-static inline bool bio_full(struct bio *bio) ++/** ++ * bio_full - check if the bio is full ++ * @bio: bio to check ++ * @len: length of one segment to be added ++ * ++ * Return true if @bio is full and one segment with @len bytes can't be ++ * added to the bio, otherwise return false ++ */ ++static inline bool bio_full(struct bio *bio, unsigned len) + { +- return bio->bi_vcnt >= bio->bi_max_vecs; ++ if (bio->bi_vcnt >= bio->bi_max_vecs) ++ return true; ++ ++ if (bio->bi_iter.bi_size > UINT_MAX - len) ++ return true; ++ ++ return false; + } + + static inline bool bio_next_segment(const struct bio *bio, diff --git a/queue-5.2/documentation-add-section-about-cpu-vulnerabilities-for-spectre.patch b/queue-5.2/documentation-add-section-about-cpu-vulnerabilities-for-spectre.patch new file mode 100644 index 00000000000..a14100ad9a8 --- /dev/null +++ b/queue-5.2/documentation-add-section-about-cpu-vulnerabilities-for-spectre.patch @@ -0,0 +1,752 @@ +From 6e88559470f581741bcd0f2794f9054814ac9740 Mon Sep 17 00:00:00 2001 +From: Tim Chen +Date: Thu, 20 Jun 2019 16:10:50 -0700 +Subject: Documentation: Add section about CPU vulnerabilities for Spectre + +From: Tim Chen + +commit 6e88559470f581741bcd0f2794f9054814ac9740 upstream. + +Add documentation for Spectre vulnerability and the mitigation mechanisms: + +- Explain the problem and risks +- Document the mitigation mechanisms +- Document the command line controls +- Document the sysfs files + +Co-developed-by: Andi Kleen +Signed-off-by: Andi Kleen +Co-developed-by: Tim Chen +Signed-off-by: Tim Chen +Reviewed-by: Randy Dunlap +Reviewed-by: Thomas Gleixner +Cc: stable@vger.kernel.org +Signed-off-by: Jonathan Corbet +Signed-off-by: Greg Kroah-Hartman + +--- + Documentation/admin-guide/hw-vuln/index.rst | 1 + Documentation/admin-guide/hw-vuln/spectre.rst | 697 ++++++++++++++++++++++++++ + Documentation/userspace-api/spec_ctrl.rst | 2 + 3 files changed, 700 insertions(+) + +--- a/Documentation/admin-guide/hw-vuln/index.rst ++++ b/Documentation/admin-guide/hw-vuln/index.rst +@@ -9,5 +9,6 @@ are configurable at compile, boot or run + .. toctree:: + :maxdepth: 1 + ++ spectre + l1tf + mds +--- /dev/null ++++ b/Documentation/admin-guide/hw-vuln/spectre.rst +@@ -0,0 +1,697 @@ ++.. SPDX-License-Identifier: GPL-2.0 ++ ++Spectre Side Channels ++===================== ++ ++Spectre is a class of side channel attacks that exploit branch prediction ++and speculative execution on modern CPUs to read memory, possibly ++bypassing access controls. Speculative execution side channel exploits ++do not modify memory but attempt to infer privileged data in the memory. ++ ++This document covers Spectre variant 1 and Spectre variant 2. ++ ++Affected processors ++------------------- ++ ++Speculative execution side channel methods affect a wide range of modern ++high performance processors, since most modern high speed processors ++use branch prediction and speculative execution. ++ ++The following CPUs are vulnerable: ++ ++ - Intel Core, Atom, Pentium, and Xeon processors ++ ++ - AMD Phenom, EPYC, and Zen processors ++ ++ - IBM POWER and zSeries processors ++ ++ - Higher end ARM processors ++ ++ - Apple CPUs ++ ++ - Higher end MIPS CPUs ++ ++ - Likely most other high performance CPUs. Contact your CPU vendor for details. ++ ++Whether a processor is affected or not can be read out from the Spectre ++vulnerability files in sysfs. See :ref:`spectre_sys_info`. ++ ++Related CVEs ++------------ ++ ++The following CVE entries describe Spectre variants: ++ ++ ============= ======================= ================= ++ CVE-2017-5753 Bounds check bypass Spectre variant 1 ++ CVE-2017-5715 Branch target injection Spectre variant 2 ++ ============= ======================= ================= ++ ++Problem ++------- ++ ++CPUs use speculative operations to improve performance. That may leave ++traces of memory accesses or computations in the processor's caches, ++buffers, and branch predictors. Malicious software may be able to ++influence the speculative execution paths, and then use the side effects ++of the speculative execution in the CPUs' caches and buffers to infer ++privileged data touched during the speculative execution. ++ ++Spectre variant 1 attacks take advantage of speculative execution of ++conditional branches, while Spectre variant 2 attacks use speculative ++execution of indirect branches to leak privileged memory. ++See :ref:`[1] ` :ref:`[5] ` :ref:`[7] ` ++:ref:`[10] ` :ref:`[11] `. ++ ++Spectre variant 1 (Bounds Check Bypass) ++--------------------------------------- ++ ++The bounds check bypass attack :ref:`[2] ` takes advantage ++of speculative execution that bypasses conditional branch instructions ++used for memory access bounds check (e.g. checking if the index of an ++array results in memory access within a valid range). This results in ++memory accesses to invalid memory (with out-of-bound index) that are ++done speculatively before validation checks resolve. Such speculative ++memory accesses can leave side effects, creating side channels which ++leak information to the attacker. ++ ++There are some extensions of Spectre variant 1 attacks for reading data ++over the network, see :ref:`[12] `. However such attacks ++are difficult, low bandwidth, fragile, and are considered low risk. ++ ++Spectre variant 2 (Branch Target Injection) ++------------------------------------------- ++ ++The branch target injection attack takes advantage of speculative ++execution of indirect branches :ref:`[3] `. The indirect ++branch predictors inside the processor used to guess the target of ++indirect branches can be influenced by an attacker, causing gadget code ++to be speculatively executed, thus exposing sensitive data touched by ++the victim. The side effects left in the CPU's caches during speculative ++execution can be measured to infer data values. ++ ++.. _poison_btb: ++ ++In Spectre variant 2 attacks, the attacker can steer speculative indirect ++branches in the victim to gadget code by poisoning the branch target ++buffer of a CPU used for predicting indirect branch addresses. Such ++poisoning could be done by indirect branching into existing code, ++with the address offset of the indirect branch under the attacker's ++control. Since the branch prediction on impacted hardware does not ++fully disambiguate branch address and uses the offset for prediction, ++this could cause privileged code's indirect branch to jump to a gadget ++code with the same offset. ++ ++The most useful gadgets take an attacker-controlled input parameter (such ++as a register value) so that the memory read can be controlled. Gadgets ++without input parameters might be possible, but the attacker would have ++very little control over what memory can be read, reducing the risk of ++the attack revealing useful data. ++ ++One other variant 2 attack vector is for the attacker to poison the ++return stack buffer (RSB) :ref:`[13] ` to cause speculative ++subroutine return instruction execution to go to a gadget. An attacker's ++imbalanced subroutine call instructions might "poison" entries in the ++return stack buffer which are later consumed by a victim's subroutine ++return instructions. This attack can be mitigated by flushing the return ++stack buffer on context switch, or virtual machine (VM) exit. ++ ++On systems with simultaneous multi-threading (SMT), attacks are possible ++from the sibling thread, as level 1 cache and branch target buffer ++(BTB) may be shared between hardware threads in a CPU core. A malicious ++program running on the sibling thread may influence its peer's BTB to ++steer its indirect branch speculations to gadget code, and measure the ++speculative execution's side effects left in level 1 cache to infer the ++victim's data. ++ ++Attack scenarios ++---------------- ++ ++The following list of attack scenarios have been anticipated, but may ++not cover all possible attack vectors. ++ ++1. A user process attacking the kernel ++^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ++ ++ The attacker passes a parameter to the kernel via a register or ++ via a known address in memory during a syscall. Such parameter may ++ be used later by the kernel as an index to an array or to derive ++ a pointer for a Spectre variant 1 attack. The index or pointer ++ is invalid, but bound checks are bypassed in the code branch taken ++ for speculative execution. This could cause privileged memory to be ++ accessed and leaked. ++ ++ For kernel code that has been identified where data pointers could ++ potentially be influenced for Spectre attacks, new "nospec" accessor ++ macros are used to prevent speculative loading of data. ++ ++ Spectre variant 2 attacker can :ref:`poison ` the branch ++ target buffer (BTB) before issuing syscall to launch an attack. ++ After entering the kernel, the kernel could use the poisoned branch ++ target buffer on indirect jump and jump to gadget code in speculative ++ execution. ++ ++ If an attacker tries to control the memory addresses leaked during ++ speculative execution, he would also need to pass a parameter to the ++ gadget, either through a register or a known address in memory. After ++ the gadget has executed, he can measure the side effect. ++ ++ The kernel can protect itself against consuming poisoned branch ++ target buffer entries by using return trampolines (also known as ++ "retpoline") :ref:`[3] ` :ref:`[9] ` for all ++ indirect branches. Return trampolines trap speculative execution paths ++ to prevent jumping to gadget code during speculative execution. ++ x86 CPUs with Enhanced Indirect Branch Restricted Speculation ++ (Enhanced IBRS) available in hardware should use the feature to ++ mitigate Spectre variant 2 instead of retpoline. Enhanced IBRS is ++ more efficient than retpoline. ++ ++ There may be gadget code in firmware which could be exploited with ++ Spectre variant 2 attack by a rogue user process. To mitigate such ++ attacks on x86, Indirect Branch Restricted Speculation (IBRS) feature ++ is turned on before the kernel invokes any firmware code. ++ ++2. A user process attacking another user process ++^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ++ ++ A malicious user process can try to attack another user process, ++ either via a context switch on the same hardware thread, or from the ++ sibling hyperthread sharing a physical processor core on simultaneous ++ multi-threading (SMT) system. ++ ++ Spectre variant 1 attacks generally require passing parameters ++ between the processes, which needs a data passing relationship, such ++ as remote procedure calls (RPC). Those parameters are used in gadget ++ code to derive invalid data pointers accessing privileged memory in ++ the attacked process. ++ ++ Spectre variant 2 attacks can be launched from a rogue process by ++ :ref:`poisoning ` the branch target buffer. This can ++ influence the indirect branch targets for a victim process that either ++ runs later on the same hardware thread, or running concurrently on ++ a sibling hardware thread sharing the same physical core. ++ ++ A user process can protect itself against Spectre variant 2 attacks ++ by using the prctl() syscall to disable indirect branch speculation ++ for itself. An administrator can also cordon off an unsafe process ++ from polluting the branch target buffer by disabling the process's ++ indirect branch speculation. This comes with a performance cost ++ from not using indirect branch speculation and clearing the branch ++ target buffer. When SMT is enabled on x86, for a process that has ++ indirect branch speculation disabled, Single Threaded Indirect Branch ++ Predictors (STIBP) :ref:`[4] ` are turned on to prevent the ++ sibling thread from controlling branch target buffer. In addition, ++ the Indirect Branch Prediction Barrier (IBPB) is issued to clear the ++ branch target buffer when context switching to and from such process. ++ ++ On x86, the return stack buffer is stuffed on context switch. ++ This prevents the branch target buffer from being used for branch ++ prediction when the return stack buffer underflows while switching to ++ a deeper call stack. Any poisoned entries in the return stack buffer ++ left by the previous process will also be cleared. ++ ++ User programs should use address space randomization to make attacks ++ more difficult (Set /proc/sys/kernel/randomize_va_space = 1 or 2). ++ ++3. A virtualized guest attacking the host ++^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ++ ++ The attack mechanism is similar to how user processes attack the ++ kernel. The kernel is entered via hyper-calls or other virtualization ++ exit paths. ++ ++ For Spectre variant 1 attacks, rogue guests can pass parameters ++ (e.g. in registers) via hyper-calls to derive invalid pointers to ++ speculate into privileged memory after entering the kernel. For places ++ where such kernel code has been identified, nospec accessor macros ++ are used to stop speculative memory access. ++ ++ For Spectre variant 2 attacks, rogue guests can :ref:`poison ++ ` the branch target buffer or return stack buffer, causing ++ the kernel to jump to gadget code in the speculative execution paths. ++ ++ To mitigate variant 2, the host kernel can use return trampolines ++ for indirect branches to bypass the poisoned branch target buffer, ++ and flushing the return stack buffer on VM exit. This prevents rogue ++ guests from affecting indirect branching in the host kernel. ++ ++ To protect host processes from rogue guests, host processes can have ++ indirect branch speculation disabled via prctl(). The branch target ++ buffer is cleared before context switching to such processes. ++ ++4. A virtualized guest attacking other guest ++^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ++ ++ A rogue guest may attack another guest to get data accessible by the ++ other guest. ++ ++ Spectre variant 1 attacks are possible if parameters can be passed ++ between guests. This may be done via mechanisms such as shared memory ++ or message passing. Such parameters could be used to derive data ++ pointers to privileged data in guest. The privileged data could be ++ accessed by gadget code in the victim's speculation paths. ++ ++ Spectre variant 2 attacks can be launched from a rogue guest by ++ :ref:`poisoning ` the branch target buffer or the return ++ stack buffer. Such poisoned entries could be used to influence ++ speculation execution paths in the victim guest. ++ ++ Linux kernel mitigates attacks to other guests running in the same ++ CPU hardware thread by flushing the return stack buffer on VM exit, ++ and clearing the branch target buffer before switching to a new guest. ++ ++ If SMT is used, Spectre variant 2 attacks from an untrusted guest ++ in the sibling hyperthread can be mitigated by the administrator, ++ by turning off the unsafe guest's indirect branch speculation via ++ prctl(). A guest can also protect itself by turning on microcode ++ based mitigations (such as IBPB or STIBP on x86) within the guest. ++ ++.. _spectre_sys_info: ++ ++Spectre system information ++-------------------------- ++ ++The Linux kernel provides a sysfs interface to enumerate the current ++mitigation status of the system for Spectre: whether the system is ++vulnerable, and which mitigations are active. ++ ++The sysfs file showing Spectre variant 1 mitigation status is: ++ ++ /sys/devices/system/cpu/vulnerabilities/spectre_v1 ++ ++The possible values in this file are: ++ ++ ======================================= ================================= ++ 'Mitigation: __user pointer sanitation' Protection in kernel on a case by ++ case base with explicit pointer ++ sanitation. ++ ======================================= ================================= ++ ++However, the protections are put in place on a case by case basis, ++and there is no guarantee that all possible attack vectors for Spectre ++variant 1 are covered. ++ ++The spectre_v2 kernel file reports if the kernel has been compiled with ++retpoline mitigation or if the CPU has hardware mitigation, and if the ++CPU has support for additional process-specific mitigation. ++ ++This file also reports CPU features enabled by microcode to mitigate ++attack between user processes: ++ ++1. Indirect Branch Prediction Barrier (IBPB) to add additional ++ isolation between processes of different users. ++2. Single Thread Indirect Branch Predictors (STIBP) to add additional ++ isolation between CPU threads running on the same core. ++ ++These CPU features may impact performance when used and can be enabled ++per process on a case-by-case base. ++ ++The sysfs file showing Spectre variant 2 mitigation status is: ++ ++ /sys/devices/system/cpu/vulnerabilities/spectre_v2 ++ ++The possible values in this file are: ++ ++ - Kernel status: ++ ++ ==================================== ================================= ++ 'Not affected' The processor is not vulnerable ++ 'Vulnerable' Vulnerable, no mitigation ++ 'Mitigation: Full generic retpoline' Software-focused mitigation ++ 'Mitigation: Full AMD retpoline' AMD-specific software mitigation ++ 'Mitigation: Enhanced IBRS' Hardware-focused mitigation ++ ==================================== ================================= ++ ++ - Firmware status: Show if Indirect Branch Restricted Speculation (IBRS) is ++ used to protect against Spectre variant 2 attacks when calling firmware (x86 only). ++ ++ ========== ============================================================= ++ 'IBRS_FW' Protection against user program attacks when calling firmware ++ ========== ============================================================= ++ ++ - Indirect branch prediction barrier (IBPB) status for protection between ++ processes of different users. This feature can be controlled through ++ prctl() per process, or through kernel command line options. This is ++ an x86 only feature. For more details see below. ++ ++ =================== ======================================================== ++ 'IBPB: disabled' IBPB unused ++ 'IBPB: always-on' Use IBPB on all tasks ++ 'IBPB: conditional' Use IBPB on SECCOMP or indirect branch restricted tasks ++ =================== ======================================================== ++ ++ - Single threaded indirect branch prediction (STIBP) status for protection ++ between different hyper threads. This feature can be controlled through ++ prctl per process, or through kernel command line options. This is x86 ++ only feature. For more details see below. ++ ++ ==================== ======================================================== ++ 'STIBP: disabled' STIBP unused ++ 'STIBP: forced' Use STIBP on all tasks ++ 'STIBP: conditional' Use STIBP on SECCOMP or indirect branch restricted tasks ++ ==================== ======================================================== ++ ++ - Return stack buffer (RSB) protection status: ++ ++ ============= =========================================== ++ 'RSB filling' Protection of RSB on context switch enabled ++ ============= =========================================== ++ ++Full mitigation might require a microcode update from the CPU ++vendor. When the necessary microcode is not available, the kernel will ++report vulnerability. ++ ++Turning on mitigation for Spectre variant 1 and Spectre variant 2 ++----------------------------------------------------------------- ++ ++1. Kernel mitigation ++^^^^^^^^^^^^^^^^^^^^ ++ ++ For the Spectre variant 1, vulnerable kernel code (as determined ++ by code audit or scanning tools) is annotated on a case by case ++ basis to use nospec accessor macros for bounds clipping :ref:`[2] ++ ` to avoid any usable disclosure gadgets. However, it may ++ not cover all attack vectors for Spectre variant 1. ++ ++ For Spectre variant 2 mitigation, the compiler turns indirect calls or ++ jumps in the kernel into equivalent return trampolines (retpolines) ++ :ref:`[3] ` :ref:`[9] ` to go to the target ++ addresses. Speculative execution paths under retpolines are trapped ++ in an infinite loop to prevent any speculative execution jumping to ++ a gadget. ++ ++ To turn on retpoline mitigation on a vulnerable CPU, the kernel ++ needs to be compiled with a gcc compiler that supports the ++ -mindirect-branch=thunk-extern -mindirect-branch-register options. ++ If the kernel is compiled with a Clang compiler, the compiler needs ++ to support -mretpoline-external-thunk option. The kernel config ++ CONFIG_RETPOLINE needs to be turned on, and the CPU needs to run with ++ the latest updated microcode. ++ ++ On Intel Skylake-era systems the mitigation covers most, but not all, ++ cases. See :ref:`[3] ` for more details. ++ ++ On CPUs with hardware mitigation for Spectre variant 2 (e.g. Enhanced ++ IBRS on x86), retpoline is automatically disabled at run time. ++ ++ The retpoline mitigation is turned on by default on vulnerable ++ CPUs. It can be forced on or off by the administrator ++ via the kernel command line and sysfs control files. See ++ :ref:`spectre_mitigation_control_command_line`. ++ ++ On x86, indirect branch restricted speculation is turned on by default ++ before invoking any firmware code to prevent Spectre variant 2 exploits ++ using the firmware. ++ ++ Using kernel address space randomization (CONFIG_RANDOMIZE_SLAB=y ++ and CONFIG_SLAB_FREELIST_RANDOM=y in the kernel configuration) makes ++ attacks on the kernel generally more difficult. ++ ++2. User program mitigation ++^^^^^^^^^^^^^^^^^^^^^^^^^^ ++ ++ User programs can mitigate Spectre variant 1 using LFENCE or "bounds ++ clipping". For more details see :ref:`[2] `. ++ ++ For Spectre variant 2 mitigation, individual user programs ++ can be compiled with return trampolines for indirect branches. ++ This protects them from consuming poisoned entries in the branch ++ target buffer left by malicious software. Alternatively, the ++ programs can disable their indirect branch speculation via prctl() ++ (See :ref:`Documentation/userspace-api/spec_ctrl.rst `). ++ On x86, this will turn on STIBP to guard against attacks from the ++ sibling thread when the user program is running, and use IBPB to ++ flush the branch target buffer when switching to/from the program. ++ ++ Restricting indirect branch speculation on a user program will ++ also prevent the program from launching a variant 2 attack ++ on x86. All sand-boxed SECCOMP programs have indirect branch ++ speculation restricted by default. Administrators can change ++ that behavior via the kernel command line and sysfs control files. ++ See :ref:`spectre_mitigation_control_command_line`. ++ ++ Programs that disable their indirect branch speculation will have ++ more overhead and run slower. ++ ++ User programs should use address space randomization ++ (/proc/sys/kernel/randomize_va_space = 1 or 2) to make attacks more ++ difficult. ++ ++3. VM mitigation ++^^^^^^^^^^^^^^^^ ++ ++ Within the kernel, Spectre variant 1 attacks from rogue guests are ++ mitigated on a case by case basis in VM exit paths. Vulnerable code ++ uses nospec accessor macros for "bounds clipping", to avoid any ++ usable disclosure gadgets. However, this may not cover all variant ++ 1 attack vectors. ++ ++ For Spectre variant 2 attacks from rogue guests to the kernel, the ++ Linux kernel uses retpoline or Enhanced IBRS to prevent consumption of ++ poisoned entries in branch target buffer left by rogue guests. It also ++ flushes the return stack buffer on every VM exit to prevent a return ++ stack buffer underflow so poisoned branch target buffer could be used, ++ or attacker guests leaving poisoned entries in the return stack buffer. ++ ++ To mitigate guest-to-guest attacks in the same CPU hardware thread, ++ the branch target buffer is sanitized by flushing before switching ++ to a new guest on a CPU. ++ ++ The above mitigations are turned on by default on vulnerable CPUs. ++ ++ To mitigate guest-to-guest attacks from sibling thread when SMT is ++ in use, an untrusted guest running in the sibling thread can have ++ its indirect branch speculation disabled by administrator via prctl(). ++ ++ The kernel also allows guests to use any microcode based mitigation ++ they choose to use (such as IBPB or STIBP on x86) to protect themselves. ++ ++.. _spectre_mitigation_control_command_line: ++ ++Mitigation control on the kernel command line ++--------------------------------------------- ++ ++Spectre variant 2 mitigation can be disabled or force enabled at the ++kernel command line. ++ ++ nospectre_v2 ++ ++ [X86] Disable all mitigations for the Spectre variant 2 ++ (indirect branch prediction) vulnerability. System may ++ allow data leaks with this option, which is equivalent ++ to spectre_v2=off. ++ ++ ++ spectre_v2= ++ ++ [X86] Control mitigation of Spectre variant 2 ++ (indirect branch speculation) vulnerability. ++ The default operation protects the kernel from ++ user space attacks. ++ ++ on ++ unconditionally enable, implies ++ spectre_v2_user=on ++ off ++ unconditionally disable, implies ++ spectre_v2_user=off ++ auto ++ kernel detects whether your CPU model is ++ vulnerable ++ ++ Selecting 'on' will, and 'auto' may, choose a ++ mitigation method at run time according to the ++ CPU, the available microcode, the setting of the ++ CONFIG_RETPOLINE configuration option, and the ++ compiler with which the kernel was built. ++ ++ Selecting 'on' will also enable the mitigation ++ against user space to user space task attacks. ++ ++ Selecting 'off' will disable both the kernel and ++ the user space protections. ++ ++ Specific mitigations can also be selected manually: ++ ++ retpoline ++ replace indirect branches ++ retpoline,generic ++ google's original retpoline ++ retpoline,amd ++ AMD-specific minimal thunk ++ ++ Not specifying this option is equivalent to ++ spectre_v2=auto. ++ ++For user space mitigation: ++ ++ spectre_v2_user= ++ ++ [X86] Control mitigation of Spectre variant 2 ++ (indirect branch speculation) vulnerability between ++ user space tasks ++ ++ on ++ Unconditionally enable mitigations. Is ++ enforced by spectre_v2=on ++ ++ off ++ Unconditionally disable mitigations. Is ++ enforced by spectre_v2=off ++ ++ prctl ++ Indirect branch speculation is enabled, ++ but mitigation can be enabled via prctl ++ per thread. The mitigation control state ++ is inherited on fork. ++ ++ prctl,ibpb ++ Like "prctl" above, but only STIBP is ++ controlled per thread. IBPB is issued ++ always when switching between different user ++ space processes. ++ ++ seccomp ++ Same as "prctl" above, but all seccomp ++ threads will enable the mitigation unless ++ they explicitly opt out. ++ ++ seccomp,ibpb ++ Like "seccomp" above, but only STIBP is ++ controlled per thread. IBPB is issued ++ always when switching between different ++ user space processes. ++ ++ auto ++ Kernel selects the mitigation depending on ++ the available CPU features and vulnerability. ++ ++ Default mitigation: ++ If CONFIG_SECCOMP=y then "seccomp", otherwise "prctl" ++ ++ Not specifying this option is equivalent to ++ spectre_v2_user=auto. ++ ++ In general the kernel by default selects ++ reasonable mitigations for the current CPU. To ++ disable Spectre variant 2 mitigations, boot with ++ spectre_v2=off. Spectre variant 1 mitigations ++ cannot be disabled. ++ ++Mitigation selection guide ++-------------------------- ++ ++1. Trusted userspace ++^^^^^^^^^^^^^^^^^^^^ ++ ++ If all userspace applications are from trusted sources and do not ++ execute externally supplied untrusted code, then the mitigations can ++ be disabled. ++ ++2. Protect sensitive programs ++^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ++ ++ For security-sensitive programs that have secrets (e.g. crypto ++ keys), protection against Spectre variant 2 can be put in place by ++ disabling indirect branch speculation when the program is running ++ (See :ref:`Documentation/userspace-api/spec_ctrl.rst `). ++ ++3. Sandbox untrusted programs ++^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ++ ++ Untrusted programs that could be a source of attacks can be cordoned ++ off by disabling their indirect branch speculation when they are run ++ (See :ref:`Documentation/userspace-api/spec_ctrl.rst `). ++ This prevents untrusted programs from polluting the branch target ++ buffer. All programs running in SECCOMP sandboxes have indirect ++ branch speculation restricted by default. This behavior can be ++ changed via the kernel command line and sysfs control files. See ++ :ref:`spectre_mitigation_control_command_line`. ++ ++3. High security mode ++^^^^^^^^^^^^^^^^^^^^^ ++ ++ All Spectre variant 2 mitigations can be forced on ++ at boot time for all programs (See the "on" option in ++ :ref:`spectre_mitigation_control_command_line`). This will add ++ overhead as indirect branch speculations for all programs will be ++ restricted. ++ ++ On x86, branch target buffer will be flushed with IBPB when switching ++ to a new program. STIBP is left on all the time to protect programs ++ against variant 2 attacks originating from programs running on ++ sibling threads. ++ ++ Alternatively, STIBP can be used only when running programs ++ whose indirect branch speculation is explicitly disabled, ++ while IBPB is still used all the time when switching to a new ++ program to clear the branch target buffer (See "ibpb" option in ++ :ref:`spectre_mitigation_control_command_line`). This "ibpb" option ++ has less performance cost than the "on" option, which leaves STIBP ++ on all the time. ++ ++References on Spectre ++--------------------- ++ ++Intel white papers: ++ ++.. _spec_ref1: ++ ++[1] `Intel analysis of speculative execution side channels `_. ++ ++.. _spec_ref2: ++ ++[2] `Bounds check bypass `_. ++ ++.. _spec_ref3: ++ ++[3] `Deep dive: Retpoline: A branch target injection mitigation `_. ++ ++.. _spec_ref4: ++ ++[4] `Deep Dive: Single Thread Indirect Branch Predictors `_. ++ ++AMD white papers: ++ ++.. _spec_ref5: ++ ++[5] `AMD64 technology indirect branch control extension `_. ++ ++.. _spec_ref6: ++ ++[6] `Software techniques for managing speculation on AMD processors `_. ++ ++ARM white papers: ++ ++.. _spec_ref7: ++ ++[7] `Cache speculation side-channels `_. ++ ++.. _spec_ref8: ++ ++[8] `Cache speculation issues update `_. ++ ++Google white paper: ++ ++.. _spec_ref9: ++ ++[9] `Retpoline: a software construct for preventing branch-target-injection `_. ++ ++MIPS white paper: ++ ++.. _spec_ref10: ++ ++[10] `MIPS: response on speculative execution and side channel vulnerabilities `_. ++ ++Academic papers: ++ ++.. _spec_ref11: ++ ++[11] `Spectre Attacks: Exploiting Speculative Execution `_. ++ ++.. _spec_ref12: ++ ++[12] `NetSpectre: Read Arbitrary Memory over Network `_. ++ ++.. _spec_ref13: ++ ++[13] `Spectre Returns! Speculation Attacks using the Return Stack Buffer `_. +--- a/Documentation/userspace-api/spec_ctrl.rst ++++ b/Documentation/userspace-api/spec_ctrl.rst +@@ -49,6 +49,8 @@ If PR_SPEC_PRCTL is set, then the per-ta + available. If not set, prctl(PR_SET_SPECULATION_CTRL) for the speculation + misfeature will fail. + ++.. _set_spec_ctrl: ++ + PR_SET_SPECULATION_CTRL + ----------------------- + diff --git a/queue-5.2/documentation-admin-remove-the-vsyscall-native-documentation.patch b/queue-5.2/documentation-admin-remove-the-vsyscall-native-documentation.patch new file mode 100644 index 00000000000..41fb44fecce --- /dev/null +++ b/queue-5.2/documentation-admin-remove-the-vsyscall-native-documentation.patch @@ -0,0 +1,43 @@ +From d974ffcfb7447db5f29a4b662a3eaf99a4e1109e Mon Sep 17 00:00:00 2001 +From: Andy Lutomirski +Date: Wed, 26 Jun 2019 21:45:02 -0700 +Subject: Documentation/admin: Remove the vsyscall=native documentation + +From: Andy Lutomirski + +commit d974ffcfb7447db5f29a4b662a3eaf99a4e1109e upstream. + +The vsyscall=native feature is gone -- remove the docs. + +Fixes: 076ca272a14c ("x86/vsyscall/64: Drop "native" vsyscalls") +Signed-off-by: Andy Lutomirski +Signed-off-by: Thomas Gleixner +Acked-by: Kees Cook +Cc: Florian Weimer +Cc: Jann Horn +Cc: stable@vger.kernel.org +Cc: Borislav Petkov +Cc: Kernel Hardening +Cc: Peter Zijlstra +Link: https://lkml.kernel.org/r/d77c7105eb4c57c1a95a95b6a5b8ba194a18e764.1561610354.git.luto@kernel.org +Signed-off-by: Greg Kroah-Hartman + +--- + Documentation/admin-guide/kernel-parameters.txt | 6 ------ + 1 file changed, 6 deletions(-) + +--- a/Documentation/admin-guide/kernel-parameters.txt ++++ b/Documentation/admin-guide/kernel-parameters.txt +@@ -5102,12 +5102,6 @@ + emulate [default] Vsyscalls turn into traps and are + emulated reasonably safely. + +- native Vsyscalls are native syscall instructions. +- This is a little bit faster than trapping +- and makes a few dynamic recompilers work +- better than they would in emulation mode. +- It also makes exploits much easier to write. +- + none Vsyscalls don't work at all. This makes + them quite hard to use for exploits but + might break your system. diff --git a/queue-5.2/fscrypt-don-t-set-policy-for-a-dead-directory.patch b/queue-5.2/fscrypt-don-t-set-policy-for-a-dead-directory.patch new file mode 100644 index 00000000000..c6fe2cccc09 --- /dev/null +++ b/queue-5.2/fscrypt-don-t-set-policy-for-a-dead-directory.patch @@ -0,0 +1,40 @@ +From 5858bdad4d0d0fc18bf29f34c3ac836e0b59441f Mon Sep 17 00:00:00 2001 +From: Hongjie Fang +Date: Wed, 22 May 2019 10:02:53 +0800 +Subject: fscrypt: don't set policy for a dead directory + +From: Hongjie Fang + +commit 5858bdad4d0d0fc18bf29f34c3ac836e0b59441f upstream. + +The directory may have been removed when entering +fscrypt_ioctl_set_policy(). If so, the empty_dir() check will return +error for ext4 file system. + +ext4_rmdir() sets i_size = 0, then ext4_empty_dir() reports an error +because 'inode->i_size < EXT4_DIR_REC_LEN(1) + EXT4_DIR_REC_LEN(2)'. If +the fs is mounted with errors=panic, it will trigger a panic issue. + +Add the check IS_DEADDIR() to fix this problem. + +Fixes: 9bd8212f981e ("ext4 crypto: add encryption policy and password salt support") +Cc: # v4.1+ +Signed-off-by: Hongjie Fang +Signed-off-by: Eric Biggers +Signed-off-by: Greg Kroah-Hartman + +--- + fs/crypto/policy.c | 2 ++ + 1 file changed, 2 insertions(+) + +--- a/fs/crypto/policy.c ++++ b/fs/crypto/policy.c +@@ -81,6 +81,8 @@ int fscrypt_ioctl_set_policy(struct file + if (ret == -ENODATA) { + if (!S_ISDIR(inode->i_mode)) + ret = -ENOTDIR; ++ else if (IS_DEADDIR(inode)) ++ ret = -ENOENT; + else if (!inode->i_sb->s_cop->empty_dir(inode)) + ret = -ENOTEMPTY; + else diff --git a/queue-5.2/media-stv0297-fix-frequency-range-limit.patch b/queue-5.2/media-stv0297-fix-frequency-range-limit.patch new file mode 100644 index 00000000000..c9f4c4e2258 --- /dev/null +++ b/queue-5.2/media-stv0297-fix-frequency-range-limit.patch @@ -0,0 +1,41 @@ +From b09a2ab2baeb36bf7ef7780405ad172281741c7c Mon Sep 17 00:00:00 2001 +From: Mauro Carvalho Chehab +Date: Tue, 25 Jun 2019 06:45:20 -0400 +Subject: media: stv0297: fix frequency range limit +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +From: Mauro Carvalho Chehab + +commit b09a2ab2baeb36bf7ef7780405ad172281741c7c upstream. + +There was a typo at the lower frequency limit for a DVB-C +card, causing the driver to fail while tuning channels at the +VHF range. + +https://bugzilla.kernel.org/show_bug.cgi?id=202083 + +Fixes: f1b1eabff0eb ("media: dvb: represent min/max/step/tolerance freqs in Hz") +Reported-by: Ari Kohtamäki +Cc: stable@vger.kernel.org +Signed-off-by: Mauro Carvalho Chehab +Signed-off-by: Sean Young +Signed-off-by: Mauro Carvalho Chehab +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/media/dvb-frontends/stv0297.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/drivers/media/dvb-frontends/stv0297.c ++++ b/drivers/media/dvb-frontends/stv0297.c +@@ -682,7 +682,7 @@ static const struct dvb_frontend_ops stv + .delsys = { SYS_DVBC_ANNEX_A }, + .info = { + .name = "ST STV0297 DVB-C", +- .frequency_min_hz = 470 * MHz, ++ .frequency_min_hz = 47 * MHz, + .frequency_max_hz = 862 * MHz, + .frequency_stepsize_hz = 62500, + .symbol_rate_min = 870000, diff --git a/queue-5.2/perf-auxtrace-fix-itrace-defaults-for-perf-script.patch b/queue-5.2/perf-auxtrace-fix-itrace-defaults-for-perf-script.patch new file mode 100644 index 00000000000..ee03317c2d0 --- /dev/null +++ b/queue-5.2/perf-auxtrace-fix-itrace-defaults-for-perf-script.patch @@ -0,0 +1,55 @@ +From 355200e0f6a9ce14771625014aa469f5ecbd8977 Mon Sep 17 00:00:00 2001 +From: Adrian Hunter +Date: Mon, 20 May 2019 14:37:08 +0300 +Subject: perf auxtrace: Fix itrace defaults for perf script + +From: Adrian Hunter + +commit 355200e0f6a9ce14771625014aa469f5ecbd8977 upstream. + +Commit 4eb068157121 ("perf script: Make itrace script default to all +calls") does not work for the case when '--itrace' only is used, because +default_no_sample is not being passed. + +Example: + + Before: + + $ perf record -e intel_pt/cyc/u ls + $ perf script --itrace > cmp1.txt + $ perf script --itrace=cepwx > cmp2.txt + $ diff -sq cmp1.txt cmp2.txt + Files cmp1.txt and cmp2.txt differ + + After: + + $ perf script --itrace > cmp1.txt + $ perf script --itrace=cepwx > cmp2.txt + $ diff -sq cmp1.txt cmp2.txt + Files cmp1.txt and cmp2.txt are identical + +Signed-off-by: Adrian Hunter +Tested-by: Arnaldo Carvalho de Melo +Cc: Jiri Olsa +Cc: stable@vger.kernel.org +Fixes: 4eb068157121 ("perf script: Make itrace script default to all calls") +Link: http://lkml.kernel.org/r/20190520113728.14389-3-adrian.hunter@intel.com +Signed-off-by: Arnaldo Carvalho de Melo +Signed-off-by: Greg Kroah-Hartman + +--- + tools/perf/util/auxtrace.c | 3 ++- + 1 file changed, 2 insertions(+), 1 deletion(-) + +--- a/tools/perf/util/auxtrace.c ++++ b/tools/perf/util/auxtrace.c +@@ -1001,7 +1001,8 @@ int itrace_parse_synth_opts(const struct + } + + if (!str) { +- itrace_synth_opts__set_default(synth_opts, false); ++ itrace_synth_opts__set_default(synth_opts, ++ synth_opts->default_no_sample); + return 0; + } + diff --git a/queue-5.2/perf-header-assign-proper-ff-ph-in-perf_event__synthesize_features.patch b/queue-5.2/perf-header-assign-proper-ff-ph-in-perf_event__synthesize_features.patch new file mode 100644 index 00000000000..0b664f32adc --- /dev/null +++ b/queue-5.2/perf-header-assign-proper-ff-ph-in-perf_event__synthesize_features.patch @@ -0,0 +1,69 @@ +From c952b35f4b15dd1b83e952718dec3307256383ef Mon Sep 17 00:00:00 2001 +From: Song Liu +Date: Wed, 19 Jun 2019 18:04:53 -0700 +Subject: perf header: Assign proper ff->ph in perf_event__synthesize_features() + +From: Song Liu + +commit c952b35f4b15dd1b83e952718dec3307256383ef upstream. + +bpf/btf write_* functions need ff->ph->env. + +With this missing, pipe-mode (perf record -o -) would crash like: + +Program terminated with signal SIGSEGV, Segmentation fault. + +This patch assign proper ph value to ff. + +Committer testing: + + (gdb) run record -o - + Starting program: /root/bin/perf record -o - + PERFILE2 + + Thread 1 "perf" received signal SIGSEGV, Segmentation fault. + __do_write_buf (size=4, buf=0x160, ff=0x7fffffff8f80) at util/header.c:126 + 126 memcpy(ff->buf + ff->offset, buf, size); + (gdb) bt + #0 __do_write_buf (size=4, buf=0x160, ff=0x7fffffff8f80) at util/header.c:126 + #1 do_write (ff=ff@entry=0x7fffffff8f80, buf=buf@entry=0x160, size=4) at util/header.c:137 + #2 0x00000000004eddba in write_bpf_prog_info (ff=0x7fffffff8f80, evlist=) at util/header.c:912 + #3 0x00000000004f69d7 in perf_event__synthesize_features (tool=tool@entry=0x97cc00 , session=session@entry=0x7fffe9c6d010, + evlist=0x7fffe9cae010, process=process@entry=0x4435d0 ) at util/header.c:3695 + #4 0x0000000000443c79 in record__synthesize (tail=tail@entry=false, rec=0x97cc00 ) at builtin-record.c:1214 + #5 0x0000000000444ec9 in __cmd_record (rec=0x97cc00 , argv=, argc=0) at builtin-record.c:1435 + #6 cmd_record (argc=0, argv=) at builtin-record.c:2450 + #7 0x00000000004ae3e9 in run_builtin (p=p@entry=0x98e058 , argc=argc@entry=3, argv=0x7fffffffd670) at perf.c:304 + #8 0x000000000042eded in handle_internal_command (argv=, argc=) at perf.c:356 + #9 run_argv (argcp=, argv=) at perf.c:400 + #10 main (argc=3, argv=) at perf.c:522 + (gdb) + +After the patch the SEGSEGV is gone. + +Reported-by: David Carrillo Cisneros +Signed-off-by: Song Liu +Tested-by: Arnaldo Carvalho de Melo +Cc: Jiri Olsa +Cc: Namhyung Kim +Cc: kernel-team@fb.com +Cc: stable@vger.kernel.org # v5.1+ +Fixes: 606f972b1361 ("perf bpf: Save bpf_prog_info information as headers to perf.data") +Link: http://lkml.kernel.org/r/20190620010453.4118689-1-songliubraving@fb.com +Signed-off-by: Arnaldo Carvalho de Melo +Signed-off-by: Greg Kroah-Hartman + +--- + tools/perf/util/header.c | 1 + + 1 file changed, 1 insertion(+) + +--- a/tools/perf/util/header.c ++++ b/tools/perf/util/header.c +@@ -3602,6 +3602,7 @@ int perf_event__synthesize_features(stru + return -ENOMEM; + + ff.size = sz - sz_hdr; ++ ff.ph = &session->header; + + for_each_set_bit(feat, header->adds_features, HEADER_FEAT_BITS) { + if (!feat_ops[feat].synthesize) { diff --git a/queue-5.2/perf-intel-pt-fix-itrace-defaults-for-perf-script-intel-pt-documentation.patch b/queue-5.2/perf-intel-pt-fix-itrace-defaults-for-perf-script-intel-pt-documentation.patch new file mode 100644 index 00000000000..dff0397fbb1 --- /dev/null +++ b/queue-5.2/perf-intel-pt-fix-itrace-defaults-for-perf-script-intel-pt-documentation.patch @@ -0,0 +1,56 @@ +From a2d8a1585e35444789c1c8cf7e2e51fb15589880 Mon Sep 17 00:00:00 2001 +From: Adrian Hunter +Date: Mon, 20 May 2019 14:37:09 +0300 +Subject: perf intel-pt: Fix itrace defaults for perf script intel-pt documentation + +From: Adrian Hunter + +commit a2d8a1585e35444789c1c8cf7e2e51fb15589880 upstream. + +Fix intel-pt documentation to reflect the change of itrace defaults for +perf script. + +Signed-off-by: Adrian Hunter +Cc: Jiri Olsa +Cc: stable@vger.kernel.org +Fixes: 4eb068157121 ("perf script: Make itrace script default to all calls") +Link: http://lkml.kernel.org/r/20190520113728.14389-4-adrian.hunter@intel.com +Signed-off-by: Arnaldo Carvalho de Melo +Signed-off-by: Greg Kroah-Hartman + +--- + tools/perf/Documentation/intel-pt.txt | 10 +++++----- + 1 file changed, 5 insertions(+), 5 deletions(-) + +--- a/tools/perf/Documentation/intel-pt.txt ++++ b/tools/perf/Documentation/intel-pt.txt +@@ -88,16 +88,16 @@ smaller. + + To represent software control flow, "branches" samples are produced. By default + a branch sample is synthesized for every single branch. To get an idea what +-data is available you can use the 'perf script' tool with no parameters, which +-will list all the samples. ++data is available you can use the 'perf script' tool with all itrace sampling ++options, which will list all the samples. + + perf record -e intel_pt//u ls +- perf script ++ perf script --itrace=ibxwpe + + An interesting field that is not printed by default is 'flags' which can be + displayed as follows: + +- perf script -Fcomm,tid,pid,time,cpu,event,trace,ip,sym,dso,addr,symoff,flags ++ perf script --itrace=ibxwpe -F+flags + + The flags are "bcrosyiABEx" which stand for branch, call, return, conditional, + system, asynchronous, interrupt, transaction abort, trace begin, trace end, and +@@ -713,7 +713,7 @@ Having no option is the same as + + which, in turn, is the same as + +- --itrace=ibxwpe ++ --itrace=cepwx + + The letters are: + diff --git a/queue-5.2/perf-intel-pt-fix-itrace-defaults-for-perf-script.patch b/queue-5.2/perf-intel-pt-fix-itrace-defaults-for-perf-script.patch new file mode 100644 index 00000000000..f378589ce8f --- /dev/null +++ b/queue-5.2/perf-intel-pt-fix-itrace-defaults-for-perf-script.patch @@ -0,0 +1,59 @@ +From 26f19c2eb7e54015564ff133b91983a74e84541b Mon Sep 17 00:00:00 2001 +From: Adrian Hunter +Date: Mon, 20 May 2019 14:37:07 +0300 +Subject: perf intel-pt: Fix itrace defaults for perf script + +From: Adrian Hunter + +commit 26f19c2eb7e54015564ff133b91983a74e84541b upstream. + +Commit 4eb068157121 ("perf script: Make itrace script default to all +calls") does not work because 'use_browser' is being used to determine +whether to default to periodic sampling (i.e. better for perf report). +The result is that nothing but CBR events display for perf script when +no --itrace option is specified. + +Fix by using 'default_no_sample' and 'inject' instead. + +Example: + + Before: + + $ perf record -e intel_pt/cyc/u ls + $ perf script > cmp1.txt + $ perf script --itrace=cepwx > cmp2.txt + $ diff -sq cmp1.txt cmp2.txt + Files cmp1.txt and cmp2.txt differ + + After: + + $ perf script > cmp1.txt + $ perf script --itrace=cepwx > cmp2.txt + $ diff -sq cmp1.txt cmp2.txt + Files cmp1.txt and cmp2.txt are identical + +Signed-off-by: Adrian Hunter +Tested-by: Arnaldo Carvalho de Melo +Cc: Jiri Olsa +Cc: stable@vger.kernel.org # v4.20+ +Fixes: 90e457f7be08 ("perf tools: Add Intel PT support") +Link: http://lkml.kernel.org/r/20190520113728.14389-2-adrian.hunter@intel.com +Signed-off-by: Arnaldo Carvalho de Melo +Signed-off-by: Greg Kroah-Hartman + +--- + tools/perf/util/intel-pt.c | 3 ++- + 1 file changed, 2 insertions(+), 1 deletion(-) + +--- a/tools/perf/util/intel-pt.c ++++ b/tools/perf/util/intel-pt.c +@@ -2579,7 +2579,8 @@ int intel_pt_process_auxtrace_info(union + } else { + itrace_synth_opts__set_default(&pt->synth_opts, + session->itrace_synth_opts->default_no_sample); +- if (use_browser != -1) { ++ if (!session->itrace_synth_opts->default_no_sample && ++ !session->itrace_synth_opts->inject) { + pt->synth_opts.branches = false; + pt->synth_opts.callchain = true; + } diff --git a/queue-5.2/perf-pmu-fix-uncore-pmu-alias-list-for-arm64.patch b/queue-5.2/perf-pmu-fix-uncore-pmu-alias-list-for-arm64.patch new file mode 100644 index 00000000000..485b36f56d3 --- /dev/null +++ b/queue-5.2/perf-pmu-fix-uncore-pmu-alias-list-for-arm64.patch @@ -0,0 +1,94 @@ +From 599ee18f0740d7661b8711249096db94c09bc508 Mon Sep 17 00:00:00 2001 +From: John Garry +Date: Fri, 14 Jun 2019 22:07:59 +0800 +Subject: perf pmu: Fix uncore PMU alias list for ARM64 + +From: John Garry + +commit 599ee18f0740d7661b8711249096db94c09bc508 upstream. + +In commit 292c34c10249 ("perf pmu: Fix core PMU alias list for X86 +platform"), we fixed the issue of CPU events being aliased to uncore +events. + +Fix this same issue for ARM64, since the said commit left the (broken) +behaviour untouched for ARM64. + +Signed-off-by: John Garry +Cc: Alexander Shishkin +Cc: Ben Hutchings +Cc: Hendrik Brueckner +Cc: Jiri Olsa +Cc: Kan Liang +Cc: Mark Rutland +Cc: Mathieu Poirier +Cc: Namhyung Kim +Cc: Peter Zijlstra +Cc: Shaokun Zhang +Cc: Thomas Richter +Cc: Will Deacon +Cc: linux-arm-kernel@lists.infradead.org +Cc: linuxarm@huawei.com +Cc: stable@vger.kernel.org +Fixes: 292c34c10249 ("perf pmu: Fix core PMU alias list for X86 platform") +Link: http://lkml.kernel.org/r/1560521283-73314-2-git-send-email-john.garry@huawei.com +Signed-off-by: Arnaldo Carvalho de Melo +Signed-off-by: Greg Kroah-Hartman + +--- + tools/perf/util/pmu.c | 28 ++++++++++++---------------- + 1 file changed, 12 insertions(+), 16 deletions(-) + +--- a/tools/perf/util/pmu.c ++++ b/tools/perf/util/pmu.c +@@ -709,9 +709,7 @@ static void pmu_add_cpu_aliases(struct l + { + int i; + struct pmu_events_map *map; +- struct pmu_event *pe; + const char *name = pmu->name; +- const char *pname; + + map = perf_pmu__find_map(pmu); + if (!map) +@@ -722,28 +720,26 @@ static void pmu_add_cpu_aliases(struct l + */ + i = 0; + while (1) { ++ const char *cpu_name = is_arm_pmu_core(name) ? name : "cpu"; ++ struct pmu_event *pe = &map->table[i++]; ++ const char *pname = pe->pmu ? pe->pmu : cpu_name; + +- pe = &map->table[i++]; + if (!pe->name) { + if (pe->metric_group || pe->metric_name) + continue; + break; + } + +- if (!is_arm_pmu_core(name)) { +- pname = pe->pmu ? pe->pmu : "cpu"; ++ /* ++ * uncore alias may be from different PMU ++ * with common prefix ++ */ ++ if (pmu_is_uncore(name) && ++ !strncmp(pname, name, strlen(pname))) ++ goto new_alias; + +- /* +- * uncore alias may be from different PMU +- * with common prefix +- */ +- if (pmu_is_uncore(name) && +- !strncmp(pname, name, strlen(pname))) +- goto new_alias; +- +- if (strcmp(pname, name)) +- continue; +- } ++ if (strcmp(pname, name)) ++ continue; + + new_alias: + /* need type casts to override 'const' */ diff --git a/queue-5.2/perf-thread-stack-fix-thread-stack-return-from-kernel-for-kernel-only-case.patch b/queue-5.2/perf-thread-stack-fix-thread-stack-return-from-kernel-for-kernel-only-case.patch new file mode 100644 index 00000000000..e8d2e65a21c --- /dev/null +++ b/queue-5.2/perf-thread-stack-fix-thread-stack-return-from-kernel-for-kernel-only-case.patch @@ -0,0 +1,187 @@ +From 97860b483c5597663a174ff7405be957b4838391 Mon Sep 17 00:00:00 2001 +From: Adrian Hunter +Date: Wed, 19 Jun 2019 09:44:28 +0300 +Subject: perf thread-stack: Fix thread stack return from kernel for kernel-only case +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +From: Adrian Hunter + +commit 97860b483c5597663a174ff7405be957b4838391 upstream. + +Commit f08046cb3082 ("perf thread-stack: Represent jmps to the start of a +different symbol") had the side-effect of introducing more stack entries +before return from kernel space. + +When user space is also traced, those entries are popped before entry to +user space, but when user space is not traced, they get stuck at the +bottom of the stack, making the stack grow progressively larger. + +Fix by detecting a return-from-kernel branch type, and popping kernel +addresses from the stack then. + +Note, the problem and fix affect the exported Call Graph / Tree but not +the callindent option used by "perf script --call-trace". + +Example: + + perf-with-kcore record example -e intel_pt//k -- ls + perf-with-kcore script example --itrace=bep -s ~/libexec/perf-core/scripts/python/export-to-sqlite.py example.db branches calls + ~/libexec/perf-core/scripts/python/exported-sql-viewer.py example.db + + Menu option: Reports -> Context-Sensitive Call Graph + + Before: (showing Call Path column only) + + Call Path + ▶ perf + ▼ ls + ▼ 12111:12111 + ▶ setup_new_exec + ▶ __task_pid_nr_ns + ▶ perf_event_pid_type + ▶ perf_event_comm_output + ▶ perf_iterate_ctx + ▶ perf_iterate_sb + ▶ perf_event_comm + ▶ __set_task_comm + ▶ load_elf_binary + ▶ search_binary_handler + ▶ __do_execve_file.isra.41 + ▶ __x64_sys_execve + ▶ do_syscall_64 + ▼ entry_SYSCALL_64_after_hwframe + ▼ swapgs_restore_regs_and_return_to_usermode + ▼ native_iret + ▶ error_entry + ▶ do_page_fault + ▼ error_exit + ▼ retint_user + ▶ prepare_exit_to_usermode + ▼ native_iret + ▶ error_entry + ▶ do_page_fault + ▼ error_exit + ▼ retint_user + ▶ prepare_exit_to_usermode + ▼ native_iret + ▶ error_entry + ▶ do_page_fault + ▼ error_exit + ▼ retint_user + ▶ prepare_exit_to_usermode + ▶ native_iret + + After: (showing Call Path column only) + + Call Path + ▶ perf + ▼ ls + ▼ 12111:12111 + ▶ setup_new_exec + ▶ __task_pid_nr_ns + ▶ perf_event_pid_type + ▶ perf_event_comm_output + ▶ perf_iterate_ctx + ▶ perf_iterate_sb + ▶ perf_event_comm + ▶ __set_task_comm + ▶ load_elf_binary + ▶ search_binary_handler + ▶ __do_execve_file.isra.41 + ▶ __x64_sys_execve + ▶ do_syscall_64 + ▶ entry_SYSCALL_64_after_hwframe + ▶ page_fault + ▼ entry_SYSCALL_64 + ▼ do_syscall_64 + ▶ __x64_sys_brk + ▶ __x64_sys_access + ▶ __x64_sys_openat + ▶ __x64_sys_newfstat + ▶ __x64_sys_mmap + ▶ __x64_sys_close + ▶ __x64_sys_read + ▶ __x64_sys_mprotect + ▶ __x64_sys_arch_prctl + ▶ __x64_sys_munmap + ▶ exit_to_usermode_loop + ▶ __x64_sys_set_tid_address + ▶ __x64_sys_set_robust_list + ▶ __x64_sys_rt_sigaction + ▶ __x64_sys_rt_sigprocmask + ▶ __x64_sys_prlimit64 + ▶ __x64_sys_statfs + ▶ __x64_sys_ioctl + ▶ __x64_sys_getdents64 + ▶ __x64_sys_write + ▶ __x64_sys_exit_group + +Committer notes: + +The first arg to the perf-with-kcore needs to be the same for the +'record' and 'script' lines, otherwise we'll record the perf.data file +and kcore_dir/ files in one directory ('example') to then try to use it +from the 'bep' directory, fix the instructions above it so that both use +'example'. + +Signed-off-by: Adrian Hunter +Tested-by: Arnaldo Carvalho de Melo +Cc: Jiri Olsa +Cc: stable@vger.kernel.org +Fixes: f08046cb3082 ("perf thread-stack: Represent jmps to the start of a different symbol") +Link: http://lkml.kernel.org/r/20190619064429.14940-2-adrian.hunter@intel.com +Signed-off-by: Arnaldo Carvalho de Melo +Signed-off-by: Greg Kroah-Hartman + +--- + tools/perf/util/thread-stack.c | 30 +++++++++++++++++++++++++++++- + 1 file changed, 29 insertions(+), 1 deletion(-) + +--- a/tools/perf/util/thread-stack.c ++++ b/tools/perf/util/thread-stack.c +@@ -616,6 +616,23 @@ static int thread_stack__bottom(struct t + true, false); + } + ++static int thread_stack__pop_ks(struct thread *thread, struct thread_stack *ts, ++ struct perf_sample *sample, u64 ref) ++{ ++ u64 tm = sample->time; ++ int err; ++ ++ /* Return to userspace, so pop all kernel addresses */ ++ while (thread_stack__in_kernel(ts)) { ++ err = thread_stack__call_return(thread, ts, --ts->cnt, ++ tm, ref, true); ++ if (err) ++ return err; ++ } ++ ++ return 0; ++} ++ + static int thread_stack__no_call_return(struct thread *thread, + struct thread_stack *ts, + struct perf_sample *sample, +@@ -896,7 +913,18 @@ int thread_stack__process(struct thread + ts->rstate = X86_RETPOLINE_DETECTED; + + } else if (sample->flags & PERF_IP_FLAG_RETURN) { +- if (!sample->ip || !sample->addr) ++ if (!sample->addr) { ++ u32 return_from_kernel = PERF_IP_FLAG_SYSCALLRET | ++ PERF_IP_FLAG_INTERRUPT; ++ ++ if (!(sample->flags & return_from_kernel)) ++ return 0; ++ ++ /* Pop kernel stack */ ++ return thread_stack__pop_ks(thread, ts, sample, ref); ++ } ++ ++ if (!sample->ip) + return 0; + + /* x86 retpoline 'return' doesn't match the stack */ diff --git a/queue-5.2/series b/queue-5.2/series index acdc05d8cda..6145b4fc016 100644 --- a/queue-5.2/series +++ b/queue-5.2/series @@ -1,3 +1,22 @@ crypto-talitos-fix-hash-on-sec1.patch crypto-lrw-use-correct-alignmask.patch crypto-talitos-rename-alternative-aead-algos.patch +fscrypt-don-t-set-policy-for-a-dead-directory.patch +udf-fix-incorrect-final-not_allocated-hole-extent-length.patch +media-stv0297-fix-frequency-range-limit.patch +alsa-usb-audio-fix-parse-of-uac2-extension-units.patch +alsa-hda-realtek-headphone-mic-can-t-record-after-s3.patch +tpm-actually-fail-on-tpm-errors-during-get-random.patch +tpm-fix-tpm-1.2-shutdown-sequence-to-prevent-future-tpm-operations.patch +block-fix-.bi_size-overflow.patch +block-bfq-null-out-the-bic-when-it-s-no-longer-valid.patch +perf-intel-pt-fix-itrace-defaults-for-perf-script.patch +perf-auxtrace-fix-itrace-defaults-for-perf-script.patch +perf-intel-pt-fix-itrace-defaults-for-perf-script-intel-pt-documentation.patch +perf-pmu-fix-uncore-pmu-alias-list-for-arm64.patch +perf-thread-stack-fix-thread-stack-return-from-kernel-for-kernel-only-case.patch +perf-header-assign-proper-ff-ph-in-perf_event__synthesize_features.patch +x86-ptrace-fix-possible-spectre-v1-in-ptrace_get_debugreg.patch +x86-tls-fix-possible-spectre-v1-in-do_get_thread_area.patch +documentation-add-section-about-cpu-vulnerabilities-for-spectre.patch +documentation-admin-remove-the-vsyscall-native-documentation.patch diff --git a/queue-5.2/tpm-actually-fail-on-tpm-errors-during-get-random.patch b/queue-5.2/tpm-actually-fail-on-tpm-errors-during-get-random.patch new file mode 100644 index 00000000000..1fe9c043b4d --- /dev/null +++ b/queue-5.2/tpm-actually-fail-on-tpm-errors-during-get-random.patch @@ -0,0 +1,88 @@ +From 782779b60faa2fc7ff609ac8ef938260fd792c0f Mon Sep 17 00:00:00 2001 +From: Kees Cook +Date: Mon, 1 Apr 2019 12:06:07 -0700 +Subject: tpm: Actually fail on TPM errors during "get random" + +From: Kees Cook + +commit 782779b60faa2fc7ff609ac8ef938260fd792c0f upstream. + +A "get random" may fail with a TPM error, but those codes were returned +as-is to the caller, which assumed the result was the number of bytes +that had been written to the target buffer, which could lead to a kernel +heap memory exposure and over-read. + +This fixes tpm1_get_random() to mask positive TPM errors into -EIO, as +before. + +[ 18.092103] tpm tpm0: A TPM error (379) occurred attempting get random +[ 18.092106] usercopy: Kernel memory exposure attempt detected from SLUB object 'kmalloc-64' (offset 0, size 379)! + +Link: https://bugzilla.redhat.com/show_bug.cgi?id=1650989 +Reported-by: Phil Baker +Reported-by: Craig Robson +Fixes: 7aee9c52d7ac ("tpm: tpm1: rewrite tpm1_get_random() using tpm_buf structure") +Cc: Laura Abbott +Cc: Tomas Winkler +Cc: Jarkko Sakkinen +Cc: stable@vger.kernel.org +Signed-off-by: Kees Cook +Reviewed-by: Tomas Winkler +Tested-by: Bartosz Szczepanek +Reviewed-by: Jarkko Sakkinen +Signed-off-by: Jarkko Sakkinen +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/char/tpm/tpm1-cmd.c | 7 +++++-- + drivers/char/tpm/tpm2-cmd.c | 7 +++++-- + 2 files changed, 10 insertions(+), 4 deletions(-) + +--- a/drivers/char/tpm/tpm1-cmd.c ++++ b/drivers/char/tpm/tpm1-cmd.c +@@ -510,7 +510,7 @@ struct tpm1_get_random_out { + * + * Return: + * * number of bytes read +- * * -errno or a TPM return code otherwise ++ * * -errno (positive TPM return codes are masked to -EIO) + */ + int tpm1_get_random(struct tpm_chip *chip, u8 *dest, size_t max) + { +@@ -531,8 +531,11 @@ int tpm1_get_random(struct tpm_chip *chi + + rc = tpm_transmit_cmd(chip, &buf, sizeof(out->rng_data_len), + "attempting get random"); +- if (rc) ++ if (rc) { ++ if (rc > 0) ++ rc = -EIO; + goto out; ++ } + + out = (struct tpm1_get_random_out *)&buf.data[TPM_HEADER_SIZE]; + +--- a/drivers/char/tpm/tpm2-cmd.c ++++ b/drivers/char/tpm/tpm2-cmd.c +@@ -297,7 +297,7 @@ struct tpm2_get_random_out { + * + * Return: + * size of the buffer on success, +- * -errno otherwise ++ * -errno otherwise (positive TPM return codes are masked to -EIO) + */ + int tpm2_get_random(struct tpm_chip *chip, u8 *dest, size_t max) + { +@@ -324,8 +324,11 @@ int tpm2_get_random(struct tpm_chip *chi + offsetof(struct tpm2_get_random_out, + buffer), + "attempting get random"); +- if (err) ++ if (err) { ++ if (err > 0) ++ err = -EIO; + goto out; ++ } + + out = (struct tpm2_get_random_out *) + &buf.data[TPM_HEADER_SIZE]; diff --git a/queue-5.2/tpm-fix-tpm-1.2-shutdown-sequence-to-prevent-future-tpm-operations.patch b/queue-5.2/tpm-fix-tpm-1.2-shutdown-sequence-to-prevent-future-tpm-operations.patch new file mode 100644 index 00000000000..ed4435995e3 --- /dev/null +++ b/queue-5.2/tpm-fix-tpm-1.2-shutdown-sequence-to-prevent-future-tpm-operations.patch @@ -0,0 +1,48 @@ +From db4d8cb9c9f2af71c4d087817160d866ed572cc9 Mon Sep 17 00:00:00 2001 +From: Vadim Sukhomlinov +Date: Mon, 10 Jun 2019 15:01:18 -0700 +Subject: tpm: Fix TPM 1.2 Shutdown sequence to prevent future TPM operations + +From: Vadim Sukhomlinov + +commit db4d8cb9c9f2af71c4d087817160d866ed572cc9 upstream. + +TPM 2.0 Shutdown involve sending TPM2_Shutdown to TPM chip and disabling +future TPM operations. TPM 1.2 behavior was different, future TPM +operations weren't disabled, causing rare issues. This patch ensures +that future TPM operations are disabled. + +Fixes: d1bd4a792d39 ("tpm: Issue a TPM2_Shutdown for TPM2 devices.") +Cc: stable@vger.kernel.org +Signed-off-by: Vadim Sukhomlinov +[dianders: resolved merge conflicts with mainline] +Signed-off-by: Douglas Anderson +Reviewed-by: Jarkko Sakkinen +Signed-off-by: Jarkko Sakkinen +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/char/tpm/tpm-chip.c | 6 +++--- + 1 file changed, 3 insertions(+), 3 deletions(-) + +--- a/drivers/char/tpm/tpm-chip.c ++++ b/drivers/char/tpm/tpm-chip.c +@@ -289,15 +289,15 @@ static int tpm_class_shutdown(struct dev + { + struct tpm_chip *chip = container_of(dev, struct tpm_chip, dev); + ++ down_write(&chip->ops_sem); + if (chip->flags & TPM_CHIP_FLAG_TPM2) { +- down_write(&chip->ops_sem); + if (!tpm_chip_start(chip)) { + tpm2_shutdown(chip, TPM2_SU_CLEAR); + tpm_chip_stop(chip); + } +- chip->ops = NULL; +- up_write(&chip->ops_sem); + } ++ chip->ops = NULL; ++ up_write(&chip->ops_sem); + + return 0; + } diff --git a/queue-5.2/udf-fix-incorrect-final-not_allocated-hole-extent-length.patch b/queue-5.2/udf-fix-incorrect-final-not_allocated-hole-extent-length.patch new file mode 100644 index 00000000000..9c4f6b0bb72 --- /dev/null +++ b/queue-5.2/udf-fix-incorrect-final-not_allocated-hole-extent-length.patch @@ -0,0 +1,223 @@ +From fa33cdbf3eceb0206a4f844fe91aeebcf6ff2b7a Mon Sep 17 00:00:00 2001 +From: "Steven J. Magnani" +Date: Sun, 30 Jun 2019 21:39:35 -0500 +Subject: udf: Fix incorrect final NOT_ALLOCATED (hole) extent length + +From: Steven J. Magnani + +commit fa33cdbf3eceb0206a4f844fe91aeebcf6ff2b7a upstream. + +In some cases, using the 'truncate' command to extend a UDF file results +in a mismatch between the length of the file's extents (specifically, due +to incorrect length of the final NOT_ALLOCATED extent) and the information +(file) length. The discrepancy can prevent other operating systems +(i.e., Windows 10) from opening the file. + +Two particular errors have been observed when extending a file: + +1. The final extent is larger than it should be, having been rounded up + to a multiple of the block size. + +B. The final extent is not shorter than it should be, due to not having + been updated when the file's information length was increased. + +[JK: simplified udf_do_extend_final_block(), fixed up some types] + +Fixes: 2c948b3f86e5 ("udf: Avoid IO in udf_clear_inode") +CC: stable@vger.kernel.org +Signed-off-by: Steven J. Magnani +Link: https://lore.kernel.org/r/1561948775-5878-1-git-send-email-steve@digidescorp.com +Signed-off-by: Jan Kara +Signed-off-by: Greg Kroah-Hartman + +--- + fs/udf/inode.c | 93 ++++++++++++++++++++++++++++++++++++--------------------- + 1 file changed, 60 insertions(+), 33 deletions(-) + +--- a/fs/udf/inode.c ++++ b/fs/udf/inode.c +@@ -470,13 +470,15 @@ static struct buffer_head *udf_getblk(st + return NULL; + } + +-/* Extend the file by 'blocks' blocks, return the number of extents added */ ++/* Extend the file with new blocks totaling 'new_block_bytes', ++ * return the number of extents added ++ */ + static int udf_do_extend_file(struct inode *inode, + struct extent_position *last_pos, + struct kernel_long_ad *last_ext, +- sector_t blocks) ++ loff_t new_block_bytes) + { +- sector_t add; ++ uint32_t add; + int count = 0, fake = !(last_ext->extLength & UDF_EXTENT_LENGTH_MASK); + struct super_block *sb = inode->i_sb; + struct kernel_lb_addr prealloc_loc = {}; +@@ -486,7 +488,7 @@ static int udf_do_extend_file(struct ino + + /* The previous extent is fake and we should not extend by anything + * - there's nothing to do... */ +- if (!blocks && fake) ++ if (!new_block_bytes && fake) + return 0; + + iinfo = UDF_I(inode); +@@ -517,13 +519,12 @@ static int udf_do_extend_file(struct ino + /* Can we merge with the previous extent? */ + if ((last_ext->extLength & UDF_EXTENT_FLAG_MASK) == + EXT_NOT_RECORDED_NOT_ALLOCATED) { +- add = ((1 << 30) - sb->s_blocksize - +- (last_ext->extLength & UDF_EXTENT_LENGTH_MASK)) >> +- sb->s_blocksize_bits; +- if (add > blocks) +- add = blocks; +- blocks -= add; +- last_ext->extLength += add << sb->s_blocksize_bits; ++ add = (1 << 30) - sb->s_blocksize - ++ (last_ext->extLength & UDF_EXTENT_LENGTH_MASK); ++ if (add > new_block_bytes) ++ add = new_block_bytes; ++ new_block_bytes -= add; ++ last_ext->extLength += add; + } + + if (fake) { +@@ -544,28 +545,27 @@ static int udf_do_extend_file(struct ino + } + + /* Managed to do everything necessary? */ +- if (!blocks) ++ if (!new_block_bytes) + goto out; + + /* All further extents will be NOT_RECORDED_NOT_ALLOCATED */ + last_ext->extLocation.logicalBlockNum = 0; + last_ext->extLocation.partitionReferenceNum = 0; +- add = (1 << (30-sb->s_blocksize_bits)) - 1; +- last_ext->extLength = EXT_NOT_RECORDED_NOT_ALLOCATED | +- (add << sb->s_blocksize_bits); ++ add = (1 << 30) - sb->s_blocksize; ++ last_ext->extLength = EXT_NOT_RECORDED_NOT_ALLOCATED | add; + + /* Create enough extents to cover the whole hole */ +- while (blocks > add) { +- blocks -= add; ++ while (new_block_bytes > add) { ++ new_block_bytes -= add; + err = udf_add_aext(inode, last_pos, &last_ext->extLocation, + last_ext->extLength, 1); + if (err) + return err; + count++; + } +- if (blocks) { ++ if (new_block_bytes) { + last_ext->extLength = EXT_NOT_RECORDED_NOT_ALLOCATED | +- (blocks << sb->s_blocksize_bits); ++ new_block_bytes; + err = udf_add_aext(inode, last_pos, &last_ext->extLocation, + last_ext->extLength, 1); + if (err) +@@ -596,6 +596,24 @@ out: + return count; + } + ++/* Extend the final block of the file to final_block_len bytes */ ++static void udf_do_extend_final_block(struct inode *inode, ++ struct extent_position *last_pos, ++ struct kernel_long_ad *last_ext, ++ uint32_t final_block_len) ++{ ++ struct super_block *sb = inode->i_sb; ++ uint32_t added_bytes; ++ ++ added_bytes = final_block_len - ++ (last_ext->extLength & (sb->s_blocksize - 1)); ++ last_ext->extLength += added_bytes; ++ UDF_I(inode)->i_lenExtents += added_bytes; ++ ++ udf_write_aext(inode, last_pos, &last_ext->extLocation, ++ last_ext->extLength, 1); ++} ++ + static int udf_extend_file(struct inode *inode, loff_t newsize) + { + +@@ -605,10 +623,12 @@ static int udf_extend_file(struct inode + int8_t etype; + struct super_block *sb = inode->i_sb; + sector_t first_block = newsize >> sb->s_blocksize_bits, offset; ++ unsigned long partial_final_block; + int adsize; + struct udf_inode_info *iinfo = UDF_I(inode); + struct kernel_long_ad extent; +- int err; ++ int err = 0; ++ int within_final_block; + + if (iinfo->i_alloc_type == ICBTAG_FLAG_AD_SHORT) + adsize = sizeof(struct short_ad); +@@ -618,18 +638,8 @@ static int udf_extend_file(struct inode + BUG(); + + etype = inode_bmap(inode, first_block, &epos, &eloc, &elen, &offset); ++ within_final_block = (etype != -1); + +- /* File has extent covering the new size (could happen when extending +- * inside a block)? */ +- if (etype != -1) +- return 0; +- if (newsize & (sb->s_blocksize - 1)) +- offset++; +- /* Extended file just to the boundary of the last file block? */ +- if (offset == 0) +- return 0; +- +- /* Truncate is extending the file by 'offset' blocks */ + if ((!epos.bh && epos.offset == udf_file_entry_alloc_offset(inode)) || + (epos.bh && epos.offset == sizeof(struct allocExtDesc))) { + /* File has no extents at all or has empty last +@@ -643,7 +653,22 @@ static int udf_extend_file(struct inode + &extent.extLength, 0); + extent.extLength |= etype << 30; + } +- err = udf_do_extend_file(inode, &epos, &extent, offset); ++ ++ partial_final_block = newsize & (sb->s_blocksize - 1); ++ ++ /* File has extent covering the new size (could happen when extending ++ * inside a block)? ++ */ ++ if (within_final_block) { ++ /* Extending file within the last file block */ ++ udf_do_extend_final_block(inode, &epos, &extent, ++ partial_final_block); ++ } else { ++ loff_t add = ((loff_t)offset << sb->s_blocksize_bits) | ++ partial_final_block; ++ err = udf_do_extend_file(inode, &epos, &extent, add); ++ } ++ + if (err < 0) + goto out; + err = 0; +@@ -745,6 +770,7 @@ static sector_t inode_getblk(struct inod + /* Are we beyond EOF? */ + if (etype == -1) { + int ret; ++ loff_t hole_len; + isBeyondEOF = true; + if (count) { + if (c) +@@ -760,7 +786,8 @@ static sector_t inode_getblk(struct inod + startnum = (offset > 0); + } + /* Create extents for the hole between EOF and offset */ +- ret = udf_do_extend_file(inode, &prev_epos, laarr, offset); ++ hole_len = (loff_t)offset << inode->i_blkbits; ++ ret = udf_do_extend_file(inode, &prev_epos, laarr, hole_len); + if (ret < 0) { + *err = ret; + newblock = 0; diff --git a/queue-5.2/x86-ptrace-fix-possible-spectre-v1-in-ptrace_get_debugreg.patch b/queue-5.2/x86-ptrace-fix-possible-spectre-v1-in-ptrace_get_debugreg.patch new file mode 100644 index 00000000000..8f03691dde6 --- /dev/null +++ b/queue-5.2/x86-ptrace-fix-possible-spectre-v1-in-ptrace_get_debugreg.patch @@ -0,0 +1,54 @@ +From 31a2fbb390fee4231281b939e1979e810f945415 Mon Sep 17 00:00:00 2001 +From: Dianzhang Chen +Date: Tue, 25 Jun 2019 23:30:17 +0800 +Subject: x86/ptrace: Fix possible spectre-v1 in ptrace_get_debugreg() + +From: Dianzhang Chen + +commit 31a2fbb390fee4231281b939e1979e810f945415 upstream. + +The index to access the threads ptrace_bps is controlled by userspace via +syscall: sys_ptrace(), hence leading to a potential exploitation of the +Spectre variant 1 vulnerability. + +The index can be controlled from: + ptrace -> arch_ptrace -> ptrace_get_debugreg. + +Fix this by sanitizing the user supplied index before using it access +thread->ptrace_bps. + +Signed-off-by: Dianzhang Chen +Signed-off-by: Thomas Gleixner +Cc: bp@alien8.de +Cc: hpa@zytor.com +Cc: stable@vger.kernel.org +Link: https://lkml.kernel.org/r/1561476617-3759-1-git-send-email-dianzhangchen0@gmail.com +Signed-off-by: Greg Kroah-Hartman + +--- + arch/x86/kernel/ptrace.c | 5 ++++- + 1 file changed, 4 insertions(+), 1 deletion(-) + +--- a/arch/x86/kernel/ptrace.c ++++ b/arch/x86/kernel/ptrace.c +@@ -25,6 +25,7 @@ + #include + #include + #include ++#include + + #include + #include +@@ -643,9 +644,11 @@ static unsigned long ptrace_get_debugreg + { + struct thread_struct *thread = &tsk->thread; + unsigned long val = 0; ++ int index = n; + + if (n < HBP_NUM) { +- struct perf_event *bp = thread->ptrace_bps[n]; ++ index = array_index_nospec(index, HBP_NUM); ++ struct perf_event *bp = thread->ptrace_bps[index]; + + if (bp) + val = bp->hw.info.address; diff --git a/queue-5.2/x86-tls-fix-possible-spectre-v1-in-do_get_thread_area.patch b/queue-5.2/x86-tls-fix-possible-spectre-v1-in-do_get_thread_area.patch new file mode 100644 index 00000000000..0ca2536f698 --- /dev/null +++ b/queue-5.2/x86-tls-fix-possible-spectre-v1-in-do_get_thread_area.patch @@ -0,0 +1,63 @@ +From 993773d11d45c90cb1c6481c2638c3d9f092ea5b Mon Sep 17 00:00:00 2001 +From: Dianzhang Chen +Date: Wed, 26 Jun 2019 12:50:30 +0800 +Subject: x86/tls: Fix possible spectre-v1 in do_get_thread_area() + +From: Dianzhang Chen + +commit 993773d11d45c90cb1c6481c2638c3d9f092ea5b upstream. + +The index to access the threads tls array is controlled by userspace +via syscall: sys_ptrace(), hence leading to a potential exploitation +of the Spectre variant 1 vulnerability. + +The index can be controlled from: + ptrace -> arch_ptrace -> do_get_thread_area. + +Fix this by sanitizing the user supplied index before using it to access +the p->thread.tls_array. + +Signed-off-by: Dianzhang Chen +Signed-off-by: Thomas Gleixner +Cc: bp@alien8.de +Cc: hpa@zytor.com +Cc: stable@vger.kernel.org +Link: https://lkml.kernel.org/r/1561524630-3642-1-git-send-email-dianzhangchen0@gmail.com +Signed-off-by: Greg Kroah-Hartman + +--- + arch/x86/kernel/tls.c | 9 +++++++-- + 1 file changed, 7 insertions(+), 2 deletions(-) + +--- a/arch/x86/kernel/tls.c ++++ b/arch/x86/kernel/tls.c +@@ -5,6 +5,7 @@ + #include + #include + #include ++#include + + #include + #include +@@ -220,6 +221,7 @@ int do_get_thread_area(struct task_struc + struct user_desc __user *u_info) + { + struct user_desc info; ++ int index; + + if (idx == -1 && get_user(idx, &u_info->entry_number)) + return -EFAULT; +@@ -227,8 +229,11 @@ int do_get_thread_area(struct task_struc + if (idx < GDT_ENTRY_TLS_MIN || idx > GDT_ENTRY_TLS_MAX) + return -EINVAL; + +- fill_user_desc(&info, idx, +- &p->thread.tls_array[idx - GDT_ENTRY_TLS_MIN]); ++ index = idx - GDT_ENTRY_TLS_MIN; ++ index = array_index_nospec(index, ++ GDT_ENTRY_TLS_MAX - GDT_ENTRY_TLS_MIN + 1); ++ ++ fill_user_desc(&info, idx, &p->thread.tls_array[index]); + + if (copy_to_user(u_info, &info, sizeof(info))) + return -EFAULT;