similar to: [RFC] Moving RELRO segment

Hello Vic, I don't have a lot to add myself. I think that majority of the input needs to come from the OS stakeholders. My main concern is if it requires work on every platform to take advantage or avoid regressions then perhaps it is worth adding as an option rather than changing the default. Some questions: - Does this need work in every OS for correctness of programs? For example you

On Thu, Aug 29, 2019 at 3:10 AM Fāng-ruì Sòng <maskray at google.com> wrote: > Hello Vic, > > To make sure I understand the proposal correctly, do you propose: > > Old: R RX RW(RELRO) RW > New: R(R+RELRO) RX RW; R includes the traditional R part and the > RELRO part > Runtime (before relocation resolving): RW RX RW > Runtime (after relocation resolving): R RX

On Fri, Aug 30, 2019 at 4:54 AM Fāng-ruì Sòng <maskray at google.com> wrote: > > > Old: R RX RW(RELRO) RW > > > New: R(R+RELRO) RX RW; R includes the traditional R part and the > > > RELRO part > > > Runtime (before relocation resolving): RW RX RW > > > Runtime (after relocation resolving): R RX RW > > > > > I actually see two

On 25 September 2015 at 20:11, Jakub Jelinek <jakub at redhat.com> wrote: > Note, in our distros we are shipping 42-bit VMA and are using patch on > top of vanilla libsanitizer (with the 1UL << 36 shadow offset) and I don't > remember any bugs reported against this not working (and the testsuite works > too). So, assuming 39-bit VMA works too, that would show that at

The problem as I recall was that we do not want jumptable sections to appear before __cfi_check, so we gave these jump tables a name so that the bfd default linker script would sort them after __cfi_check. This is the relevant part of the default linker script: .text : { [...] *(.text.hot .text.hot.*) *(.text .stub .text.* .gnu.linkonce.t.*) } So I guess the idea was

Taking out that line breaks some LowerTypeTest tests, need to investigate. Runtime compiler-rt all passed. > On May 1, 2018, at 3:11 PM, Peter Collingbourne <peter at pcc.me.uk> wrote: > > The problem as I recall was that we do not want jumptable sections to appear before __cfi_check, so we gave these jump tables a name so that the bfd default linker script would sort them after

On Mon, Aug 26, 2019 at 11:02:12AM -0700, Ralph Campbell wrote: > > On 8/24/19 3:37 PM, Christoph Hellwig wrote: > > On Fri, Aug 23, 2019 at 03:17:52PM -0700, Ralph Campbell wrote: > > > Although hmm_range_fault() calls find_vma() to make sure that a vma exists > > > before calling walk_page_range(), hmm_vma_walk_hole() can still be called > > > with

On Wed, May 17, 2017 at 1:32 PM, Rui Ueyama via llvm-dev < llvm-dev at lists.llvm.org> wrote: > On Wed, May 17, 2017 at 1:11 PM, Petr Hosek <phosek at chromium.org> wrote: > >> The motivation is not only memory savings but also security: >> can-never-be-written is strictly better than RELRO in all cases. The >> biggest win is when .dynamic is the sole reason

Hi, I am looking into Control-Flow Integrity for indirect function calls, implemented with jump tables. I want to step through the code that produces these jump tables in GDB. I have built clang and opt from source with debugging symbols. I believe this code lives in llvm/lib/Transforms/LowerTypeTests.cpp, but when I try to debug *opt* by running the command "run -lowertypetests cfi-icall.bc

Jump table sections already have this prefix: ".text..L.cfi.jumptable.”, without forcing the name with setSection(). Is that good enough? > On May 1, 2018, at 1:16 PM, Peter Collingbourne <peter at pcc.me.uk> wrote: > > I think we just need to change the section name for non-MachO object formats because "__TEXT,__text,regular,pure_instructions" is the default text

On 8 May 2020, at 16:06, Ralph Campbell wrote: > On 5/8/20 12:51 PM, Christoph Hellwig wrote: >> On Fri, May 08, 2020 at 12:20:07PM -0700, Ralph Campbell wrote: >>> hmm_range_fault() returns an array of page frame numbers and flags for >>> how the pages are mapped in the requested process' page tables. The PFN >>> can be used to get the struct page with

Jakub makes a good point, are you sure that there is no single shadow offset value that works for all VMA variants? What exactly breaks when 1<<36 is used on 42-bit VMA? On Fri, Sep 25, 2015 at 3:28 AM, Yury Gribov via llvm-dev <llvm-dev at lists.llvm.org> wrote: > On 09/25/2015 01:27 PM, Yury Gribov wrote: >> >> On 09/25/2015 11:53 AM, Jakub Jelinek via llvm-dev

On 02/10/19 19:04, Jerome Glisse wrote: > On Wed, Oct 02, 2019 at 06:18:06PM +0200, Paolo Bonzini wrote: >>>> If the mapping of the source VMA changes, mirroring can update the >>>> target VMA via insert_pfn. But what ensures that KVM's MMU notifier >>>> dismantles its own existing page tables (so that they can be recreated >>>> with the new

On 02/10/19 19:04, Jerome Glisse wrote: > On Wed, Oct 02, 2019 at 06:18:06PM +0200, Paolo Bonzini wrote: >>>> If the mapping of the source VMA changes, mirroring can update the >>>> target VMA via insert_pfn. But what ensures that KVM's MMU notifier >>>> dismantles its own existing page tables (so that they can be recreated >>>> with the new

On Fri, Aug 23, 2019 at 03:17:52PM -0700, Ralph Campbell wrote: > Although hmm_range_fault() calls find_vma() to make sure that a vma exists > before calling walk_page_range(), hmm_vma_walk_hole() can still be called > with walk->vma == NULL if the start and end address are not contained > within the vma range. Should we convert to walk_vma_range instead? Or keep walk_page_range

On 02/10/19 16:15, Jerome Glisse wrote: >>> Why would you need to target mmu notifier on target vma ? >> If the mapping of the source VMA changes, mirroring can update the >> target VMA via insert_pfn. But what ensures that KVM's MMU notifier >> dismantles its own existing page tables (so that they can be recreated >> with the new mapping from the source VMA)?

On 02/10/19 16:15, Jerome Glisse wrote: >>> Why would you need to target mmu notifier on target vma ? >> If the mapping of the source VMA changes, mirroring can update the >> target VMA via insert_pfn. But what ensures that KVM's MMU notifier >> dismantles its own existing page tables (so that they can be recreated >> with the new mapping from the source VMA)?

I get some failing tests from compiler-rt. FAIL: cfi :: cross-dso/stats.cpp (30831 of 30893) ******************** TEST 'cfi :: cross-dso/stats.cpp' FAILED ******************** Script: -- /usr/local/google/home/prazek/llvm-build-release/./bin/clang -fuse-ld=gold -flto -fsanitize=cfi -fwhole-program-vtables --driver-mode=g++ -fsanitize-cfi-cross-dso -fvisibility=default -DSHARED_LIB -fPIC

On Tue, May 23, 2017 at 4:39 PM, Evgenii Stepanov <eugeni.stepanov at gmail.com > wrote: > On Tue, May 16, 2017 at 4:33 PM, Evgenii Stepanov > <eugeni.stepanov at gmail.com> wrote: > > On Mon, May 15, 2017 at 6:44 PM, Peter Collingbourne <peter at pcc.me.uk> > wrote: > >> Thanks for sending this out. A few comments below. > >> > >> On

On Mon, May 15, 2017 at 6:44 PM, Peter Collingbourne <peter at pcc.me.uk> wrote: > Thanks for sending this out. A few comments below. > > On Mon, May 15, 2017 at 5:17 PM, Evgenii Stepanov via llvm-dev > <llvm-dev at lists.llvm.org> wrote: >> >> Hi, >> >> this is a proposal for the implementation of CFI-icall [1] with ThinLTO. >> >>