Re: [PATCH v2 2/3] binder: do not initialize locals passed to copy_from_user()
On Wed, Mar 04, 2020 at 10:13:40AM -0800, Kees Cook wrote: > On Tue, Mar 03, 2020 at 12:38:32PM +0300, Dan Carpenter wrote: > > The real fix is to initialize everything manually, the automated > > initialization is a hardenning feature which many people will disable. > > I cannot disagree more with this sentiment. Linus has specifically said he > wants this initialization on by default[1], Fine, but as long as it's a configurable thing then we need to manually initialize as well or it's still a CVE etc. It will take a while before we drop support for old versions of GCC as well. regards, dan carpenter ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v2 2/3] binder: do not initialize locals passed to copy_from_user()
On Thu, Mar 05, 2020 at 11:07:56AM +0300, Dan Carpenter wrote: > On Wed, Mar 04, 2020 at 10:13:40AM -0800, Kees Cook wrote: > > On Tue, Mar 03, 2020 at 12:38:32PM +0300, Dan Carpenter wrote: > > > The real fix is to initialize everything manually, the automated > > > initialization is a hardenning feature which many people will disable. > > > > I cannot disagree more with this sentiment. Linus has specifically said he > > wants this initialization on by default[1], > > Fine, but as long as it's a configurable thing then we need to manually > initialize as well or it's still a CVE etc. It will take a while before > we drop support for old versions of GCC as well. Yes, I agree; that's totally true. We need to continue to fix all the uninitialized flaws we encounter unless this is on by default for all supported compiler versions (which will be a looong time). (But it's not relevant to this patch because copy_from_user() does already do the initialization.) This set of patches was about dealing with the pathological cases of auto-init colliding with functions that do, in fact, fully init. Though I must say, I remain concerned about inventing such markings for fear they'll be used in places where the "trust me, it's fully initialized" state does not actually hold[1] but the author thinks it does. -Kees [1] https://lore.kernel.org/netdev/1509471094.3828.26.ca...@edumazet-glaptop3.roam.corp.google.com/ -- Kees Cook ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v2 2/3] binder: do not initialize locals passed to copy_from_user()
On 02/03/2020 19.31, Jann Horn wrote: > On Mon, Mar 2, 2020 at 7:17 PM Alexander Potapenko wrote: >> On Mon, Mar 2, 2020 at 3:00 PM Joe Perches wrote: >>> >>> So? CONFIG_INIT_STACK_ALL by design slows down code. >> Correct. >> >>> This marking would likely need to be done for nearly all >>> 3000+ copy_from_user entries. >> Unfortunately, yes. I was just hoping to do so for a handful of hot >> cases that we encounter, but in the long-term a compiler solution must >> supersede them. >> >>> Why not try to get something done on the compiler side >>> to mark the function itself rather than the uses? >> This is being worked on in the meantime as well (see >> http://lists.llvm.org/pipermail/cfe-dev/2020-February/064633.html) >> Do you have any particular requisitions about how this should look on >> the source level? > > Just thinking out loud: Should this be a function attribute, or should > it be a builtin - something like __builtin_assume_initialized(ptr, > len)? That would make it also work for macros, But with macros (and static inlines), the compiler sees all the initialization being done, no? and it might simplify > the handling of inlining in the compiler. And you wouldn't need such a > complicated attribute that refers to function arguments by index and > such. Does copy_from_user guarantee to zero-initialize the remaining buffer if copying fails partway through? Otherwise it will be hard for the compiler to make use of an annotation such as __assume_initialized(buf, size - ret_from_cfu) - it will have to say "ok, the caller is bailing out unless ret_from_cfu is 0, and in that case, yes, the whole local struct variable is indeed initialized". And we can't make the annotation unconditionally __assume_initialized(buf, size) [unless c_f_u comes with that guarantee] because we don't know that all callers of c_f_u() bail out on non-zero. Somewhat related: I've long wanted a bunch of function attributes __may_read(ptr, bytes) __may_write(ptr, bytes) __will_write(ptr, bytes) The first could be used to warn about passing an uninitialized or too-small buffer (e.g. struct pollfd fds[4]; poll(fds, sizeof(fds), ...) // whoops, should have been ARRAY_SIZE) the second also for warning about a too-small buffer, and the third would essentially be the same as __assume_initializes. Perhaps with some sanitization option the compiler could also instrument the function definition to not read/write beyond the area declared via those attributes. But the attribute syntax doesn't currently allow complex expressions in terms of the parameter names; I'd want to annotate poll as int poll(struct pollfd *fds, nfds_t nfds, int to) __may_rw(fds, nfds * sizeof(*fds)) Rasmus ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[no subject]
Herzlichen Glückwunsch Lieber Begünstigter,Sie erhalten diese E-Mail von der Robert Bailey Foundation. Ich bin ein pensionierter Regierungsangestellter aus Harlem und ein Gewinner des Powerball Lottery Jackpot im Wert von 343,8 Millionen US-Dollar. Ich bin der größte Jackpot-Gewinner in der Geschichte der New Yorker Lotterie im US-Bundesstaat Amerika. Ich habe diese Lotterie am 27. Oktober 2018 gewonnen und möchte Sie darüber informieren, dass Google in Zusammenarbeit mit Microsoft Ihre "E-Mail-Adresse" auf meine Bitte, einen Spendenbetrag von 3.000.000,00 Millionen Euro zu erhalten, übermittelt hat. Ich spende diese 3 Millionen Euro an Sie, um den Wohltätigkeitsheimen und armen Menschen in Ihrer Gemeinde zu helfen, damit wir die Welt für alle verbessern können.Weitere Informationen finden Sie auf der folgenden Website, damit Sie nicht skeptisch sind Diese Spende von 3 Mio. EUR.https://nypost.com/2018/11/14/meet-the-winner-of-the-biggest-lottery-jackpot-in-new-york-history/Sie können auch mein YouTube für mehr Bestätigung aufpassen: https://www.youtube.com/watch?v=H5vT18Ysavc Bitte beachten Sie, dass alle Antworten an (robertdonati...@gmail.com ) gesendet werden, damit wir das können Fahren Sie fort, um das gespendete Geld an Sie zu überweisen.E-Mail: robertdonation7@gmail.comFreundliche Grüße, Robert Bailey * * * * * * * * * * * * * * * * Powerball Jackpot Gewinner ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 2/2] mm/vma: Introduce VM_ACCESS_FLAGS
On 3/5/20 7:50 AM, Anshuman Khandual wrote: > There are many places where all basic VMA access flags (read, write, exec) > are initialized or checked against as a group. One such example is during > page fault. Existing vma_is_accessible() wrapper already creates the notion > of VMA accessibility as a group access permissions. Hence lets just create > VM_ACCESS_FLAGS (VM_READ|VM_WRITE|VM_EXEC) which will not only reduce code > duplication but also extend the VMA accessibility concept in general. > > Cc: Russell King > CC: Catalin Marinas > CC: Mark Salter > Cc: Nick Hu > CC: Ley Foon Tan > Cc: Michael Ellerman > Cc: Heiko Carstens > Cc: Yoshinori Sato > Cc: Guan Xuetao > Cc: Dave Hansen > Cc: Thomas Gleixner > Cc: Rob Springer > Cc: Greg Kroah-Hartman > Cc: Andrew Morton > Cc: linux-arm-ker...@lists.infradead.org > Cc: linuxppc-...@lists.ozlabs.org > Cc: linux-s...@vger.kernel.org > Cc: de...@driverdev.osuosl.org > Cc: linux...@kvack.org > Cc: linux-ker...@vger.kernel.org > Signed-off-by: Anshuman Khandual Reviewed-by: Vlastimil Babka Thanks. ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 8/8] arm64: dts: renesas: salvator: add a connection from adv748x codec (HDMI input) to the R-Car SoC
Hi Geert,
Geert Uytterhoeven, Mon, Mar 02, 2020 17:13:30 +0100:
> On Mon, Mar 2, 2020 at 5:09 PM Alex Riesen
> wrote:
> > Geert Uytterhoeven, Mon, Mar 02, 2020 16:32:32 +0100:
> > >
> > > The #clock-cells should be in the main video-receiver node.
> > > Probably there is more than one clock output, so #clock-cells may be 1?
> >
> > AFAICS, the device can provide only this one clock line (audio master clock
> > for I2S output)... I shall re-check, just in case.
And you're right, of course: the audio output formatting module of the ADV748x
devices provides a set of clock lines related to the I2S pins: the already
discussed master clock, left-right channel clock and the serial clock (bit
clock?).
> > > There is no need for a fixed-clock compatible, nor for clock-frequency
> > > and clock-output-names.
> > >
> > > But most important: this should be documented in the adv748x DT bindings,
> > > and implemented in the adv748x driver.
> >
> > So if the driver is to export that clock for the kernel (like in this case),
> > it must implement its support?
>
> Exactly. Unless that pin is hardcoded to output a fixed clock, in which case
> you can just override the existing audio_clk_c rate.
Just to try it out (I'll set #clock-cells to 1), I registered a fixed rate
clock in the driver, added a clock provider:
adv748x_probe:
clk = clk_register_fixed_rate(state->dev,
"clk-hdmi-i2s-mclk",
NULL /* parent_name */,
0/* flags */,
12288000 /* rate */);
of_clk_add_provider(state->dev->of_node, of_clk_src_simple_get, clk);
And removed the audio_clk_c frequency setting. I also replaced the audio_clk_c
in the list of input clocks of the R-Car-side sound card with the phandle of
the adv7482 main node:
salvator-common.dtsi:
&i2c4 {
status = "okay";
adv7482_hdmi_decoder: video-receiver@70 {
#clock-cells = <0>; // to be replaced with <1>
};
};
&rcar_sound {
clocks = ..., <&adv7482_hdmi_decoder>, ...;
};
As everything continues to work as before, I assume that at least the clock
dependencies were resolved.
Is there a way to verify that the added input clock is actually used?
IOW, if its frequency is actually has been programmed into the ssi4 (R-Car
receiving hardware) registers, and not just a left-over from previuos attempts
or plain default setting?
As the ADV748x devices seem to provide also the clocks for video outputs, will
it make any sense to place the clock definition into the port node?
Or should all provided clocks be indexed in the main device node?
Regards,
Alex
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re:-
A donation was made in your favour by Francois Pinault, reply for more details. ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Hello 05/03/2020
Good day, My name is Reem E. Hashimy, the Emirates Minister of State and Managing Director of the United Arab Emirates (Dubai) World Expo 2020 Committee. I am writing you to manage my funds I received as financial gratification from various foreign companies I assisted to receive participation slot in the incoming Dubai World Expo 2020. The amount is $44,762,906.00 United States dollars.The cumulative deposit were given as an expression of appreciation from the various foreign companies whose applications received approval to participate in the in-coming Dubai Expo 2020. But I could not receive the various gratifications to my personal account in my country because my social status as a married Muslim lady with limitations to certain investment opportunities. For this reason, an agreement was reached with a consulting firm to keep the funds in open beneficiary account with a financial institution where it will be possible to instruct transfer of the funds to a third party account for investment purpose which is the reason I am contacting you to receive and manage the funds as my investment partner. The detail will be discuss on your indication of interest with your information and capacity to manage the fund. However, if you are not ready to take up responsibility in this partnership, please do not reply. While looking forward to good partnership, I am wishing you the best of the year. my Regards Reem Hashimy. ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[driver-core:driver-core-testing] BUILD SUCCESS 9211f0a6a91ada1ee28b3fb5f30d79c8a67c73b1
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core.git driver-core-testing branch HEAD: 9211f0a6a91ada1ee28b3fb5f30d79c8a67c73b1 driver core: fw_devlink_flags can be static elapsed time: 483m configs tested: 160 configs skipped: 0 The following configs have been built successfully. More configs may be tested in the coming days. arm64allyesconfig arm allyesconfig arm64allmodconfig arm64 allnoconfig arm allnoconfig arm allmodconfig arm at91_dt_defconfig arm efm32_defconfig arm exynos_defconfig armmulti_v5_defconfig armmulti_v7_defconfig armshmobile_defconfig arm sunxi_defconfig arm64 defconfig sparcallyesconfig sparc64 allnoconfig nds32 defconfig xtensa common_defconfig ia64defconfig powerpc defconfig i386 allnoconfig i386 allyesconfig i386 alldefconfig i386defconfig ia64 alldefconfig ia64 allmodconfig ia64 allnoconfig ia64 allyesconfig c6x allyesconfig c6xevmc6678_defconfig nios2 10m50_defconfig nios2 3c120_defconfig openriscor1ksim_defconfig openrisc simple_smp_defconfig xtensa iss_defconfig h8300 edosk2674_defconfig h8300h8300h-sim_defconfig h8300 h8s-sim_defconfig m68k allmodconfig m68k m5475evb_defconfig m68k multi_defconfig m68k sun3_defconfig powerpc ppc64_defconfig powerpc rhel-kconfig arc allyesconfig arc defconfig microblaze mmu_defconfig microblazenommu_defconfig powerpc allnoconfig mips allyesconfig mips allnoconfig mips 32r2_defconfig mips allmodconfig mips 64r6el_defconfig mips fuloong2e_defconfig mips malta_kvm_defconfig pariscallnoconfig pariscgeneric-64bit_defconfig pariscgeneric-32bit_defconfig parisc allyesconfig x86_64 randconfig-a001-20200306 x86_64 randconfig-a002-20200306 x86_64 randconfig-a003-20200306 i386 randconfig-a001-20200306 i386 randconfig-a002-20200306 i386 randconfig-a003-20200306 riscvrandconfig-a001-20200305 alpharandconfig-a001-20200305 m68k randconfig-a001-20200305 nds32randconfig-a001-20200305 mips randconfig-a001-20200305 parisc randconfig-a001-20200305 sparc64 randconfig-a001-20200305 c6x randconfig-a001-20200305 nios2randconfig-a001-20200305 h8300randconfig-a001-20200305 sh randconfig-a001-20200305 openrisc randconfig-a001-20200305 csky randconfig-a001-20200305 s390 randconfig-a001-20200305 xtensa randconfig-a001-20200305 x86_64 randconfig-b002-20200305 x86_64 randconfig-b001-20200305 i386 randconfig-b001-20200305 i386 randconfig-b003-20200305 i386 randconfig-b002-20200305 x86_64 randconfig-b003-20200305 i386 randconfig-c002-20200305 x86_64 randconfig-c003-20200305 i386 randconfig-c001-20200305 x86_64 randconfig-c002-20200305 i386 randconfig-c003-20200305 x86_64 randconfig-c001-20200305 x86_64 randconfig-e001-20200305 x86_64 randconfig-e002-20200305 x86_64 randconfig-e003-20200305 i386 randconfig-e001-20200305 i386 randconfig-e002-20200305 i386 randconfig-e003-20200305 x86_64 randconfig-f001-20200305 x86_64
[RFC] ashmem: Fix ashmem shrinker nr_to_scan
nr_to_scan is the number of pages to be freed however ashmem doesn't discount nr_to_scan correctly as it frees ranges. It should be discounting them by pages than by ranges. Correct the issue. Cc: sur...@google.com Signed-off-by: Joel Fernandes (Google) --- drivers/staging/android/ashmem.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/staging/android/ashmem.c b/drivers/staging/android/ashmem.c index 5891d0744a760..cb525ea6db98a 100644 --- a/drivers/staging/android/ashmem.c +++ b/drivers/staging/android/ashmem.c @@ -458,6 +458,8 @@ ashmem_shrink_scan(struct shrinker *shrink, struct shrink_control *sc) lru_del(range); freed += range_size(range); + sc->nr_to_scan -= range_size(range); + mutex_unlock(&ashmem_mutex); f->f_op->fallocate(f, FALLOC_FL_PUNCH_HOLE | FALLOC_FL_KEEP_SIZE, @@ -467,7 +469,7 @@ ashmem_shrink_scan(struct shrinker *shrink, struct shrink_control *sc) wake_up_all(&ashmem_shrink_wait); if (!mutex_trylock(&ashmem_mutex)) goto out; - if (--sc->nr_to_scan <= 0) + if (sc->nr_to_scan <= 0) break; } mutex_unlock(&ashmem_mutex); -- 2.25.0.265.gbab2e86ba0-goog ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v2 2/3] binder: do not initialize locals passed to copy_from_user()
On Thu, Mar 05, 2020 at 10:03:25AM +0100, Rasmus Villemoes wrote: > Does copy_from_user guarantee to zero-initialize the remaining buffer if > copying fails partway through? That's guaranteed, short of raw_copy_from_user() being completely broken. What raw_copy_from_user() implementation must guarantee is that if raw_copy_from_user(to, from, N) returns N - n, then * 0 <= n <= N * all attempted reads had been within the range [from .. from + N - 1] * all stores had been to the range [to .. to + n - 1] and every byte within that range had been overwritten * for all k in [0 .. n - 1], the value stored at to[k] by the end of the call is equal to the value that would've been possible to read from from[k] at some point during the call. In particular, for all bytes in range [from .. from + n - 1] there had been a successful read of some object containing that byte. * if everything in [from .. from + N - 1] is readable, the call will copy the entire range into [to .. to + N - 1] and return 0. Provided that, copy_from_user() will leave no uninitialized data in destination object in any case, success or no success. ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
