2025년 4월 4일 (금) 05:45에 Ahn9807님의 편집

2025-04-04T05:45:45Z

← 이전 판		2025년 4월 4일 (금) 05:45 판
27번째 줄:		27번째 줄:
	=== Part 2: Starting the Problem ===		=== Part 2: Starting the Problem ===
	Shared context에 대한 글 뒤에, 보통은 But 혹은 However과 같은 말로써, Shared context에서 가지는 문제점을 지적하게 된다. Problem이 Problem처럼 느껴지기 위해서는 두개의 조건을 만족해야 한다.		Shared context에 대한 글 뒤에, 보통은 But 혹은 However과 같은 말로써, Shared context에서 가지는 문제점을 지적하게 된다. Problem이 Problem처럼 느껴지기 위해서는 두개의 조건을 만족해야 한다.
	# Condition 혹은 Situtation: 문제를 일으킬 가능성이 있는 존재 ~~(E.g., 테러, 과음, 계엄)~~		# Condition 혹은 Situtation: 문제를 일으킬 가능성이 있는 존재
	# Itolerable consequence or cost of the condition: 그 존재로 인하여 발생하는 비용 ~~(E.g., 사회혼란, 건강의 해악)~~		# Itolerable consequence or cost of the condition: 그 존재로 인하여 발생하는 비용

	우선 Condition혹은 Situtation이 나오고 그후 <So, what?>에 해당하는 답인 Cost에 해당하는 설명이 나와야 한다.		우선 Condition혹은 Situtation이 나오고 그후 <So, what?>에 해당하는 답인 Cost에 해당하는 설명이 나와야 한다.

2025년 1월 15일 (수) 10:19에 Ahn9807님의 편집

2025-01-15T10:19:04Z

← 이전 판		2025년 1월 15일 (수) 10:19 판
82번째 줄:		82번째 줄:
	== Conclusion 작성법 ==		== Conclusion 작성법 ==
	Conclusion은 글의 요점, 중요성, 그리고 암시하는 바를 문제와 함께 다시한번 정리해야 한다. Conclusion은 Introduction보다는 정형화 되어 있지 않지만, Introduction의 순서를 반대로 하는 것으로 어느정도 흐름을 잡을 수 있다.		Conclusion은 글의 요점, 중요성, 그리고 암시하는 바를 문제와 함께 다시한번 정리해야 한다. Conclusion은 Introduction보다는 정형화 되어 있지 않지만, Introduction의 순서를 반대로 하는 것으로 어느정도 흐름을 잡을 수 있다.
	; 간단한 요점, 주장, 그리고 해결방안으로 시작한다.		* 간단한 요점, 주장, 그리고 해결방안으로 시작한다.
	: This paper presents a practical OTA designed by separating		<blockquote>
			This paper presents a practical OTA designed by separating
	virtual and physical address management and by co-designing		virtual and physical address management and by co-designing
	one-time-allocator and virtual address management at the user-		one-time-allocator and virtual address management at the user-
	level.		level.
			</blockquote>

	; 중요성을 다시하번 강조한다. So, What?		* 중요성을 다시하번 강조한다. So, What?
	: BUDAlloc showcases well-rounded results in terms of		<blockquote>
			BUDAlloc showcases well-rounded results in terms of
	performance, memory use, scalability, and bug detectability		performance, memory use, scalability, and bug detectability
	compared to FFmalloc, DangZero, and MarkUs.		compared to FFmalloc, DangZero, and MarkUs.
			</blockquote>

	; 추가적으로 필요한 이야기를 제시한다. Now What?		* 추가적으로 필요한 이야기를 제시한다. Now What?
	; Prelude에서 말한 3가지 요소를 마지막으로 마무리 한다.		* Prelude에서 말한 3가지 요소를 마지막으로 마무리 한다.

	보통 Computer sience논문에서는 아래 두 요소는 ~~생략하는 것 같다~~.		보통 Computer sience논문에서는 아래 두 요소는 생략한다.

Ahn9807: 새 문서: 분류: Style: Lessons in Clarity and Grace == 개요 == 어떻게 Introduction, Motivation, 그리고 Conclusion을 써야 할 것이지 설명한다. Motivation은 크게 두가지 목적이 있다. * 독자들에게 앞으로 어떤 것에 대해서 설명할으로써, 그들이 좀더 많은 지식을 가지고 글을 읽을 수 있도록 함 * 독자들이 글을 읽고 싶도록 Motivate하여, 그들이 그을 더욱 자세히 읽도록 함 == Introduction 을 작...

2025-01-15T10:18:03Z

새 문서: 분류: Style: Lessons in Clarity and Grace == 개요 == 어떻게 Introduction, Motivation, 그리고 Conclusion을 써야 할 것이지 설명한다. Motivation은 크게 두가지 목적이 있다. * 독자들에게 앞으로 어떤 것에 대해서 설명할으로써, 그들이 좀더 많은 지식을 가지고 글을 읽을 수 있도록 함 * 독자들이 글을 읽고 싶도록 Motivate하여, 그들이 그을 더욱 자세히 읽도록 함 == Introduction 을 작...

새 문서

[[분류: Style: Lessons in Clarity and Grace]]

== 개요 ==
어떻게 Introduction, Motivation, 그리고 Conclusion을 써야 할 것이지 설명한다.

Motivation은 크게 두가지 목적이 있다.
* 독자들에게 앞으로 어떤 것에 대해서 설명할으로써, 그들이 좀더 많은 지식을 가지고 글을 읽을 수 있도록 함
* 독자들이 글을 읽고 싶도록 Motivate하여, 그들이 그을 더욱 자세히 읽도록 함

== Introduction 을 작성하는 법 ==
Introduction은 당신 뿐만 아니라 독자들도 흥미로워하는 지식을 통해서 독자들을 Motivating하여야 한다. Introduction은 다음 세가지 단계로 구성된다.
Shared context -> Problem -> Solution/Main Point/Claim

=== Part 1: Establishing a Shared Context ===
우선 독자들이 알고 있는 사실을 환기하며 글을 시작해야 한다. 이를 통해서 독자들은 뒤에 제시될 Problem이 독자들이 잘 알고 있는 분야에 큰 문제가 된다는 사실을 더욱 공감할 수 있게 해야 한다. 이런 사실은 역사적인 Background사실이나, 아니면 Recent event, 혹은 Common belief와 같은 것들이 온다.
<blockquote>
Memory bugs persist as enduring security vulnerabilities in
software systems. Arising from developers’ oversights and the
use of memory-unsafe languages, these bugs are prime targets
for exploitation by attackers. Numerous strategies have been
proposed to prevent or detect use-after-free (UAF) bug.
OTA incorporates the notion of virtual
aliasing [23], where multiple aliases
of objects are mapped to a single page [42].
</blockquote>

=== Part 2: Starting the Problem ===
Shared context에 대한 글 뒤에, 보통은 But 혹은 However과 같은 말로써, Shared context에서 가지는 문제점을 지적하게 된다. Problem이 Problem처럼 느껴지기 위해서는 두개의 조건을 만족해야 한다.
# Condition 혹은 Situtation: 문제를 일으킬 가능성이 있는 존재 (E.g., 테러, 과음, 계엄)
# Itolerable consequence or cost of the condition: 그 존재로 인하여 발생하는 비용 (E.g., 사회혼란, 건강의 해악)

우선 Condition혹은 Situtation이 나오고 그후 <So, what?>에 해당하는 답인 Cost에 해당하는 설명이 나와야 한다.
<blockquote>
However, the
aliased-based OTA<condition> introduces a notable performance overhead
due to frequent system calls (one syscall for each allocation or
free) <so, what?>.
</blockquote>

Problem은 크게 두개의 종류로 나누어진다.
# Practical problem: Action을 요구하는 문제이다. 이 문제는 해결해야 하는 문제로, 특정 행위를 해서 해결해야 한다. 예를 들어서, 술을 먹는 학생들이 일으키는 문제를 해결하기 위한 방안들은 Practical problem이다.
# Conceptual problem: Understanding를 요구하는 문제이다. 이 문제는 밝혀내야 하는 문제로, 이해를 통해서 해결해야 한다. 예를 들어서 술을 먹는 학새들이 왜 술을 먹는가에 대한 문제는 밝혀내야 하는 문제이다.

이 두 종류는 해결하고자 하는 문제의 종류가 다르기 때문에, 과연 내 문제가 두 종류중 어느것에 속하는지를 알아내는 것이 Motivation을 쓰기 전에 생각해야할 중요한 문제라고 할 수 있을것이다.

=== Part 3: Starting the Solution ===
Solution은 이제 본격적으로 우리가 주장하고 싶은 바이다.
; Practical Problems: WHat We Should Do
: Practical problem을 해결하기 위해서 저자는 독자에게 '''어떠한 행위'''를 해야 함을 주장해야 한다.

; Conceptual Problems: What We Should Think
: Conceptual problem을 해결하기 위해서 저자는 독자에게 '''이해 혹은 믿음(Understand or believe)'''를 해야 함을 설득해야 한다.

<blockquote>
This paper introduces BUDAlloc, presenting a new design
approach for the practical implementation of OTA. BUDAlloc
aims to strike a balance between performance and memory
overhead while providing strong UAF bug detectability<solution/point>.
BUDAlloc does not compromise compatibility, allowing unmodified
binaries to use BUDAlloc by simply replacing the default
allocator using LD_PRELOAD.
The core idea of BUDAlloc consists of two parts: separating
virtual address from in-kernel memory management, and
co-designing a one-time-allocator and virtual address management
at the user-level. <solution/point>
</blockquote>

=== Another Part: Prelude ===
위에 설명한 것 이외에, Skillfull한 저자들은 다음의 장치를 이용해서 보다 확끄는 Introduction을 작성하기도 한다.
# A Quotation: 인용 E.g., "호의가 계속 되면 권리인줄 알더라 - 고길동"
# A Startling Fact: E.g., "구체형 지구의 둘레는 약 4만 km라고 배운다. 만약 4만 km로 구체 지구가 정말로 맞다면, 5km만 지나도 굴곡이 생기기 시작해야 한다. 하지만 지구는 그렇게 생기지 않았다. 수십, 수백 km를 지나도 땅은 평평하다."
# An illustrative anecdote: "내가 피행기에 타보니깐, 지구의 표면이 둥글게 보이는게 아니라 평평하게 보이더라"

== Introduction을 개조하는 법 ==
# 문제가 Practical problem인지 아니면 Conceptual problem인지를 구분한다.
# Introduction이 끝나는 부분을 명확히 한다.
# Introduction을 shared context + problem + solution/main point/claim의 세 부분으로 나눈다.
# Shared context뒤에 But, However과 같은 단어를 사용해서 shared context에서 challenge하려는 문제가 무엇인지를 명확히 한다.
# Problem을 condition과 cost로 나누어 설명한다.
# Introduction말미에, solution/main point/claim을 명확히 강조하며 끝을낸다.

== Conclusion 작성법 ==
Conclusion은 글의 요점, 중요성, 그리고 암시하는 바를 문제와 함께 다시한번 정리해야 한다. Conclusion은 Introduction보다는 정형화 되어 있지 않지만, Introduction의 순서를 반대로 하는 것으로 어느정도 흐름을 잡을 수 있다.
; 간단한 요점, 주장, 그리고 해결방안으로 시작한다.
: This paper presents a practical OTA designed by separating
virtual and physical address management and by co-designing
one-time-allocator and virtual address management at the user-
level.

; 중요성을 다시하번 강조한다. So, What?
: BUDAlloc showcases well-rounded results in terms of
performance, memory use, scalability, and bug detectability
compared to FFmalloc, DangZero, and MarkUs.

; 추가적으로 필요한 이야기를 제시한다. Now What?
; Prelude에서 말한 3가지 요소를 마지막으로 마무리 한다.

보통 Computer sience논문에서는 아래 두 요소는 생략하는 것 같다.

Motivation - 편집 역사

2025년 4월 4일 (금) 05:45에 Ahn9807님의 편집

2025년 1월 15일 (수) 10:19에 Ahn9807님의 편집