lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <3607326c-9d39-a9e7-8e14-65aaef2094fd@michaelkloos.com>
Date:   Sun, 23 Jan 2022 12:15:00 -0500
From:   "Michael T. Kloos" <michael@...haelkloos.com>
To:     Jessica Clarke <jrtc27@...c27.com>
Cc:     Paul Walmsley <paul.walmsley@...ive.com>,
        Palmer Dabbelt <palmer@...belt.com>,
        Albert Ou <aou@...s.berkeley.edu>,
        linux-riscv <linux-riscv@...ts.infradead.org>,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2] Fixed: Misaligned memory access. Fixed pointer
 comparison.

Yes, you are correct, but while I am not that knowledgeable in the kernel
build system, I believe that in many build systems, binutils "as" is usually
called by the "gcc" wrapper, rather than being executed directly.  This
allows for the C preprocessor to be easily and automatically run over *.S
files first.  Binutils "as" doesn't care about suffix.  It just assembles.
"gcc" will check and call the other tools as necessary to build.

Perhaps I should have been more specific in my language.  However,
I was trying to refer to the 2 different build systems in their entirety,
not their individually sub-components because I had originally test
built with gcc, not clang.

	Michael

On 1/23/22 10:44, Jessica Clarke wrote:

> On 23 Jan 2022, at 03:45, Michael T. Kloos <michael@...haelkloos.com> wrote:
>> Rewrote the riscv memmove() assembly implementation.  The
>> previous implementation did not check memory alignment and it
>> compared 2 pointers with a signed comparison.  The misaligned
>> memory access would cause the kernel to crash on systems that
>> did not emulate it in firmware and did not support it in hardware.
>> Firmware emulation is slow and may not exist.  Additionally,
>> hardware support may not exist and would likely still run slower
>> than aligned accesses even if it did.  The RISC-V spec does not
>> guarantee that support for misaligned memory accesses will exist.
>> It should not be depended on.
>>
>> This patch now checks for the maximum granularity of co-alignment
>> between the pointers and copies them with that, using single-byte
>> copy for any unaligned data at their terminations.  It also now uses
>> unsigned comparison for the pointers.
>>
>> Added half-word and, if built for 64-bit, double-word copy.
>>
>> Migrated to the	newer assembler annotations from the now deprecated
>> ones.
>>
>> Commit Message Edited on Jan 22 2022: Fixed some typos.
>>
>> [v2]
>>
>> Per kernel test robot, I have fixed the build under clang.  This
>> was broken due to a difference between gcc and clang, clang requiring
>> explict zero offsets the jalr instruction. gcc allowed them to be
>> omitted if zero.
> Unlike LLVM, GCC does not have an assembler, that’s binutils’s GNU as.
>
> Jess
>

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ